UDT Tags Not Updating Consistently for Modbus TCP Devices

Ignition
1

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):

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!

2

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:

3

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, end0, step0, 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?

4

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.

5

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)

6

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 , end0 , step0 , 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.

7

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.

8

Ignition logs and Wireshark capture?

You might also try turning off "Span Gaps" in the Ignition Modbus device settings.

9

Span Gaps did the trick. Thanks everyone!