Registered reading of OPCUA server


For some third part OPCUA server, it support registered reading (such as Siemens S-1500 OPCUA server), which is much faster (about 10 times from a benchmark test by Siemens) than general reading.

It seems that the only thing need the OPCUA client to do is just registering the nodes on the OPCUA server before do reading operation.

I saw that we could only choose “subscribe” or “pull” mode to read OPCUA data. Does it support registered reading in Ignition as an OPCUA client?

No, registered reads are not supported. They’d only make sense of you were using OPC Read Mode for reason, or repeatedly reading the same nodes via scripting instead of using a subscription.

It’s not clear to me what support would even look like. Maybe a scripting function?

@Kevin.Herron thanks for your quick answer.

Yes, it seems that it could be considered as a script in Ignition.
Is it possible for us to register the OPC node ID to the third part OPCUA server in Ignition?

For OPCUA registered reading, the OPCUA client only need to register the to be read nodes on OPCUA server by sending out a list of OPCUA nodes to OPCUA server. Then the OPCUA server will send back the registered nodes to client.

When I use the OPC Foundation’s C# OPCUA client library’s registernode function, sending a group of OPCUA string node ID such as “ns=3,node_info1” to the Siemens S-1500 OPCUA server , the S-1500 OPCUA sever will give back a group of OPC numberical node ID (I think OPCUA server has done some optimazation for these registered nodes).

After that when OPCUA client call read function repeatly for the registered nodeID, the average reading speed is much faster than non-registered reading.

The referenced C# RegisterNodes() function is shown in below link:

BTW, I aslo found that the aslo support similar features as shown in below link.

BTW, per my understanding, the only difference for registered reading method and normal reading method is that it will call register node function before reading data for registered reading method. After that the registered reading method will call the same reading function as normal reading method.

For OPCUA, it has below functions:

So is it possible to provide function like system.opc.registerTag(tags) /system.opc.unregisterTag(tags) ?

The parameter tags is the to be read OPCUA tags in system.opc.readValues.

Please be more precise in your terminology: “Tag” isn’t the best word here, as it confuses Ignition’s tags with OPC items. OPC items don’t necessarily point at tags, and if they do, they aren’t Ignition’s tags. If support for this is done at all, the calls should be [un]registerItems(items) or, perhaps, [un]registerNodes(nodes).

Thanks for your correction, the term Items or Nodes is more accurate.

Yeah it would look something like registerNodes(server, nodeIds) and unregisterNodes(server, nodeIds).

There’s a bit of a problem with the lifetime of the registration though. For example, with the server in the S7-1500 any time you download to it the server restarts and you would lose all your registered nodes. You’d only figure this out when your reads started failing.

You can’t just register/read/unregister every time because that would defeat the purpose of registering and be even less performant.

Maybe a ‘registered read’ checkbox in the tag configuration could be an option.
On the first read command, the client checks if the node is already registered and registers it if not. Of course this would need some work in the api.

It’s a good point that it may have problem when the S7-1500 OPCUA server is down after client had already registered it.
in fact, when we use registered reading function with C# libary, we only register it at the beginning, then we called the read function repeatly for a very long time, after than we could call the unregister.
So is it possible to implement such feature on Ignition? Or just using the subscribe way or noraml reading with periodially pull is good enough for Igniton?

Subscriptions are always the best way to go about continually receiving values for any Node. The improved performance of reading registered nodes is irrelevant when you use subscriptions. The cost of the string-based NodeId lookup is only paid once, when the monitored item is created.

Thanks for your suggestion.
I will use subscribe way.

I’ll still look into adding a scripting call. @chi’s suggestion is reasonable, but will take some additional work to handle a server that only allows a certain number of registered nodes as well as retries when the nodes suddenly become unregistered because the server restarted or something.