How does the Logix driver divide the tags into request counts

I have an Ignition 8.16 vision project that has some very slow device connections. I was using a leased scan group, but the screens would take forever to show live data. I contacted tech support and found out the Logix driver has to optimize the tags anytime a tag scan rate has changed. This device connection has 44,464 tags, so the process takes around 10 seconds. So I tried using a direct scan group, but this leads the load on the driver exceeding 100%.

I have other projects in a 7.9 gateway with large tag counts. Another Logix driver project has 31,117 tags running around 38% load.

So then I started playing around with how much tags lead to load on the driver. I created a 50,000 DINT array in a dev environment and was impressed that it can handle all those tags in < 1ms. But it only created on request count to get all those tags.

The device connection with 44k tags has 265 requests and is overloaded.
The device connection with 31k tags has 166 requests and runs great.

So I think the answer is to somehow architect the tags so the driver has a reduced amount or request counts. Does anyone have a link to helpful information of how to get this under control, or any other helpful information?

We have already messed around with increasing the amount of connections the driver can create, but we haven't seen any huge improvements. Right now it is set for 8. I am connecting to a 1756-L84ES through a 1756-EN2T.

Optimization is per-tag. The services uses to make requests work, at most, per-tag. (Including aliases as tags.) Each service grabs contiguous bytes from the PLC's tag storage and deliver for decoding in Ignition. Where unambiguous, and no tag or member permissions problems interfere, and not an AOI, structures can be read in bulk. Saving much time on both ends. So too with arrays of structures.

Many small services can be bundled into a larger (composite) service, which further reduces the number of requests that cross the wire (as fitted into the connection buffer--see the advanced props), but that bundling adds some CPU time on the PLC side (to unmarshal the inner requests and marshal the responses back into as single response).

So, to go fast:

  • consolidate PLC tags into UDTs with no permissions restrictions,
  • make arrays, both of primitive types and structs,
  • avoid aliases like the plague (point Ignition at the target of the alias, not at the alias).
  • for any given PLC tag, make sure all OPC tags use the same pace

Also, review this entire topic:

{ Psst! And watch the 3rd party modules category.... }

One more thing, for your case especially:

  • Use the front port of 1756-L8x processors for Ignition and SCADA in general, moving other loads to chassis-based communications.