# UDT Tags Not Updating Consistently for Modbus TCP Devices **URL:** \ **Category:** Ignition\ **Tags:** modbus\ **Created:** [April 11, 2025, 12:15pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994 "2025-04-11T12:15:13Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![AP25](https://avatars.discourse-cdn.com/v4/letter/a/51bf81/32.png) [@AP25](https://forum.inductiveautomation.com/u/AP25)\ **Post date:** [April 11, 2025, 12:15pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/1 "2025-04-11T12:15:13Z")
Hi all, I'm facing an issue with a Modbus TCP device connection in the Ignition gateway. Here are the details: **1. Connection Settings:** Timeout: 10000ms Radix: 10 **2. Tag Configuration:** UDTs are created using the multi-instance wizard with the following OPC Item Path variables: {PanelName}, {Module}, and {Circuit}. Multi-instance wizard setup: Base Tag Name: Heater\_ Tag Name Pattern: 1-30 Panel Parameters: {PanelName} Pattern: MOB1, Size: 1 {Circuit} Pattern: 1-10, 1-10, 1-10, Size: 30 {Module} Pattern: 1\*10, 2\*10, 3\*10, Size: 30 **3. Modbus Address Configuration:** Below is an excerpt of the Modbus address configuration (this structure is repeated across all 30 devices, with each heater’s address incrementing by 190): ```python HTR_1__1_ 0 1 FALSE 1 HoldingRegisterUInt16 72 HTR_1__2_ 0 0 FALSE 1 HoldingRegisterUInt16 76 HTR_1__3_ 0 1 FALSE 1 HoldingRegisterUInt16 85 HTR_1__4_ 0 0 FALSE 1 HoldingRegisterUInt16 93 HTR_1__5_ 0 8 FALSE 1 HoldingRegisterUInt16 94 HTR_1__6_ 0 0 FALSE 1 HoldingRegisterUInt16 104 HTR_1__7_ 0 4 FALSE 1 HoldingRegisterUInt16 110 HTR_1__8_ 0 3 FALSE 1 HoldingRegisterUInt16 116 HTR_1__9_ 0 1 FALSE 1 HoldingRegisterUInt16 122 ``` **4. Issue Description:** The problem affects tags associated with Modbus address 110, 300, ... (HTR\_1\_\_7\_, HTR\_2\_\_7\_, ...). If the device value changes, the tags may briefly update but then revert to their previous state. Additionally, values for other tags update unpredictably (no consistent tag or offset). Dragging the problematic tag(s) directly from the OPC Browser into a new folder resolves the issue. Once dragged, both the newly created tag and the original UDT tag update as expected. **5. Additional Observations:** The OPC Item Path for the UDT tag and the dragged tag is identical. No gateway errors are logged. This behavior occurs across multiple devices, not just one. Monitoring through Kepserver shows consistent updates for the address. Restarting the gateway does not resolve the issue. **Request for Help:** Has anyone experienced similar behavior or could offer insights into: Why UDT tags behave inconsistently until dragged from the OPC Browser. What might be causing this issue with Modbus TCP devices and UDTs. Any potential workarounds or diagnostics I may have missed. Thanks in advance for your help! ---
**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:** [April 11, 2025, 12:34pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/2 "2025-04-11T12:34:24Z")
Consider discarding your address mappings. It makes it hard to help you. Construct your UDTs with an address offset parameter that can be included in manually constructed OPC Item Paths. My Spreadsheet Import Tool in the Ignition Exchange has some modbus UDT examples of this approach, and is far more capable than the multi-instance wizard: > [@Spreadsheet Import Tool](https://forum.inductiveautomation.com/t/spreadsheet-import-tool/93500): > > Now [in the Ignition Exchange](https://inductiveautomation.com/exchange/2660/overview). While waiting on IA review, i Interested parties can also get this here: [https://www.automation-pros.com/SpreadsheetImportTool/](https://www.automation-pros.com/SpreadsheetImportTool/) I intend to publish at this link as well as in the Exchange going forward. Announcements will be in this topic. (: ---
**Author:** ![AP25](https://avatars.discourse-cdn.com/v4/letter/a/51bf81/32.png) [@AP25](https://forum.inductiveautomation.com/u/AP25)\ **Post date:** [April 11, 2025, 6:26pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/3 "2025-04-11T18:26:35Z")
Hi @pturmel, Thanks for the suggestion. I tried testing the direct path approach (`[DeviceName]UnitID.HRx`) you recommended before restructuring everything with the spreadsheet tool. I'm running into a roadblock: direct paths consistently give me `Error_Configuration` or `Uncertain_InitialValue` qualities. **Quick Summary:** - Device `DeviceName` shows **Connected**. - Internal `[Diagnostics]/Connected` tag reads **Good**. - Direct paths like `[DeviceName]1.HR73` or `[DeviceName]1.HR0` result in **`Error_Configuration`**. - **However** , if I add a map in the device config (e.g., prefix `TestHR`, start `0`, end`0`, step`0`, unit id `1`, modbus type `Holding Register (Int16)`, modbus address `73`), a tag pointing to the mapped name (`[DeviceName]1.TestHR0`) works fine ( **`Good`** quality). So, it seems direct address paths fail configuration for this device if no address configuration exists for that device. Is there anything you can think of that I might be missing? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [April 11, 2025, 6:47pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/4 "2025-04-11T18:47:35Z")
Directly tagging in my experience has been more reliable than using the mapping approach. Have you tried turning off the SpanGaps option on the driver connection settings. Sometimes that can cause issues if the driver is trying to optimize polling but the end device rejects reads on registers that don't have values causing the errors you're seeing. ---
**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:** [April 11, 2025, 6:58pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/5 "2025-04-11T18:58:04Z")
When using direct manual addressing, unit ID defaults to zero with the IA driver, so you _must_ provide it as `[DeviceName]1.HR73`. Do note that `1.HR0` would not be valid by default with IA's driver, as it defaults to one-based addressing. {`x.HR1` through `x.HR65536`) ---
**Author:** ![AP25](https://avatars.discourse-cdn.com/v4/letter/a/51bf81/32.png) [@AP25](https://forum.inductiveautomation.com/u/AP25)\ **Post date:** [April 11, 2025, 7:26pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/6 "2025-04-11T19:26:28Z")
Good point about the one-based addressing. Old habits die hard. `[DeviceName]1.HR73` still returned the `Uncertain_InitialValue` quality. What ended up working was just leaving a single dummy row in the address configuration settings. prefix `DUMMY` , start `0` , end`0` , step`0` , unit id `1` , modbus type `Holding Register (Int16)` , modbus address `1` The above row enabled the data to start populating for all 3 unit id's from this modbus connection. ---
**Author:** ![AP25](https://avatars.discourse-cdn.com/v4/letter/a/51bf81/32.png) [@AP25](https://forum.inductiveautomation.com/u/AP25)\ **Post date:** [April 12, 2025, 1:13pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/7 "2025-04-12T13:13:44Z")
So, after rebuilding these UDTs with direct manual addressing, I am back at square one. I have an identical situation as the original post that I made. Any other ideas here? Could it be due to the quantity of tags? I probably have 4000 different tags within these UDTs. They are reading 6 Modbus devices, 18 unit ids. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 12, 2025, 1:25pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/8 "2025-04-12T13:25:02Z")
Ignition logs and Wireshark capture? You might also try turning off "Span Gaps" in the Ignition Modbus device settings. ---
**Author:** ![AP25](https://avatars.discourse-cdn.com/v4/letter/a/51bf81/32.png) [@AP25](https://forum.inductiveautomation.com/u/AP25)\ **Post date:** [April 14, 2025, 3:37pm UTC](https://forum.inductiveautomation.com/t/udt-tags-not-updating-consistently-for-modbus-tcp-devices/104994/9 "2025-04-14T15:37:10Z")
Span Gaps did the trick. Thanks everyone!