11/15/2021
Hi,
I have a PLC (Server) connected to my PC (Client) via OPC UA protocol. When I check the KeepAliveEventArgs.status from KeepAliveEventHandler, I see the connection expires after 2 or 3 days so I think there is a life time in the session. Is there any way to make it permanent?
thank you in advance.
11/15/2021
thank you for your quick response
There is no error code. I was checking the property Session.KeepAliveStopped in KeepAliveEventHandler and at some point (perhaps after 3 days), the flag showed false.
The PLC just sent the live signal to the PC. There was no message transferred in this case. What do you mean by sequence number wrap-around error?
Moreover, I find the Opc.Ua.ApplicationConfiguration.ClientConfiguration.DefaultSessionTimeout property. Could it define the life time of the session?
05/30/2017
DefaultSessionTimeout only affects the timeout for idle sessions. If you are sending heartbeats the session will not timeout.
SequenceNumber wrapping error is a low level protocol error which you would need WireShark to detect (WireShark has an OPC UA plugin).
What else are you doing in those 3 days? Can you summarize the interactions between your client and the PLC in those 3 days?
11/15/2021
Hi,
do you have any document explaining SequenceNumber wrapping error?
according to your explanation, I think of network interruption in this case, because if someone restarted the PLC, my logic in it should reinitiate the connection again. However if the OPC UA's connection lost, the PLC could not recognize by itself. Is there any flag variable in PLC site, which allows me to observe the connection state?
I did implement this in KeepAliveEventHandler for PC's side:
while ServiceResult.IsGood(Session.KeepAliveEventArgs.Status)
Session.reconnect
if timer > 5 Min
break
end if
end while
However it seems the reconnect method didn't work, or the reconnection effort was timeout. Does the reconnect method work based on this instruction: https://reference.opcfoundatio.....Part4/6.7/ ?
05/30/2017
OK - I was assuming there were no network interruptions or PLC restarts that would explain the dropped session. If the network is interrupted then the KeepAliveEvent allows you to trigger the recovery logic in your client.
Only part of that recovery logic is implemented in the NETStandard codebase. Do you have recovery logic in your Client?
11/15/2021
Hi,
after many experiments, I realize that the session is not expired, the connection is still there. The subscription could be the problem. I read the documentation and find out that there is lifetimecount property which could be relevant to the phenomena. The variable I monitor in PLC changes very little. Sometime it stays the same the whole day.
In the documentation 5.13.1.1 of OPC UA Online Reference it is said:
After creation of the Subscription, the Server starts the publishing timer and restarts it whenever it expires. If the timer expires the number of times defined for the Subscription lifetime without having received a Subscription Service request from the Client, the Subscription assumes that the Client is no longer present, and terminates.
As far as I can understand, I have to let the client send publish request to the server to reset the timer or raise the lifetime of the subscription.
Can I change the lifetime of the subscription by setting the variable MinLifetimeInterval? Is it in second or millisecond?
How can I perform the publish request to the server? I can't see any variable for that.
11/15/2021
I am using UA .NET stack to code the client.
You mean the keepalive event is from subscription, not from session? It sounds weird because the event is from the class opc.ua.client.session
Do you think if there is another reason to make a subscription expire in a session? I have found this topic and it shares similar problem.
05/30/2017
The term keep alive is overloaded.
Each subscription returns and empty notification each time the keep alive expires (expressed as multiple of the publishing interval).
The subscription or session should have a event that allows you get notified when these messages arrive.
As long as the subscription keep alives come the subscription lifetime will not expire.
Separately the session has a timeout that will never happen as long as subscription keep alives are being received.
Lastly, the Session class has a watchdog timer that pings the server periodically and raises a client side event of the server does not respond. This also has the effect of ensuring the Session does not expire.
11/15/2021
I have done an experiment and find out a very weird behavior. In this experiment, there are 2 subscription. The first one has one monitored item and it changes once. The second one has 5 monitored items and they don't change. I let the live signals of subscriptions printed and observe.
The first subscription seems to work normally. The live signals come each 10 seconds adequately.
The second subscription has kind of phenomenon. After 30 minute, some of its live signals start missing gradually. The live signals stop coming after 3 hour.
I have also done this experiment on 2 different PLCs and the phenomenon happened on both of them.
11/15/2021
Subscription parameter
CurrentPublishingInterval : 1s
CurrentKeepAliveCount : 10
CurrentLifetimeCount : 300 but LifetimeCount is 1000 (should they be the same?)
Monitor these values
PublishTime : 1/2/2012 12:49:11 AM (current clock in PLC)
LastNotificationTime : 2 hours sooner comparing with current time
NotificationCount : 1
SequenceNumber of the Subscription with 1 monitored item is 5
SequenceNumber of the Subscription with 5 monitored items is 2
05/30/2017
LifetimeCount can be reduced by the server. Your subscriptions expire after 300s of inactivity.
If everything is working correctly:
For both subscriptions you should see the PublishTime change every 10s.
That said, a bad clock on the PLC could be the source of your issues. Why is it so out of synch?
11/15/2021
PublishTime change every 10s. This one is correct because I receive live signal from each subscription every 10s.
Inactivity of subscription here means no live signal, doesn't it? From what I have observe, if the subscription is created but the PLC tag doesn't change from the beginning, the live signals become weaker from time to time (not 10s anymore but somewhat 5min).
Is there anyway to make the LifetimeCount from the Server fix?
I am gonna check how to change the clock in the PLC.
11/15/2021
Hi,
I have logged the publish error event and I have this record, which shows the behavior of the connection when it hits it lifetime limit.
- First the PLC sends all of the value of the subscribed tag. Although none of them is changed.
- Then there are publish errors:
26.04.22,02:42:41.2,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadMessageNotAvailable
26.04.22,02:42:41.2,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadConnectionClosed
26.04.22,02:42:41.2,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadConnectionClosed
26.04.22,02:43:08.2,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSecureChannelClosed
26.04.22,02:43:10.8,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSecureChannelClosed
26.04.22,02:43:33.7,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSecureChannelClosed
26.04.22,02:43:36.3,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSecureChannelClosed
- After 3 times of the reports above, there is time out in session and the session is closed.
26.04.22,02:47:07.7,INFO;OPC_UA connection ends; SessionNr: ns=1;i=3951517821; Message: Reconnect timeout
26.04.22,02:47:07.8,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSessionClosed
26.04.22,02:47:07.8,INFO; Publish Error in Session: ns=1;i=3951517821; Statuscode: BadSessionClosed
1 Guest(s)