I am trying to help a customer in optimizing opcUa client-server communication. He developed a C# opcUa client that runs on a customized B&R APC (with the subscription method because the browse had very slow communication time). The opcUa server runs on a X20CP0484.
During the test he saw that the communication between client and server was very slow (more or less 200 ms).
He didn’t use opcUafx because of the older version of AR and because he has to exchange structured variables and arrays.
Anybody knows some parameters on the opcUa server to try to improve the performance?
Is there a more efficient way to write the opcUa client?
Anybody that tried in the past to write a little opcUa client?
Any suggestions? I’m trying to use the ua expert performance plugin to understood if the problem is the client or the server…anybody used it in the past?
I never write a PC opcUa client so I don’t know where I can bang my head…
There are a couple of server-side communication settings you can take a look at:
CPU Configuration → OPC UA System → Limits: Publishing Interval “Limits the range that is available to a client for the publishing interval. The client determines the desired publishing interval when setting up or modifying a monitored item. The server limits the value within this range and informs the client of the actual value in the answer. See “CreateSubscription” in part 4 of the OPC UA specification.”
OPC UA Default View file → Minimum sampling interval “Minimum sampling interval for the OPC UA server as a timer. [Default: NOT set]
In A4.32 and later, the sampling intervals are specified as timers. The number of available timers, each timer’s sampling interval and a default timer can be set in the CPU’s OPC UA server configuration. The default timer is used for a monitored item if the client does not provide a sampling interval.”
On the client-side, the Client should be able to provide a PublishingInterval when it creates a subscription. This will tell the Server how often data will be published. It must conform to the above settings, but that may be a way to speed up communication.
Of course, if the client is custom-written there may also be programming optimizations to be made.
In general, OPC UA isn’t a real-time communication protocol (unless you’re using OpcUA FX or OPC UA over TSN). In fact, it can get quite slow when there is a lot of data, even when using the ReadBulk and WriteBulk function blocks of the AsOpcUac library which were made specifically to communicate a lot of data. See the table at the bottom of this page. In addition to processing time, you also have to take into account network parameters of any device the communication has to pass through.
It could also help to use Information model->PV 2.0 and only enable the base name of the structure variable in the default view file and not all sub-elements.
The structure is now a so called extension-object and the OPC-client can access only the whole structure (read/write). If this structure variable is placed in a subcription, the whole structure is sent, if one off the elements has changed (but this could still be one tcp-frame).
This will also speed up the startup of the opc-client, because less nodeids’s are needed.
Hi Giovanni, maybe my question is out of topic. Have you tried to check communication using UAExpert and have you recorded Wireshark trace. Is it communication slow as well? If so, then problem is on server side, if not then you can focus on customer Client and his implementation.
Hi @boschellog, did any of the above suggestions resolve the topic for you? If so, could you please mark the solution? Alternatively, if this is still an open topic, can you please let us know the latest status?
Hello Brittany! I am waiting for the customer to checking the communication time using UA expert as client and B&R PLC as opcUa server. I’ll update when I will get some news.
