Got the subscription logic functional for my driver. Via the OPCXML protocol, I can set my driver to either return all subscribed tags when polling a subscription, or just the tags that have changed. When I set the driver to the latter, Ignition seems to flag the unchanged tags as having failed, and they’re marked with a red ‘x’. The ‘x’ goes away when they are later updated.
The problem is that when the history for these tags is turned on, they’re making a huge number of records. When I set the driver to return all tags, whether or not they’re updated, they seem to make a record every time they’re polled. Otherwise, they make records when they change AND when they go dead. Is there something special I need to do in my driver to make my tags only log when they’ve changed?
The server expects subscribed tags to be updated at the sampling rate regardless of whether the value has changed. Eventually, when (sampling rate * stale threshold) has elapsed without an update, the server marks the tags as stale.
Further upstream from you, in the server, there should be a filter in place (on the OPC-UA MonitoredItem) that prevents changes in timestamp alone from being reported to the UA client, unless the UA client has requested a different filter configuration when creating the MonitoredItems. Ignition’s UA client always chooses a filter configuration that results in values being reported upon change in quality or value, but not in timestamp.
It’s not anything a driver implementation needs to worry about, it’s just the background information and the reason why you shouldn’t be seeing duplicate values get logged in SQLTags history. I have a hard time believing the filtering isn’t working, so you’ll have to show me something that indicates otherwise.
There’s nothing you should need to set, Ignition’s UA client always uses a filter that requests only changes in status or value be reported when creating monitored items.
Is there anything that could cause the tag quality to ‘flicker’? I’m updating everything again, and the tags are still logging far in excess of their value changes…
We moved the tags to a separate scan class and historical scan class, and now they’re behaving as they should…not sure what caused that, but for anyone else, that’s a potential fix.