# Tag refresh rates on tags / tag change scripts **URL:** \ **Category:** Ignition\ **Created:** [May 14, 2018, 5:15pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023 "2018-05-14T17:15:51Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![compuzak](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@compuzak](https://forum.inductiveautomation.com/u/compuzak)\ **Post date:** [May 14, 2018, 5:15pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/1 "2018-05-14T17:15:51Z")
I am having some problems in a script with tags not updating quickly enough and I am accessing the tag before the tag has changed. I change the tag refresh rate and use time.sleep to delay and it works correctly, but this slows down my processing loop quite a bit and I am worried about fluctuations in the refresh time and added overhead to the Ignition server. I have a couple questions: 1. Why does a memory tag have a refresh rate for the tag itself? I would have thought that it would be instantly reset each time the tag is set (since there are no external devices changing the tags, just the Ignition program). I fully understand a refresh rate on OPC tags, but I don’t understand one on memory tags. 2. Will it cause performance problems on the Ignition server if I put 10ms refresh rate on a memory tag? 3. I have had delay problems in scripts before when I run them in shared threads. Do the “tag change” scripts run in a dedicated thread or a shared thread? I don’t see where I can set the thread sharing type on a “tag change” thread, like I can on “timed threads”. ---
**Author:** ![compuzak](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@compuzak](https://forum.inductiveautomation.com/u/compuzak)\ **Post date:** [May 14, 2018, 5:26pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/2 "2018-05-14T17:26:00Z")
Also, I have text box on a window that I enter data into and then access the data “on property change”. I have the tag set to refresh every 100ms. I set it and then wait 200ms, but sometimes I get the old data when I access the tag. Does the client poll rate in the project parameters override the tag refresh values? ---
**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:** [May 14, 2018, 7:19pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/3 "2018-05-14T19:19:11Z")
Client poll rate is the fastest a tag update can be noted in a client. I suspect you are struggling with tag changes that are both initiated and monitored at one client. Such changes must make the round trip to the gateway, and I believe will only trigger a client tag change event on the read/return. Side note: under no circumstances should you **_ever_** use time.sleep or it java equivalent. Always use system.util.invokeLater in the client, and delegate to a timer script state machine in the gateway. ---
**Author:** ![compuzak](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@compuzak](https://forum.inductiveautomation.com/u/compuzak)\ **Post date:** [May 15, 2018, 1:25am UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/4 "2018-05-15T01:25:19Z")
pturmel thanks for the information on the client poll rate. The tag changes are actually done in gateway scripts(either a timed script or a “on tag change” script). The client is accessing the information and processing it, so my delay was the client poll rate. Once I lowered that, everything started working much better, thanks. Any feedback on the 3 questions I originally asked? Not sure exactly how this forum works, new to it, so if these should all be posted separate, please let me know. ---
**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:** [May 15, 2018, 5:43pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/5 "2018-05-15T17:43:46Z")
> [@compuzak](#): > > Any feedback on the 3 questions I originally asked? 1. Don't know. 2. Probably not, if not many tags are involved. 3. Shouldn't matter, as you should never, _ **ever** _ use any form of sleep(). ---
**Author:** ![bill.diblasi](https://avatars.discourse-cdn.com/v4/letter/b/8baadc/32.png) [@bill.diblasi](https://forum.inductiveautomation.com/u/bill.diblasi)\ **Post date:** [June 17, 2018, 11:47pm UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/6 "2018-06-17T23:47:21Z")
@pturmel I know you probably considered this already in your response but I wanted to ask a specific follow-up question regarding best practices - I am executing some named queries on tag value change (i.e. `'tagStart' = True then INSERT new batch row. 'tagStart' = False then UPDATE completion time`) - Since my database is going to grow over years of data collection, should I be concerned about Client lag during these actions? My thought was maybe I should put the named queries in a shared script and access them using `invokeAsynchronous` from the tag change script? - Should I be using Gateway Tag Event scripts instead of the direct tag change scripts? While I have the time and inclination right now to build a robust program, I do not have the experience 😅. Just wondering if anyone could offer advice! ---
**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:** [June 18, 2018, 12:16am UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/7 "2018-06-18T00:16:12Z")
> [@bill.diblasi](#): > > should I be concerned about Client lag Not if these are gateway events. However, you might impact a scan class if you are using tag events. I strongly recommend avoiding all of the Tag Events (the ones defined as part of the tag itself). Use Tag Change Event Scripts in a project, and list all relevant tags for the one script. These events use a different Thread Pool, and have the option for a dedicated thread. And they can call project scripts. That helps minimizing total gateway script restarts due to shared script edits. > [@bill.diblasi](#): > > Should I be using Your nomenclature wasn't quite clear. See how I described them. ---
**Author:** ![bill.diblasi](https://avatars.discourse-cdn.com/v4/letter/b/8baadc/32.png) [@bill.diblasi](https://forum.inductiveautomation.com/u/bill.diblasi)\ **Post date:** [June 18, 2018, 12:32am UTC](https://forum.inductiveautomation.com/t/tag-refresh-rates-on-tags-tag-change-scripts/18023/8 "2018-06-18T00:32:11Z")
Thank for the reply, and I will update my nomenclature moving forward. I had a feeling the Tag Change Event Scripts were a better alternative to the Tag Events. With many paths to the same solution I got a little lost down this rabbit hole! Now that you mention the dedicated thread option that is built into the Tag Change Event Scripts, I realize the answer was more apparent than I thought 🙂. Also, duly noted that I have again mixed up Client and Gateway actions! Thank you for the reminder.