# Tag Polling in UDT

**URL:** <https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813>\
**Category:** Ignition\
**Tags:** perspective, ignition81\
**Created:** [June 2, 2026, 8:52pm UTC](https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813 "2026-06-02T20:52:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![sbartz](https://avatars.discourse-cdn.com/v4/letter/s/839c29/32.png) [@sbartz](https://forum.inductiveautomation.com/u/sbartz)\
**Post date:** [June 2, 2026, 8:52pm UTC](https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813/1 "2026-06-02T20:52:56Z")

</div>

I have a machine with an Allen Bradley PLC and an Ignition Perspective Edge 8.1 HMI. I have a UDT defined in Ignition with ~20 tags and a boolean tag, and every tag is in the same Tag Group. On the boolean tag there is a value changed script that detects when the boolean tag turns true and then processes the data from the other tags in the UDT. All data is set in the same PLC scan, but it appears that when the value changed script is executed the data isn't fully populated in Ignition for all the UDT tags.

Is it possible that tags in a UDT aren't all populated at the same time even though they are in the same Tag Group? And could a value changed script then only grab partial data like I'm seeing? Or is there likely something else going on I'll need to investigate further.

And if that is the issue, what would be the best way to fix it?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 2, 2026, 9:04pm UTC](https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813/2 "2026-06-02T21:04:01Z")

</div>

> [@sbartz](#):
>
> all populated at the same time even though they are in the same Tag Group?

This is true. OPC Subscriptions have no delivery ordering guarantees, and Ignition is entirely asynchronous (parallelized). You likely need to use `system.opc.readValues()` in a script to read everything other than the trigger. In which case, you probably do not need (and do not want) actual tags in the UDT for those.

Whatever you do, do **not** put any `system.opc.*()` call in a tag valueChange event, or any other event defined on the tag. Use a project's Tag Change gateway event to listen for your triggers.

---

<div class="post-metadata">

**Author:** ![sbartz](https://avatars.discourse-cdn.com/v4/letter/s/839c29/32.png) [@sbartz](https://forum.inductiveautomation.com/u/sbartz)\
**Post date:** [June 2, 2026, 9:43pm UTC](https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813/3 "2026-06-02T21:43:14Z")

</div>

Thanks for the very quick response! That makes sense.

Changing these scripts/ UDT structures might be more work than we have time to implement and test right now. So we're looking into just temporarily adding delays on the PLC side of things to ensure Ignition has all of the data. If I have all of the UDT tags in a tag group with a 250ms polling rate, adding a 250ms timer in the PLC between when we set all the other tags in the UDT and when we turn on that boolean should resolve this issue, right? Or is there a reason why we'd need a higher delay?

Is there a guideline for how fast you can set a tag group without seeing issues? Or is it likely dependent on too many other factors for there to be a guideline?

Then also out of curiosity, why shouldn't you put system.opc.\*() calls in a tag event?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 2, 2026, 9:49pm UTC](https://forum.inductiveautomation.com/t/tag-polling-in-udt/115813/4 "2026-06-02T21:49:16Z")

</div>

> [@sbartz](#):
>
> Or is there a reason why we'd need a higher delay?

Subscription pace is a **target**. Often not met when a PLC is overloaded, or spikes in workload are involved. A deliberate OPC read initiated after the trigger is noticed by Ignition is the only solid approach. Sorry.

> [@sbartz](#):
>
> why shouldn't you put system.opc.\*() calls in a tag event?

Limited thread pool for tag events. Lots of forum topics here with details. It is very easy to lock up all tag event processing if a small number of event script block on networking hiccups.
