The connection to the PLC is made through a selector switch that switches the communications between the old SCADA system and the new Ignition system.
We tested connecting the cable directly to the new SCADA system, bypassing the selector switch, to rule out any issues with the selector switch. However, the problem still occurs.
Any help or suggestions on how to troubleshoot this issue would be greatly appreciated. Thanks in advance!
Is the driver showing an overload % in the status page?
This is pretty typical of a system that's not quite fast enough on the wire speed for the amount of tags and rate and eventually times out, then starts responding again when the requests get cancelled.
You definitely should use a shorter communication timeout for this setup. Like, 300ms instead of 3000.
You are likely getting an occassional CRC error (in either direction), which causes the message to be dropped and that delay comes into play. (My alternate driver reports these so it is obvious in the logs when the wiring is marginal.)
Does the other SCADA system report any comm errors?
We (along with IA support) struggled through similar issues with the Ignition RTU driver and had to abandon its use (somewhere around 8.1.48ish)..
Try placing just one register on scan, change the driver log to TRACE and look for anything strange. We found the driver to misbehave quite frequently, with many different devices & gateways. Adding a TCP-serial converter and using the TCP driver solved our issues (begrudgingly).
I’d like to add some more information regarding this issue. After continuing with the commissioning process, I can provide some additional information about the Overload. It doesn’t seem to be particularly high.
However, what does catch my attention is the number of disconnection messages appearing in the log. These seem to be causing the tags to lose their connection status practically every few seconds.
I wanted to gather this information before proceeding with any changes to the driver configuration.
I’d also like to mention something rather curious that happened.
Since the communications are coming through a serial cable, we have a selector switch that allows the operator to switch between the old SCADA system and the new SCADA system developed in Ignition.
The selector was switched over to the new system, and I tried to send a telecontrol command. However, its status was not updated. We tried sending the same telecontrol command several times, but nothing changed, even after 4–5 minutes.
At that point, I asked the operator to switch the selector back so that the old SCADA system could regain communications. Interestingly, immediately after switching the selector back, the telecontrol command that had been sent several minutes earlier was displayed in the old SCADA system, and it was also updated in the new Ignition system at exactly the same time.
This seems quite unusual to me and may provide another clue about what is happening with the communications.
Best regards, and thank you very much in advance for your responses.
I just noticed that you have a predetermined character timing of 4ms set in the controller. If it does what I think, this will screw up the required timing for complete RTU packets. A 250 byte message should take 286ms @ 9600 baud. A 4ms pace would stretch that out to a full second. This would not work at all with my alternate driver.
You may have unrealistic expectations for how much data you can monitor--70 requests in 3000ms will be difficult to achieve. Just the minimum framing for the requests and replies and CRCs will take nearly a second at 9600 baud, not including data or execution time.
Reduce data to a single request. This is most-easily accomplished by requesting a single register / tag. Do you still see black --> red --> black tags? Send some information for that tag group (anticipated poll times), and screenshot of any trace logs around the time of that event.
