[Bug]: OPCUA driver : Code Syntax (usage) for writing tags is inconsistent with say Ads Driver

[patrickboisclair]

What happened?

In order to write tags using ads Driver, in 0.12.0 I need to specify the "PlcType" in the "addTagAddress" method like this:

PlcWriteRequest writeRequest = plcConnection.writeRequestBuilder()
.addTagAddress("ValX", "MAIN.ValX", new PlcDINT(154)) <= NEED to pass a PlcDINT
.build();
If I dont, I get an error.

On the other hand, with OPCUA driver for example, doing the same thing, results in an error:

Exception in thread "main" org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Expected PlcValue of type NULL but got INT

In this case doing:
PlcWriteRequest writeRequest = plcConnection.writeRequestBuilder()
.addTagAddress("ValX", "MAIN.ValX", 154) <= MUST NOT SPECIFY a PlcType
.build();

it works.

So it seems there's some inconsistencies between drivers.

Version

v0.12.0

Programming Languages

• plc4j
• plc4go
• plc4c
• plc4net

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• CANopen
• DeltaV
• DF1
• EtherNet/IP
• Firmata
• KNXnet/IP
• Modbus
• OPC-UA
• S7

[chrisdutz]

Well in genereal, I think for most drivers I'm working on we went to requiring PlcValue types as we were having loads of issues otherwise.

[patrickboisclair]

Hi Chris,

I think requiring PlcValue is fine. That's what I use with 0.9.1.
It's just that right now, in 0.12.0, not all the drivers do so.

Best example, is the OPCUA one, which you cannot pass PLCValue. It throws an exception like:
Exception in thread "main" org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Expected PlcValue of type NULL but got INT

In my use case, I can connect to any type of PLC (supported by PLC4X) via a configuration from a .yaml file.
We connect to PLC "x", get the data and push it on different platformms (RabbitMQ, MQTT, Kafka, SignalR,...) depending on the needs.

As of now, I can have a workaround using a "switch statement" on the "driver" and using the addTagAdress() method appropriatly, but it just feels inconsistent and "harder" for newcomers.

Just my 0.2 cents on the subject :)

As always, I really appreciate all the works you guys do on the project.
I love PLC4X and just wish the best for it.

Best regards

[chrisdutz]

Yeah ... the OPC-UA Driver I usually stay way from as much as I can ... so guess the part of the team that works on this should probably jump in to help. But I agree ... all drivers should handle this thing the same way as that's the promise of PLC4X: "Access all da thingz with a shared API"

@hutcheb @sruehl @splatch?

[chrisdutz]

I think we should probably rename this issue, as it's actually the OPC-UA driver which seems to be doing things differently.

[patrickboisclair]

Good point. I renamed the issue.

[qtvbwfn]

Hi
I have tried it, and it works properly when the data type is explicitly defined in the tagAddress. Here is my screenshot. In theory, other protocols can also be used in the same way.
@chrisdutz
@patrickboisclair
@ottlukas

[chrisdutz]

I don't work on the OPC-UA driver ... so hopefully some of the others will be able to help you.

[splatch]

Yeah ... the OPC-UA Driver I usually stay way from as much as I can ... so guess the part of the team that works on this should probably jump in to help. But I agree ... all drivers should handle this thing the same way as that's the promise of PLC4X: "Access all da thingz with a shared API"

@hutcheb @sruehl @splatch?

Agree, we should indeed guarantee that handling of arguments passed by caller keep basic API contract. Currently due to tag syntax we can in theory assume some stuff for UA.

I'll keep this issue on my radar. I need to sync up my knowledge of what happens with values passed to this driver.