Database write from tag historian is delayed by one value (sort of)

Ignition
, ,
1

Hello everyone!

I've notice a quirk of which I'd like to ask two questions -

  1. Is this normal behavior, or is something weird on my end?
  2. If this is normal, what's the best way resolve the issue? If it isn't, how can I fix this?

I have my Ignition (v8.1, perspective) system reading tags from my ControlLogix PLC, and writing these tags to a MySQL database (hosted on the same system as Ignition) via the default tag editor's "history" functionality. I think this is called tag historian? My tag in question is a floating point number and is being written "on change" with 0 delay between samples (min/max) and the default 0.01 deadband settings. I suspect this is occurring with other data types i.e. integer as well, but I haven't confirmed. My physical process driving these tag values is only updating every few seconds or so - call it something on the order 20 updates/minute.

I've noticed that there is an offset between the most current data in my database versus the PLC tag's and Ignition tag's values. The PLC and Ignition could both have a tag value of say 5.0, but the database doesn't have that value yet. It is delayed by one write it seems, having only up to the previous value. When I open the tag diagnostics page in Ignition, the "Last published value" field is seemingly correct - it will show the actual date/time, and that value of 5.0, along with a "Good" data condition. In the History -> Deadband -> Last Stored Value & Last Stored Time fields, however, I see the previous value. So it seems like this is working normally, but I don't quite understand why it would be like this, or how to fix it. At the end of a production shift, the final value (e.g. that 5.0 value) should be written to the database, but due to this behavior simply isn't, and my data is out by one value. I'm hesitant to use a brute force method such as writing in a 0 to the PLC tag or something as I don't want that to cause the next production shift to have that 0 logged.

Your time and thoughts are greatly appreciated, thank you in advance!

2

This is deliberate and documented for analog mode history storage. Part of the "compression" technique that waits for a deviation from a recent trend before committing to write.

3 Likes
3

Excellent as always Phil! Thanks so much for cluing me in on which parameter was causing this. After reviewing that section of the manual (located here for future readers), I believe simply changing to discrete storage will be absolutely fine for my application. It seems like the only thing I lose out on is interpolation, but as this is sampled on change and at such a low frequency I don't actually miss any data anyways - so there's nothing to interpolate. I could absolutely see analog storage being much more useful for a more unstable application.

Have a great rest of your day!

2 Likes