I'm working on (re)writing some code, which logs CNC machine statuses. There's some logic with translating from the machine's statuses to a shared set, and HMI overrides to the status, but nothing too complex.
The previous solution was using gateway event scripts on the machine status tags, doing the translations in scripting, writing them to tags, and then using transactions groups on these tags to store them.
Considering that all the transaction groups are doing is waiting for the script to finish, and then writing the data to the database, a simple named query at the end of the script is likely a more elegant solution in this case.
Are transactions groups mostly meant for the mid-complexity use cases, which are more than the Historian is built for, but not enough to warrent writing a whole script? For example storing a value whenever a second "latch" value comes on?
Are there that many people working on your ignition system without scripting knowledge, that it's a useful tool to have?
My initial guess was that transaction groups would be a lot faster than scripts (because they're only using expressions). But, I can't find a way to have them run off UDTs, which are the only way I can see having enough objects to justify the performance (unless you write 500 transaction groups manually?)
Java thread pools and race conditions.... I though I had escaped those.
Anyways, looks like some very useful reading that I'll delve into later.
I keep meaning to download the toolkit module (as well as some better charts for perspective), but unfortunately my boss is a bit wary to include 3rd party modules.
