Tag historian Vs transaction groups when storing data for OEE system

[pturmel]

@KeepItCurrent

read further

Start here:

Tag Change Scripts stop working

Every once in a while, we have a situation where basically all of our tag change scripts stop processing. I finally saw this error in the Console of the designer Diagnostics. It's almost as if the Basic Execution Engine has run out of threads. WARN Common.BasicExecutionEngine - Execution rejected... running in calling thread [AWT-EventQueue-0] immediately. [com.inductiveautomation.ignition.designer.tags.tree.TagTreeModelImpl$BatchOp$$Lambda$949/0x0000016597b1a668@d72dc75] Any ideas where I can…

For a detailed discussion of techniques for the last bit of advice in that topic, see this:

Java concurrent queue for tag change scripts

Continuing the discussion from [SOLVED] Are tag Value Changed scripts running asynchronously?: We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on …

@KeepItCurrent

perhaps run a duration calculation within the script

I recommend you not do this. Just store the timestamp, event value, and some kind of process/machine/component ID with S&F.

Databases are really good at delivering the actual durations after the fact using LEAD() or LAG(), without having to do anything special to account for system start/stop, scripting restarts, and/or tag restarts.