Slow write to Mitsubishi OPC Server and PLC

Questions regarding the use of the .NET SDK 2.0 for Server or Client development or integration into customer products ...

Moderator: uasdknet

Post Reply
richng01
Full Member
Full Member
Posts: 6
Joined: 25 May 2017, 09:11

Slow write to Mitsubishi OPC Server and PLC

Post by richng01 »

Hi all,

I am using .NET based OPC UA SDK for my opc ua client.
When subscribe more than 6000 tags, it is slow (5- 10 seconds) to write to Mitsubishi OPC server and the PLC.
When subscribe to less than 1000 tags, it is fast (2-3 seconds)to write to Mitsubishi OPC server and the PLC.
What is the benchmark speed of write data to PLC and data onchange if subscribe to more than 6000 tags?

Thank you in advance,
RIchie

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Slow write to Mitsubishi OPC Server and PLC

Post by Support Team »

Hi,

what is the speed when you write the 6000 tags WITHOUT using OPC UA to the PLC? Have you tried same szenario with CC-Link or with the Melsec protocol? Have you measured with your own UA client implementation, or have you measured with UaExpert (Performance View)?

Generally, if you use 6 times more tags in the write call, the speed will be 6 times slower, how come that you expect differently?

The communication speed depends on the CPU speed of the PLC (when UA Server resides on the PLC), but will depend on the communication link between PLC and PC (when UA Server resides on PC). In the latter case it is expected that communication will not be faster than with the original protocol.
Best regards
Unified Automation Support Team

richng01
Full Member
Full Member
Posts: 6
Joined: 25 May 2017, 09:11

Re: Slow write to Mitsubishi OPC Server and PLC

Post by richng01 »

Hi Support team,

Thank you for your reply.

I am using .NET based OPC UA SDK for my opc ua client.
I subscribe to 6000 tags and write to one tag only.
For UAExpert, write one tag takes around 1-2 seconds.
For my .NET based OPC UA SDK opc ua client, write one tag takes around 2-5 seconds.
I am calling the API: public List<StatusCode> Session.Write(IList<WriteValue> nodesToWrite);

Thank you.
Richie

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Slow write to Mitsubishi OPC Server and PLC

Post by Support Team »

Hi,

your measurement is so incredibly slow that you most likely have switched "on" trace at "data" level? or are you attached with debugger?

Secondly is not clear if you really measure the same scenario. With UaExpert you add 6000 distinct tags to the DA-View, and additionally open the Performance-View and measure Write with "one" tag in a loop of 100 measurements? The average time between WirteRequest and WriteResponse should be arround 10-100 ms, but may depend on the cycle speed of the PLC, because most PLC do communication only once per cycle (one IO update per cycle). The Write should be independent from the Subscription (except for the general load the subscription puts on the server).

However, if you try to measure "roundtrip", starting with "write" and waiting for feedback on the same item when subscribed, the measurement is wrong (for that reason not possible with UaExpert). Measuring response time with MonitoredItem, will not get you the speed of the communication.
Best regards
Unified Automation Support Team

richng01
Full Member
Full Member
Posts: 6
Joined: 25 May 2017, 09:11

Re: Slow write to Mitsubishi OPC Server and PLC

Post by richng01 »

Hi Support team,

Thank you for your super fast reply.

1. I checked that TraceSettings is set to false.

2. Yes, I added 6000 tags to the Da-View in UAExpert.

3. I am using wireShark to check the timestamp. After calling the API: public List<StatusCode> Session.Write(IList<WriteValue> nodesToWrite);, it sometimes delay for 3-4 seconds before sending WriteRequest. You are correct that the average time between WriteRequest and WriteResponse should be arround 10-100 ms. But the delay is between calling Session.Write() API and sending WriteRequest, and it happens sometimes, not everytime.


Thank you.
Richie

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Slow write to Mitsubishi OPC Server and PLC

Post by Support Team »

Hi,

if the wireshark shows the high speed between WriteRequest and WriteResponse, it is pretty clear that the Server/PLC is not the bottleneck. The UA Server and the PLC is very fast. The UA communication on the wire is very fast. So what is the issue here?

In contrast thereto it seems that your own clientside application is very slow, or at lease occasionally slow/blocking. If the trace setting is "false", the trace and it's file operation can not be the reason. Therefore what is left over? Most likely you block the clientside application yourself while measuring.

The most common programming error is "calling blocking functions within callback (event handler)". You should check your code to ensure not to block within event handlers.

Again, as written before, if you want to measure performance without error, you should use the UaExpert as reference. Everything else (slower or faster) is most probably a programming error in your own application. In any case, you should not measure the Subscription, because you will most likely measure the "scan rate" and the "publish rate", which makes no sense, because is known before (it will not be faster than revised publish rate given by the server).
Best regards
Unified Automation Support Team

richng01
Full Member
Full Member
Posts: 6
Joined: 25 May 2017, 09:11

Re: Slow write to Mitsubishi OPC Server and PLC

Post by richng01 »

Hi Support team,

Thank you for your detailed reply. I learned a lot from your explanation.

Yes, the wireshark shows the high speed between WriteRequest and WriteResponse.
The issue is delay between calling Session.Write() API and sending out WriteRequest, which means the WriteRequest is delayed before send out.

Is that my own clientside application slow will cause delay to send out the WriteRequest?
I will check my code again for any blocking functions.

Thank you.
Richie

Post Reply