Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modbus RTU - Serial Direction Pin #229

Open
ViliamVadocz opened this issue Dec 8, 2023 · 8 comments · May be fixed by #289
Open

Modbus RTU - Serial Direction Pin #229

ViliamVadocz opened this issue Dec 8, 2023 · 8 comments · May be fixed by #289

Comments

@ViliamVadocz
Copy link

ViliamVadocz commented Dec 8, 2023

Is it possible to configure a serial direction pin when using Modbus RTU?

I am communicating between a Raspberry Pi 4 and a CLM8 Intelligent Junction Box (load cell amplifier).
I am sending using UART which gets converted to RS485 with MAX485. I think I need to set a specific pin high/low based on whether I am transmitting or receiving. Would it be possible to do this within this library?

I am able to access the pins using rppal, but I would think you would juse use OutputPin from embedded_hal in your interface.

Related issues in another library: emelianov/modbus-esp8266#62

@ViliamVadocz
Copy link
Author

For anyone who finds themselves in a similar situation: I used rmodbus instead which is a bit more verbose, but lets me change pin voltage between writing and receiving over UART.

@fredrik-jansson-se
Copy link

@ViliamVadocz, I'd also be interested in this. Could you by any chance share some (pseudo) code on how you used rmodbus to accomplish this?

@ViliamVadocz
Copy link
Author

ViliamVadocz commented Mar 4, 2024

@fredrik-jansson-se

Pseudocode:

let mut direction_pin = gpio.get(DIRECTION_PIN)?.into_output();
let mut modbus_request = ModbusRequest::new(SLAVE_ADDRESS, ModbusProto::Rtu);

let mut request_buffer = Vec::new();
let mut response_buffer = Vec::new();
let mut uart_buffer = [0u8; 128];

// example: get registers
modbus_request.generate_get_holdings(address, num_registers, &mut request_buffer)?;

direction_pin.set_high();
uart.write(&request)?;
// sleep (~ 1ms) to let device see that the pin is high and read data
direction_pin.set_low();
// sleep (~ 10ms) to let the device process request and send response

let read = uart.read(&mut uart_buffer)?;
modbus_request.parse_u16(&uart_buffer[..read], &mut response_buffer)?;
// use data in `response_buffer`

Of course, be sure to .clear() the Vecs and .fill(0) the UART buffer before or after use.

@fredrik-jansson-se
Copy link

Fantastic, thank you!!

@amreo
Copy link

amreo commented Apr 26, 2024

@fredrik-jansson-se

Pseudocode:

let mut direction_pin = gpio.get(DIRECTION_PIN)?.into_output();
let mut modbus_request = ModbusRequest::new(SLAVE_ADDRESS, ModbusProto::Rtu);

let mut request_buffer = Vec::new();
let mut response_buffer = Vec::new();
let mut uart_buffer = [0u8; 128];

// example: get registers
modbus_request.generate_get_holdings(address, num_registers, &mut request_buffer)?;

direction_pin.set_high();
uart.write(&request)?;
// sleep (~ 1ms) to let device see that the pin is high and read data
direction_pin.set_low();
// sleep (~ 10ms) to let the device process request and send response

let read = uart.read(&mut uart_buffer)?;
modbus_request.parse_u16(&uart_buffer[..read], &mut response_buffer)?;
// use data in `response_buffer`

Of course, be sure to .clear() the Vecs and .fill(0) the UART buffer before or after use.

What is uart in this pseudocode?

@fredrik-jansson-se
Copy link

@amreo, full disclouse, I ended up hacking this demo in Python. But I assume the uart instance is e.g. an instance of SerialPort from https://crates.io/crates/serial.

Does that help?

@uklotzde
Copy link
Member

This is a valid use case. Unfortunately the current, method-style request/response API does not support to inject custom code between sending the request and receiving the response.

If anyone has ideas how the API could be modified or extended to support this use case, please make a proposal. A low-level API that decouples sending and receiving would be an option. Ideally, these low-level methods would be invoked and reused by the existing high-level API.

@uklotzde
Copy link
Member

Please check if #289 enables your use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants