OPC Tags - Subscribed vs Polling

[Andrew_Benzing]

Hello!

Looking for some help understanding Subscribed vs Polling (8.1.32, Allen-Bradley).

We have all of our OPC tags in one group set to Subscribed. I would like to move some of our low runners to Polling to save resources.

Say I have two OPC tags, both set to Subscribed. As I understand it, Subscribed means there is a constant open connection to that PLC. Is that understanding correct? And if it's a constant open connection, is that to the device as a whole, or just to the specific tag?

If I change one of the tags from Subscribed to instead Poll every thirty seconds, have I just added an additional connection to the PLC every thirty seconds, or have I saved resources because Ignition isn't constantly connected to the OPC tag?

Said another way - if I have one subscribed OPC tag for a given device, is there any reason to not just have every other tag on the device set to Subscribed?

I appreciate y'all's help.

[Kevin.Herron]

You haven’t done either of those things, and you’ve potentially made things worse if these tags belong to the same UDT in the PLC.

Use Subscribe mode unless you have a real reason or are told by support to use Read mode.

[pturmel]

@Andrew_Benzing

to save resources.

This hints at current problems with performance. Have you looked around here for related topics? Especially this one:

Ignition & Logix Best Practice Tips for better communications

Hi All, After a whole bunch of issues I have gone down the rabbit hole of what is wrong with our setup on site. I will preface this by saying I a relatively new to all of this.... so be gentle Based on much reading(such wow) I believe I have a list of things our site could take away for a better system. Some of them are easy to implement, whilst some of them need... significant work to realize. Especially the AOI approach in point 5 Before going too far a…

(There are many other topics linked there, and cross-referenced linking there, that are worth studying.)

Much depends on how tags are organized (or not) in your PLC. Some speed gains cannot be made without PLC changes.

[Andrew_Benzing]

Thank you both for the replies. I'll read through those linked resources.

Actually we don't currently have problems with performance. Our system grew slowly over about eight years. Now that we've reached a more mature phase, we've realized that our current setup will not scale very well (significant scripts with multiple queries living on tag change events, etc.). I'm working through the system exploring ways to restructure and optimize.

Circling back to this issue - If switching to Polling is not appropriate, is there anything to be gained by slowing down the rate on some of our Subscribed tags? Right now the group is set to 1,000 ms. We have several tags in our UDT that are set up during the construction of a workcell, then left on for the life of the workcell (several years). We're working on eliminating them entirely, but I'd like to make improvements in the meantime. I'm new to this, but it seems inefficient to be checking the value of that tag every second. Let me know if I'm barking up the wrong tree.

Thanks!

[Kevin.Herron]

@Andrew_Benzing

is there anything to be gained by slowing down the rate on some of our Subscribed tags? Right now the group is set to 1,000 ms.

Sure, you may be able to reduce your PLC comms load a little bit. Check the diagnostics page for your device(s) to see if you're currently keeping up with the demand.

But you need to be careful not to slow down tags that are part of a UDT where other tags are being polled quickly. Any tags you move to a slower rate should be part of fully independent top level UDTs.

Ignition isn't breaking a sweat about these rates either way, so you don't need to be concerned about that.

[Andrew_Benzing]

Ah, I see. All of the tags I'm reviewing live in the same UDT - thanks for the heads up!