I’m having some issues with response times and as a result, overloading on OPC communications to several PLC-5/40Es at a plant we are converting from Wonderware to Ignition.
Moved many tags to higher sample rate tag groups or leased tag groups. This lowered Overload from ~600% to what you see above, but it seems the ‘Mean Response Time’ has no change no matter how many tags i’m polling. More on that later.
Changing the ‘Communications Time Slice’ parameter S:77 in the PLC-5 to allow more time for communication processing. This had no effect.
Monitored traffic on the switch port this PLC is connected to. I know the PLC-5/40E is limited to 10 Mbps, but I only see 300 - 500 Kbps of activity on the line, so that didn’t seem to be the bottleneck.
Tested a small amount of tag connections for another PLC-5/40E for which I had no other tags configured yet. You can see it is not yet experiencing significant overload, but the response time still sits at ~95 ms.
Took a look at the communication data from their existing Wonderware system to all the PLC-5s and SLCs in the plant. It seems to be a pre-existing issue, as you can see here there are really bad update times from all PLCs.
Is there a physical limitation of the PLC-5/40E that could be causing these slow speeds? At this point I am thinking it must be something on that end, or else a physical bottleneck somewhere in the network between the server and the PLC.
So, first thing here is that if you are subscribing to the tags while wonderware is still connected, you are doubling the comms overload on the PLC.
If you want to test the different tag polling rates, change all your tags to the same rates, that way you can guarantee that any optimisation of the connection can be done over all your tags.
Thanks for the quick response. Fair point about the dual connections. The reason I wasn’t going down that path as a root cause is that I tested disabling all the PLC connections from Ignition and then could see from monitoring the Wonderware connections that they still have really poor update times and time per message.
I did try to block them to optimize the number of reads needed but I will be reviewing the tag setup further to see if I can make more improvements there.
Contiguous blocks are going to give you the best chance. You may need to slow things down even further to get an acceptable response from that dinosaur PLC.
Yeah that lines up with what I've been seeing with the response time, since I've seen no change there no matter how I change the tag configuration. Just now I created a new tag provider, disabled the default tag provider, and added a single tag from this PLC. Still have ~95 ms response time for the one tag.. Is a speed that bad just to be expected from a PLC5?
I'll have to wait for some plant downtime to disable the Wonderware connection and see if I see any improvement taking that connection offline.
So, I'm gonna start with the IP. Thats a public internet IP on that PLC that is going to cause you issues somewhere down the line. That said, if you have a department that didn't know that when they set up the PLC, you may have another thing going on with it. The PLC5 IP settings uses a default subnet mask of 0.0.0.0 as when they were launched, subnets really weren't a thing. If this is still the case, your PLC may be listening to a lot more traffic than it should. Attached to this is that the PLC will suffer from multicast traffic, as it needs to evaluate every packet.
Ideally on old PLCs like this you would have a subnet mask of 255.255.255.0.
Check if you have it attached directly to a managed switch, if you do, make sure IGMP snooping and IGMP Query are enabled on that port. This will reduce drastically the multicast traffic on the port.
Next chuck your IP into a browser and have a look at the errors and ignored packets statistics to check if the IP interface on the PLC is getting drowned.
What @David_Stone said will help with diagnosing traffic. However... These are old.PLCs that you will really have to temper expectations on performance.
Yes. It is old technology with a single-threaded and rather slow CPU. Your only hope for improvement will be to consolidate information into just a few PLC files, and only about 250 bytes per each.
(And only one client, WW or Ignition, at a time.)
Also, consider splitting the main task into pieces. Comms can only be handled between logic scans, and I bet your scan time is ~90-100ms.
You really need to look at converting it over to a ControlLogix or CompactLogix. You can always do it in stages by getting a DHRIO card in a 1756 chassis/rack or getting a rack over conversion kit. The PLC code would need converted also, but if anything fails on the hardware you're currently stuck buying used parts off eBay. We have a bunch of old PLC stuff sitting on a shelf that I think we're finally selling, but had been holding into it just in case one of our customers needed it, but they've all pretty much migrated now so we have no use for it.
Thanks Phil, I will see if consolidating needed tags to a few files is feasible.
Curiously enough, the scan time is about 10-20 ms. I did try to modify the communications time slice parameter S:77 as well to manually give time for handling comms, but that seemed to have no effect on the response times.
I’ll turn off communications from Wonderware to this PLC when I have the opportunity and see what kind of improvement we get there.
The guys at this plant are aware they need to make that change at least, but it was not made part of the scope of this current project. Just another reason for them to go ahead with it though. Hope to be able to do that for them soon.
Series F added 10/100 full duplex with auto negotiate. Prior was 10mb half duplex. If you have a pre series F, make sure any switch is set to 10/half. If you have a series F, depending on what else is communicating to it, make sure it’s set to auto neg if connected to a switch that’s also set to auto neg.
