There are several in play together which prevent the OPC UA byte array from working in QuickOPC-UA for method calls.
The first thing is, that it is not really possible to have a TypeCode for a ByteArray. TypeCode-s are very limited. Our software is actually written in .NET, and there we have much wider choice (the Type type) that can cover different cases. But when projecting the .NET API to COM, we had to make some limitations, and the use of TypeCode-s is one of them.
The second thing is, even with .NET Type-s, OPC UA byte arrays are a bit problematic, because there is no direct .NET representation for them. The closest is a simple array of Byte,; the problem with it is that OPC UA can *also* work with an array of Byte, thus the two would become indistinguishable in .NET, unless we chose a special representation "of our own making" just for byte arrays.
The third issue is that OPC UA requires the argument be passed precisely in the type it has. The UA server is not required to convert any "similar" types. Therefore the code you write must somehow be able to precise instruct which type to use - that's why we have these TypeCode-s as an input argument in the first place.
And the fourth issue: Similar problem happens with OPC UA Write-s. For writing, the caller needs to specify the input arguments, similar to the OPC UA (method) Call. We allow omitting the type code for Write. If that happens, we first interrogate the server for the value type, and then convert the value as necessary. This is less efficient, but much more convenient for the user. The similar "workaround" would probably be possible with OPC UA methods Call-s, but it is not implemented yet.
The bottom line, and an answer to your question is: With the current QuickOPC, you cannot pass the byte arrays as inputs to OPC UA method calls. We can, however, have a look at implementing the necessary extra code for auto-determining the type from the server. When this is implemented, you would: 1) pass a COM safe array of bytes in place of UA byte string, and 2) specify the corresponding type code as Empty (0).
We have some other things planned, therefore expected delivery of such change would be somewhere in 2-3 weeks from now. Would that work for you?
Best regards
