Heartbeat for cRIO

[frajocosta]

Hello,

I have an issue with one machine which sometimes the main .vi on PC freezes.

It is a GUI in PC which commands a cRIO for Input and Output control. 

What happens is that when the GUI freezes the cRIO continues operating with the set variables causing some issues.

I currently have a heart beat system using shared variables. On main .vi a random number generator, generating a number to a shared variable.

Then on cRIO a Read Variable with Timeout function which the timeout is linked to a case structure and if there is a timeout the cRIO resets all ouputs.

But this approach seems not to be working.

Do you know any other approach for this issue or am I doing anything wrong?

Thank you.

[crossrulz]

General advice: Avoid Network Published Shared Variables.  They are slow and insecure.

What I do is have a loop on the cRIO that does nothing but communicate with the host over TCP/IP.  Queues are used for getting messages sent by this module and to return data received by the host.  If the read from the host times out, I declare that the connection is bad, disconnect, and do whatever I need to with the outputs.  This assumes that regular communications is being performed by both the host and cRIO.

[ZYOng]

How to Detect Network Connection Loss of NI Real-Time Target

[frajocosta]

This is a similar approach of what I already have.

One question that came to my mind. If the cRIO software crashes how the outputs behave? Will they have the same state as prior to the crash or will they reset?

[crossrulz]

---

@frajocosta wrote:

One question that came to my mind. If the cRIO software crashes how the outputs behave? Will they have the same state as prior to the crash or will they reset?

---

If you are just using the Scan Engine, the outputs will freeze where they are at.  If using the FPGA interface, then you should have a watchdog signal to the FPGA and then the FPGA should shut everything down when the heartbeat has a timeout.  I typically see this done by just having the RT set a latched Boolean control to TRUE every so often.  When the FPGA reads it, the latching action will cause the control to reset to FALSE.  If the control stays FALSE too many times, then you have the timeout.

[ZYOng]

To supplement what crossrulz had shared:

LabVIEW Real-Time Watchdog Timer Overview

Detect Network Disconnection Between FPGA and Host Computer cRIO