diag_query_data might not be working as expected for msg-parameter length of one or two bytes #2451
Replies: 3 comments 8 replies
|
Thanks I will try to simulate your device responses. 32 bytes is a magical limit for a number of rs485 usb devices, so it's normal the message will be received in chunks, however pymodbus should assemble the, and present a complete response.....it not, then please make a short debug log so I have something to simulate. |
|
For the ~>32 byte investigation: It works intermittently. Minimal example: Debug log when it works: When it fails it looks like this: |
|
Hmm it fails because the package is split over multiple receives. Return query do not have a length field, which makes it especially difficult to find the end of the message (and whether everything was received). The sync version of pymodbus makes it even harder, but feel free to submit an issue if you find it to be a real problem. |
|
It is not really a problem to me given that I only use pymodbus for testing purposes and the command is a diagnostics command only. Knowing that it most likely happens on the computer side is sufficient for me. Only reason to try and improve on it would be to avoid other users potentially running into similar issues. I'm happy to resubmit as an issue if you think it makes sense - it being listed in Issues even if it is not being fixed might already help people who encounter it. |
|
Please look at the the modbus standard, "return query data" have a data field of minimum 2 bytes and it must be a multiple of 2. So sending 0, 1 or 3 bytes are not allowed. |
|
I'm looking at MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3 - Is this the same document you are working off? I didn't see this limitation. I found the fact that it should be even in tables now. Data: N x 2 Bytes. I didn't find that 0 is disallowed. Interestingly (even so not part of the standard) everything seems to work fine for larger odd numbers (tested for 3 bytes). Personally I think that behavior is ok as the standard doesn't name this as a case that should raise an Exception. |
|
The standard defines the data as N * 2 so odd numbers are clearly outside the standard. No data defies the purpose of the command, which is to return the data. If you want the code to work differently please submit a pull request. |
|
Thank you. I'll have a go at it later if time permits. |
|
I don't quite agree with no data defying the purpose of the command as I'd see it as the a likely candidate if I was looking for a command to do a "ping". |
|
be my quest to have opinions.....but please do not forget that a large number of devices do not implement diagnostics, traditionally you use read_coils as ping, because all devices implement that. Having opinions is very valid, but it might also be beneficial to listen to people who have a lifetime experience with the protocol. |
|
if you want a check on the input data, then pull requests are welcome. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
When testing the diagnostics function on a serial connection to a hardware device I find that for most messages of two bytes or longer it works as expected. For single byte or zero byte messages an error is generated instead. It looks like the replies are discarded because they are considered to be to short.
This is using the dev branch (couple of days old pull) of pymodbus.
Test code:
Debug messages:
Side note: For long test messages (~> 32 bytes) the reply sometimes gets truncated. Still investigating if that happens in my hardware or in pymodbus.
All reactions