Hi, We have a critical system that use transaction group.
A register is inserted each time a tag changes, this depends on the system behaviour could be each 5 minutes or in weekend could be only one time at day.
The problem is that on friday the transaction group stops without any information.
Customer calls us when data is lost on monday and we stop and start the transaction and everything goes fine again.
We need to monitor the status of the transaction group continuously, but we have not seen how to monitor via scripting or any other way.
I don’t know of a direct way to do it based on a tag change but you could do a tag event script to turn on a bool memory tag when the value changes(I’m assuming your looking for any value change to trigger your transaction group too). On the memory tag you can set up an alarm with an active delay that gives time for the transaction group to run. In your transaction group on the tigger tab, you can use the “Write handshake on success” function to set the memory tag back to 0. I would think doing this would give you an alarm that can be used for the status and allows you to set up an alarm pipeline to send off an email or sms message when there is an issue. By using the active delay in the alarm you should be able to set it to a point that prevents false alarms.
It’s a very good idea, and really interesting approach for knowing transaction status.
But in this case, I’ll know only that the system it’s not working after the first fault and maybe I could lose that data.
For me it’s preferible to monitor directly the status of the transaction, I’ve search for internal Java functions to get the information about the internal Ignition server tasks from gateway context but I’ve not been succesful.
I don’t understand why this information it’s not under system tags like OPC, Gateway, Alarms and database information. It should be there!
If the database causes the group to error out someone would have to manually restart it. If this is critical data that you don’t want to lose, I would look at other options for collecting the data if you want to make you always have it. But if your database connection goes down you will run into issues either way.
With the alarm I mentioned before, you could add the data points into the email so it can be manually entered later. I know that normally wouldn’t be preferred but if you have it emailed to you then you always have it unless something goes wrong with email too.
You could also add in a dataset memory tag that the data can be written to if there is a failure. In your alarm pipeline you could have a script read the dataset and the values you want to record then append the dataset. You could then give a method to review the saved data, then insert into your database, and then clear the dataset for future use.
You could even build a named query that does the same insert as the transaction group is set to do. In your alarm script you can attempt to run that named query and then check the value returned. When doing an update using system.db.runNamedQuery() it will return an int representing how many rows are affected. If your database connection is down it may error our so I would wrap it in a try/except and have the backup be writing the data to the dataset like mentioned above or sending it out in an email.
I know these aren’t what you would prefer to do but I don’t see any way to monitor the transaction group either and even if you could monitor it I haven’t noticed a way to re-start the transaction group through a script if it fails. With that being the case, I’d plan for a backup method in case things go wrong if its critical data. With any of the ones I mentioned, you would also want to clear the alarm memory tag at the end so it will trigger the next time the data should be sent out.
