Invoking methods with no arguments from open62541 based client

[jknudstr]

I’m trying to invoke a method in an OPC UA server based on opcua-asyncio.
When trying to invoke a method with no arguments from the open62541 client, defined like this:

@uamethod
def RPC_Init(self, parent):
…

I get the following error:
Traceback (most recent call last):
File …/address_space.py", line 587, in _call
result = await self._run_method(node.call, method.ObjectId, *method.InputArguments)
TypeError: Value after * must be an iterable, not NoneType
The problem is that when there are no arguments for the method call, open62541 submits “nullptr” for the arguments, which ends up being a “NoneType” in the Python code.
So far, I have found no way (no workaround) to avoid this in the open62541 client.

I should mention that this works with the Softing OPC UA client SDK. I.e., for methods having no arguments, this ends up being an empty list or tuple.
For the purpose of testing, I implemented a small work-around in “asyncua/server/address_space.py” (my modifications marked with “# <<<<<”):

async def _call(self, method):
    self.logger.info("Calling: %s", method)
    res = ua.CallMethodResult()
    if method.ObjectId not in self._aspace or method.MethodId not in self._aspace:
        res.StatusCode = ua.StatusCode(ua.StatusCodes.BadNodeIdInvalid)
    else:
        node = self._aspace[method.MethodId]
        if node.call is None:
            res.StatusCode = ua.StatusCode(ua.StatusCodes.BadNothingToDo)
        else:
            try:
                if (method.InputArguments == None): # <<<<<
                    input_args = [] # <<<<<
                else: # <<<<<
                    input_args = method.InputArguments # <<<<<
                #result = await self._run_method(node.call, method.ObjectId, *method.InputArguments) # <<<<<
                result = await self._run_method(node.call, method.ObjectId, *input_args) # <<<<<
    …

whereby it is checked if “method.InputArguments” is “None” and if yes, it is redefined to become an empty list.

Then it works.

My question now is, what is the proper solution to this issue:

1. Trying to find a work-around in my open62541 based client, or
2. Trying to have an update introduced in the open62541 SDK to ensure that an ‘array’ is always submitted, or
3. Implementing the above-mentioned, or similar, fix in “asyncua/server/address_space.py”, or
4. Or something else…

Thanks in advance for any help to resolve this issue!

[AndreasHeine]

the question is how dose the opc ua request look like compared to the other if you investigate with wireshark -> with that we can crosscheck to opc ua spec what it should be!

[jknudstr]

OK, thanks for the quick feedback. I will try to produce this information, using Wireshark.

Just for information, I added a print statement in “asyncua/server/address_space.py” in the “_call()” function, to see what is received, in this case from Softing and from my open62541 client:

Softing:

_call(): node.call=method.ObjectId=|NodeId(Identifier='MAIN.Actuator1', NamespaceIndex=4, NodeIdType=<NodeIdType.String: 3>)|, method.InputArguments=|[]|

open62541 client:

_call(): node.call=method.ObjectId=|NodeId(Identifier='MAIN.Actuator1', NamespaceIndex=4, NodeIdType=<NodeIdType.String: 3>)|, method.InputArguments=|None|

[AndreasHeine]

@schroeder- this explaines the array topic in general but in the call service its explisitly says an empty list... so thats confusing!
would be interesting what other commercial sdk's do? like prosys / C# / unified automation / ... i mean sofring does it right

[schroeder-]

Softing is always sending None for empty arrays. I don't know about other sdks, but from my experience most are sending []. Because I stumbled a cross some issues in some opc ua libraries when using against my OPC UA Server that uses the softing sdk, that always send None for all empty arrays.

[GoetzGoerisch]

From above I see that the array shall be empty and as the quote from @schroeder- applies looks like a issue of open62541.
@jknudstr please raise an issue in open62541 on this.

[jknudstr]

@GoetzGoerisch: OK, will do.
Thanks all for looking into this!

[schroeder-]

I think both is valid. But a lot of sdks have problems with Null arrays. So we should fix our code to accept Null as well.

[jknudstr]

Thanks again Andreas.

Would be interesting to know if this is an issue to be fixed in open62541.

In order for us to proceed, we will try to find a work-around in the open62542 client.
If that is not possible, we could maybe install an updated version of opcua-asyncio with the above mentioned work-around.
This is not ideal.
Would you consider to implement this work-around in opcua-asyncio (temporarily)?

Note: We're using the open62541 client with the OPC UA server on Beckhoff Soft-PLCs (TwinCAT).
That works, despite "null" is sent from the client in case the methods have no arguments, so maybe the Beckhoff OPC UA server has implemented the work-around.

[danmoser]

Folks, I'm facing exactly the same issue. FYI, UaExpert is following the standard (ie., providing an empty list as input argument).

More details at open62541/open62541#5627

[schroeder-]

Fixed in #1217

[jknudstr]

Sounds good! Many thanks!