main.rs

extern crate futures;
extern crate tokio_core;
extern crate tokio_modbus;
extern crate tokio_serial;

use tokio_core::reactor::Core;
use futures::future::Future;
use tokio_serial::{Serial, SerialPortSettings};
use tokio_modbus::*;

pub fn main() {
    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let port_path = "COM1";
    let server_addr = 0x01;

    let mut settings = SerialPortSettings::default();
    settings.baud_rate = 19200;
    let mut port = Serial::from_path(port_path, &settings, &handle).unwrap();
    port.set_exclusive(false).unwrap();

    let task = Client::connect_rtu(port, server_addr, &handle).and_then(|client| {
        println!("Reading a sensor value");
        client
            .read_holding_registers(0x082B, 2)
            .and_then(move |res| {
                println!("Sensor value is: {:?}", res);
                Ok(())
            })
    });

    core.run(task).unwrap();
}

Cargo.toml

[dependencies]  
futures = "*"  
tokio = "*"  
tokio-core = "*"
tokio-serial = "*"
tokio-service = "*"
tokio-modbus = { version = "*", default-features = false, features = ["rtu"] }

Results

C:/Users/test/.cargo/bin/cargo.exe run --package modbus_test --bin modbus_test
   Compiling tokio-modbus v0.2.1
error[E0432]: unresolved import `tokio_serial::Serial`
 --> C:\Users\test\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-modbus-0.2.1\src\service\rtu.rs:3:5
  |
3 | use tokio_serial::Serial;
  |     ^^^^^^^^^^^^^^^^^^^^ no `Serial` in the root

error[E0432]: unresolved imports `tokio_serial::Serial`, `tokio_serial::SerialPortSettings`
 --> C:\Users\test\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-modbus-0.2.1\src\client.rs:9:20
  |
9 | use tokio_serial::{Serial, SerialPortSettings};
  |                    ^^^^^^  ^^^^^^^^^^^^^^^^^^ no `SerialPortSettings` in the root
  |                    |
  |                    no `Serial` in the root

error[E0433]: failed to resolve. Could not find `tcp` in `proto`
  --> C:\Users\test\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-modbus-0.2.1\src\server.rs:75:39
   |
75 |                 TcpServer::new(proto::tcp::Proto, addr)
   |                                       ^^^ Could not find `tcp` in `proto`

error[E0277]: the size for values of type `dyn futures::Future<Item=frame::Response, Error=std::io::Error>` cannot be known at compilation time
  --> C:\Users\test\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-modbus-0.2.1\src\service\rtu.rs:52:9
   |
52 |         Box::new(result)
   |         ^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `std::marker::Sized` is not implemented for `dyn futures::Future<Item=frame::Response, Error=std::io::Error>`
   = note: to learn more, visit <https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
   = note: required by `<std::boxed::Box<T>>::new`

error[E0277]: the size for values of type `dyn futures::Future<Item=frame::Response, Error=std::io::Error>` cannot be known at compilation time
  --> C:\Users\test\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-modbus-0.2.1\src\service\rtu.rs:40:13
   |
