How to break tag history when a downstream Modbus device fails (comm status only exists as a PLC tag)

Ignition
,
1

Hi everyone,

I'd like some advice on what the accepted approach is for this architecture.

Setup

  • Ignition [8.1.49], single Gateway.
  • The only device the Gateway communicates with is one PLC: Gateway is the OPC UA client, the PLC is the OPC UA server.
  • Every other device in the plant is a Modbus TCP slave of the PLC, not of Ignition. The only exceptions are hardwired I/O (DI, DO, AI, AO).
  • The Gateway therefore never talks to those slaves directly — it only sees their data and their status through PLC tags.
  • The PLC provides one "comm fail" bit per Modbus slave, which I bring into Ignition as OPC tags.

image
image910×500 6.6 KB

What already works
Those comm-fail bits drive an animation on the HMI screens, so the operator can clearly see that a given device is offline.

The problem
While a slave is offline, the tags belonging to that device still have Good quality from the Gateway's point of view — the OPC UA connection to the PLC is perfectly healthy — so the Tag Historian keeps logging the last value the PLC managed to read. On a trend this produces a flat line, which an operator can easily read as "the process was stable" instead of "there was no data at all". What I want is a real gap in the chart for that interval.

I'm aware that when a device connection at the Gateway level goes down, the historian logs a bad-quality record and the chart breaks the pen accordingly. In my case, the connection that actually failed (PLC → Modbus slave) is invisible to the Gateway.

What I considered and don't like
A Gateway Tag Change Script on the comm-fail bit calling system.tag.configure to toggle historyEnabled on the affected tags. I don't like it for two reasons: changing tag configuration at runtime is fragile (a partial failure leaves tags in an inconsistent state and troubleshooting becomes very unpleasant), and as far as I understand it wouldn't even solve the problem — with no bad-quality record stored, the chart would just interpolate a straight line across the gap, which is the same misleading picture I'm trying to avoid.

Has any of you run into this?

Any ideas on how to work around it?

Thanks!

2

One thing that would help me a lot would be the ability to put an expression binding on the tag's History Enabled property, so I could point it at my comm-fail tag. Since everything is inside UDTs, that would be easy to roll out, and in my opinion it would no longer be a "bad practice".

The problem is that bindings on those properties can only reference UDT parameters — and the parameters themselves can't be bound to anything. They can only be edited directly by the developer, or through a script at runtime (bad practice again).

3

No, still a bad practice, as anything other that value changes involves a tag restart (config changes).

I have a tag actor solution to this in mind... coming soon to my Integration Toolkit.

4

How many tags are we talking about?

If it’s not too many, you could consider the OPC tags from the device to be “raw source” material, and then create a separate set of expression or derived tags that used forceQuality, conditionally based on the comm status bits, to force bad quality. History would just be enabled perpetually on these, and not at all on the source tags.