How to determine the disconnection of the RT controller?

[William1225]

Hi,

I'm using a compact RIO to monitor several sensors in a system, and I'd like to use the shared variables to pass the data from the RT controller to the host(my laptop).

Since it just monitor the current system condition, I think it's fine to use the shared variables for now...

However some problem is confusing me that if the RT controller is shut down or disconnected for some reason, I still can read the shared varible(the latest values).

I wonder if i have to ping the RT controller constantly, or I can get some information from the RT controller to determine the disconnection between the host and the controller.

Is there other better way to do it? 

[GerdW · Accepted solution]

Hi William,

use an additional shared variable as some kind of watchdog (or "Alive" marker): have the RT system increment/change the value of that variable constantly. When your PC host reads a constant value the connection is lost…

[crossrulz]

The quick and simple way is to do as Gerd said: have a boolean that toggles or have an integer that you increment.  Due to the nature of shared variables, expect some nice delays.

The "proper" solution is to use a direct TCP connection to pass data back and forth.  The cRIO should be constantly sending data over the connection (all of your status) and the PC should send back an ACK just to keep the connection active both ways.  If you do not recieve a message after say 1 second (depending on what your update rate is), you know you have been disconnected.

Full Discloser: I have had nothing but horrible problems with Network Published Shared Variables and I avoid them like the plague.

[B_Strange]

---

@crossrulz wrote:

I have had nothing but horrible problems with Network Published Shared Variables and I avoid them like the plague.

---

I have never used network published shared variables. Whenever I've messed with cRIO, I've used separate TCP read/write loops, each sending a flattened string that unpacks to a typedef cluster. This has been very reliable in my experience.

In the watchdog scenario presented with this thread, I imagine having the UI computer generate a timestamp every time it properly executes a TCP read loop iteration, then comparing the previous timestamp with the current time. If the time difference exceeds x seconds, then an alert can be generated. Is it possible that a similar setup using network published variables might fail? If so, why?

[crossrulz]

---

Dave_St wrote: Is it possible that a similar setup using network published variables might fail? If so, why?

---

I do not have the equipment here to check, but I am not sure how the shared variables will react if the connection is removed from the cRIO.  Assuming the shared variables are hosted by the cRIO, I think if there is a disconnection that the PC is just going to keep returning the last values it updated.  It might return an error (assuming you are actually looking for it).  But the whole question is how do you know you had a successful read?  The simplest way is to have the cRIO update a variable and then the PC looks for that value to change.  I have learned that it is typically best to use an integer that is incremented since it is possible to miss updates.  With the boolean, you miss the false and read multiple true, you assume the disconnection even though it was just a race condition.  With an integer, you miss a number and you don't care.  3 (the last read value) is different than 1 (the previously read number).

[BillMe]

Full Discloser: I have had nothing but horrible problems with Network Published Shared Variables and I avoid them like the plague.

Interesting as I've had just the opposite experience (using them between a host and an RT controller with the Simulation Interface Toolkit).

[Electromecha]

You can simply show and wire the 'Timed-out' terminal on the Shared Variables within your Host (HMI) application, assuming the Shared Variables are hosted on the RT.

Then if the RT is not running, the Shared Variables on the Host will time-out.