Resolving Ignition 7.8 Stale Tags on Modbus TCP Devices

Where does a tag read stop when the value freezes?

Follow the packet. A tag value in the gateway travels this path: the scan class requests the value, the gateway's internal OPC-UA server holds a subscription for it, the device driver (Modbus TCP or Logix) turns the subscription into polled requests, and TCP carries those requests to the PLC. In Ignition 7.x the Modbus and Logix drivers run inside the OPC-UA module. A fault in that module can break the path above the wire, even when the Ethernet link and the PLC are healthy.

The field symptom after the 7.8 upgrade looks like this:

• Tags on a subset of roughly 80 Modbus TCP PLCs go stale intermittently. Logix5000 tags do the same on other systems.
• Quality reads Uncertain. The last value stays displayed instead of dropping to null.
• Tag overlays show a red X or a green config-error indicator.
• Selecting the tags in the Designer and reapplying the scan class restores Good quality until the next event. A gateway restart also clears it.

A stale tag that holds its last value means the gateway stopped receiving updates. It does not mean it received a bad read. Reapplying the scan class tears down the subscription and builds it again. That cure points above the TCP session, but you prove it layer by layer.

Check: while a tag is stale, open the device status page in the Gateway web interface and note the connection state of the owning device. Record which devices and which scan classes are affected.

Is layer one and the TCP session actually up?

Layer one first. A stall in the subscription layer and a dropped TCP connection can both show stale quality, and you only need the module fix for the first one.

Check: if the device stays connected and the PLC answers on the wire while its tags sit at Uncertain, the break is inside the gateway. Move on to classifying it. If the device drops its connection, fix the network or the PLC connection limit first. A new module will not cure a lost socket.

Which failure mode is this: subscription stall or throughput overrun?

Two different faults produce stale tags on 7.8. Whether the tags recover by themselves separates them.

A throughput overrun happens when the driver cannot finish one poll cycle before the scan class asks for the next. Each Modbus TCP request carries a limited block of registers and waits for a response. The PLC answers one request at a time on a connection. With enough tags at a fast enough rate, the cycle time exceeds the scan period and updates arrive late. Tags then flicker stale and recover.

Check: leave one affected device alone for a full shift without reapplying anything. If its tags stay stale until you intervene, treat it as a subscription stall. If they come back on their own, go to the throughput section.

How do I replace the OPC-UA module on the gateway?

The fixes for the 7.8 OPC-UA subscription problems ship in later builds. The 7.8.1-beta1 build contains all the fixes made at that point. Installing the OPC-UA module from 7.8.2 Beta2 also cleared persistent stale tags. Inductive Automation technical support will also supply the current patched module on request.

1. Take a gateway backup from the Gateway web interface before changing any module.
2. Get the patched build: the full 7.8.1-beta1 or later build from the official downloads, or the standalone OPC-UA module file from Inductive Automation support.
3. Decide on scope. Upgrade the whole gateway to the patched build, or swap only the OPC-UA module. Upgrading the whole gateway keeps module versions consistent. Swapping only the module is the smaller change for a running plant.
4. Install the module from the Gateway web interface module configuration page. The drivers run inside this module, so every Modbus TCP and Logix device reconnects when it restarts. Schedule it as a comms outage.
5. Confirm the new module version is listed and running, and that every device returns to connected.
6. Reapply scan classes once on all tags to clear any subscriptions left stalled under the old module.

Pitfall: a beta build in production is a change-control decision. Run it on a test or redundant backup gateway first if you have one. Move to the release build carrying the same fixes once it is available.

Check: the module page shows the new version, all roughly 80 devices report connected, and every tag reads Good right after the restart.

What if tags still go stale periodically after the module update?

Any stale tags that remain after the patched module and recover on their own point to throughput. The gateway is not reading enough data per second for the tag count and scan rate you configured. Reduce the load on the slowest devices:

1. Find the devices whose tags go stale first. Count their tags and note which scan class each tag uses.
2. Move tags that do not need fast updates, such as setpoints, totals and configuration values, to a slower scan class. Keep the fast class for values that drive alarms or control.
3. Group Modbus addresses into contiguous register blocks where the PLC map allows it. The driver can then fetch many tags in one request instead of scattered small reads.
4. Remove tags that are unused or duplicated. With 80 PLCs, leftover tags from commissioning add real polling load.
5. Review the device's request-size and timeout settings on the gateway device configuration page against what the PLC supports. Increase request size only as far as the PLC accepts.

Check: during a stale window, compare the device's poll or response timing on the device status or diagnostics view against the scan class rate. The cycle has to finish comfortably inside the scan period.

How do I verify the fix end to end?

1. Pick a representative set: the devices that failed most often, the ones with the highest tag counts, and at least one Logix device if the gateway has any.
2. Write a changing value in each PLC, such as a counter or heartbeat register, and trend it in the gateway at its scan class rate.
3. Run a soak test longer than the longest interval you saw between stale events before the fix. Do not reapply scan classes or restart anything during the test.
4. Log every quality transition away from Good, with device and time.
5. Pass criteria: no Uncertain quality, no red X or config-error overlays, and a heartbeat trend with no flat segments on any device across the full soak window.

FAQ