cRIO My Host VI is not responding

[Mudda]

Hi,

      I have couple of questions regarding my cRio. I made a Host application and I executed it, it was running ok but now when I tried to run it again every time it is not responding and I have to close all the labview windows. The FPGA VI is running fine no issues with it.

The other question  I have is how do I deploy the applications the FPGA VI, my Host VI and its SUB VI's on to the cRio and when ever I power the cRio I want the application to run. Will this cause any issues if I run the application from My Laptop?

thanks in advance,

Mudda.

[MattP]

Hello Mudda,

With regards to the RT Host VI, it may be the case that the VI is taking up all of the execution time of the processor and is starving out the communication loop that is used to send data back to your PC.  You should make sure that all of your loops have some kind of timing element (a timed loop or a wait function inside of a regular loop) to ensure that your loops will leave some execution time for the default communicaton process.  This is especially true when using just the default front panel communication method (i.e., clicking 'run' on the RT VI rather than communicating with it via a windows VI over shared variables).

To make your application (RT host VI and FPGA VI) run automatically on startup of your cRIO, you will need to do the following:

1.  Download the FPGA VI to the flash memory on your cRIO.  If using LabVIEW 8, right-click on the VI in the Project Explorer Window and select Download VI or Attributes to Flash Memory...

2.  Build an executable out of the RT VI.  Under your RT target  in the Project Explorer, right-click on Build Specifications and select New>>Real-Time Application.  Select the source files necessary for your application and any support files to be included.  Click Build.

3.. After building the RT Application, you will find its entry under the Build Specifications folder in your project.  Right-click on the application and choose Set as startup.  Right-click again and choose Deploy, which will download the application to your cRIO.

[kugeler]

Hi Matt,

your answer to Mudda's question converning the "starving out of the communication loop" was helpful to a similar question I was going to post here.
Nevertheless, I am wondering how this issue can be handled properly.
I am reluctant to sacrifice processor cycles for the communication with the host, as this was the reason why I changed to RT-LV in the first place.
When I press the stop button in my time critical application, the routines somehow stop working, so a basic communication is actually taking place.
The problem is, that they don't stop working ENTIRELY.
My question is: Am I missing something? Are there any VIs that I can attach to the end of the program, that speed up the termination of the routines.
Or maybe there are ways, to quickly clear the memory of the RT-host?
Any help on this would be greatly appreciated.

Sincerely,

Oliver

[MattP]

Hello Oliver,

We'll need to sacrifice some of those processor cycles to allow for the lower-priority communications routine to operate, but with good programming architecture, this should not affect the operation of your more time-critical loops.

I'm a little unclear as to what you mean when you say that the routines stop, but not entirely.  Do you have several loops, and only some of them are stopping when commanded?  If so, it's important to remember that a while loop will finish its current iteration before evaluating the stop condition, so those other loops might be stuck in a sequence structure or other processing before they can exit their loops.  If that is the case, you can employ case structures to short-circuit code execution in the loop if the stop condition signals its time to stop.

[kugeler]

Hello Matt,

thanks for your fast reply.
I'm sorry I was not very clear about routines stopping "entirely".
My architecture is as follows: I am using a PXI host running RT in combination with a PC running Labview.
The user interface is on the PC.

I have to admit, that I'm still new to programming LV-RT, so my problem might very well be a trivial one. I am aware of the problem you are describing in the second part of your reply, therefore I have reduced my routines to one single loop running at the fastest possible speed.

What I meant with not stopping "entirely" is the fact, that my routines are working fine when I first run them on a freshly rebooted host.
Yet, when I stop them, and try to rerun them a second time, it sometimes takes forever to compile them again. The host seems to be busy with things that weren't there the first time. There are various messages from the host side, like "waiting for host to reply", or "stop waiting and disconnect". I was wondering if I could implement additional code into my routines, that would remove those routines from memory, or, return the host to the state it was in after rebooting. (Obviously I could always reboot the host, but I would rather avoid this time-consuming solution)


All the best and thanks in advance,

Oliver

[MattP]

Hello Oliver,

It sounds like you're running into the front-panel communication problem that I was working with Mudda about.  What I suspect is happening is that your previous code is in fact still executing on the RT target and as such it is unable to process the commands from your PC.  It might seem counterintuitive, but if you put a small loop delay into your while loop(for example, a Wait Until Next ms Multiple VI with a 100 ms time), this should free up enough processor cycles so you don't hit this error.  Using the default front-panel communication is very inefficient, so we recommend that for your final system you create separate host and target VI's, each communicating via shared variables if you are using LabVIEW 8.0 or later, or via TCP/IP if on 7.1 and below.  This way, you can send only the data you need, when you need it, and not need to waste processor cycles on updating a front panel.

[kugeler]

Hello Matt,

thanks again for your help.
This last point of yours actually did the job.
I think with all your suggestions I'm now able to build my code properly.

Sincerely,

Oliver