Tag refresh rates on tags / tag change scripts

Ignition
1

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

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?

3

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
4

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.

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

@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!

7

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
8

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.