Modbus Comm Bug

[Mikhail]

It’s a useful formula.
Just a note: you can simplify

if (ChannelErrors[CnlNum] >= n) {return double.NaN;}
else {return Val();}

to
return ChannelErrors[CnlNum] >= n ? double.NaN : Val();

[JW]

Hi Mikhail,

Recently when I implementing a TCP protocol, I encounter a problem with similar symptoms of this Modbus issue.

I am going to use the Modbus error as example. I label the following error message with line number.
————————————–
1. Request element group “ch1.011”
2. Send (12): 05 42 00 00 00 06 01 03 04 4C 00 64
3. Receive (7 / 7): 05 42 00 00 00 CB 01
4. Receive (202 / 202): 03 C8 42 0A 8A 3D 42 0A E6 66 42 0B 41 89 42 0B 9C AC ….
5. OK!
6. Request element group “ch1.012”
7. Send (12): 05 43 00 00 00 06 01 03 04 4C 00 64
8. Receive (0 / 7):
9. Communication error!
10. Request element group “ch1.012”
11. Send (12): 05 44 00 00 00 06 01 03 04 4C 00 64
12. Receive (7 / 7): 05 43 00 00 00 CB 01
13. Incorrect MBAP Header data!
14. Request element group “ch1.012”
15. Send (12): 05 45 00 00 00 06 01 03 04 4C 00 64
16. Receive (7 / 7): 03 C8 42 IA FC EE 42
17. Incorrect MBAP Header data!

18. 2021-01-11 23:28:40 Disconnect from 127.0.0.1
————————————–

Line 7 sent a request(05 43) but did not get proper reply.
Line 11 sent a new request(05 44). then line 12 receive data(05 43), but which is the reply of header of line 7 request(05 43). it was considered incorrect because it did not match with line 12 request.
Line 15 sent a new request again. then line 16 receive data, which is the body of the reply of header of line 7 request(05 43). it was considered incorrect again because it did not match with line 12 request nor the header format.

The reason I got this error is as follow. (I guess the Modbus driver may have similar issue but not sure).

For such small amount of data, I assumed it will be always receive at 1 try.
So I use sock.recv(7) to get header, then calculate the length of data from header, e.g. 0xCB = 203, the reset of data should be 203-1=202, then I use sock.recv(202) to get the rest of the data body.

But I found very rarely, it will only get e.g. maybe 100 bytes of data on sock.recv(202) or 5 bytes on sock.recv(7). This will not only create 1 error of incomplete reply, but also messed up the following sequence.

So I changed to use a while loop to receive data, to make I received the proper length of data. something like the sudo code below.

recv_data = bytearray()
while recv_data_length < expected_length:
recv_data += sock.recv(expected_length-recv_data_length)

[JW]

For error handling, in case any request and reply sequence get messed up, I am thinking the following approach.

after the error of line 7 and 8, I would run and wait an additional loop of sock.recv() for a period (maybe same time of timeout), and then discard of all the data of this recv. in the above case, it would get line 12 and line 16 and so on.

then send a new request of line 11, then the reply should be correct from now on.

[Mikhail]

Hi,
This mess of data can be caused by a too small timeout of the device polling. When old packet comes, the app is already sent the next request and waiting for the next reply.

[JW]

What does the following log mean? No reply within “Timeout” period or “Delay” period? Or socket throws an exception or receive an empty message?
8. Receive (0 / 7):
9. Communication error!

I still get this error from time to time, even the communication line is connecting to a virtual device on localhost. Sometimes it never happened in months, sometimes it happened a few times in an hour.

[Mikhail]

6. Request element group “ch1.012”
7. Send (12): 05 43 00 00 00 06 01 03 04 4C 00 64
8. Receive (0 / 7):
9. Communication error!

Item 8 waits for data during the timeout, expecting 7 bytes. No data was received.
Network does not guarantee 100% packet delivery.

[Author]

Posts