Due to an occasional communications problem with the Digi One, I upgraded the unit from firmware E to F. Recently the same problem arrose after 13 days in operation.
Architecture: SCADA Modbus master sends modbus message via TCP/IP to Digi One, Digi One translates modbus to Ethernet/IP, Digi One sends Ethernet/IP message via TCP/IP to SLC5/05. Response sent back to SCADA Modbus master through reverse route.
Performance: Appears to work very wonderfully, except on occassion.
Symptom: The SLC5/05 data being displayed on the SCADA Master will oscillate every transmission, typically every 1 second.
Data: The status of the data in the SLC5/05 is stable, not oscillating. However, the SCADA Master shows that 1 or many of the digital I/O points (coils) is oscillating.
Result: Rebooting the Digi One corrects the symptom and regains normal communications and status reporting.
Do I perhaps have some timeouts set incorrectly in the Digi One? What may be causing this communication glitch with incorrect status being reported? Attached is a copy of the backup configuration.
How often does the Modbus Master poll (roughly) - 10 times a second or once per 15 seconds.
For the SLC5/05, AB/Ethernet or CSPv4 is a much simpler protocol and will give cleaner results. The main problem with Ethernet/IP is it forces the connections to close fairly fast. If you really want to use Ethernet/IP, try the “class=ucmm” as this cuts out the CIP connection timeout.
There also are some ODVA “ambiguities” related to how UniData (ie: connected class 3 packets) are handled if the Encap Session times out but the TCP socket hasn’t closed yet. ODVA forbids the peer from returning an error response & so one risks a pair getting into a state where the connection is one-half down, but the activity keeps it “alive” eneough though no meaningful comms takes place. The “F” firmware fixes a bug when paired with the ENI Series C and newer that sees this.
Your error sounds like in some error condition the DOIAP is incorrectly returning all NULL data to the Modbus master instead of an exception response (so perhaps the oscillations only occur when bits are “1”?). I fixed such a situation when the slave doesn’t respond, but perhaps there is some Ethernet/IP error response that isn’t being correctly “mapped” to a Modbus exception response.
If you tell me your timing settings I can speculate more. My email is LynnL at you know who (ie: digi.com)For an exact answer, run an Ethereal trace of the DOIAP traffic showing MB->DOIAP and DOIAP->SLC5. You’ll need an old 10MB hub if your SLC5 is the older 10MB only style.
Or telnet to the DOIAP (use DOS window telnet on XP - the Hyperterminal on XP is broken in the name of security patches verse MS being too cheap to pay new royalties to the owner of HyperTerminal for a new rev) and run the “set trace state=on mask=ia:i+d+w” command. Be warned it dumps a hugh amount of data out and likely will drop many lines to prevent getting behind).
How often do you poll? Every 15 sec? Every 1 sec? 20 times per second?
I’d first suggest changing to use the SLC5/05’s native CSPv4 (we call AB/Ethernet) on TCP port 2222. This protocol is very much less work for both units, is less than half the network bytes, and avoids some timing issues Ethernet/IP suffers (wasn’t designed for poll-resonse).
I have a SLC5/05 - if you list what you are polling and at what rate, I can try the same setup here and perhaps see what you’re seeing (your oscillations).
Thanks for the direction. I have switched to AB/Ethernet from Ethernet/IP, and changed the timeouts from the previous values as listed below.
> What are your 3 main timeouts & poll rate?
> 1) The Modbus “Master” messagetimeout
was 5 sec.; now 500ms
> 2) The Ethernet/IP “route” slavetimeout
was 5 sec.; now 500ms
> 3) The Ethernet/IP “route” charactertimeout
was 1 sec.; now 100ms
> 4) How often does the Modbus Master poll (roughly) -
> 10 times a second or once per 15 seconds.
It is set for a 1 sec. timeout, but will poll as fast as it gets responses back from the modbus slave device(s).
Originally, I used the default timeouts, and had very bad com problems, so I extended the timeouts way out to get coms functionoing. Then I upgraded the firmware from ‘E’ to ‘F’, but kept the extended timeouts. I have also just upgraded the modbus master software, which I just found out may have been contributing to the com errors.
I’ll have to wait and see if the com problem arrises again. If it does I will attempt a data capture of the various ports using one of the methods you suggested.
You should bump your messagetimeout up to 600msec - this reduces the race condition of a “slave-timeout” and “master/messagetimeout” happening at the same time. The desired relationship is OPC/Tool timeout > DOIAP “messagetimeout” > DOIAP “slavetimeout” > DOIAP “chartimeout”. Plus I usually put both the OPC/Toll timeout and “messagetimeout” at 2.5 times the slavetimeout because that allows me to come in with a second “master” gracefully. Likely part of your problem before was your OPC/Tool (PLC in this case) timeout of 1 second was faster than the default DOIAP 2.5 sec “messagetimeout”. So your reduction of the “messagetimeout” is correct.
My tests show natural MB<>AB bridging through a DOIAP tops out at about 50 messages per second under AB/Enet and 35 with Ethernet/IP. My preference is to add a timer to trigger my MSG blocks & when I have more than a few MSG blocks, I chain them in series not parallel. This allows easier troubleshooting as I can slow down the polls to once per second or speed them up to 25 per second, etc.
Communications ran perfect for 2 months. However, the oscillation of the data being transmitted from the DOIAP to the master started again. Communications recovered fine after a reboot. Attached is the text file of the DOIAP backup configuration “backup.cfg”. The master polling timeout is set at 1 sec; I just increased it to 2 seconds.
I started a telnet session and ran the following comand:
set trace state=on mask=ia:+i+w+d
Attached are two files showing the captured text from the debug statement:
plc2_trace_060628 - This shows the traffic with the oscillation ocurring
plc2_trace_060628_reboot - This show the traffic running when I rebooted the unit, and then I captured some traffic after the reboot so hopefully the data can be analyzed to determine what is causing this anamoly.
I had the pollrate set at once every 1 sec, but have now increased the master to poll only once every 2 seconds.
Two months ago, per your direction, I changed to using the AB/Ethernet on port 2222. So that is how it is now configured.
I am polling modbus coil addresses 1-56, 4001-4112; and registers 40001-40005, 43001-43004
Communications have appeared to function perfectly for the past two months with using the AB/Ethernet. Prior to this the oscillations would occur in less than 2 weeks.