OPC-UA Method Calls

Module Development
1

Hello,

A while back I inquired into how to call OPC-UA methods from within Ignition. At the time it was reported that the current OPC-UA stack did not allow method calls, but something was in the works.

I was wondering if the situation had changed?

I have a device that provides an OPC-UA stack, and in looking at the documentation, almost everything I need to accomplish with this device uses method calls.

Hoping that Ignition is a viable option for this.

Thank you,
Bill

1 Like
2

We’ve made progress towards it, but it likely won’t be possible until Ignition 7.9.

1 Like
3

Sorry, Original thread was https://inductiveautomation.com/forum/viewtopic.php?t=13070.

In that thread you mentioned having OPC-UA Client Method calls in 7.8. Did that happen? That’s what I actually need.

If not, do you have something that is ready for beta testing? That I could use for proof of concept?

Unfortunately I’m not sure the time frame for this project, but it’s probably fairly quick.

Presently I’m looking at just needing an Ignition Server with just the OPC-UA module, I can talk to the robot controller using JSON, so the next half is this device that only supplies an OPC-UA interface. There are very few variables provided by the OPC-UA server, most of the interesting stuff is via OPC-UA Method calls.

If it can’t be done in Ignition, will Milo provide what I need? Any examples if so?

I’d prefer to use Ignition for this…

Thank you

Bill

BTW: Should this thread be moved to a different forum? Since it’s not really module development.

4

Right, so as if Ignition 7.8 the UA client code is/will be using Milo, and the Milo client does support UA method calls.

The problem is that all the work to plumb it into some kind of scripting methods hasn’t been done. And in order to even start that, a more fundamental problem needs to be addressed, which is that currently none of the UA libraries get loaded into client scope, and you would presumably need to be able to use some of the UA data structures and types in order to invoke methods. This would limit any implementation done now to gateway-scoped scripts.

edit: I sure was optimistic in that other thread… :open_mouth:

5

Basically, I need to provide a middleman between two devices, one is running a JSON web service and the other is running OPC-UA with some variables and events, but also needing to call at least 1 method. They have quite a few methods defined.

The discussion over my wall was discussing using Kepware to accomplish this, I piped up suggesting that Ignition should be able to do it as well.

I don’t anticipate running any vision clients at this time for this, but like the option later on. As far as I can tell, Just the base + OPC-UA module should get me what I need right now.

I can also do this with Milo or some other OPC-UA client SDK. I just thought it might be faster to do it with Ignition.

I don’t necessarily need direct scripting access. Would you be able to provide me with enough information to add in hooks to access what I need via Java modules that could then be accessed from the Jython? I did a driver, why not Java scripting modules?

Maybe if done correctly could even be done in a way that would match IA’s eventual script naming.

Thanks

6

Kevin, you are too modest. Really.

For the rest of y’all, look here and here.

Kudos to IA, too, for letting Kevin do this under an open license.

7

You could build a module that has a dependency on the OPC-UA module and then provide your own scripting functions, leveraging the fact that by depending on the UA module you now have the UA client SDK on your classpath.

The biggest downside I can see is that you wouldn’t be able to “re-use” the OPC-UA connections configured in the gateway; there’s simply no access to them right now. Which would mean your module/scripting functions would also have to deal with the configuring and creating an OPC-UA client connection as well.

8

I’m fine with server side only. Don’t need client side access atm. What would it take for IA to include the necessary hooks to allow access to the OPC-UA Server connection path.

With that, would we be able to just implement a new MethodWriteRequest which implements UARequestMessage to pack the method call request that could be used in the appropriate uaclient write method call, then maybe a MethodResponseMessage class which implements UAResponseMessage would need to be generated containing the response message. Probably a whole lot more involved that this… But one can dream.

My problem with the above, is that it requires assistance from IA probably in the form of you Mr. Herron otherwise the learning curve for me is too much, plus I still need to decide if I want to attempt the ABB RobotWebServices as a driver or simply parse with Jython.

In either way, the benefits going with Ignition are going down fast. It really depends upon how much help IA can provide us, and what the cost would be for said assistance.

Presently this is a one-off, but it does have the potential to be repeated if we do it correctly.

Thanks for your responses so far.

Bill S.

9

Kevin, do have any news about OPC-UA method calls?
I could not find anything about this topic.

Thank you
Marinel

10

The changes I was discussing above got cut from the 7.9 release plan. They should be going into 8.0 instead.

I can say with confidence you’ll be able to invoke methods on configured OPC UA connections, and with a little less confidence that drivers for the OPC UA server should be able to expose methods.

11

Thank you, Kevin,

I get more and more request for this type of OPC capabilities.
Do you think that v8 will be released at the ICC?

Regards
Marinel

12

Hi Kevin - would it be the case that the Method call feature is already included in the current version of the “OPC-UA Next” beta module?
The need for this feature starts to get quite important.

If not - would there be an alternative way to gain this functionality? - for sure with a bit more programming involved.

13

The Next module does not have any functions for calling methods.

The only way I could see to get this functionality yourself would be to build a module that added your own scripting functions for calling methods. It would have to be capable of making a connection to an OPC UA server all on its own.

1 Like
14

Okay :wink: I’d rather not go in that direction.
Just to assure - waiting for Ignition 8 should still fulfill the method call need, right?

15

Yes, I’ve already started implementing it. I’ll try to finish it up so it lands in a nightly build.

3 Likes
16

Mighty good :smiley: :clap:

17

Please let us know when this feature is implemented. This will be highly usable.

1 Like
18

Hmm, it’s not in the online docs, but system.opcua.callMethod is in 8.0. The autocomplete menu describes the params.

Its usage looks something like this:

    # call the Server object's GetMonitoredItems method
    result = system.opcua.callMethod(
        "Ignition OPC UA Server",
        "ns=0;i=2253",
        "ns=0;i=11492",
        [1]
    )
    
    print result[0]
    print result[1]
    print result[2]

callMethod.desc=Call a method in an OPC UA server.
callMethod.param.connectionName=Name of the OPC UA connection to the server the method resides in.
callMethod.param.objectId=NodeId of the Object Node the Method is a member of.
callMethod.param.methodId=NodeId of the Method Node to call.
callMethod.param.inputs=A list of input values expected by the method.
callMethod.returns=A 3-tuple containing the call result StatusCode, a list of StatusCodes corresponding to each input
argument, and a list of output values. Each StatusCode is itself a 3-tuple containing the value, name, and
description of the StatusCode.

2 Likes
19

In the interest of posterity, the docs have been updated: system.opcua.callMethod

2 Likes
20

Do you have any methods to determine the NodeId from a Node Name?