Pull Rate of Ignition and Data Collectors/PLCs

Good Afternoon,

I would like to bring up a question and something that my company is currently working through. What is the rate of pull that occurs when Ignition pulls from a PLC? If a bit that Ignition is looking at turns on at a faster rate than the time it takes for Ignition to pull and process the day, are there transactions getting lost? How quick of a signal can Ignition handle. Is there a standard or implementation that can handle this scenario?

What we know. Ignition is designed to collect data and to format data. What was the general approach of data collection? What was expected to be seen in real life for data collection? Was the time base of scanning and reading data focused on? Would we, for example, be able to connect to the photo eye directly from Ignition. Would the speeds not match and would data get lost?

You configure this as part of tag groups that you configure in Ignition. Ignition will poll for values at that configured rate. Example, 1000ms poll rate, Ignition polls once every 1000ms.

If the bit goes high and then low again in between polls, Ignition will not know.

Several factors influence this, including PLC make and model, Ignition server resources, location of Ignition server in regards to the PLC (cloud or onsite? Never do cloud if you want it to talk directly to a PLC). Typically fastest on base ignition is 250ms, with work being done on the PLC side to optimize data locations in PLC memory to help with comms load.

If you use 3rd party modules, like pturmels Ethernet/IP driver, people have reported as good as 100ms poll rates, again with work done on PLC side to optimize.

If you require high volume/speed data collection, the following method is the recommended/most followed:

Basic method layout is:
Have your plc stuff data into a ring buffer at real time speed (however fast you want to collect data). Make sure each datapoint has a timestamp value included with it. This will mean you need to have your PLC and Ignition server clocks synced to the same master clock.

Make the buffer max size enough to handle minor windows of comms disconnect, or several times the Ignition poll rate.

This allows ignition to catch back up in case of a bad transaction or comms hiccup, without stopping your machine.

Read from that ring buffer at slower poll rate with Ignition (5s for example) and read >5s worth of data from the ring buffer. Stuff the data into a db table or do whatever processing you want on it.

You will NOT be able to use the SQL bridge module to perform this, you will have to script these data transactions. SQL Bridge module is NOT required to talk to a db.

4 Likes

Also keep in mind that total throughput from PLC to Ignition is largely dictated by the PLC. PLCs are optimized to run real-time processes, not have blazing fast communications. I/O protocols have the highest packet rates, but are not request-response handlers for arbitrary data.

Rockwell publishes max possible packet rates for its processors and communications cards, segregated by protocol.

3 Likes

Thank you for your answers! I'm glad to see the concept we are doing is similar. And I appreciate all of the knowledge and answers to each question that was provided. It helps a lot!