When the OPCUA client driver uses settings with a publishing interval and a MaxKeepAliveCount that result in a value of more than 20 seconds, and the OPCUA server sends no value changes (publish responses) for all the variables in the subscription, variables in zenon become INVALID, even though no bad status is received, and even though the timeout for the server (publishing interval x maxkeepalivecount) to reply has not yet expired.
With the default settings in the driver, (500ms publishing interval, keepalivecount 5) this issue does not occur (server is supposed to send a response at the latest after 2.5 seconds)
With a 5000ms publishing interval, and keepalivecount 12, the server is only supposed to send a response at the latest after 60 seconds if there is no value change. In this case, the driver after 20 seconds incorrectly assumes that the server is no longer available and set the variables to INVALID, without attempting to reconnect to the server.
When the OPCUA client driver uses settings with a publishing interval and a MaxKeepAliveCount that result in a value of more than 20 seconds, and the OPCUA server sends no value changes (publish responses) for all the variables in the subscription, variables in zenon become INVALID, even though no bad status is received, and even though the timeout for the server (publishing interval x maxkeepalivecount) to reply has not yet expired.
With the default settings in the driver, (500ms publishing interval, keepalivecount 5) this issue does not occur (server is supposed to send a response at the latest after 2.5 seconds)
With a 5000ms publishing interval, and keepalivecount 12, the server is only supposed to send a response at the latest after 60 seconds if there is no value change. In this case, the driver after 20 seconds incorrectly assumes that the server is no longer available and set the variables to INVALID, without attempting to reconnect to the server.
An issue has been addressed in the OPCUA client driver where after 20 seconds without receiving a publishresponse, with either a DataChangeNotfication or a keep alive message, the OPCUA client driver set the variables in zenon INVALID, even though the server still had time to send a publish response with a keep alive message.
Now the OPCUA client driver correctly waits the appropriate time to receive a Keep Alive message from the server and no longer sets the variables to INVALID if no PublishResponse with a DataChangeNotification or KeepAlive was received.
Also the OPCUA client driver now correctly calculates the time until the server must send a PublishResponse with either a DataChangeNotification or a keep alive message, and will consider the connection to the server broken, after: publishing interval x keepalivecount + 1 second, when it has not received such message from the server. The OPCUA client driver will then cyclically attempt to reconnect to the server and create a new subscription.
If there are no value changes for the MonitoredItems in the subscription on the OPCUA server, the OPCUA server must at least send an empty PublishResponse after the revised publishintervall x keepalivecount, to indicate connected OPCUA clients that the server is still available.