-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
TCP: behaviour for "unit identifier == 0" makes little sense. #376
Comments
mhei
added a commit
to mhei/libmodbus
that referenced
this issue
Apr 7, 2017
According to the Modbus standard, the unit identifier is choosen by the TCP client and can be any value: "This field is used for intra-system routing purpose. It is typically used to communicate to a MODBUS+ or a MODBUS serial line slave through a gateway between an Ethernet TCP-IP network and a MODBUS serial line. This field is set by the MODBUS Client in the request and must be returned with the same value in the response by the server." So the current check in modbus_reply must be extended to check whether we are in a RTU or TCP context. Also the unit-test has to be adjusted. Signed-off-by: Michael Heimpold <[email protected]>
I would agree that this is a bug because as of my understanding the unit identifier can take any value. This is because a broadcast does not make sense in a TCP context - only when the Modbus server is a "Modbus TCP to RTU proxy"... |
Yupp, looks good! |
georgidimov
pushed a commit
to georgidimov/libmodbus
that referenced
this issue
Jul 24, 2017
According to the Modbus standard, the unit identifier is choosen by the TCP client and can be any value: "This field is used for intra-system routing purpose. It is typically used to communicate to a MODBUS+ or a MODBUS serial line slave through a gateway between an Ethernet TCP-IP network and a MODBUS serial line. This field is set by the MODBUS Client in the request and must be returned with the same value in the response by the server." So the current check in modbus_reply must be extended to check whether we are in a RTU or TCP context. Also the unit-test has to be adjusted. Signed-off-by: Michael Heimpold <[email protected]>
epsilonrt
pushed a commit
to epsilonrt/libmodbus
that referenced
this issue
Jun 19, 2023
According to the Modbus standard, the unit identifier is choosen by the TCP client and can be any value: "This field is used for intra-system routing purpose. It is typically used to communicate to a MODBUS+ or a MODBUS serial line slave through a gateway between an Ethernet TCP-IP network and a MODBUS serial line. This field is set by the MODBUS Client in the request and must be returned with the same value in the response by the server." So the current check in modbus_reply must be extended to check whether we are in a RTU or TCP context. Also the unit-test has to be adjusted. Signed-off-by: Michael Heimpold <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
libmodbus version
3.1.4
OS and/or distribution
Linux (ArchLinux)
Environment
64 bit
Description
I sent a message using ModbusTCP with a "unit identifier" of 0.
Expected behaviour
A response to the message.
Actual behaviour
No response is sent.
Suspected place of bug
I think the bug is here. I'm guessing, without having studied the code in detail, that the TCP request frame is scaled down to match an RTU frame. This means that the "unit identifier" has the same location as "slave address". The line I pointed to will drop responses for "slave address == 0".
This behaviour is, AFAIU, not according to standard. I can also not find any documentation of it.
The text was updated successfully, but these errors were encountered: