61850 - remote server - connection status

[Woss]

Hi,

I ran into a problem while testing the 61850 communication.
I connected to a relay with 61850, then shut down the power to the relay to provoke a loss of connection and force our cRIO to try to reconnect to the relay until the power comes back.

I tried the following 2 options:
https://gyazo.com/9cebc8267cfb5d692412c6b9a8ad984c

However, the dequeue report doesnt give an error after a loss of connection and the remote server connection status property stays as "connected" and never goes to "disconnected".
The same way, getting the remote server from the client and checking the connection status only shows "connected".

The easiest way with which I succeeded to get a "disconnected" status is by using the conclude function, which is not useful in this case.

The 2nd way (my current workaround) is to use IO handler in order to read a variable (The $RptEna of the BR report control I use) before using the Dequeue Report vi. After a few timeout from the IO handler, the remote server connection status suddenly switches to "disconnected". Note that if I dont use the IO handler to read a variable, the remote server connection status stays "connected" and never goes to "disconnected".

This workaround however takes too much time to indicate a loss of connection so I use the timeout response of IO handler Send Request vi directly, without waiting for the remote server connection status to switch to disconnected.

Does anyone with experience with 61850 know the proper way to detect a loss of connection?

Thank you for your help,

[ThreeLions]

Hello,

Thanks for your question. According to your description, in your project, the relay acts as server and the cRIO acts as client, is it right? If so, I believe the example, Initiate.vi in IEC 61850 MMS Client.lvproj, could help you.

The Initiate.vi will read the Connection Status through property node. It is the same as your first way. If you click the Conclude button, client will lose the connection with server. The speed of response is very quickly. So I wonder if you put that property node in a loop?

Also, you have mentioned your workaroun. Could you please send it to me for reference? Is it similar with the example Report(Common).vi?

Thanks!

[Woss]

Hi ThreeLions,

You are right, the relay is the server and the cRIO is the client.

I have no problem connecting to the relay, reading data, writing data, subscribing to BR report and receiving those reports. I can also conclude a connection if wanted. The cRIO works as a proper 61850 client, no problem there.

My problem concern the Remote Server -> Property node -> Connection Status:

After initiate, the status goes to "Connected".

After Conclude, the status goes to "Dİsconnected".

-> no problem so far.

However, After initiating a connection to the relay and getting the "Connected" status, I power down the relay and the status stays as "Connected", even though the relay is now offline.

-> here is my problem.

I made a little video that shows the problem (7ziped down to about 11Mb) using the client application.vi that is provided with the 61850 library:

https://mega.nz/#!FJhVEC7L!JvnzNEYxaq6uCO-XVD38rNQuWEtGAYuP00i-c45GWds

you can see that I connect to our relay with client application vi and ping the relay IP address, which shows that the relay is online.
-> the status becomes "connected".
I then shut down the relay and try to ping it again, now the ping fails and proves that the relay is offline
-> However, the status stays "connected"
I then try to conclude the connection to the relay
-> the Conclude operation times out, again proving that the relay was already offline and disconnected
-> the Connection Status finally becomes "disconnected"

I then do it again, this time while probing the connection status of the remote server property node (in _Update_RemoteServer_ConnectionStatus_To_Tree.vi), to further show how client application vi fails to give the disconnected status.

If I did something wrong during this video demonstration that would explain why the connection status stays as "connected", please let me know.

Thanks for your help.

[Woss]

Hi ThreeLions,

You asked for my workaround which is shown on this screenshot:

https://gyazo.com/6332f6dc9dbafd9b71099ea3c26a0c0b

Report (Common).vi only uses "Dequeue Report.vi", which, like I said in my 1st post, does not generate an error when the relay is taken offline (most probably for the same reason, or because, remote server connection status is still "Connected").

My workaround consist on creating an IO handler and on reading the "BR report enabled" variable.
If the response is a TimeOut (or not "Response"), then I dont bother using "Dequeue Report.vi". I destroy the report, conclude the connection, and try to reconnect to the relay.

Like I said in my 1st post:

- If I use this IO handler, after a few timeouts from the IO handler response, the connection status of the remote server does turn to "disconnected".

- But if I dont use the IO handler, the status stays as "Connected" as long as the relay is offline. However, when I turn the relay back on, then I receive a error telling me that I should 1st initiate a connection to the relay.

I hope those information can help pinpoint my problem. I have some ideas as to what the issue might be but cant be sure without looking at the source code 🙂

Thank you again for your help.

[ThreeLions]

Hello Woss,

Thanks for your detailed descriptions. I have reproduced this issue in my environment. As a result, Keepalive leads to the unreasonable Connection Status.

As a inherent attribute of TCP/IP, Keepalive can be used to indicate to Internet infrastructure that the connection should be preserved. The default of timeout is 7,200,000 milliseconds(2 hours), and does 5 times connections during that time. Thus, if do nothing after power down the relay, you will take 2 hours to waitting for the Disconnection status. And I have done this test. However, if you do some operations during that time, like you did in video. The network will detect the Disconnection status. So it is a general case in TCP/IP, not a bug for IEC 61850.

I believe your workaround have already overcomed this issue. And if you have more questions, please don't hesitate to contact us

Thanks!

[Woss]

Thank you for your time and your explanations ThreeLions.

[ThreeLions]

You are welcome!