To help manufacturers understand how they can mitigate potential negative impacts to production operations when message brokers are not yet or can’t be used to manage data required from PLCs, Automation World connected with Evan Novakowski, senior engineer at system integrator Actemium Avanceon, for a recent episode of the “Automation World Gets Your Questions Answered” podcast series.
See links at end of this article for more information about how message brokers can eliminate the impact of data polling on PLCs.
How data polling over Ethernet impacts PLC cycle time
According to Novakowksi, the impact of controller data polling depends on how much data you’re generating, how often those data are needed, and how the data gets from point A to point B. Any evaluation of this starts with thinking through the criticality of the data, what the use case for it is and how your industry may dictate the requirements of specific processes or decisions that need to be made.
On the more technical side, he said it really comes down to the frequency that you need the data, the packet sizes needed to carry the data, the protocol methods used and your network bandwidth and layout.
How frequency of polling affects the CPU load and the cycle time of the PLC
“The speed and frequency that you need the data is going to have the most impact on increasing the cycle time,” explained Novakowski. “With the direction PLCs and their programming are headed, this issue is become more task based now. This means you’ll likely be looking more at periodic tasks rather than a continuous task where the cycle time isn't something users would be as tuned into today as they were, say, 10 years ago. But even before that, especially with some older PLC hardware, you would still see anomalies if you overtaxed a PLC to the point where you’d see data dropping out or data corruption. You could also see the controller skipping execution of logic if you're overtaxing the PLC by too heavily requesting I/O data or having too many Ethernet connections to the processor.”
The bottom line here is that the faster you need data, the more capacity you’ll need in your PLC’s processor.
Any attempts to reduce these impacts on the controller comes down to being intentional about your controller settings. “If you have data that's not critical, you can slow down requested packet intervals on those I/O points so that you're getting the data you need at a more reasonable rate,” he said.
“If you have a high-speed counter that needs data quickly for the execution of your logic, you can have that coming in at a quicker polling rate and have your slow response data coming in at a higher requested packet interval. These tactics can also be used on your SCADA system, where you can break up your data into fast responses and slow responses so that you can minimize the impact on the PLC.”
Network bandwidth and packet size effects
Novakowski recommends organizing the controller data needed via polling into groups so that you're “not transmitting a little bit of data here and little bit of data there via multiple pathways but rather consolidating the data in a single structure. By doing this, you're making one transmission with all the data that's needed by another device.”
In terms of network bandwidth, Novakowski says to consider the devices you’re using and the physical network architecture that exists between points A and B, while being mindful of the network switch that you're going through and its port limits if you're using a virtual LAN on that switch to isolate the data.
“You may want to isolate the local I/O data from the plant network data so that you don’t have a flat network with a lot of traffic going across the entire network,” he said. “This is an important tactic because that local data is only pertinent to a single device. That’s why controlling the flow of data across your network and being mindful of the physical assets on the network are necessary to really understand your bandwidth constraints and where the bottleneck would be if, for instance, you're connected to a Gigabit port in one place on a network switch but the other device you're communicating with is only capable of handling, say, 100 megabits per second. When that happens, you’re going to have a bottleneck on one side.”
The impact of message priority
“I have seen a shift in industry of getting away from single continuous processes as processors have gotten more powerful and moving towards more of a periodic, task-based program programming method,” said Novakowski.
Considering this shift, he advised manufacturers to look into prioritizing the data that your controller logic is based on.
“I'd look to give whatever I/O that's coming back to the processor the highest prioritization and the quickest frequency so that you know your PLC’s logic is executing on the most current data,” he said. “From there, if you had some PID loops that needed a quicker loop update time, you could consider those to be next in line for prioritization.”
Recommended strategies to optimize PLC cycle time
In addition to Novakowski’s recommendations about breaking up I/O data to avoid having all I/O communications hit the PLC at the same time, as noted above, he suggests programming the PLC logic to step through each task and waiting until one task has completed the execution of one communication before it initiates the next one.
“I also recommend reviewing your network communications to the controller to make sure you reduce any spikes in the network traffic as much as possible,” he said. “Some older tricks for doing this on the SCADA side involve tactics like using prime numbers for your update time so that you’re doing what you can in every instance possible to reduce your communications from hitting all at once.”
More industrial network message broker insights from Automation World:
