Hi,
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 unified-automation.com aslo support similar features as shown in below link.
http://documentation.unified-automation.com/uasdkcpp/1.4.0/html/L3GettingStartedClientLesson05.html
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).
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.
@Kevin.Herron
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.
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.
Has this feature been added to any of the newer versions of Ignition 8.1? This would be extremely beneficial for something I am working with.
Not, and don't hold your breath.
Any recommendations to clear out stuck opc item paths without an entire OPC restart? I have worked with Autosol support to troubleshoot an issue where a tags will get hung with unknown source(Whatever was updating stopped). This happens when changing an alias in Autosol. Sometimes I can disable the UDTs in Ignition and it will update right away. Other times (50% of the time) it will not remove with disabling the UDT, I won't actually see any of the items being removed in the logs like I do when it does actually work. The only work around is bouncing the service.
Nothing discussed here would help you with Autosol’s broken OPC server… maybe a new thread where you describe the issue in detail? It sounds vaguely familiar from support escalation in the past…
I can create another ticket, but I have worked with Ignition and Autosol support on this issue. Both pointed the finger at the other so we are basically stuck bouncing the service a couple times a week, which is very impactful.
Assuming this is OPC UA, between Wireshark and DEBUG/TRACE logging on the Ignition side, you should be able to show something definitive.
You haven't described your issue in detail, but it sounds like you're "changing an alias" on the Autosol side is resulting in the NodeId for some Node(s) changing, which is a configuration change that also then needs to be made on the Ignition side. I'm assuming that you make that change, Ignition tries to create new Monitored Items, but Autosol still doesn't recognize the new NodeIds for some reason (NodeId is OPC Item Path in Ignition).
In one of your support tickets you also mention that UaExpert as a client demonstrates the same problematic behavior...
Yes, I am experiencing it in the UA Expert client also. I am going to push on Autosol more, shouldn't have to bounce the entire UA service for an individual device.