Problem reading OPC UA String values from Beckhoff PLC using RUT956 OPC UA Client

[tucekl]

Dear Teltonika Support,

I would like to report a persistent issue with the OPC UA client on the RUT956 (RUT9M_R_00.07.18.3).
I have performed extensive testing and comparisons, and it seems that the OPC UA client is unable to read String or certain DateTime-related values from a Beckhoff OPC UA server, while other datatypes work normally.

Returned json for these data types is always:

{
     “error”: 0,
     “result”: ""
}

I’m using ubus call opcua_client.rpc shell command inside RUTOS for more flexible control over requested data.

My testing enviroment is:

• Beckhoff PLC (TwinCAT OPC UA Server TF6100 - V5.2.123)

• Local RUT956 OPC UA server (for cross-validation)

When testing against the local OPC UA server running on the RUT956, all datatypes—including String and array of String—are read successfully.

{
     "error": 0,
     "result": "\"RUT9M_R_00.07.18.3\""
}

{
     "error": 0,
     "result": "\"RUT956\""
}

Data types that I was able to successfully read are:

• Bool
• Int32
• UInt32
• Real
• ULINT

Data types that I wasn’t able to successfully read are:

• String
• DateTime

These variables exist, are readable in UAExpert, and are standard Beckhoff PLC datatypes. UAExpert reads them without issues:

• STRING(255)
• DATE_AND_TIME

Could you please confirm:

1. Does the OPC UA client in RUT956 fully support OPC UA String type coming from Beckhoff TwinCAT OPC UA Server?
2. Does the client support reading String / DateTime / DateTimeOnly from Beckhoff OPC UA server?
3. If supported, are there any known compatibility issues with Beckhoff OPC UA Server?
4. Is there a recommended configuration for Beckhoff → Teltonika OPC UA interoperability?

Thank you for you help and further assistance.

Lukas Tucek

[Matas]

Greetings,

I believe, that to troubleshoot this issue more efficiently, we’ll need the troubleshoot file as well as some debug logs from you. To avoid sharing these publicly, I’d like to move to a different communication channel for you. For that, I’ve sent you a form to fill out, which you’ll receive into your inbox of the e-mail that you’ve registered your forum account on. In the Ticket ID field, simply enter 16404 which is the ID of your thread.

Regards,
M.

[Vilius]

Hello,

I hope this email finds you well,

Here is a short summary of our remote session.

During the remote session I was able to collect the opcua client logs, that were requested by our R&D team. I forwarded the requested logs and I will inform you once I have an update on the issue.

Warm regards,

V.

[tucekl]

Hello Vilius,

Thank you for your help. How did the troubleshooting session go? Have you tried to read OPC UA data using the ubus call function?

OPC UA Node ID I tried to read:

AlarmsGVL.testAlarm1.description
AlarmsGVL.heartbeat
AlarmsGVL.testAlarm1.active
AlarmsGVL.testAlarm1.cleareTimestamp
AlarmsGVL.testAlarm1.severity

These logs shows the problem clearly:

root@RUT956:~# ubus call opcua_client.rpc test_value '{"group_value":{"sampling_interval":1000,"deadband_type":0,"deadba
nd_value":0}, "server":{"url":"opc.tcp://192.168.144.20:4840","timeout":3000,"identity":0,"security_mode":0}, "server_node":{"ns":4,"type":1,"id":"AlarmsGVL.testAlarm1.description"}}'
{
"error": 0,
"result": ""
}
root@RUT956:~# ubus call opcua_client.rpc test_value '{"group_value":{"sampling_interval":1000,"deadband_type":0,"deadba
nd_value":0}, "server":{"url":"opc.tcp://192.168.144.20:4840","timeout":3000,"identity":0,"security_mode":0}, "server_node":{"ns":4,"type":1,"id":"AlarmsGVL.heartbeat"}}'
{
"error": 0,
"result": "22992"
}
root@RUT956:~# ubus call opcua_client.rpc test_value '{"group_value":{"sampling_interval":1000,"deadband_type":0,"deadba
nd_value":0}, "server":{"url":"opc.tcp://192.168.144.20:4840","timeout":3000,"identity":0,"security_mode":0}, "server_node":{"ns":4,"type":1,"id":"AlarmsGVL.testAlarm1.active"}}'
{
"error": 0,
"result": "true"
}
root@RUT956:~# ubus call opcua_client.rpc test_value '{"group_value":{"sampling_interval":1000,"deadband_type":0,"deadba
nd_value":0}, "server":{"url":"opc.tcp://192.168.144.20:4840","timeout":3000,"identity":0,"security_mode":0}, "server_node":{"ns":4,"type":1,"id":"AlarmsGVL.testAlarm1.cleareTimestamp"}}'
{
"error": 0,
"result": "\"15154451151664412233\""
}
root@RUT956:~# ubus call opcua_client.rpc test_value '{"group_value":{"sampling_interval":1000,"deadband_type":0,"deadband_value":0}, "server": "url":"opc.tcp://192.168.144.20:4840","timeout":3000,"identity":0,"security_mode":0}, "server_node":{"ns":4,"type":1,"id":"AlarmsGVL.testAlarm1.severity"}}'
{
"error": 0,
"result": ""
}

Some of the Node IDs were read successfully but some just returns empty string

{
  "error": 0,
  "result": ""
}

The UA Expert application doesn’t seem to have a problem with reading all data types.

We can schedule another TeamViewer session to figure out the problem.
Thank you for your support.

Best regards,

Lukas Tucek

[Vilius]

Hello, @tucekl,

I hope this message finds you well.

During our remote session, I collected the logs requested by the R&D team. Additionally, I will forward the information you provided in this thread. Once I receive an update from the R&D team, I will let you know so we can reschedule a remote session.

Best regards,
V.

[Matas]

The issue has been resolved by upgrading the firmware to the test firmware provided by our R&D.

A fix for this will be released in the near future with upcoming firmware releases.

Regards,
M.