Hi, so the fundamental issue is we have boolean OPC tags (polled via OPC-UA, this is important see below) that are valid live and correct, that have historians attached set to record on change, and the changes do not seem to be captured in the data bases.
The full description follows:
We are replacing an old hardware screen based HMI that is failing with an Ignition screen. One feature of this screen was a fault table. There are ~300 or so faults (there are six identical modules that can throw the same faults so ~50 separate faults, on 6 modules).
To avoid crudding up our databases as we integrated this, our IT team had us use a test SQL database for the historian. Everything worked swimmingly.
I then mass selected the tags, Edit Tag, for Storage Provider switched to our production database and... nothing. There are only a few errors that we can safely force high - door opening interlocks, Estop button presses, and errorneous settings requests - and the remaining errors happen to rarely for us to have a pattern on them yet, but it seems that when a fault changes state from high to low or back again, it is not historicized.
The only thing I can think is somehow in transitioning from one historian DB to the other something was missed?
The tags all show the new historian as their storage provider.
No other changes about their History properties were changed from when they were directed to TestDB - and worked fine.
The tag changes after the DB transition are not reflected in the old DB, and the tags are all visible in the sqlth_te database on the production DB - so its not that they're misdirected.
The tags live two folders deep (one folder for the PLC they come off of then a separate tag folder for alarms, as there are so many we don't want our normal tags to be lost in a haystack) this didn't matter for the test DB
When we create a new memory tag in that folder, with the production DB as storage provider and toggle it, we DO see the tag pop up on the DB.
It really does seem like something was lost in pulling the tags from using one historian to the other, as the magic seems to be 'they work out of the box but fail if transferred'.
The answer to the obvious question is the sqth_te database will be 40% by volume fault tags for this one device if I simply delete and recreate these tags anew with the production DB as their storage provider. And 20% will be 'retired', dead tags. Not a catastrophe, but it bugs me a little bit to accept this as a solution.
The code that populates the fault table on the HMI also filters on tag path and as we'll have 2 copies for every tag path, one retired and one active I do worry that will break something else.
Filtering on tagid would work for now as all tags will exist in one contiguous block, but if we ever add another tag, the fragmented nature will make the code a mess.