[Bug] Ignition 8.1.7: missing tags in nested UDTs after a gateway restart

  1. Unexpected behaviour
  • Some tags are missing in nested UDTs after a gateway restart.
  1. Expecting to see
  • No tags missing in nested UDTs after a gateway restart.
  1. Steps to reproduce the issue
    Please see the attached UDT file. Gateway backup cannot be attached due to size limit
  • Importing the target UDTs (with nested UDT instances) with policy ‘overwrite’.
  • Checking to see that no tags are missing.
  • Restarting the gateway.
  • Checking to see missing tags in the nested UDTs (the tags missing may differ from time to time, or from UDT to UDT).
    image
    image
    image
  1. Helpful information
  • We have not experienced this issue if the UDTs are created/modified directly in the designer (i.e., not importing with policity ‘overwrite’)
  • The tags missing can be recovered by applying ‘restart tag’ function in the context menu (i.e., right-click) on the affected UDT.
  • Ignition version: 8.1.7
  • Windows info (running Ignition designer): Windows 10 Pro Version 20H2, OS build 19042.985.

UDT_root.json (44.1 KB)

1 Like

I’d be interested, if you had any property overrides on within that folder or on the nested UDTs’ tags in general, if these overrides are still present in 8.1.7.

FWIW we have been seeing the same thing across multiple customer installations. We have a ticket in on this exact issue and are waiting on a resolution or a work around. This isn’t happening on 8.1.5, just 8.1.7. It is definitely a crippling bug for sure.

Thank you for your interest.
I did a test to see whether overrides would retain after the missing tags are restored - and the overrides still exist after applying ‘restart tag’.
Please see the attached gif as a proof.
overridesRetain

1 Like

Thank you for your information.
Our workaround is to apply ‘restart tag’ option (in the context menu) to all the UDTs after a gateway restart.

We tried to replicate this ‘restart tag’ behaviour with a script (i.e., using system.tag.getConfiguration() & system.tag.configure()) activated upon a gateway start-up event - and we did not succeed.

We hope to see this get fixed in 8.1.8 soon.

Awesome, that’s good news. Otherwise it would be a major bug, thanks for checking! Not that it isn’t at the moment, but certainly far less so than removed data

The biggest issue is on a server restart you have to do this… and if you are remotely located and this occurs in the middle of the night then it can be catastrophic for a customer.

@bao.nguyen Thanks! I’ll relay this info to my colleagues and have them test it as well.

We had a ticket open for something that sounds exactly like this… Inductive just closed it on me without it being resolved… I worked around the problem by completely redesigning my tag structure for the affected UDT’s.

And it wasn’t only on startup… I’d have UDT structures just magically disappear.

Good luck getting this resolved!

Bill S.

1 Like

Bill,
Could you explain how you changed your tag structure to work around the issue?

Yes please Bill, could you explain what you did?

FYI it appears that this has been fixed in 8.1.8:

Data Model
Fixed an issue where UDT Instance members sometimes weren't showing up after upgrade or restart.
1 Like

I am using 8.1.7! That is good news, thanks bschroeder. Ill make the upgrade.
The problem seems to have settled for now, I lost my UDT tags 3 times in a row after gateway reset. But has stopped happening for now, still using 8.1.7.
At least now i’m ultra-zealous about saving my UDT’s and Tags… :slight_smile:

I’m having this same problem in 8.1.7
I see that 8.1.8 is not available for download but I see the same release note (pointed out by @bschroeder - good catch!) in 8.1.9
Has anyone verified that this is fixed in 8.1.9?

We have upgraded our gateway to 8.1.9 recently - the problem has been fixed since then.

1 Like

I am using 8.1.20 but I am also facing the issue of disappearing the few UDTs and Tags. Can anyone tell me the solution. I am creating tags using device connection using siemens s7-1500 PLC.