Ignition & Logix Best Practice Tips for better communications

If you must use AOIs and not just UDTs, yes.

There’s been a few different strategies discussed around here for isolating the tags needed by Ignition and getting them into a separate UDT. The most recent I can remember was in this post.

@pturmel might have something to say about a particular magic driver he has to get around these issues

It is linked in that topic. Just read the whole topic.

Hi, which is the best way to group data inside PLC to get maximum performance, where I can read about how Ignition/Rockwell is required to be data grouped for best connection performance? I am using udt structure only with different data types inside udt. I trying to create some guidance for my organization of how to do data grouping, but cannot find any proper document of how Ignition or Rockwell doing transfer optimization. I not really like to create arrays of REALs to send analog data to the ignition, because in this case is really a mess to work with this PLC code. Best case for me is grouping data into udt like udt_Valve, udt_VFD, udt_Motor etc, and each udt has all requried data for specific unit. But how to group those udts to have max performance it's is a question for me. (Example program has 200 valves, 100 VFDs and 50 Motors). The best approach be to group them into arrays (VFD[100], Valve[200], Motor[50])? or there any better solutions present?

1 Like

UDTs are very good for performance. Arrays of UDTs are especially good. With some constraints. I recommend you read the topics linked above, because they have a great deal of information about how this stuff works. The best summary is probably this one:

Most importantly, for any given base tag in the controller (a controller tag, or a program tag, at the top level), use only one subscription pace. Optimization can only occur for OPC items that are part of the same tag, and at the same pace.

Things that are less important to your operation, and can operate at slower paces, should be in a completely separate tag hierarchy, preferably another array of UDTs.

If you must use AOI tags, and cannot do any InOut parameters nor tweak AOI locals into a nested UDT, you probably want to use my alternate driver.


Question about udt:
If udt has 5 tags:

  • Tag 1 (dint)
  • Tag 2 (dint) (not used in ignition)
  • Tag 3 (real) (not used in ignition)
  • Tag 4 (real)
  • Tag 5 (bit)

Tag 2 and 3 are not required in Ignition, how data be called from PLC in this case?
Should i group tags into udt specifically for ignition or there any difference if udt has some tags which is not for HMI?

1 Like

{Terminology note: UDTs in the PLC do not contain tags, they have members. "Tags" are only the top-level names in controller tags or in a program's tags.}

When Ignition is told to get Member 1, 4, and 5 at the same subscription pace, Ignition's driver (and my alternate driver) will read the entire structure in one request, if possible. Members 2 and 3 will be transferred in the response, and then be thrown away.

If you have large UDTs with many such ignored members, it will cut into the performance of the driver.


"#8: Never poll across a WAN. Latency crushes polling protocols."

Curious what exactly gets 'crushed' ? -- our enterprise design is to run Ignition in a regional datacenter to avoid putting server hardware /edge compute at the site. Instead we use L2NATs at the site which forward EthernetIP (port 44818) from plant floor to the offsite datacenter. Our ping times are around 35 ms.

In summary our PLC protocols (mainly Logix drivers with a few legacy) are going over the WAN from plant to datacenter where Ignition is running. What would be the drawbacks of this approach other than a slower latency for Ignition?

I am most interested if there would be any impacts to the PLC comms module? Phil I read over some of your other post you mention OPC drivers for PLC protocols don't buffer streams of requests and reply in streams but handle requests one-by-one. Also, "An A-B driver running over a connection with even 20 ms ping time will have a tenth of the usable capacity as a local LAN connection.

Ultimately, you may not achieve the polling rate you want for as many tags as you want. You may have to settle for slower. Look at the diagnostics for each driver to see where you stand.


On a LAN, where round trip time is tens of microseconds, simple requests to an L81E will be answered in about a millisecond. More complex requests will be answered in 15-20 millis. So, with a WAN round trip of 35ms, the 1ms responses become 36ms, and the 20ms responses become 55ms. So your driver load will be 3x to 36x higher with Ignition in the remote datacenter.

This is true for Modbus TCP, too, fwiw. Using request/response protocols across a WAN is just dumb. You should reconsider your network design and gateway placement. Consider putting Edge in your facilities.

OPC UA and MQTT are both non-polling protocols, and don't have this problem with remote connections.

1 Like

Is there a UDT size or UDT array size limit or best practice in UDT size for fastest comms?

In other words, say I have 100 AB PLC tags (or datapoints) I want to read and write with ignition.

Would it be more efficient to make 10 UDTs with 10 datapoints each or one UDT with 100 datapoints?

Would it be better to make a 10 member array with the 10 datapoints?

Would it be better to make UDTs of same datatype (bool, real, DINT, etc.) or is mix and match ok?

Or am I splitting hairs here?

What if I have 1000 tags? 10,000 tags? 100,000 tags?


Arrays versus UDTs doesn't make a difference. It is simply packing items together to be read as a contiguous block is what makes reads efficient. The advantage diminishes (a little) after a tag's total size reaches the buffer size of your connection, as the rest will be read with continuations. (Continuations of a single tag do not run concurrently.)

For UDTs, try to avoid unnecessary gaps due to different size elements. Put 64-bit types first, then 32-bit types, etc, and keep all booleans together.


With the modern Ignition Rockwell driver, wouldn't a situation where you are using leased tags be a reason to have multiple connections? My understanding is that when the leased tags change, the whole driver is resubscribed, causing a brief blip/delay in comms. Using multiple connections would then reduce the amount of tags that are being affected, reducing the duration of the blip.

I'm not sure this is still true. Definitely not true for my alternate driver.

It is true that re-subscribing a tag at a new pace can be slow for that tag.