How do you increase performance for clients?

This somewhat works on a visionWindowOpened event:

system.tag.setOverlaysEnabled(False)
def enableOverlays():
	system.tag.setOverlaysEnabled(True)
system.util.invokeLater(enableOverlays, 5000)

Issues:

  1. It’s client-wide (unless it is gateway-wide–haven’t checked) so every time you open a window with this script it affects all windows (though that’s not visible if other windows aren’t showing overlays at the time).
  2. If you swap windows quickly, you can get interesting effects, like a previously scheduled enableOverlays function invoked later running right after the visionWindowOpened event so overlays are displayed after all.

I’m sure #2 could be worked around, but overall I like a loading overlay better because disabling overlays means we display incorrect “as configured” data on the page without any indication it is incorrect before live data arrives.

EDIT: Counterpoint–we could probably make the as-configured appearance of each component/template look the way we’d like them to before live data arrives so they display our own version of uncertain, rather than incorrect state.

Check how many tags you use for a window in gateway webpage - > Status → Vision Clients (select client session). If you use udt or nested udt all tags from udt in templates all tags from udt are subscribed. If you have big udt it is better idea to use tag path as parameter to template, and then get value by indirect binding.

1 Like

This is true, "big udt" or otherwise.

I use indirect addressing/binding for everything, with a few exceptions. I have as little as 24 subscribed tags for a screen, and it lags just the same as the screens with larger amounts of tags.

Can you explain what event you chose for this script @witman ?

How do you have your tag group configured for those tags?

What kind of PLC?

Tag group for the majority of the tags talked about is a default subscribed group @ 500 ms. I have lowered this to 300 ms with no change. PLC is a ControlLogix 5580.

@William_Rawson, the event hides overlay once bindings have been evaluated. You may need to add a bit of additional delay to it too.

I would very much doubt that lowering the rate would help your issue.

There are ways to get very fast tag updates (@pturmel’s Ethernet IP Module). The question is, do you really need that update rate? How quickly are the tag values changing?

There’s a moderately significant edge case (accessing templates through scripting) affecting Vision performance that’s fixed in 8.1.19+; upgrading may help with apparent performance regression from 7.9. It’s not a panacea, but it may help if you’re using lots of scripting.

A couple delays that may be relevant:

  1. Delay to subscribe tags if they are leased and weren’t previously subscribed: if your tags aren’t in direct mode, you could try changing to direct mode.
  2. Delay to deliver new values to client.

I’m doubtful the subscription rate affects these much, though it may reduce delay to get newly subscribed leased tag values related to first delay noted above (only applies if tags are leased):

Do you get periodic quality overlays on your screens or only on initial screen load? Just wondering if your PLC connection may be Overloaded. First thing that came to mind with seeing a default scan rate of 300-500ms.

1 Like

What does the overload look like for the PLC(s) involved in this?

As @WillMT10 has mentioned an overloaded PLC might be causing this.

What about your Gateway performance? Does it look normal?

Are any of the bindings using the tag() expression or are they 100% all just indirect?

2 Likes

Those are some of the first things I checked. @500 ms for the default subscribed tag base, the overload is sub 10%. When I bump the rate faster from 350-400 ms, the overload is sub 50%, so that’s not the issue. Out of all of the screens with lag, most have indirect tags, though some have a few expressions.

Well if it is sub 10% then your PLC is overloaded by that amount.

Are you using the tag() expression at all?
Are there calls on the screens that use runScript?

Since this is a ControlLogix, are the tags you reading inside of AOIs or are they UDTs?

Last time I talked to someone on support at Ignition, they said running at sub 10% is perfectly fine / normal. I maybe have 1 or two tag expressions total. There are no calls on screens that run scripts. Most of the tags I am pulling from are within UDTs. I don’t recall any being from an AOI.

Another issue is using the template repeater. It lags very bad when generating the templates inside of it. All tags inside are indirectly addressed. I hope that’s not another “you shouldn’t use template repeaters”, because that’s just one more thing added to the list that are “functions” of ignition yet don’t work well enough to use.

Edit: BTW, thanks for all the feedback!

I encountered the same issue.

I made a window with just one component pointing to one tag and it still blinked red.

The surprising thing to me is why some people notice this issue while others don't.

Right?! I feel like this is a major issue but its not getting the attention it deserves. I just keep reading “you shouldn’t use that” for different functions in ignition because they don’t work well. It seems like there’s only one specific way to do things, using one specific method, and if you don’t do it that way it you won’t be successful. Kind of a bummer TBH.