I've seen previous posts on similar topics but none of the suggested fixes have fully resolved the nuisance of slow OPC tag loading. The best improvement implemented thus far was changing the cache policy parameter from "auto" to "always". Now, the 5-12 second loading time only occurs when the screen is opened for the first time.
The default tag group that nearly all my OPC tags are assigned to was changed from direct to leased with the following parameters. Only my fault OPC tags belong to a tag group whose mode is set to direct.
Under Project Properties->Project->General->Tag Settings, the Client Poll Rate is set to 500ms and, under Project Properties->Vision->Timing the Polling Base Rate is set to 500ms as well.
The machine the gateway is running on is pretty powerful with the following specifications:
Lastly, here are a few screenshots of the gateway performance and a snapshot of the 1756-EN2T Ethernet card that is handling the communication between my PLC and gateway.
That guarantees the client won't see changes any faster. You should set that to the fastest OPC pace you actually want to see at the UI. (But faster than 100ms is generally not meaningful to human viewers.)
That's for database queries, not tags. That would be unusually fast, I would think.
I don't see any reason your device can't use a fixed 100ms pace, not leased, based on your device stats. Fixed rate is much better than leased, as switching tags back and forth is not instant.
Caching the windows doesn't keep the tag subscriptions fresh, though.
If you have specific tags that you want to the client to always have as fresh as possible, create a client tag change event, put pass as the one-line script, and put all of those tags in the subscription list.
If you do that, you probably won't need to cache any windows.
@michael.flagler There aren't many tags per screen but there are some screens that get their tags from imported UDT's that are gigantic. Overall, I have around 200k tags. I think I recall seeing a post that mentioned that the gateway is inspecting all the tags in the imported UDT even if you are trying reference just one of the individual tags inside of it. I could have misunderstood though. I'll try to go back to direct and see how it works.
@pturmel Thank you for the clarification on the polling rate settings. For @m.pelagatti, something like this is what you were referring to with the Client Tag Change Event script, correct?
Your comment about how the cached windows don't retain tag subscriptions is interesting also. It almost sounds like the improvements I saw from changing the cache policy from "auto" to "always" indicates that the slowness could be due to the graphics I'm displaying and not the OPC tags themselves? hmm...
Perhaps. But that would usually only show up on a slow link between gateway and Vision client.
Do you have antivirus on the client machine? If so, could you turn it off for testing? What does the client machine's CPU/memory/disk performance look like?
Good call. I disabled defender/firewall since these don't have external access, but it looks like I missed an anti-malware program that I didn't know inherently came loaded on Dynics screens. I'll try disabling that although it doesn't look to be putting much of a strain on the system.
Here are a few snapshots of the machine the gateway is running on:
This hasn't really been a problem but more of just a nuisance. Just figured if there is a way to get those initial loading times down to 3 or so seconds that would be awesome but I suppose it's not the end of the world if this is the best I can achieve.
There is only one HMI for this particular project so the machine the gateway is running on is the same machine vision is running the project from. The two means I'm using to interface with it are directly or using UltraVNC. I guess what I mean to say is there aren't any other clients.
You should carefully examine both your client memory max allowance and your gateway memory max allowance to ensure you leave a couple GB unused for the OS, without hitting the machine's swapfile. (I'd disable the swapfile entirely if you can.)
So @pturmel knows this better than I do, but what I've learned is that UDTs will optimize as long as you have all members set to at least ReadOnly for external access (by default I believe they are ReadWrite). But I've got an entire plant with everything on direct scan at different rates for the different UDTs (I have nested UDTs with status bits dedicated to one of those nested UDTs that shows everything that would be needed for the main screens, so all those bits on my system are set to 1s direct. Configuration tags I have set to 5 seconds direct (rarely get changed and are linked to separate AOI tags which aren't optimized in Ignition's driver) but have read after write and optimized writes with a short write timeout enabled. Any string tags for tag descriptions, units, etc that I have in the PLC are on a 30 second direct scan. Then on any commands (buttons for operator control) set for 2 seconds direct.
Together I have over 40k tags reading with virtually 0% overload.
I think his issue is he has a lot set to Leased with the normal non-leased rate set to -1, so none of the tags go on scan to get valid data until they're displayed, causing the driver to have to put them on scan and causing the slow loading. That's why it's only showing 638 tags on scan, but supposedly he has over 200k tags. I think any tags displayed on a main window should be set to direct to help screen load times, then faceplates can be set to leased if necessary, but then the complaint will be that faceplates are slow to load.
Ah, missed that in the last post. You're right. This will never be very quick if everything is leased. A leased tag switching to subscribed is not quick.
Derek, you probably also need my EtherNet/IP driver, but it is not available for Edge.
You're correct. I thought we were being clever by changing the default tag group to leased, attempting to not choke the communications between the gateway and PLC, but it's sounding like it may have done the opposite by polling for all the updates at once when a screen is opened.
I tried changing my default group back to direct with a 1 second scan rate and things were still functional and updating quickly but it instantly threw me into overload.
Sounds like if I throw that guy in his own tag group, slow him way down, and ask for reads after a write then I might be OK. I guess that leaves me with one question.
Is there a way to change the group an entire UDT is assigned to? I know if you double click on an individual tag, you can change this in the properties, but how could I quickly do that for the 175k tags in my recipe UDT?
Create a UDT parameter for that, and set it in the definition to the desired new group. Bind to that for each tag in the definition. Save. All of the instances will update to use that group.
Another thing to watch is the OPC Client diagnostics. The device diagnostics/status shows how many requests you're using (notice only 1 request for the 1000ms group, but 178 for the 100ms group?) The OPC client diagnostics will show how many tags each scan group is reading, and you can check it to also see if you have any errors connecting to tags for each (sort by Status Code). How many of those tags do you really need to read at 100ms? And like you mentioned, slow down the recipe tag (if it's an array, make a UDT for one "recipe" or whatever each base tag is, then use parameters with the multi-instance wizard to bulk create your tags).
Admittedly, when we first started noticing the slow reaction times, we started playing around with the parameters of the tag group to see how we could make it better. During that process the OPC UA Publishing Interval was set to 100ms and the Sampling Interval was set to 100ms also and was never changed again until just now. After looking deeper in the parameter descriptions, I've set the Publishing Interval to "-1" and the Sampling Interval to 1000ms.
In regard to your question though, you're right, with a recipe list like this I don't really care about reading any of those tags unless they change. That being said, putting a decent chunk of time between reads, and forcing a read on change would be fine.
I like the suggestion of creating a UDT parameter and giving the recipe its own tag group. First, I'm going to have to do some reading on the proper way to set up UDT parameters in Igntion and how to use this multi-instance wizard.
