Kepware/OPC UA connection status

[iain]

I have an application where any of several PLCs may be disconnected (network cable unplugged) at any time. I'm using Kepware to connect to them all using OPC UA, and have a single PLC to test against.

Using the Kepware OPC Quick Client I can see .._System._Error and ._System._FailedConnection change when I pull the network cable. I had planned to use those two to disable the poll group for the relevant PLC.

In OA, though, as soon as I pull the cable the datapoints stop updating. (The Kepware server is on the OA machine addressed as 127.0.0.1, so I won't have connection issues between OA and Kepware.)

16 seconds later I see a single update to the _System._Error and _System._Failed connection tags. This would be sufficient for me to disable the poll group, but brings up a couple of concerns:

• How is the Kepware Quick Client still able to communicate to the server, and why is the OA client different? (Perhaps it's normal OPC rather than OPC UA?)
• After the disconnect I see several pages of
  WARNING, 17/opcua, OpcUaCServerQueue in Function push, Queue overflow @ opcua1-Queue, 1000 exceeded, values will be discarded
  Obviously I don't care about values on that particular device, since the cable is unplugged, but there are several devices still connected, and if the driver is throwing away changes on other devices that would be a problem.

Is there a way for me to determine the status of a device connected to through OPC UA without the 16 second delay? If Kepware Quick Client is using OPC rather than OPC UA should I consider switching to that? (If that question even makes sense...)

(Note: the 16 second delay doesn't appear to be affected by poll rate or the amount of overflowed messages.)

[leoknipp]

I had a look at the description but I do not understand it in detail.
In WinCC OA you have configured the WinCC OA OPC UA client which connects to the Kepware OPC UA server running on the same machine.
Is this correct?
The OPC UA server is connected to the PLCs.

If you unplug the cable the OPC UA server will loose the connection to the PLC.
As the OPC UA server and the client are running on the same machine they still will have a connection.
I expect that the WinCC OA OPC UA client will still have a connection to the server in that case.

Do you see a connection loss between the WinCC OA OPC UA client and server?

Which WinCC OA version and operating system are you using?

Best Regards
Leopold Knipp
Senior Support Specialist

[iain]

Thanks for the reply.

If you unplug the cable the OPC UA server will loose the connection to the PLC.
As the OPC UA server and the client are running on the same machine they still will have a connection.
I expect that the WinCC OA OPC UA client will still have a connection to the server in that case.

This is what I'd expect, too.

Do you see a connection loss between the WinCC OA OPC UA client and server?

I'm not certain. I see hundreds of
WARNING, 17/opcua, OpcUaCServerQueue in Function push, Queue overflow @ opcua1-Queue, 1000 exceeded, values will be discarded

Which I would assume would be due to a disconnection between the WinCC OA OPC UA client and the Kepware server.

Which WinCC OA version and operating system are you using?

3.14 P4 (I believe it's quite old, but it's what we have at customer sites)
Windows 7/64 pro

Edit

It might be worth adding that the Kepware quick client continues to update while I'm seeing these messages, which implies that Kepware isn't causing this by freezing on a disconnect but that the quick client is using OPC, not OPC UA, so Kepware's behavior might change with UA.

[leoknipp]

The log message describe that the queue for the read/write requests to the OPC UA server has reached the limit.
Why the queue was filled cannot be seen without detailed information, e.g. by activating debug flags for the OPC UA client.

If the OPC UA client looses connection to the OPC UA server you will get other log messsages. In my test I got the following ones

WCCOAopcua (4), 2018.02.22 15:51:27.691, SYS, WARNING, 5/opcua, OpcUaCComm in Function read, Can not read from node group @ opc.tcp://localhost:4840 (Statuscode: BadConnectionClosed)
WCCOAopcua (4), 2018.02.22 15:51:29.610, SYS, SEVERE, 53/opcua, OpcUaCComm in Function getEndpointInfo, Get the endpoints for discovery URL opc.tcp://localhost:4840 was not successful (Statuscode: BadCommunicationError)

If you need more detailed information please get in contact with your common WinCC OA support.

Best Regards
Leopold Knipp
Senior Support Specialist

[nmnogueira]

Just an idea, but check if the OPC client is connected to "localhost" (as indicated in Leopold's post), and not to the IP of the machine. I suspect that the IP address will not be available if you unplug the cable

[iain]

That's a good thought, I've had a problem like that in a point-to-point setup. In this case there's a lot of other network activity going on and both localhost and 127.0.0.1 are available. I was using 127.0.0.1:49320 rather than localhost.

I've since switched to OPC DA which seems not to have the same problem.

[a_labropoulos@akatt.gr]

Hello.
I will also managed to use Kepware as OPC Server and WinCC OA as OPC Client to a project.
I need a special License for WinCC OA for this configuration??
Thanks

[leoknipp]

For the WinCC OA OPC client you need no special license. There is no license keyword reserved for the WinCC OA OPC client.

Best Regards
Leopold Knipp
Senior Support Specialist