MQTT tags go stale due to UNS report-by-exception

Ignition
,
1

A general issue with tags originating from the MQTT Engine and an underlying UNS way of transferring data is that tags can go "Bad_Stale" after some period of time.

There might be a lot of tags from lets say a PLC that does not change very often, and is maybe not expected to change unless something is wrong.
And as an underlying UNS rule, these types of tags should not be reported on unless they change to keep the communication resource lightweight. This is RBE (report-by-exception).

However, even though the tags go stale and get a flaming red overlay in the perspective session, the tags can still be written to, updating the value on the PLC and propagating back as a change and a good quality.

I know I can do a custom overlay and opt-out of the default ones, but I will then lose all other error overlays.

Now, my question is; is there a way to get around the stale quality issue?
How is the time until stale actually calculated? And is it possible to adjust this for certain tags?

I don't see a direct way to adjust the time until stale in the Tag Group Editor, or anywhere else for that matter, but I did find this from pre 8.0 versions without it explaining too much:

image
image1042×211 13.1 KB

I'm at the point now where I'm considering doing only RBE on a higher level, like an entire PLC object, to ensure that the tags don't go stale.
Any insight on the subject would be helpful :slightly_smiling_face:

2

I noticed this problem and I remember that when at least one tag was communicating quickly within the Device_ID, the quality of the other tags remained good.

3

Yes, this is true if the RBE is applied on the Device level.

We are using HighByte to convert from OPC-UA to Sparkplug, which can filter on "Only Changes, compressed". Essentially this filters all the way down to individual tags in the metric name:

image
image716×301 13.7 KB

If I set this to "All values" then it would function the way you describes, but I would still send a lot of unnecessary duplicates of unchanged values living under the Device_ID.

So yes, that's an option but not ideal :slightly_smiling_face:

4

I would contact Cirrus Link and ask them why the value is getting set to Stale quality in the first place. AFAIK that is not something Ignition is doing, and that stale timeout property on tag groups is mostly a legacy thing.

5

Ok, I will try my luck with Cirrus Link.

Thanks for the clarification :+1: :grinning:

6

So I have a similar problem. I have Ignition Edge with Trassmissin and Ignition with Engine. Some values ​​within Device_ID have not changed for 2 days and their value in MQTT Engine has changed to null. Have you ever seen it too?

Thank you for answer.

7

https://forum.cirrus-link.com/search?q=value%20in%20MQTT%20engine%20null