Hello All. Long time troll, first post. Usually I can find the answers to my questions here or by reviewing the Inductive University videos. Thanks for all the info!
I am using a standard transaction group to perform a data look up. Hence DB to OPC. The group is using a custom index and the update/select table action with a key/value pair. Worth noting, I am using OPC items directly to avoid tag group rate delays. I have a trigger tag from the PLC and am writing back values for success or failure. This works great 99.9% of the time. And I always receive the DB data before the success value when it works.
Intermittently, I get the success value with no data from the table. No errors, failed executions or log entries. I have waited up to 5 minutes for the data and it never arrives. Any ideas on why this may be occurring?
Any chance you simply have no row that matches your criteria? An empty result set is still a "success". Consider using a script instead of a transaction group when you have corner cases like this.
I have been trying to monitor that as closely as possible. I am logging a reject table for this and other rejects. They always seem have a valid matching part number string in the table. Also I check in the PLC that the data is loaded prior to triggering the group. I set it up this way because we were doing it in another gateway project. I will look at moving to a script instead. I appreciate the suggestion.
To anyone watching this post I wanted to make a quick update.
I switched to using a script instead of the transaction group as suggested by @pturmel. Unfortunately I still encountered the same issue. Phil's comment:
Any chance you simply have no row that matches your criteria? An empty result set is still a "success".
Got me thinking that the PLC tag being used for the WHERE clause must be empty when the trigger was active. Probably should have coded the script better.
I added a delay timer in the PLC to ensure the WHERE clause tag was loaded prior to the trigger. This eliminated the issue. Out of curiosity I switched back to the transaction group to evaluate its behavior again. It also worked without issue after adding the delay timer.
Are you confident that, in the PLC code, the trigger tag was last to be written? And using OPC Mode == "Read" in the transaction group instead of "Subscribed"? With those criteria, you should not need a delay.
Any use of "Subscribe" for anything but the trigger (which does get subscribed anyways), including indirectly through OPC tags (instead of OPC items in the transaction group), leaves delivery order up to chance.
I was pretty certain the trigger tag was the last to be written to. Although in these modern processors I have ran into odd issues with the interrupts.
Honestly I have not ever changed the OPC Mode in a transaction group. Guess I will have to go back and try that now also. Thanks for the additional feedback Phil!