Ignition Version: 8.1.38
I have a system that has been running for about a year now using the Modbus TCP protocol and being converted to Modbus RTU over RS232. This particular system communicates over radio to 8 devices with a baud rate of 9600, I understand that comms arent always 100% over RF. The TCP to RTU comms were terrible and I tried every possible setting I could to get the comms to be somewhat reliable but failed. The legacy system that was in use prior to Ignition was using Modbus RTU over it's local Serial Port and had around >=90% success rate on all devices. Today I tried moving all my devices over to Modbus RTU since the server has a Serial Com Port. I moved over one device to see if it would work and had a relaible connection, so I moved over the rest of the devices but only one device stays connected the others flip from Connecting to Disconnected. If I disable the Connected device another enabled device will connect while the others flip from Connecting to Disconnected.Every once in a while the Connected device will disconnect and another will automatically connect. I would assume I would see a device connect than disconnect, move to the next device Connect than Disconnect. Why is only one device staying connected for a long period of time and the others wont connect? I've tried putting the tags in different tag groups to pull at different frequencies, with no success. I have my timeouts in the Device and OPC settings up as high as 16 seconds. Is there any way to monitor these serial connections further? The logs shows Request Failed. FailureType==DISCONNECTED
If I change the Communication Timeout to around 16000msecs and hit save changes the device shows connecting for about two seconds than shows Disconnected, shouldn't it try for the 16 seconds before saying disconnected?
How many devices do you have configured in Ignition and how many serial ports do you have? Each serial port can only be used by one device. Multiple devices sharing a single port would need to be handled by addressing multiple unit/slave IDs on the same device instance.
I have one serial port that is connected to a MDS Transnet 900 Spread Spectrum radio. So I need to setup all devices (8) in one Device Connection? If that is correct how do I go about handling Reverse Word order on half the devices while the other half do not require it?
If I switched over to RS485 and checked the RS-485 Mode would it let me multidrop, ie.. use more than one Device Connection per com port?
We have this problem several years before.
The Ignition Serial communication has a big bug. It is developed based on Ethernet with handling collision detection on the ethernet layer. So in Serial media, it doesn't wait until the previous request finishes this causes time to time when Ignition sends a new request to the next device in the queue before the previous one sends its response so both messages collide.
Workaround:
- Your device should be very fast(No delay for response, so if you use PLC the modbus code should be handle in interrupt instead of the main loop)
- Use Higher buadrate to minimum transmit time on the bus
- Use smaller packet size to min the traveling time on the bus (not good for efficiency but good for this one)
- Use multiple serial line on the Ignition Gateway and load balance devices on them
- Use kepware Modbus driver or Node red instead
- May be @pturmel modbus driver handle this one.
My alternate driver allows these settings to be per-unit-address. It also has a number of timing tweaks that IA's driver does not.
If converting, note that it only does zero-based addressing, does not use address mappings, and defaults to unit #1 instead of unit #0.
The IA Modbus RTU driver is not going to work for you in this scenario.
I'm having some trouble mentally picturing your network topology from your post.
Naturally, I would assume it's RTU (you say RS-232) to a TCP/IP converter/gateway, then your server connects to it that way. I guess the other end of the RS-232 connection is an RF modem that routes comms to the 8 RF devices?
Then you say "today I tried moving all my devices over to Modbus RTU..." well, what was it before...?
Either way, the fundamental issue seems to be the locking of the serial com port (which you've stated is in the server itself).
As far as I understand it, when an application makes a 'connection' to a COM port, it is locked out and cannot be used by other applications/connections. This is even true for virtual COM port connections made via serial-to-USB dongles.
@Kevin.Herron alludes to this in his first post.
The solution would be to either have multiple COM ports (likely requiring multiple physical serial cards in the server) or to use multi-drop comms via RS-485 or similar.
Not possible with a single radio.
Already working that way over the one radio.
With different settings required per unit address, only my module will serve this application from within Ignition. Other OPC servers might be able to as well, but I've not seen any specs to say so.
I would recommend using a single PLC with Ethernet and serial Modbus RTU capability to poll the radio network, and let Ignition interact with it using Ethernet. We use the Click Plus and Micrologix1400 frequently for this sort of application. Your PLC program can implement the polling, inter-message timing, skipping of disabled nodes, etc. and all of that can be custom programmed for your situation.
Thanks for the replies. I have decided to go the Kepware route. I initially went with the Ignition route to reduce setup time but in the end costed me a full day.
It would be nice if Inductive Automation had a little more documentation on the Modbus RTU driver providing some of the behind the scenes facts, such as:
***It is developed based on Ethernet with handling collision detection on the ethernet layer. So in Serial media, it doesn't wait until the previous request finishes this causes time to time when Ignition sends a new request to the next device in the queue before the previous one sends its response so both messages collide. , *** Or I failed at finding any such documentation.
Kepware Modbus Suite works fantastic for all Modbus protocols (TCP or RTU)
Because that quote is not from IA. And I'm not so sure it accurately reflects the behavior of IA's driver. (But I never use it, having my own.)
Sorry, didn't mean it like that, I meant more like the inner workings of the driver.
Where'd this come from? It's simply not true.
There are some obvious shortcomings with the Serial/RTU driver, but it's not this fundamentally broken.