BLUF: Transaction groups sporadically fails to update a couple cell values, despite “Always store NULL for bad quality items” being unchecked.
I am trying to catch 4 events regarding an operation cycle and put relevant data in one row of a database table for each cycle (as required by the customer, so that they can embed the database table in some other software of their own). To do that, I created 4 transaction groups, first one creates the row with the rest of the values as null, the others update their respective cells when their trigger is active.
Although my logs show many “Trigger did not evaluate - source item currently has bad quality [[0, Unknown, …” info on the groups, I have no issues with the times the data is saved. Only problem is some of the cells are left as ‘null’ sometimes. Is there anyway that I can improve it not to miss any value? TIA.
How is your execution scheduling setup? I had a vaguely similar problem. I had a trigger as a tag value change, and had the schedule set between 2 times. If the trigger happened before the time frame the values didn’t record because they were not active. To fix this I created a run always tag, that was ‘1’ when it was a specific time, and “0” at any other time. This could be anything, not just a time parameter. This fixed my problem, because it had values for the group tags all day long, but only logged them when the time trigger went true. I haven’t missed any values since.
I’ve always found it far more reliable to have the PLC collect the various data items for a cycle and then set a trigger to collect them all together at the end. Then you can use OPC Read mode and single insert transaction to ensure the data items are read together, after the trigger.
Thanks for the reply. The tag associated with the missing value resides in “Basic OPC/Group Items” and executes every 1 second, and it is an OPC tag that comes from a P3000 PLC through Modbus. It is a setpoint that I need to record at the beginning of the sequence and at the end of the sequence, in case the operator changes it during the run (the customer wanted to ignore if it changes multiple times). Update mode is “Bi-directional OPC wins.” The trigger is a tag that indicates the sequence is active (1) or not active (0). The beginning of the sequence saves at the rising edge of the tag, the end of sequence saves at the falling edge. Since the value is a direct value of an OPC tag, I quite did not get why it does not save it to the database when trigger occurs. And it saves at one record, skips saving at another record. Also, there are timers within the same group that records the seconds during the sequence is active. That goes into the database without any errors. Any ideas if the gateway removes the tag value in between unsuccessful Modbus readings, and sends out a “null” value instead of the actual value?
Thanks for the reply. Although what you suggest is a better approach, the customer needs the data near-real time as the events occur. All can be done with the ignition in a better, easier, and healthier way, however, the customer does not want the hand held devices and scan guns to be handled by ignition or by the PLC through us, rather they have their IT working with another software company to come up with a solution that is integrated to their existing logistics system. My portion of it is to provide a row with each cycle and update the values as the sequences occur, so that they can mimic a real-time change in their screen by connecting to the database with their own software. And the transaction group basically - actually not so basically after all (-: - saves several set points, and pressure&temperature values as it progresses. I would suspect the database connections, store-forward system, CPU/memory performance, etc… however they all look to be more than sufficient. As I tried to explain, it is only with one tag value (float) inside a transaction group, that comes through Modbus at 1 second poll rate, and it saves sometimes, does not save other times with no pattern. Any ideas? Thanks.
I think that fixed the issue. What I did is, similar to yours, I created a Run-Always Expression Tag, and reflected the OPC tag's value directly into that expression tag. I am using the OPC tag inside "Basic/OPC Group Items" as read-only, and saving its mirror inside the "Run-Always Expression Items" to the DB. Now that it does not have an execution schedule, it is being written into the database (at least it did in the last 4 cycle )
)