Through some conversations with Support I think we’ve ruled out Ignition as the cause for the slow read/writes I’ve been encountering. By adjusting the timeout and adding a couple more SQL bridge threads, I’ve started to see that its likely 2 particular devices that are the culprit for clogging up these threads, but unfortunately I don’t necessarily have enough PLC background to know what to look for to say that we need to either upgrade PLCs or adjust network architecture for this project.
Anyone have recommendations on statistics or tools to see what could be causing these PLCs to slow? I’m trying to bring a case to our controls guys who aren’t seeing the significant slow down on their side.
7 Allen Bradley 3 of them are still on firmware 20.014, and the other 4 are on newer firmware. I’ll get the exact models once I can get back online with the system.
Network is super basic, but relatively small in terms of devices. Each PLC gets an unmanaged switch(unfortunately) and that each of those run up to a switch at the computer running Ignition. I’ve had our networking guy look at some wireshark captures, and he didn’t see anything that was jumping out at him.
What do the device load and response time stats look like on the driver diagnostic pages? In a LAN, they should be single digit millisecond responses.
In Logix processors, the default task is a “continuous” task, and it runs as fast as possible, less a “communication time slice” percentage. That comms time slice may need to be increased. Even better is to convert that continuous task to a periodic task, with a time period that fits the needs of the process, not just “go fast”.
Also, be sure you haven’t over-subscribed to the tags in these PLCs. You should never drag-and-drop whole trees of tags from the OPC browser to the Ignition Tag Browser. That is almost certain to cause driver load problems.
If the device load is only 1%, then look at your scan classes / tag groups. Are you sure you have the tags configured with an update pace that is suited to the UI? Humans generally don’t think responses are “immediate” unless the response is in the neighborhood of 100ms. That can be difficult to achieve in any SCADA (out of the box), but approaching that level of performance is important.
Also note that transaction groups in “OPC Read” mode, tag writes, and any use of system.opc.* will not be factored into the device load statistics. Those only account for subscriptions.
Almost all of these tags I am connecting to are for transaction groups only. The fastest of which is looking for a trigger at 200ms, but almost all of them are at 1 second or greater. It is a fairly basic data collection system. Not much in the realm of control.
Older PLCs are 1769-L32E Running 20.014 Firmware
Newer PLCs are 1769-L33ERM/A Running 30.014
Support ticket is 100434. All devices regardless of driver end up getting ‘stuck’ since the threads get locked up for transaction groups until they start to time out, though both of my two biggest suspects for PLC issues both are using the legacy driver.
If there aren’t a lot of tags in play and you have some time to experiment, it might be worth switching these older devices to use the newer driver. It works, it’s just slower. But I think you’ll have to update some OPC Item Paths too, so you’d wanna do this on a test system or something.
I may give that a shot again and see what happens. We had it on the new driver originally, but we switched back, probably because of the speed, but we’ve cleaned up quite a few other things, so maybe it will work.