hirschenberger/modbus-rs

Modbus implementation in pure Rust

modbus-rs's Issues

Transport implementing Clone

Is it possible to make Transport impl Clone ?
I want to read a lot of registers constantly without having to keep reopening a socket.
I thought it would be useful to keep the transport alive to reuse ?
Thanks

MODBUS_MAX_READ_COUNT and MODBUS_MAX_WRITE_COUNT are hardcoded

Don't know if it is possible: It would be nice to make them configurable somehow.

I know that my controller certainly accepts 56 words after the header (7d/125 in total), however MODBUS_MAX_WRITE_COUNT is hardcoded to be 79/121

Implement coil/discrete input read functions

What would it take to get these into the library?

MODBUS/TCP Security support

Hi. Congrats for the project.
Is it possible to add support for the new specification, the Modbus TCP Security, based on TLS?

Some of new protocols based on modbus are migrating for this modbus version, as the sunspec modbus protocol. The specification is available at:

Thanks in advance.
Gustavo Denardin

CTP client to use RTU framer

Sometimes there are situations in which we connect to RTU devices over TCP, relayed by socat command like;

sudo socat -d -d -d tcp-l:502,reuseaddr,fork /dev/ttyS3,raw,b9600,nonblock,waitlock=/var/run/ttyS3.lock

In this case, modbus payloads must be interpreted by RTU Framer, not TCP Framer.
Pymodbus library offers this flexibility by passig framer argument to Client class when instantiating one.
https://pymodbus.readthedocs.io/en/latest/source/library/framer.html
https://pymodbus.readthedocs.io/en/latest/source/library/client.html#pymodbus.client.ModbusBaseClient

Can we do the equivalent in modbus-rs library?
I'd love to contribute by implementing this so I read the source code, only to find I'm not that good at Rust yet 😔

Many thanks in advance. I highly appreciate the robustness and performance modbus-rs offers 😘

How specify the Unit ID to connect with?

Hi, thanks for your effort on this lib.

I'm trying to figure out where can be specified the Unit ID in order to select a slave device to connect with.

Cheers!

disconnecting the client

At the moment the client disconnects automatically because of the implemented Drop trait. But if something fails, I have no chance to catch the error :(
What about using a close method that returns a Result ?

Use libmodbus unittest server code

Use the libmodbus unittest code for testing.

https://github.com/stephane/libmodbus/tree/master/tests

error due to modbus-test-server

Using the modbus crate causes this Cargo error:

error: Package `modbus v0.4.1` does not have these features: `modbus-test-server`

Clarification of `read_holding_registers` result

Hey there,
I'm currently using your awesome library to write a proof of concept for one of our customers. While I can already read out my desired variables, the docs do not really provide guidance on how to convert the Vec<u16> result of read_holding_registers to a single float value. I tried

let res = ((vec[0] as i32) << 16) | (vec[1] as i32));

but this does not seem to work.

Also, I noticed that you are using the byteorder crate to read out the big endian ordered modbus data, but I don't really get whether the representation is still big endian.

Serial ASCII and RTU?

Hi,

it would be very great to get serial support ASCII and RTU from your crate, please.

Proposal: add support for modbus-RTU (and serial ports)

I'd like to contribute a module, initially modeled on the existing tcp module, for supporting modbus RTU communication over a serial port. I have plenty of hardware to test and verify on, and I think this would be a really useful extension of what is already a great contribution to the ecosystem.

Is this something you'd be interested in?

Remove dependency on "diagslave" in tests

I tried running "cargo test" on my MacBook, and got an error when a test attempted to run this program, which is for 32-bit Linux systems. I understand it was probably just added for quickness, but portability will be important; having binaries in Git repos is generally bad form; and depending on a non-FOSS program feels "icky" :)

Proposal: Functions for dealing with multi-register values

Commonly, Modbus utilizes values that are represented by multiple registers (IEEE 32-bit Float being the most common). Would there be any interest in including this higher-level functionality? If so, what thoughts are there on how to implement this? I've accomplished this in my own projects by implementing traits on f32 and u32 that provide T::to_registers(self) -> [u16;2] and T::from_registers([u16;2]) -> T. For a more general implementation, there would need to be a way to specify either low or high word order. Any input here is appreciated.

byteorder big, wordorder little

I am porting some code from python to rust. In python I write:

    decoder = BinaryPayloadDecoder.fromRegisters(
            r.registers, byteorder=Endian.Big, wordorder=Endian.Little)

In rust, I write:
let buf = binary::unpack_bytes(&registers);

The problem is, that even when specifying the "word order" here, it wouldn't work, because it needs to be applied on a per register basis. So currently, I read 8 and 16 bit values directly from the buffer, while I hacked this helper function for 32 bit values:

    fn read_big_little_i32<R: Read>(mut inbuf: R) -> Result<i32> {
        let a = inbuf.read_u8()?;
        let b = inbuf.read_u8()?;
        let c = inbuf.read_u8()?;
        let d = inbuf.read_u8()?;
        let buf = &[c, d, a, b];
        (&buf[..]).read_i32::<byteorder::BE>()
    }

Am I missing something here? Can this be done simpler? :-)

Best approach to read out multiple registers simultaneously

Hey there,
I was just wondering whether there is any best practice approach on reading out multiple registers at once.

My current implementation comprises a vector of ModbusRegister structs, each comprising a field named register. I then iterate of this vector after 200 ms have passed since the most recent read out and call read_holding_registers on my client struct, passing in the appropriate register. As this strikes me as a pretty ugly implementation (while getting the job done), how you would handle this.

Reading in the range of numerically first and last register and then slicing the Vec<u16> in appropriate pieces seems somewhat cumbersome as well.

Best,
Deniz

Server implementation?

How difficult do would it be to extend this to support creating Modbus servers/slaves?

Error info is not detailed enough

I had to download source manually and add some debug println!s into modbus-rs to track the actual reason for InvalidData. Maybe to provide some enum value or extra string.

Don't ignore errors in `scoped` drop functions

See #10

CC: @flosse