# Tag refresh rate **URL:** \ **Category:** Ignition\ **Tags:** ignition79, ignition80\ **Created:** [July 26, 2019, 6:54am UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898 "2019-07-26T06:54:21Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![pawel.kondol](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@pawel.kondol](https://forum.inductiveautomation.com/u/pawel.kondol)\ **Post date:** [July 26, 2019, 6:54am UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/1 "2019-07-26T06:54:21Z")
Hi, I have time tags, each integer tag as separate values representing Seconds, Minutes, Hours etc. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/1/1c9ceb093d59485b0b3d2fe59cff599a786d6541.png) 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 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 26, 2019, 2:44pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/2 "2019-07-26T14:44:11Z")
> [@pawel.kondol](#): > > Is there any queing refresh rate or refresh aftrer single tag refresh. 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. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [July 26, 2019, 3:27pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/3 "2019-07-26T15:27:22Z")
> [@pturmel](#): > > read the others using system.opc.read…(). 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 26, 2019, 4:28pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/4 "2019-07-26T16:28:56Z")
> [@chi](#): > > 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. 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). ---
**Author:** ![pawel.kondol](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@pawel.kondol](https://forum.inductiveautomation.com/u/pawel.kondol)\ **Post date:** [September 26, 2019, 2:11pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/5 "2019-09-26T14:11:20Z")
Thanks for all the answers. At least I know there is not much I can do about this. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 26, 2019, 2:19pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/6 "2019-09-26T14:19:55Z")
> [@pawel.kondol](#): > > there is not much I can do Well, no, not if you are hung up on keeping your existing separate tags. But you can make this _ **so** _ much better if you follow any of the suggestions. ---
**Author:** ![pawel.kondol](https://avatars.discourse-cdn.com/v4/letter/p/96bed5/32.png) [@pawel.kondol](https://forum.inductiveautomation.com/u/pawel.kondol)\ **Post date:** [September 26, 2019, 2:34pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rate/26898/7 "2019-09-26T14:34:18Z")
Unfortunately it is beyond my knowledge at the moment. I may come back to this when I educate myself bit more.