You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For an RTU server, it's important to know a request's unit ID when the devices are on a bus. For example, on an RS-485 bus, all devices will receive all requests but only the intended receipient should send a reply.
For a TCP server, knowing the request's unit ID allows implementing logical devices or the implementation of a gateway that forwards a request to an RTU device.
The rtu and tcp server implementation already have the unit id readily available in the Header struct that they get in a frame:
The text was updated successfully, but these errors were encountered:
fdlg
changed the title
Server::Service trait has not mechanism to obtain request's unit ID from call implementation
Server::Service trait has no mechanism to obtain request's unit ID from call implementation
Aug 25, 2021
fdlg
changed the title
Server::Service trait has no mechanism to obtain request's unit ID from call implementation
Server::Service trait has no mechanism to obtain request's unit ID in call implementation
Aug 25, 2021
For an RTU server, it's important to know a request's unit ID when the devices are on a bus. For example, on an RS-485 bus, all devices will receive all requests but only the intended receipient should send a reply.
For a TCP server, knowing the request's unit ID allows implementing logical devices or the implementation of a gateway that forwards a request to an RTU device.
The rtu and tcp server implementation already have the unit id readily available in the
Header
struct that they get in a frame:tokio-modbus/src/server/rtu.rs
Lines 89 to 90 in 996511c
tokio-modbus/src/server/tcp.rs
Lines 147 to 148 in 996511c
The first potential solution that comes to mind is modifying
Server::Service::call
's signature to this:The text was updated successfully, but these errors were encountered: