OPC-UA - Method call with "complex" input values

I’m afraid you might be at a roadblock for now then. I don’t think it’s possible to write a ByteString value from Ignition at the moment. We’ll have to add support for it in a future release.

Damn, ok.
Would have been nice to be able to read the content of the tag and then be able to write (through another method).
Guess we will have to plug them to a PLC to do that instead of using Ignition directly through OPCUA.

I’ll try to keep an eye on the release notes of future versions for the ByteString support.

Thanks a lot for the help.

Hi Kevin,

I'm getting a similar issue.
I'm trying to execute a method that is returning an "Complex" output that cannot be recognize.
Folling the error log:
INFO | jvm 1 | 2022/12/22 09:44:30 | Caused by: org.eclipse.milo.opcua.stack.core.UaSerializationException: no codec registered for encodingId=NodeId{ns=8, id=5052}
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.types.OpcUaDefaultBinaryEncoding.decode(OpcUaDefaultBinaryEncoding.java:105)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.types.builtin.ExtensionObject.lambda$0(ExtensionObject.java:105)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.util.Lazy.maybeCompute(Lazy.java:50)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.util.Lazy.getOrCompute(Lazy.java:36)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.types.builtin.ExtensionObject.decode(ExtensionObject.java:105)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.eclipse.milo.opcua.stack.core.types.builtin.ExtensionObject.decode(ExtensionObject.java:96)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.util.ConversionsKt.getScalarValue(conversions.kt:237)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.util.ConversionsKt.getValue(conversions.kt:218)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.scripting.CallMethodKt.coerceFromArgumentType(callMethod.kt:167)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.scripting.CallMethodKt.callMethod(callMethod.kt:87)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.scripting.CallMethodKt$callMethod$1.invokeSuspend(callMethod.kt)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:274)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:85)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:59)
INFO | jvm 1 | 2022/12/22 09:44:30 | at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
INFO | jvm 1 | 2022/12/22 09:44:30 | at com.inductiveautomation.ignition.gateway.opcua.scripting.OpcUaGatewayScriptingFunctions.callMethod(OpcUaGatewayScriptingFunctions.kt:72)
INFO | jvm 1 | 2022/12/22 09:44:30 | at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO | jvm 1 | 2022/12/22 09:44:30 | at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO | jvm 1 | 2022/12/22 09:44:30 | at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO | jvm 1 | 2022/12/22 09:44:30 | at java.base/java.lang.reflect.Method.invoke(Unknown Source)
INFO | jvm 1 | 2022/12/22 09:44:30 | at org.python.core.PyReflectedFunction.call(PyReflectedFunction.java:190)
INFO | jvm 1 | 2022/12/22 09:44:30 | ... 35 common frames omitted

Here you can find some information about the object the cannot be serialized:
image

How can I proceed with SDK to solve it?

Hi,

is there a solution planned for future releases? We are facing the same problem with the call method and "complex" input parameters.
Thanks

Hi,

We had the same problem trying to send the recipe file to a press.
For us it was fixed in 8.1.15

" 5480: The function system.opcua.callMethod incorrectly encodes ByteString parameters**
Support coercion of primitive arrays to ByteString when writing to tags or calling methods with ByteString type input arguments."

"Nightly 8.1 Changelogs - 2022 - #15 by sreis"

give it a try
Andrea

Hi Andrea,

We are already running with version 8.1.23.

Did you ever get this working? Also, are you using a Sick RFID controller? Everything you posted in this forum is almost identical to what we're trying to do with a Sick RFU6xx controller.

No, we are not working with RFID controller, but you will facing this issue if you are trying to use any complex data coming wrong OPC UA server. As I understood they are still working on it an maybe in the future Ignition will serialize complex data.

Hi Kevin.
Bumped in to my past "requirement" again.
Any chance there will be a solution to this one in the near future or better to seek alternative solutions?

Kr Niels

I’m not sure what your original requirement or issue was. There have been some fixes and improvements, it works with some servers and methods. You might just have to try again and see.

Sorry - The first post in the thread;) - Will give it a try and see if it works with OPC-UA AutoID readers from Siemens once our system is upgraded to the newest ignition release.

I don’t remember what the original issue was, but it looks like I may have diagnosed and fixed something back then:

While trying to call the Acknowledge Method function, we ran into problems with passing a ByteString and a LocalizedText as method arguments.

We activated logging for Conversions and call methods as proposed above but got no additional hints on how to supply the arguments in a proper format.

We tried to import ByteString via:

from org.eclipse.milo.opcua.stack.core.types.builtin import ByteString
But milo was not available from within the alarmAcked method.

Do we have to provide the method arguments in JSON format and if so, is there a schema to follow?

From what I can tell, it looks like in the latest versions of Ignition you can supply an array or list of numeric type and it will get coerced to ByteString behind the scenes, but unfortunately it doesn't appear there's any support for the LocalizedText type.

I don't see any possibility for supplying a value of that type right now.

Where did you get the node IDs? I am able to pull the read data through nodeID 6093, but would like to pull dB data and cannot find anything that lists out the nodes.