How to choose RT System at Run Time

[Bob_Schor]

Variations of this question have been asked, but I'm not sure if they've been answered.

We use LabVIEW RT to do a variety of behavior tests.  We have multiple experimenters using the same hardware, and each has his/her own set of "What I want to do" requirements.

Originally, we used LabVIEW 7.0 (i.e. Before Project) to develop a Host and Remote (PXI) application.  The Host application was built as an .EXE, while the Remote was saved as an .LLB, copied to the PXI, and "invoked" at Run Time by calls to VI Server.  Note that this means that the code on the Remote might (is?) not be as compact, efficient, or optimized as if we had built an .EXE.  But we definitely can have Bob's Experiment, Jane's Experiment, and Joe's Experiment on the PC (as separate executables), and each could respectively call Bob's RT, Jane's RT, or Joe's RT on the PXI at run time.  No need to have LabVIEW (or LabVIEW expertise) on this system, and Bob, Jane, and Joe can be "ordinary users".

"Modern LabVIEW" takes a slightly different (and probably better) view towards Real-Time -- both the Host and Remote programs are built as Executables (the RT is built as an .RTEXE).  We can "pre-deploy" the RT code to the PXI, and set it to run at Startup.  This makes getting the RT side "running" semi-automatic -- all you need to do (if it isn't running) is reboot the PXI.

But what if you want Bob, Jane, and Joe's version, selectable by running (on the Host) Bob, Jane, or Joe's Host application?

I'm playing with the following algorithm, which seems to work.  I'm presenting it here to get feedback, especially if there is a "better way" to do this.

The key to this method is that there is an .INI file on the Remote, C:\ni-rt.ini, that contains, among other things, the RT Target's Startup Application path (by default, this is C:\ni-rt\startup\startup.rtexe).

Consider three Projects, Project Bob, Project Jane, and Project Joe.  Within each Project, a Host executable is built having a name like "UI Bob" (or "Jane" or "Joe"), while the Target executable is given the name "RT Bob" (or "Jane" or "Joe").  The three .RTEXE files are copied to the Target and placed in the Startup folder, C:\ni-rt\startup.

Now run one of the Host executables.  It does the following:

• FTP a copy of C:\ni-rt.ini from the Target to itself.
• Get the name of the Startup .RTEXE.
• If it is the "appropriate" name (i.e. if the Host program is UI Bob.exe, the Remote should be RT Bob.rtexe), do nothing, as the Target is already running the right code.
• Otherwise, we need to force the Target to run the correct Target code.  We can do this by changing the Startup entry in the .INI file to the Remote code we need (for example, RT Bob.rtexe), then tell the Remote to Reboot.  When it comes back, it will be running the appropriate RT code.
• The Host now goes ahead and tries to connect to the Remote.  If a connection cannot be established (for example, the Remote code might have stopped), a Reboot of the Remote might fix things up.

Short of trying to write a single enormous program that encompasses every experimental scenario and situation (i.e. have a big Case Statement with a Bob, Jane, or Joe "choice", and a single executable that had everyone's code in it), this seemed to be a fairly simple way to have the robustness of compiled executables on both the Host and Remote machines, yet maintain the flexibility to let the (non-LabVIEW-guru) User choose which executable to run.

I haven't fully deployed this system -- I'm currently at "Proof-of-Concept" stage, but I've got the various "pieces" working.  Does this seem like a sensible appropach?  Are there other, simpler, ways to accomplish this?

Bob Schor

[Texas_Diaz]

Hey Bob.

So I assume you're -completely- working with built executables?  You're not going to work in the editor environment to modify your projects at all?

If this is the case, then having a generic deployment phase at the beginning of the executable (with a "setting up hardware for your app" splash screen) isn't a bad idea -

1. Check the binary on the target, ensure it matches the binary you have on the host machine (in case you ever decide to update).
• If they don't match, FTP the new file down to replace the old one.
2. FTP the ni-rt.ini file, ensure the startup exe is enabled and is pointing to the correct location.  
• If it's not enabled or not pointing to the correct startup file, modify the .INI file and FTP back to the target.
• If you had to update the INI file, ask target to reboot itself.  Wait 30 seconds, and wait for target to become available again.
3. Connect to the target. If you cannot connect, reboot target.  If the target comes back and you still cannot connect to the app, notify user.

That's almost exactly how we handle installation and deployment via MAX.  

The big assumption here is that the built executables were all built with the same version of LabVIEW Real-Time.  If not, you'd need a system replication step in there to make sure the proper version of LabVIEW is on the target before launching the built .rtexe.  

-Danny

[Bob_Schor]

I'm deploying these systems to a lab where students are running experiments.  They know nothing about LabVIEW -- they just want to run their version of the software ("Bob", "Jane", or "Joe") and have it run.  Yes, I'll be making changes and updates from time-to-time, but I'll do that on a Development System, not on the "Production System".

Sounds like what you are proposing is identical (with some minor variations) with my scheme.  The difference is that the Production System does not have LabVIEW (except for the Run-Time System), and is (by design) configured so that the Host and Target run "matching" software (because I develop and test them to match, and then deploy both Host and Target routines to the Production System).

Note that if you ask an RT Target to reboot itself, you don't need to put in a 30" wait -- you can have the System routine simply do the Wait for you.  I tend to put the Reboot code into a Modal Sub-VI that displays a big Decoration on its Front Panel that says "Please be patient -- Target is rebooting ...".

BS