OK, thanks for details.

There is not much I can add, though. It is the server's responsibility to maintain the connections to the underlying systems, and it is the server's responsibility to fulfill the Read with valid data if possible. The server seems to be failing at that, and it is therefore the server side where this should primarily be resolved.

Best regards

Thank you for your detailed reply.

Usually when I see that connectionstate is not 20, I don't try to Read because it never succeeds.
But I made change and tried to read when connectionstate is not good.

At ReadValue I get exception:

An OPC-UA operation failure with error code -1 (0xFFFFFFFF) occurred, originating from ''. The inner exception, of type 'OpcLabs.EasyOpc.UA.UAStatusCodeException', contains details about the problem.

Inner exception:
InnerException (System.Exception) {"Status is not good: BadTimeout."}
System.Exception {OpcLabs.EasyOpc.UA.UAStatusCodeException}

I got a code that Siemens AG uses for their sample .NET program with OPC foundation's DLL.
It seems to reconnect at read after some seconds. I'm seeking differences with my code.

Thank you.

Best regards

Hello,

I understand the issue. Whatever happens between the OPC UA server code and the actual hardware is generally, however, outside of control of any OPC client. Normally, the server is expected to assure connections to the downstream systems automatically - for reads, writes, subscriptions etc., without the client having to do anything for that.

We do not do anything "magical" in QuickOPC's SubscribeDataChange. Only the things that are necessary and that every client has to do: Creating a subscription, adding monitored items, etc.

Some servers need time to set things up. In this case, if you subscribe, you may not notice anything, because the server will eventually send the data, when it becomes available. But the behavior of such servers in case of Read (from device) is not always the same. Some servers may block the call until the data becomes available. Others may simply return an error (or bad status). The data may become available later, so the next Read may succeed. It is possible that this is your case, but it is just one of the possibilities, and I cannot be sure.

All in all, the question is more about server behavior, so it should rather be directed at the server vendor.

What exception or status code do you get when you do the Read and the server is not connected to the PLC?

Best regards

Hi, I'm new to this forum.

I'm developping a application to read/write data on Simens's PLC, via SIMATIC NET OPC UA server.

First I wrote a working version using OPC foundation's .NET DLL, later, after our company purchased
QuickOPC, using OPCLabs EasyOpcUa DLL. Both version works properly.

My problem is, that the connection between OPC UA Server and PLC sometimes drops.
or when the PLC is off when OPC UA server started running, then UA server does not detect that the PLC started running later.

Simens's OPC UA Server for their S7 PLC has variable "connectionstate",
(example: opc.tcp://localhost:55101/; ns=3;s=S7_connection1.connectionstate )
which s 20 (or 19) when PLC is connected, and 17 or 18 when not connected.
When this is value is not 20 (or 19) Read or Write oparation on any tags fails.

I need a way to make UA server connect to PLC, from UA client code.

With OPC foundation's DLL (Opc.Ua.Core and Opc.Ua.Client) I could not make server connect to PLC.
With OPCLabs EasyOpcUa, when I subscribe to a tag (using EasyUAClient.SharedInstance.SubscribeDataChange)
UA server magically reconnect to PLC, but with normal read/write action (using EasyUAClient.ReadValue or WriteVaue)
UA server does not reconnect to PLC.

I wonder what SubscribeDataChange does behind the scene to make UA server reconnect, what ReadValue does not.

My program does not need Subscriotion for its own purpose. I wish I can find what I can do to make server reconnect before reading value, when connection between UA server and PLC is down.


With best regard
Mutsumu Nomura a.k.a Muchan