I am learning Ignition and am curious what under what conditions Transaction Group Status information gets reset. It seems to get reset whenever I save changes to the project. What I am looking for is if I can reset it automatically, either based on a time of day or a tag value change?
Hi,
Yes, it resets when the group is restarted, but beyond that, there is no way to reset it arbitrarily. It basically is meant to track the lifetime of the running group, which for some people is probably pushing into years. However, it’s purely a diagnostic mechanism, so it wouldn’t be a problem to add a reset button on that panel. I don’t think we’ll add any way to have it reset automatically, at least not directly. There have been requests to expose the stats through Status Tags, and if that happens, there will likely be a writable reset tag, that you could bind up to reset automatically, I suppose.
Regards,
I am looking to replace another vendor’s product with something like the SQL Bridge module, and I want to make sure the solution I choose has the monitoring capabilities that I need. I plan to to use the SQL Bridge module to update our production line tracking database so when a unit passes a tracking point, a PLC bit goes high, and based on the particular PLC and tag address (ultimately the tag name to Ignition), a stored procedure is run and the database is updated based on the tracking event. We need to able to monitor these events and be alerted if the tracking process fails, be it if Ignition is cannot poll the OPC tag (alarm on bad quality?), if Ignition cannot execute the stored procedure due to a database issue (write handshake on failure and alarm based on this Boolean tag going high?), or if the stored procedure returns an error code (output parameter written to a tag with alarms on certain values?). Do my ideas in parentheses make sense and do you believe they would cover the range of failure types in these processes? I also envision creating an HMI screen that would give an overall status view of all tracking points (last tracking attempt successful = green, last failed = red, maybe heat map colors getting less green as failures increase), showing a history of successes and failures for the current shift, and being able to go back and show the history of successes and failures of previous shifts. Does this all sound doable today?
Hi,
All of that sounds pretty good. Creating a history of successful vs. failed runs might take a little work, and I think if possible it would be nice to have some sort of “heartbeat” monitoring where if the group doesn’t run within the expected amount of time (assuming there is an expected amount of time), a failure is reported. I think this all might be possible through two groups per tracking point.
How many of these tracking points are there?
Regards,
250 tracking points, increasing to maybe 300 in the next few years with our plant expansion.