40 |         let result = self.service.call(req).and_then(move |resp| {
   |             ^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `std::marker::Sized` is not implemented for `dyn futures::Future<Item=frame::Response, Error=std::io::Error>`
   = note: to learn more, visit <https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
   = note: all local variables must have a statically known size
   = help: unsized locals are gated as an unstable feature

error: aborting due to 5 previous errors

Some errors occurred: E0277, E0432, E0433.
For more information about an error, try `rustc --explain E0277`.
error: Could not compile `tokio-modbus`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

We have been using this library a lot here at omnio and are working on updating our code base to use the new async features. We have already helped update tokio-serial here and would love to see tokio-modbus updated as well. We internally built an updated version of tokio-modbus, and you can find the changes in this PR.

This pull requests still needs some polishing, but we would like to hear your opinion on the direction we've been taking the library before continuing the implementation, especially regarding the removal of tokio-proto, which has a certain impact on the external api:

1. Several methods now require &mut self instead of &self.
2. These methods also borrow self inside the returned future.

The tokio-proto crate previously supplied a layer that uses interior mutability to put requests in a queue and later dispatch the results to the appropriate future. As proto is now gone, this dispatching mechanism is also gone, which means that we instead have to rely on mutable borrows to ensure at compile time that at most a single modbus request exists per connection at any time.

The disadvantage of modifying the api in this way is that it can be harder to use the api: previously you were able to just create a bunch of requests and await them all. Now you must create the next request when the preceding one finishes.

Luckily it also turns out that the introduction of async makes the kind of loop described above much easier to write: The introduction of pin makes futures that borrow from the modbus context usable, and the ability to write a loop in async code avoids certain issues with using for_each to create the requests.

// example of using a loop to read many requests.
let requests_i_want = vec![...];
let results = Vec::with_capacity(requests_i_want.len());
for request in requests_i_want {
    let result = modbus_context.call(request).await?;
    results.push(result);
}
return results;

There are also quite a few traits that return a Pin<Box<...>>. It would be nice to use associated types in the traits to return non-heap-allocated futures instead, but we have not looked into implementing that yet.

When trying to cross-compile this crate for a Raspberry Pi (armv7-unknown-linux-gnueabihf), the libudev dependency of tokio-serial failed to build.

I considered two ways of addressing this: Either set up proper cross-compilation for libudev, or remove it as a dependency. I tried the latter, and it appears that libudev is not needed as a dependency in this project.

When you run the example in Windows 10 and there is no response to reading the registers from the device, the program just hangs without returning an error. Is it possible to set a read/write timeout?

Some technical changes for the next evolution of the API:

• New prelude module that includes all public exports
• Isolate features in submodules
  • rtu / tcp
  • sync
• Split ModbusClient trait into Client + Reader + Writer traits
• Rename Client into Connection
  • synchronous / asynchronous
• Provide various connect() functions in submodules for establishing client connections
  • TCP / RTU
  • synchronous / asynchronous
• Move TCP server into submodule
• Client: Switch between different slaves dynamically at runtime

Migration instructions can be found in CHANGELOG.md and the examples reflect what users of this crate might need to change.

Maybe we should declare the server-side as experimental? Currently users are not able to control the TCP server instance once it has been attached to a port. This will hopefully change when we replace tokio-core and tokio-proto.

• I wanted to give to give the Modbus RTU client examples a test drive but failed in both cases
  • rtu-client-sync.rs panics with

    $ cargo run --features rtu,sync --example rtu-client-sync
       Compiling tokio-modbus v0.5.2 (/.../tokio-modbus)
        Finished dev [unoptimized + debuginfo] target(s) in 0.85s
         Running `target/debug/examples/rtu-client-sync`
    thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', /.../.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.0/src/runtime/context.rs:29:26
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    

• Is this examples expected to run out of the box?
• What could I do to actually get it running?
• At a first first glance into context.rs:29 it looks like borrowing from CONTEXT fails and I bet there is some initialization missing. But this is my first contact with Tokio and I have no idea about the what, how, and why.

Adds RTU server functionality based on #72

This PR simply replicates that previous proposal that was sidelined by the #78 merge, but updated to compile based on the changes in tokio-serial.

Functionality has absolutely not been field-tested by me (beyond the provided example code), and since I have no practical use-case for an RTU server application, I'd ask someone more involved in this field (like @efancier-cn @ivomurrell or @david-mcgillicuddy-moixa) to do the necessary validations.

Closes #73

The type aliases that are defined in the code are not visible in the documentation, so it's better to have an explicit documentation.

Here is what the current documentation looks like on docs.rs: https://docs.rs/tokio-modbus/0.3.5/tokio_modbus/prelude/enum.Request.html

The type aliases such as Address, Coil, Quantity, etc. are not visible in the documentation.

Hello,

Last week (11th June) I have been testing 'tcp-server.rs' from 'slowtec/tokio-modbus/examples' and there is some kind of issue related to 'tcp' and 'server' features. If you try to compile 'tcp-server.rs' you will receive an error and I think that it comes from the feature 'server'. It is like it cannot be found even writing it in 'dependencies' in 'Cargo.toml'

However, I tried 'tcp-server.rs' tag v0.3.5 and it runs without problem.

Now that tokio 1.0 is finally out, it seems like a good time to upgrade to the stable version so that other projects can use tokio-modbus after upgrading to tokio 1.0. Currently using the tokio 1.0 update for tokio-serial that is still in PR form so will have to treat this as a draft until that is merged and published. Nevertheless, seems like a fairly straightforward migration!

Closes #71

Target: ARMv7 (musl)

I have a warp webserver that upon a request will open a connection and read some registers, and I want the connection to close after the registers are successfully read. Using the async API, I expected the TCP client connections to close when contexts are dropped, but they do not (netstat shows them in established state). I tried Context::disconnect, but that causes a panic ('internal error: entered unreachable code'). What is the correct way to disconnect the TCP connection?

let read_input_registers = get2()
        .and(path!("rir" / u16 / u16)
        .and(path::end())
        .and_then(move |start, count|{
            let (p, c) = futures::sync::oneshot::channel::<String>();
            remote.spawn(move |handle|
                client::tcp::connect(handle, localhost)
                .and_then(move |ctx| ctx.read_input_registers(start, count)/*.and_then(move |res| ctx.disconnect().then(|_| Ok(res)))*/)
                .then(|res|{
                    p.send(match res{
                        Ok(data) => format!("{:?}", data),
                        Err(err) =>  format!("{:?}", err)
                    }).unwrap_or(());
                    Ok(())
                })
            );
            c.map_err(|err| warp::reject::custom(err))
        }));

I've switched to the modbus crate until I can figure this out. I'd prefer to use this one since it's non-blocking.

Only use tokio and tokio-modbus, and run the tcp-client example code, but show Fetching the coupler ID

Reproduction:

1. cargo new a new project
2. add tokio-modbus = "0.5.3", tokio = {version = "=1.22.0", features = ["full"]} to Cargo.toml
3. copy the example tcp-client code to main.rs
4. run cargo build, success, but cargo run show:

D:\xxx\yyy>cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.11s
     Running `target\debug\tokio-modbus.exe`
Fetching the coupler ID

Environment: Win10 rustc 1.65.0 (897e37553 2022-11-02) rustup 1.25.1 (bb60b1e89 2022-07-12) x86_64-pc-windows-msvc Modbus server use the Qt QModubs example's modbusslave.exe, with the configuration: tcp, 127.0.0.1:502 (modbusmaster.exe can work well)

When I add tokio-modbus as a dependencies, cargo build will failed.

Reproduction:

1. cargo new a new project
2. add tokio-modbus = "0.5.3" to Cargo.toml
3. copy the example tcp-client code to main.rs
4. run cargo build, and show:

   Compiling mio-serial v5.0.3
error[E0308]: mismatched types
   --> C:\Users\dell\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\mio-serial-5.0.3\src\lib.rs:822:42
    |
822 |         let r = unsafe { SetCommTimeouts(handle, &mut timeouts) };
    |                          --------------- ^^^^^^ expected enum `winapi::ctypes::c_void`, found enum `std::ffi::c_void`
    |                          |
    |                          arguments to this function are incorrect
    |
    = note: expected raw pointer `*mut winapi::ctypes::c_void`
               found raw pointer `*mut std::ffi::c_void`
note: function defined here
   --> C:\Users\dell\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\winapi-0.3.9\src\um\commapi.rs:74:12
    |
74  |     pub fn SetCommTimeouts(
    |            ^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `mio-serial` due to previous error

Environment: Win10 rustc 1.65.0 (897e37553 2022-11-02) rustup 1.25.1 (bb60b1e89 2022-07-12) x86_64-pc-windows-msvc

I was investigating a problem and noticed that we could trigger the modbus lib to 'collect' multiple Modbus ADUs into a single TCP PDU.

This is from Wireshark showing the trace between the client (a nodejs script for testing purposes) and the server (baked with tokio-modbus):

Notice that packet 113 has multiple responses, which can be viewed:

I am pretty sure that this behavior is causing a problem for one of our customers, who is using a PLC which does support a list of Modbus ADUs in a single TCP PDU. In the other cases our customers PLCs must be waiting for the reponse before making a new request.

From the Modbus_Messaging_Implementation_Guide_V1_0b.pdf in your README, it seems that this should not be done at all. At page 10:

This fix is simply to disable Nagle's algorithm by setting nodelay = true. This can not be done the tokio::net::TcpListener directly so I was forced to use from_std and constructing a standard socket.

I was considering making the nodelay a setting, but as it advised not to use it in the document above, I think it should be standard.

This is what it looks like after the fix. Note that packet 102 / Transaction 5 has 3 requests (Modbus ADUs) in it. The Decoder is perfectly cable of handling this response .

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: https://modbus.org/docs/MB-TCP-Security-v21_2018-07-24.pdf

I beleive it can be implemented based on tokio-rustls.

Thanks in advance. Gustavo Denardin

Hi, is it possible to pass a f32 float with quantity 2 via two u16 registers and only get 2 buffer values? When I pass 2 u16's into the input register vector, it returns 4 buffer values in my modbus client.