Loosing contact with DistributedRealTimeController

[ollesvensson]

I Use three Compact Rio Realtime Controllers, that are logging Data and sending data to a PC through Fifo. Very often the information "Waiting for real Time Target to respond" comes up on a dialog.  After that the dialog "Stop waiting and disconnect" appears. There is nothing else to do exept accepting, because the dialog locks all other Labview windows. After accepting, the real time controller is disconected and there is no way that I know about to to communicate with the controller. The only thing that works is a physical hardware reset. This will not be possible in the future because of the location of the controller. I can accept that the controller stop working if it is possible to do a software reboot but this shuld not happend at all.
Is there a good guidance to implement a working watchdog?
How do I do a correct error handeling of the communication with the variables.
Is it possible to implement a automatic reboot of the controller when Labview disconnets the controller?
What software is generating this dialog.
/Olle

PS
The fifos is located on the PC. It would have been better to locate the fifos on the remote targets but then the dialoge allways appears.
I have installed the latest version of Labview and hoped  that it would solve the problem but it did not.
 

[Karunya_R]

Hi,

When you say FIFOs, I am assuming that you mean the RT FIFOs. The problem could be caused when large datapackets are sent back and forth or when the smaller data packets are sent in rapid succession or if the CPU gets starved. Have you always had this problem? Or did you just start to have this issue?

Is there a good guidance to implement a working watchdog?

About the network watchdogs, you might this link useful. This discussion forum can also be useful for you.

How do I do a correct error handeling of the communication with the variables.
About error handling on your shared variables, what type of variables are they? If you are using a global variable or a single process shared variable, they generally do not return errors.

Is it possible to implement a automatic reboot of the controller when Labview disconnets the controller?

Yes it is. There is a VI called RT Reboot controller. This knowledgebase tells you how to find it.

• What cRIO controller are you using?
• What version of LabVIEW, LabVIEW RT do you have?
• Are you using LabVIEW FPGA? If yes, what version?
• Have you always had this problem? Or did you just start to have this issue?

[ollesvensson]

Thank you for the answers. I will answer your questions about my system more detalied then I will look deeper in to your solutions.
The FIFo is a Real-Time network published FIFO 32 000 Arrays with 32 elements (single). Sending data from distributed controllers to PC that stores the data on  the hard disk.
All variabled has only one process in one computer that writes to the variable and one process on another computer that reads from it.

My hardware is two cRio-9012 with 9101 FPGA chassi and one cRio 9014 with 9104 fpga chassi
All labview program versions are 8.5.1 including FPGA
I have allways had this problem, the problems decreases in every new version of Labview.

Can you explain what part of labview that gives the message "Waiting of real time Target to respond"?

Best Regards Olle Svensson

[StevenA]

Olle,

Have you checked your RT CPU usage?  How fast and how much data are you transfering?  Usually you will get this message when you are over taxing your RT CPU and the default communication to labview will drop out as the RT tries to run the code as best it can.