Persistence/NoChange with Async OPC Updates

[tfranklin]

We've recently had a number of requests for using persistence to prevent alarms getting raised unless a value has been in a state for X seconds.  Advanced OPC has state by state persistence which is perfect for this.  The issue, however, is that you need to use Synchronous polling for this to work properly.  This is obviously less efficient than async would be and would require not only a second scan group but also a second server connection where the scan mode is set to synchronous. 

I understand the reason behind it, but I kind of figured I might be able to get around it if I combine persistence with async + confidence polling from the cache.  I tried this and it does not work, or at least didn't in my testing.  To boot, you can't set confidence from cache on a point so it has to be done on the scan group.  Not a huge deal since you can easily create a special scan group that does confidence polling for the points that may need this.

My scenario is simple -- there's a server where the scan mode is async and I want to enable persistence on a handful of points across every station. 

My idea -- allow points on async to have state level persistence IF confidence polling is enabled on those points (using point level confidence polling).  To take it even further as a super neat feature, similar to promoted polling for modbus/dnp3, have an option to enable confidence polling on points when a certain state is met. This would effectively act as a "fast scan" while a point is in a certain state.  I can see another checkbox getting added next to each state to "enable" promoted confidence polling when that state is active (analog and digital).  My idea wouldn't currently work since for some reason you can enable cache async polling on a scan group but not on a point, which doesn't seem like a bug but rather some oversight.  Maybe my crazy request would be possible if point level confidence polling would be possible.

Lastly -- this idea as a whole would solve 2 problems. 

1. Point state alarm persistence with async
2. NoChange alarms functional as real no change alarms

NoChange has always been one of the most confusing things for customers to grasp because the name implies what it does not do.  It is not a way for you to alarm if a value has failed to update, but rather a way for you to determine if a point who is getting valid updates continuously has failed to update.  I frequently have seen users try to use this as a way to indicate that comms have failed, which it just will not do as it was not designed for that.  Having a background confidence update would potentially allow this to work that way though. 

[sbeadle]

Thank you Trent.