We’re using Ignition 8.0.3 on a project that’s been online at a customer’s site for a couple years. We got called in out of the blue because they were suddenly experiencing a loss of some of their process data. When I took a closer look, I found that three of OPC tags were “Bad_Stale” (accounting for the loss of data), but the rest were fine. More than that, the tag paths were still seemingly valid. In fact, dragging the tag to a different location made it work again. Copying the tag resulted in the copy working. Changing the tag group to one with a longer rate made it work again, but if I changed it back to the original tag group it would stop working again.
The PLC code had been updated a few weeks prior, but not immediately before losing data. There were no other known changes to the system, and the gateway shows it’s been up for about a year (but the data loss began two months ago).
Why did those tags stop working (when the rest of the tags using that device connection were fine), and why was copy-paste-rename a functional solution? I’d like to know how to avoid this in the future.
For additional context, the OPC tags are PLC tags in an AB PLC we’re connecting to with the Allen-Bradley Logix Driver.
Thanks in advance.
If you still have the logs support might be able to do a bit of a postmortem but ideally you would have made a call while it was happening.
I strongly recommend upgrading to the most recent release your customer license allows for. The early 8.0.x releases were a little rough.
I still have instances of the old tags that don't work, fwiw:
I just don't have logs reaching back to when we initially lost data. The logs seem to be overwhelmed by DiskDataStore errors and warnings - would those be related, do you think?
java.io.FileNotFoundException: C:\Windows\Temp\jetty-0.0.0.0-8060-main-_-any-9178578943319093773.dir\WicketFilter-filestore\7397\973\node0e2a0dwtokhdk1p63bu58jxthj1\data (The system cannot find the path specified)
at java.base/java.io.RandomAccessFile.open0(Native Method)
at java.base/java.io.RandomAccessFile.open(Unknown Source)
at java.base/java.io.RandomAccessFile.(Unknown Source)
at java.base/java.io.RandomAccessFile.(Unknown Source)
at org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:425)
at org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:343)
at org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:181)
at org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:355)
at java.base/java.lang.Thread.run(Unknown Source)
Hard to say if it’s related, but I’d say at this point that gateway is in need of a restart when downtime permits.
What causes that type of DiskDataStore error? Is there a recommended limit for how long a gateway should be up before needing a restart? I should be able to restart it today and see if those errors stop flooding the gateway.
It looks like maybe a temp directory got wiped out from underneath it? I don’t know how/why that would happen.
There shouldn’t be any need to regularly restart a gateway. If one does need to be continually restarted something is wrong, either with Ignition or with something that has been implemented in Ignition (not likely in this case).
Support or somebody else here in the forum could maybe say if they’ve seen an error like this before.
+1 We ran into a lot of odd tag issues in the 8.0.x realm (duplicate alerts, tags going stale, etc). Haven't had any of these issues on 8.1.x (...scrambling to find a piece of wood to knock on...).
Restarted everything and now the tags work and the DataDiskStore errors stopped flooding in… ¯\_(ツ)_/¯
Would you expect any issues going from 8.0.3 to something like 8.0.16 in terms of backward compatibility? Should I just be able to upgrade it and import the project or will it be potentially more of a hassle?
You should be able to just upgrade - no importing a project needed. Just run the installer. Make a backup first.
If the license allows for 8.1 that would be better because the 8.0.x line is EOL and not receiving updates any more.
1 Like
Thanks for the help and fast responses.
