How to interpret Modbus error code: EA 0B

W

Thread Starter

Weimin Chen

I have a Digi (Model: Connect WAN 3G IA) connected between a Modbus PLC and my Scada server. The protocol between Digi and the server is Modbus TCP, and Modbus RTU is used between the Digi and the PLC. When I poll a small range of registers, I got good data back. But if I poll one or more registers beyond the range, even though the new range is still valid, I got a bad response: 03 01 EA 0B.

How to interpret these error code: EA 0B?

I suspect the Digi caused the problem when it translated the data.

Thanks.
 
L

Lynn August Linse

It is easy to see where the strange response is from - check out this web page, which shows how to see a trace within the Digi showing all bytes.
http://digitips.wikispaces.com/Seeing+Modbus+slave+response+times+in+Digi+IAP

Use the command "set trace state=on mask=ia:i+d" and you should see all bytes received and send via the Digi.

It is possible the PLC is returning that answer - some devices have configurable internal ranges which return 'no data' even if you poll 1 or 20 or 100 registers. You would think the byte count of zero would still be there. Anyway, check out the trace.
 
W
Thanks a lot for your good info! Now I got some idea about the problem: it must be the Slave Timeout value on the Digi is too small, and it didn't get PLC resp.

In my trace log, the max resp time is max:1005 msec, hitting the slave timeout value! I'll try to change the value and see.

#> set trace state=on mode =concurrent mask=ia:i+w+d
#>
#> 9366838:ia:INFO:mbtcp:m02 recv req 99
9366838:ia:DEBG: 00 E5 00 00 00 06 01 03 A0 87 00 04
9366840:ia:INFO:mbrtu:CH01 send req 99
9366840:ia:DEBG: 01 03 A0 87 00 04 D6 20
9367855:ia:WARN:mbrtu:CH01 slave timeout error
9367857:ia:INFO:mbtcp:m02 send resp 99
9367857:ia:DEBG: 00 E5 00 00 00 03 01 EF 0B
9367858:ia:INFO:mbtcp:m02 full rsp min:118 avg:762 max:1005 msec
9368086:ia:DEBG:MBRTU: Estimated Rsp length is 21
9368086:ia:WARN:mbrtu:CH01 match request error
 
I dumped out the port setting parameters, and yes, slavetimeout = 1000. As soon as I changed that to 3000, I got data back. And I had to increase that again when the poll cmd included more registers.

However, when I did the same thing to another DIGI which also replies 0x0B error, I go both "Message timeout error" and "Slave timeout error":

714674346:ia:INFO:mbtcp:m03 send resp 54173
714674346:ia:DEBG: 00 8F 00 00 00 03 01 80 0B
714675955:ia:INFO:mbtcp:m02 recv req 54175
714675955:ia:DEBG: 31 2B 00 00 00 06 01 03 A0 86 00 03
714679903:ia:WARN:mbtcp:m02 message timeout error
714679904:ia:INFO:mbtcp:m02 send resp 54174
714679904:ia:DEBG: 31 2A 00 00 00 03 01 80 0B
714683416:ia:WARN:mbrtu:CH01 slave timeout error
714683417:ia:INFO:mbrtu:CH01 send req 54175
714683418:ia:DEBG: 01 03 A0 86 00 03 C6 22
714685955:ia:INFO:mbtcp:m02 recv req 54176
714685956:ia:DEBG: 31 2C 00 00 00 06 01 03 30 00 00 26
714685959:ia:WARN:mbtcp:m02 message timeout error
714685959:ia:INFO:mbtcp:m02 send resp 54175
714685959:ia:DEBG: 31 2B 00 00 00 03 01 80 0B
714693002:ia:INFO:mbtcp:m02 recv req 54177
714693003:ia:DEBG: 31 2D 00 00 00 09 01 10 A0 5D 00 01 02 00 03
714693425:ia:WARN:mbrtu:CH01 slave timeout error
714693427:ia:INFO:mbrtu:CH01 send req 54176
714693427:ia:DEBG: 01 03 30 00 00 26 CB 10
714695956:ia:WARN:mbtcp:m02 message timeout error
714695957:ia:INFO:mbtcp:m02 send resp 54176
714695957:ia:DEBG: 31 2C 00 00 00 03 01 80 0B

================ ia parameters ===============================================
set ia table=1 state=on name= family=modbus accessmode=multi ownerperiod=15000

set ia table=1 addroute=1
set ia table=1 route=1 active=on type=serial protaddr=0-255 port=1

set ia serial=1 type=slave protocol=modbusrtu slavetimeout=10000
set ia serial=1 chartimeout=200 lineturnmode=off fixedaddress=0 rbx=off
set ia serial=1 active=on

set ia master=1 active=on type=tcp ipport=502 protocol=modbustcp table=1
set ia master=1 priority=medium messagetimeout=10000 chartimeout=30000
set ia master=1 idletimeout=4500 lineturnmode=off errorresponse=on
set ia master=1 broadcast=replace

set ia master=2 active=on type=udp ipport=502 protocol=modbustcp table=1
set ia master=2 priority=medium messagetimeout=10000 chartimeout=50
set ia master=2 idletimeout=0 lineturnmode=off errorresponse=on
set ia master=2 broadcast=replace
 
L

Lynn August Linse

So it is the Digi making that code - the '80 0B' looks like a bug. I haven't actually looked at any of the Digi Connect Modbus products for like 5 years :)

Because of the 'bank customer queuing' model used, the relationship of the many timeouts can be difficult to grasp. You have multiple masters competing for bandwidth, so 1 master can 'starve' another (that is the "Message timeout error"). This often means you are sending too many requests and the serial-line is plugging up. For example with a 10 sec slave timeout, your master should NOT send more than 1 request per 10 seconds. Imagine a bank where 1 person enters per second, but the bank only finishes 1 customer every 10 seconds - it will lead to long lines!

Anyway, check out this link to read about the impact. ftp://ftp1.digi.com/support/documentation/90000649_a.pdf

Anyone else looking at creating Modbus/TCP to serial bridges needs to understand the basic concepts in that queuing model. I know the first generation of such bridges (like the Modicon CEV) just left the queue build - because of low memory, they left the queue in the TCP buffers and one could see the CEV poll the serial line for minutes after the master stopped polling (I witness a 20 minute lag at one site :-] ). The Digi model instead timestamps the requests (aka: the customers look at the watch), and then after the request has waited too long, it returns the 0x0B error even thought the request NEVER made it to the serial port (so is like the customer getting pissed at waiting and just leaves).

What is usually the best plan is to get the unit working in steady state with a large slave timeout, then allow it to run for a week. In that Digi trace you should see a min/max/avg response time printed after each good response. So if you start with a 10sec timeout, you might discover that by the end of the week the max is 0.9 sec, which means dropping it to 1.5 secs is wise. At other times you might see that the max is 6 seconds, so 8 or even 10 seconds is best. You often see long variable response times on products running Modbus as an option (often spoofed in a BASIC module). For example I worked on a brewery system with inspection machines, and anytime a bad bottle was seen, the Modbus port stopped responding, but kept receiving requests. So perhaps 6 second in the future, if you'd polled it 6 times (once per second), you'd get 6 responses returned with little gap despite the fact the host had only 1 outstanding request.
 
Top