I have time tags, each integer tag as separate values representing Seconds, Minutes, Hours etc.
I have combined them together to tag as DateTime then I have transaction groups triggered every second for this DateTime tag and few other.
The problem I have is that sometime I received information for tag Minutes faster than tag Seconds.
SO I may have combined tag
a) Fri Jul 26 07:50:59 BST 2019
b) Fri Jul 26 07:51:59 BST 2019
c) Fri Jul 26 07:51:01 BST 2019
d) Fri Jul 26 07:51:02 BST 2019
So in b) it jumped 1 minute ahead and then in c comes back to normal.
This is happening every so often. I am just wondering what can be done to fix it.
Is there any queing refresh rate or refresh aftrer single tag refresh.
Best regards
Pawel
No. What you are seeing is a normal side effect of any communication that subscribes to individual data items -- you don't have control of the order. For your specific case, you should only subscribe to (have a tag for) Seconds, and when it changes (tag change event), read the others using system.opc.read....(). Assemble your timestamp from the result. I would write the result to a DateTime memory tag that other parts of your system can subscribe to.
Very thin ice here! For second 59 e.g. it totally depends on communication and execution speed what minute (or what day in the last minute before midnight) is returned.
You will have to find a way to receive consistent data from your device. A custom TCP packet or some kind of handshake would be an alternative, but what you are trying to do is not an easy task.
No question that there's no magic bullet for multiple entities. But trigger+read is less thin than just subscribing to all. It can be improved by including the trigger object in the low-level read to ensure it hasn't changed. That will generally be executed as a single-packet read, especially if the elements are consecutive array or structure items. You are right though, best is a single element that embodies the entire object, like the packet read you suggest (my Ethernet/IP driver is ideal for implementing such traffic). Another option is to use a date-time type that can be held in a solitary intrinsic type, like a 64-bit integer Unix microseconds (eg. AB LINT wallclock time).
