Launch a VI programmatically on RealTime target from a host PC

[smurfup]

Dear community,

I tried to launch a VI on a cRio device programmatically from a VI running on my PC. Therefore I followed the instructions given here: http://digital.ni.com/public.nsf/allkb/A7DBA869C000B5AE862570B2007C4170

As described I created a build specification, built and deployed it without errors. But when I try to start the VI programmatically the execution node returns an error, saying that the VI can't be executed because it contains some errors. Nevertheless when I execute the RT VI manually all works fine. After stopping it but NOT closing it I can start the VI programmatically. But when I close it it dosen’t work any longer 😞

I believe something is missing in the build specification. I put all the sub VIs, etc. into the build specification and I unchecked the options in the distribution property window not to exclude files from vi.lib etc. but something might be missing.

Is there a way to debug the VI inside the build specification to get more precise error information?

[Bob_Schor]

What are you really trying to do?  The modern "model" of the RT Target is that you can be in "Development Mode", running LabVIEW on your PC and having a Project with code deployable to the RT Target and runnable from within Project, or in "Executable" mode, where the RT Target reboots and runs a VI that you designate when it starts up.

When I started with LabVIEW RT, we were using LabVIEW 7.0, which used a very different model -- LabVIEW ran on the Remote, and you interacted with it through LabVIEW Server.  This allowed you, at run-time, to have multiple possible routines living on the Remote and designate one of them to be run when you invoked it through VI Server.  But not now.

If you need this functionality, you can either build it into the start-up routine that runs on the Remote (i.e. if you want to choose between Routine A, Routine B, or Routine C, have a Super-Routine that accepts A, B, or C and runs the appropriate Routine) or can programmatically change the Start-up routine on the Remote and reboot it.

In my case, I chose the latter approach.  When I build, say, Routine A to run on the Remote, instead of naming it Startup.rtexe, I name it Routine A.rtexe, with similar logic for Routine B and C.  The actual routine that is run is saved as an entry in the Remote's ni-rt.ini file, which can be queried (by FTPing it to the Host and using the Configuration File utilities to examine it) to see which routine actually is the Startup routine.  If it needs to be changed, the appropriate entry in the .ini file can be reset and the Remote given the "Reboot yourself" command.

In our situation, most of the time we run Routine A.  If someone wants to run Routine B, she runs Reset Remote, specifies Routine B, then is responsible for running it again after she finishes and resetting the Startup to Routine A.

We could have (but didn't) partly automated this by having the Remote, when first contacted by the Host, identify itself.  If Host A says "Who are you?", and the answer comes back "Remote B", then the Host could, in principle, fix the problem itself (but we didn't need to do that, so we didn't).

Bob Schor

[smurfup]

Thank you for the reply Bob. I see that my question was not really clear. First of all I’m using LabView 2015 and I am using the “Development Mode” that you described. At the moment I only have one remote PC and one routine for the cRio.

My project consists of three parts: part one is the GUI running on a Windows PC, part two is a VI running on the real time controller and part three is an VI for the FPGA. At least the VI on the PC communicates with the help of shared variables over LAN with the realtime VI and this interacts with the FPGA VI. All this is running when I follow these steps:

1. connecting to the cRio my using the commands in the LabView project explorer
2. open the GUI VI
3. open the realtime VI
4. start the realtime VI (here Labview compiles the VI if necessary and deploys it on the target automatically)
5. stop the realtime VI without closing it
6. start the VI on PC that invokes the realtime VI. Now both VI (PC and cRIO) are running

I like to skip step 3, 4, 5. My goal is to put the real time part of my project into the cRio target (it’s an cRio 9033) and start it programmatically from one Windows machine. There is only the one VI (with some sub vi and some necessary libraries) that should rest in the memory of the cRIO device.

Today I created a really easy realtime VI and followed the instructions from the knowledge article I mentioned above. This worked. It was possible to start the realtime VI from PC without opening it manually before.

So I believe my problem has something to do that after deploying the VI and all sub vi etc. to the cRio something might be missing or there are some sub vi or libraries that can’t be found in this configuration. Unfortunately, the invoke node in the PC vi only tells me that there are errors in the realtime vi but let me unclear about the details of these errors.

[Bob_Schor]

It's been about a year since I had to make any changes to my LabVIEW RT Project, so I forgot some of the steps.  I'm currently sitting at that machine, with the Project open, reminding myself of the steps.  My RT Target is a PXI rather than a cRIO, but I think the same principles apply (except you have the additional "fun" of FPGA code, of course ...).

So I'll remind you that the "model" for LabVIEW RT (which you can violate, but you do so at your considerable peril and pain, as you are discovering) is that code is deployed on both the Host and the Target, the code on the Target is started first, and then the code on the Host makes the appropriate connections with the Target.

There are two common ways to get the Target to start first, the "Run-Time" method and the "Development" method.  The Run-Time method is to have the Remote code compiled as a Real-Time Executable, deployed on the Remote, and set to Run as Startup (so just turning on the Power on the Remote starts the program running).  The Development method is to have the code in LabVIEW Project, Connect to the Remote (which if it is running an RTEXE will cause it to complain and make you insist), deploy the code to the Remote, and then manually Run the top-level Remote VI (actually, when you hit Run, it deploys all the sub-VIs that it needs from Project anyway).

When you are just getting started, you are, of course, in Development Mode (as you haven't finished the Real-Time code for the Remote).  Whether or not you've made any changes to the RT code, you will need (at least once) to do a Connect (and "OK" past any inconsistencies it mentions) and Run your Top-Level Remote VI (right from Project), which will do the Deploy for you.  Now you can run your Host code, which should start by setting up hand-shaking with its RT counterpart, and away you go.

Once you get the RT code "stable", you can Build an RTEXE out of it and tell the Builder to Run as Startup.  It will probably ask you if you want to reboot your Target (to get it into memory and running).  Once it is running, you can concentrate on the Host code which, when it starts, will again hand-shake with the (now-running) RT counterpart.  Note that when the Host stops, you can get things back to a stable configuration by simply rebooting the Remote, something the Host can "force" or the Remote can "detect" (presumably a well-behaved Host says "Good-bye" to the Remote) and reboot itself.

Eventually, both Host and Remote codes will become stable.  Now you build an Executable for the Host, have a deployed-as-startup RT-executable in the Remote, turn on the Remote, double-click the nice Icon you made for the Host Executable, and Away You Go!

That's the way NI wants you to do it.  Like you, I rebelled against this "We Know Better Than You How To Do This" and tried various auto-loading/launching schemes (some of which worked), but ultimately I came around to the realization that (a) with the current structure of LabVIEW Project (which I really like), (b) the difficulty of doing "programmatic" deployment and running during Development, (c) the relatively "painless" method (described above) of doing testing on the RT side during development, and (d) the tremendous advantage of not having to make any changes in the code when switching from Development to Executable modes (other than building the Executables), I am willing to concede that NI is (Mainly) Correct.

Bob Schor

[smurfup]

Thanks a lot for this detailed explanation. I think some things becoming clearer for me. I will be back in laboratory at the end of week and continue to work on that project. Let you now about my results soon.