Hello Everyone,
On my gateway, I have noticed that leased tags take an excessive amount time to switch from their slow mode to fast mode once they are needed initially (10-60s). I am using a slow rate of 30,000 ms and a fast rate of 1,000 ms. The test that I am doing is as follows: open a popup window that contains a tag binding for a leased tag, toggle the state of the tag in the PLC and observe how long it takes to update. Once it updates, I toggle the state again to see if it is starting to update with the fast rate or it just happened to update at the slow rate. This corresponds to when the subscriptions change on the device monitoring screen. The switchover typically occurs anywhere between 10-60 seconds after the popup window is opened. This is way too slow and significantly detracts from what I thought was the advantage of using a leased tag group. Is it typically this slow for everyone else? Is it an unfair expectation to get an up to date value within the fast poll rate from switching from the slow one?
What I have tried so far:
- Creating a separate device connection for leased tags (I think this solved a different issue but doesn’t help here)
- Creating another separate device connection for a much smaller subset of leased tags
- Creating a smaller tag group with a single tag in it
- Calling the system.tag.requestGroupExecution function to attempt to trigger it to switch
- Updating to Ignition 8.1.5 (from 8.1.1)
Does anyone have any solutions or suggestions?
Unfortunately, I have too many tags to move them all to poll at the fast rate. If nothing else, I can modify all of my popups to do their own polled OPC reads instead of using tags. But this just doesn’t seem like an ideal solution…
Update:
I solved it by changing the OPC mode on the tag group from Subscribed to Polled.
1 Like
This 100% resolved my issue. I also confirmed it by switching back and forth between polled and subscribed; it would always take forever to start updating my tags on subscribed.
Ignition's OPC server seems to batch subscription changes at ~10 second intervals.
1 Like
Subscription synchronization is debounced @ 250ms and then delayed if necessary to ensure it happens no more frequent than 8 seconds.
So sometimes it will be immediate-ish (250ms), and sometimes you'll get up to 8 seconds of delay.
1 Like
Is that across the whole server, or per device?
Per OPC UA connection, this is all OPC UA connection logic.
So, client side? Any way to configure that?
No, it's all hardcoded.
It's tricky because if you have any tags configured that aren't valid, then the subscription logic is continually running, forever, until the Ignition subscription model and the actual OPC model are in sync.
Oy! Feature request? Defer only the invalid items? Change the time factors to configurable with those defaults?
Maybe. Most 3rd party servers will fall over if you start smashing them with create/modify/delete subscription/item requests. This is the only thing preventing that from happening.
Updating this would be a huge change in the usefulness of leased tags.
I'm sure it would be, but this logic is all super finicky and there's no chance it's getting rewritten (again) any time soon.
And again, there's only potentially a delay if a sync already recently occurred. Maybe that's frequent for most people, I'm not sure. In a system where none of your tags point to OPC paths that don't exist, the lease change will be ~immediate.
This is all 8.1 behavior, it looks like in 8.3 you'll probably experience at most a 1 second delay?
edit: need to look closer, not sure.
Very common condition. A single disabled device that has tags pointing at it will put your entire loopback connection into this pathological state. All subscription changes will be applied every eight seconds. 
This really ought to be refactored to only hurt the subscription items that fail.
Yeah, that is far too long to wait upon change from screen to screen. I'd be okay with 2-3s before tags go to the faster interval, but 10s is horrible.
Alright, I just put up a PR in 8.3 that should improve the situation a bit... hopefully we don't start knocking down Kepware servers again.
1 Like