Tag refresh rates on tags / tag change scripts

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”.

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?

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.

2 Likes

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.

  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().

@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 :sweat_smile:. Just wondering if anyone could offer advice!

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.

Your nomenclature wasn’t quite clear. See how I described them.

1 Like

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 :slight_smile:.

Also, duly noted that I have again mixed up Client and Gateway actions! Thank you for the reminder.