Performance problems with Tag Provider

We are currently developing our own MES, using the Java modules.

Do to this we need to read, write and subscribe to PLC tags. The communication between the MES and PLC is based on handshake, i.e. setting a Boolean tag to true to triggers functions to be executed in the MES and vice-versa.

Our current setup looks like this

  1. Connect to the device using the gateway UI. In this case it’s a Allen-Bradley Logix Driver
  2. Setup an OPC UA Client using the gateway UI. The UA Server is the interal one from Ignition itself
  3. Setup a Tag Provider using the gateway UI
    image
  4. Import the tags using the designer
  5. Note that currently all tags use the same Tag Group

Now on the Java site, we use the gateway context to get the Tag Provider to do our read, write and subscribe stuff.

We are doing some testing and it technically it works, but ran into some heavy performance issues, that I feel like are either because of wrongly configured settings, or because of how the Tag Provider works internally.

For that I have some questions:

  • How many tags does one Ignition support per device and in which rates?
    • We are looking at at least 10k+ tags that we need to read and write and roughly 700 tags that have a subscription
  • The Tag Provider seems to update ALL its known tag on EVERY single interval, even if I set the Data Mode to “Subscribed”
    • I know that there are different modes (direct, driven, least) to change the update interval
    • In the logs I can clearly see, that all tags are pooled on each interval, even if there was no change on the value on the UA server site
    • I set the update interval to 1000ms. This causes the Tag Provider to query all 10k tag every 1000ms, even if there was no change on the tag value on the UA server site
    • This understandably kills the performance on the device site, since all tags are constantly polled, since the client doesn’t use the publishing system that OPC UA generally provides
    • Same thing when I try to read a tag. Why does it wait for the next poll interval for the value to update in the Tag Provider, instead of just making a read request to the UA server?

Either I misunderstand the concept of the tag provider, but I feel like the idea is, that the tag provider tries to update all its value on each interval (depending on the tag group), and does not listen to publishing changes from the UA server. My module than uses the tag provider for these operations, but the tag provider kind of acts as it’s own server, instead of just relaying the commands to the actual UA server.

I even tested this behaviour like this:

  • Connect an UA client (UaExpert) to the UA Server
  • Connect an UA client (UaExpert) to the tag provider
  • If I browse the tags, I can see that the UA Server knows all the device tags and updates their values on value change accordingly without any performance hits
  • If I do the same on the tag provider, it’s values are updated only on it’s configured interval and not on value change, causing the performance to drop the more tags that are configured on the provider

Splitting in up to more providers doesn’t help, since everything still goes through the same device.
Using different tag groups and even dynamically adjusting the polling interval using driven would not really help, since we would have ~700 handshakes with it's own data block, which would required the same amount if tag groups to keep in sync.

Am I misunderstanding the concept, or is the Tag Provider really polling everything every time to keep it's values interally up-to-date? This seems like a mayor performance issue on large amount of tags, instead of just updating it on value changes on the UA server - or the Data Mode setting in the tag group does not work as expected.

My only solution is to not use the tag provider from Ignition and rather connect my own OPC client and handle the request as would be expected in the UA standard.

A 100ms leased rate for Logix tags is usually unreasonable, and leased/unleased changeover is pathological in anything prior to Ignition v8.3.

Subscribed tags only have changes reported through OPC, but the driver itself has to poll to notice changes in the PLC.

I think you narrowed it there

This understandably kills the performance on the device site, since all tags are constantly polled, since the client doesn’t use the publishing system that OPC UA generally provides

If a native device just doesn't support pushing changes when needed, you're pretty much stuck with polling. Slipping an OPC UA server in the middle speeds up the link between OPC UA and Ignition, but unfortunately it doesn't remove the need to poll the device itself—it just shifts where that poll originates.

You'll probably need to do some tuning across the board here. Splitting tags into different scan classes or execution groups (slow vs. fast), switching non-critical data to on-demand reads, or using event-driven polls should help lighten the load quite a bit.