Polling driver suggestions

Is there a way with Ignition to set up the scan classes to act like a polling driver?

Like several of you out there, we have many systems that use a PLC as a data concentrator to message other PLCs over serial and Ethernet radio and cellular networks. We use a PLC because we can control the timing of the polling to each site, rather than having the SCADA software maintaining a connection to the remote PLC and constantly sending/receiving data. This is critical in cellular networks to control the data usage. Connecting Ignition directly to a PLC over a cell modem really burns through the data.

I’d really like to get rid of the data concentrator PLC’s in our designs. Polling speed isn’t a critical factor.

You can use scan classes in OPC Read Mode to approximate this, but unfortunately the way many of the drivers are written is that they are basically a state machine trying to stay in the CONNECTED state at all times… which means even if you aren’t subscribed to data and are only occasionally doing reads, the driver is still trying to stay connected all the time which causes unwanted data usage.

The Allen-Bradley Ignition drivers are practically silent on the wire if autobrowse is turned off and no SQLtags are subscribed. You can then do all of your interactions with the system.opc.* scripting functions on whatever timing you desire, and no other real traffic will go to the target, other than TCP overhead.
The traffic control problem you are trying to solve can be addressed in other ways, too. MQTT being the hottest topic lately, with good reason. The intent is for traffic to be generated only when a plant-local device deems it necessary, following some simple rules. Ignition EDGE with the MQTT module(s) can do this, where the driver polling is confined to the plant, and only relevant changes get published over your cell modem.
Another possibility is using a passive driver, like the base version of my Ethernet/IP Class1 Communications suite. It can sit waiting for connections from plant-local PLCs using message instructions to send data directly to Ignition as needed.

1 Like

If you can’t go the MQTT route, your next best option is going to be using Kepware or Autosol. These have polling and scheduling built in.

Thanks for the feedback. I am excited to start using MQTT and I believe that is the best direction for the future. It isn’t practical to add an MQTT device at each remote station for a lot of existing systems. I will be incorporating it into future designs.

Could you expand on your response?:
The Allen-Bradley Ignition drivers are practically silent on the wire if autobrowse is turned off and no SQLtags are subscribed. You can then do all of your interactions with the system.opc.* scripting functions on whatever timing you desire,…

It looks like the Legacy AB CLX driver has an Advanced setting for “Disable Automatic Browse”, but the current AB CLX driver has “Automatic Rebrowse”.

Do you know how are these settings different between the drivers?
Are you suggesting that if “Automatic Rebrowse” is disabled that Ignition will only request data when scripting functions are called to to read/write the tags (system.opc…)?
How is your suggested method (using scripting functions) different from using scan classes and OPC Read mode, for controlling the data exchange rate?

Thank you