I made a driven tag group to update 9 tags in my database every time a pointer changes value. I left pretty much all settings default, but I made the driving expression be the value of the pointer (changes 1-20 then recycles back to 1 after 20) and I set it to 'Any Change' as the driving comparison. So everytime a product is finalized in its process, the pointer changes and I wanted to update the information associated with the previous into the database. Looking at it run all day, we've only triggered it about 10 times, but sometimes it has stored 7 tags, others 3, others 5... seems random.
On the tags themselves, under 'basic properties' I associated the tag group, then in history I enabled, picked my database, sample mode as 'tag group' and historical tag group as the tag group I made.
I definitely seem to have done something wrong, I didn't really change any other settings, so I am wondering if one of them is causing me a problem.
Have you considered just making a gateway tag change event that uses system.opc.readValues() to go get those values? And writing directly to a wide database table?
Have not gotten into the weeds on that at all, I am still very new to this!
I figured this Tag group and change thing should be simple, but already observing some peculiarities. I think part of the problem I am running into right now is the same rung of logic I am evaluating the changed pointer value, houses the information I want. I just watched it increment at the bottom of said rung from 5 to 6, and the saw that the information above it in the rung must not have updated to the new values prior to the pointer changing, which is odd... the scan through the same rung must go top down before it goes left to right, so I am considering changing the increment of the +1 to the pointer to be to the right of all the movements of data, as opposed to below it in the ladder, to see if that forces all data to be updated prior to the value incrementing.
but beyond that, which has nothing to do with a tag group, I really just kind of thought it was pretty straight forward to say update this tag group on change of this tags value, and all 9 tags should update. What am I missing?
Anyhow, I am also more than willing to learn what you are suggesting as an alternative as well. I would much prefer to write them to my own table anyhow, so each entry would be displayed in the same row without need to group by t_stamp and display in a more human friendly manner.
So, I need to read about Gateway tag change events, and just make a new table in my database to pass this information into? Is that the overall preferred method for these sorts of things?
Yes. If you really like drag-n-drop, you can do this directly with the SQL Bridge module, with OPC items instead of tags, and OPC mode set to "Read" instead of "Subscribe".
This worked very well, thank you for this suggestion!
the getTimestamp() displays in a manner I am not necessary in love with. I figured I could populate a column based on the timestamp it reads from one of the values. I am sure there is a way to just read the gateway timestamp and maybe it is more manipulatable into a format I want? I suppose I should be able to find this within the docs.
Timestamp objects in Ignition are java.util.Date, which are UTC milliseconds under the hood. You should deliver them as objects via "Prep" or named query parameters for your JDBC driver to convert to database format. Do not turn them into strings.
In the database, you need a column type that won't screw up the timezone--use datetime2 in MS SQL Server, timestamptz in PostgreSQL. (Or run the DB and gateway both in UTC.)
Worked like a charm! One of the examples in the ignition docs showed to and a .toString() to the backend of the timestamp, so I was doing that. Recreated the table with that column as a datetime2 (I know I am still using MSSQL sorry) and looks great!