I have a customer who setup many trigger tags as follows so they can save a list of tag values to a database.
if initialChange == False:
if currentValue.value != False:
tagList = ["tag1", "tag2", "tag3"]
time.sleep(2)
logger.debug("Tag change event on %s" % tagPath)
system.tag.readAsync(tagList, myCallbackFunc)
time.sleep(5)
system.tag.writeBlocking([tagPath], [0])
When a trigger tag is set the above code writes the tagList to a database using the myCallbackFunc.
Am I correct in advising them to move away from this processing of the data? I believe time.sleep() is an inappropriate function to use here and I am not even sure why they need it.
Would I advise them to move to a Transaction Group? They seemed to have gone to great lengths to not use Transaction Groups even though they have the module.
Are these in the tag change scripts or gateway tag change scripts?
If this is on tag change scripts, I would love to see how bad the metrics on the tag providers are.
Legitimately this is where they should be using Event Streams with Tag Events set as the source.
1 Like
Event streams might actually be better for them. They upgraded early to 8.3 and are claiming to have more issues after upgrading.
If you have them replace system.tag.readAsync() with system.opc.readValues() (guarantees post-trigger values), you can get rid of the sleep operations. The final tag write should be Async if not a memory tag.
However, system.opc.* is as dangerous as .sleep() in a tag event. These should be gateway tag change events in a project, not attached to tags.
1 Like
The trigger tag appears to be a PLC tag in all the cases I have identified so far.
All this functionality with the database handlers easily scripted in using the exact same script, just this time its in part of the system where its easy to maintain.
If they won't buy the Event Streams module, Phil's advice is the way to go.
1 Like
I will advise them to go down this route for this particular issue. Thank you!
