There is a bug in browsing the node i=84.
You can directly input the node id to OPC UA Viewer for subscription. The node id is just the path of node, like Device.Node.
I run the downloaded Server.vi on the cRIO-9074, which has a static IP. The downloaded Client.vi works fine on another host Windows XP.
However, Prosysopc java client is not able to read data out. The debug print out indicates that the discovered endpoint from server is opc.tcp://localhost:4841. The communication fails to reach server on localhost.
Is it bug with server or the client?
It's an indicator output from the VI. I mean, when you connect the client to the server, you need to tell an url to the client, just give the client opc.tcp://ip:4841, it doesn't matter if you see the localhost in the VI output.
The Prosysopc UA java client seems to follow the discovered endpoint, after its first successful connection for discovery.
I assume I could have missed some options using the API. Will dig more.
The Client.vi runs fine.
most opc ua clients browses the discovery server for regiesterd server endpoint, and also they are able to directly input the server endpoint to connect without the discovery server. The problem is that, we don't have the discovery server on RT, so we expect the client to directly connect to the server with the endpoint without request the discovery server first. Maybe it remembers the endpoint you use last time?
We'd like to run the java client from a linux box. I've used the following code snippet.
NodeId nodeId = new NodeId(2, "Device.Node");
DataValue value = client.readValue(nodeId);
System.out.println("[" + i + "]: " + value);
After first successful read, the Server.vi crashes.
What did I do wrong?
You need to make sure to apply client.disconnect();
actually, just make one connection and in the read loop test client==null;
So, in a separate section of code put connect and disconnect actions.
Do you see the crash every time? It should not crash.
Can you create a memory dump for the crash?
You can use this tool
Input the command before crash
procdump -e labview.exe c:\dump.dmp
You can upload the crash to ftp://ftp.ni.com/incoming
I've uploaded 9f6ef3ef-47e4-4168-8a23-ba1e71127ee6.zip.
The zip was generated by LabView when it crashed, not by procdump.
Hope this helps.
If you needs procdump output, let me know.
I cannot extract the zip file. The dump file in zip is damaged. Can you upload it again? I notice that the zip is just 27kb, please also check the size after you upload it.
Hello, I want underline my interest for this protocol because it represents a modern approach in industrial communication. So I'm trying this new API in order to update all my software as soon as possible. I have two questions:
1) the implementation of methods is foreseen in future updates?
2) I tried to generate a windows executable. It works onto the development machine, not into a CPU with runtime engine because it is not able to open the subvi's as indicated in the picture.
Can you help me?
Thanks a lot,