In the Driver Interface, there is a Read stub that must be overridden, but this appears to be a general, asynchronous read. Is there a method I can override to deal with polling for tags with a subscription?
Driver#alterSubscriptions() is called any time a monitored item for a node is added or deleted to let you know what you should be subscribed to and at what rate.
I’m trying to talk to a device that speaks OPCXML. The method that it uses to just read a tag, versus reading a tag that is part of a subscription, is different. Does Driver just use Read to get the tag values of subscribed tags?
No, reads aren’t necessarily related to subscribed items.
You can, if you choose to implement it this way, detect if items you’re getting a read call for are already part of a subscription and just return the latest value you have on hand for that item though.
But there’s no requirement that an item you get a read request for is part of a subscription.
Also, unless you REALLY need the data from the device exposed through the UA server for some reason, consider implementing and adding an SROPCServer to the platform instead of adding a Driver to the UA module.
If you went that route, you’d end up with the ability to add a 3rd type of OPC connection (XML, in addition to DCOM and UA).
I’m already a fair chunk of the way through the driver…as long as subscribed items use the read method to get their values, I’m alright, even if other tags also use the read method. That was my big concern.
I’m not sure what you mean when you say “as long as subscribed items use the read method to get their values”.
Don’t expect Driver#readItems() to be called repeatedly, or at all, for items you receive in Driver#alterSubscriptions().
Calls to Driver#readItems() are initiated when the OPC-UA server receives a read service call for an item belonging to your driver, that’s all.
I’m trying to relate the Driver methods to OPCXML calls. In OPCXML, you can do an asynchronous read of a list of tags, which returns their values. Alternatively, you can make a PolledRefresh call where you pass the pertinent subscription, and the tag values are returned.
I was assuming that SQLTags and transaction groups would call Read according to their scan rates, in which case I would use PolledRefresh…but I’m not sure one way or the other. OPCXML requires you to poll for tags, even when they have subscriptions.
Perhaps the pertinent question is, under what circumstances does Ignition use the Read() method in Driver?
[quote=“lisawas”]
Perhaps the pertinent question is, under what circumstances does Ignition use the Read() method in Driver?[/quote]
When a scan class is in “Read Mode” instead of “Subscribe Mode”, ditto for groups, or when a user calls system.opc.readValues() from scripting.
Or when any other OPC-UA client (which is what Ignition is as well) calls the OPC-UA read service on the server.
By default, scan classes and groups use subscribe mode.
I see…is there a method that I can override that Ignition calls when it wants to get tag values in Subscribe mode?
No, these are totally separate systems we’re talking about here. The drivers, OPC-UA server, and even OPC-UA client code don’t know anything about scan classes or their modes.
They all know how to read things they’re asked to read, and how to subscribe to things they’re asked to subscribe to.
Does Ignition operate under the idea that items with subscriptions will push changes to Ignition?
At this point, I’m tempted to register a task to poll my device and update the tags whose values have changed.
[quote=“lisawas”]Does Ignition operate under the idea that items with subscriptions will push changes to Ignition?
At this point, I’m tempted to register a task to poll my device and update the tags whose values have changed.[/quote]
It’ll help if you stop referring to the system as a whole (Ignition) and start referring to the specific subsystem(s) we’re dealing with - in this case drivers and the OPC-UA server.
The OPC-UA server expects that all SubscriptionItems it passes to a Driver in Driver#alterSubscriptions() will have setValue() called on that item, repeatedly, at the rate specified in the item. You must make this setValue() call at the specified rate, or as close as possible, whether or not the value has actually changed. How ever you manage to do this is up to your implementation.
Okay. I think I know how I want to do that, then. Thank you.