Change RTEXE from program cause SVE issue

[1984]

Hi,

I have created a VI which

• Compares the contents of the RT (c:\ni-rt\startup) to the latest release on the host pc
  • If different
    • Reboots the RT in safe mode
    • Erases the contents of the c:\ni-rt\startup of the RT
    • Copies the most uptodate files from the PC to the RT c:\ni-rt\startup
    • Adjusts the ni-rt.exe if neccessary by chaning the startup rtexe name
    • Reboots the controller in normal mode

Overall this works just great to "reimage" the controller. 

What I have realized though is if I add this VI into my main application and a "reimaging" occured then the app will drop error code -1950679035 (SV engine not started) when the app wants to start reading the network variables. First I though I just need to add some delay to the end, but no... it actually no matter how much I wait the host application (reading the network variables) will always drop me that message.

What I also have realized that if I run my small "imaging" routine separately, let it finish, and then start my host app then it runs just fine, even if I start the host app right after the imaging routine without any delay. 

This makes me thing that once the imaging is done I need to stop labview to execute VIs. Once its stopped and I start my host VI it runs perfectly fine. 

I can change my app in a way that if it has to reimage the RT then it shuts down the main host app, and warns the user to restart the app. So when the user runs the host app again, the imaging routine doesnt need to do anything (as it just installed the latest files to the RT), so no reboot is needed, so the app will run fine.

This is a little bit complicated though, if possible I'd like to avoid any restarts.

How can make my app to read the network variables without an error, without restarting the application?

thx.

[Bob_Schor]

I started doing LabVIEW RT with LabVIEW 7, where there was no "Deploy", no "RTEXE" -- you did everything through VI Server and started whatever routine you wanted to run on the PXI whenever you wanted to (making sure you stopped the PXI when you were done).

When I moved to the (much better, in many ways) "new way" of doing LabVIEW RT, I wanted to know how to select, at run-time, which of several RT routines to run (as we had several "pairs" of Host/Remote codes).  I finally arrived at the following scheme:

• Each RT Routine would be given a unique name, e.g. App 1 Start.rtexe.
• Each Startup routine would be deployed to its own Target Directory, e.g. c:\ni-rt\startup\App 1
• One of these would be set to run at Startup.

All of my RT routines were designed to reboot themselves on Exit, leaving them "ready to roll".  I made a Host Action Engine with three Actions, all involving the C:\ni-rt.ini file on the Remote:

• Query -- FTP the INI file to the Host and return the RTTarget.ApplicationPath as the Startup Path to the caller.
• Clear -- FTP the INI file to the Host, set the Startup to \startup\startup.rtexe (the Default), FTP it back.
• Set -- FTP the INI file to the Host, set the Startup to the Path passed in, and FTP it back.

Once the Set or Clear Action was done, reboot the Remote to start it running the "correct" code.

In practice, we (now) mostly run a single Remote routine, so our Host routines don't bother querying the Remote, though the code is there to do so.  Instead, if a User knows he/she needs to run an older version, they run the Reset PXI utility, inputs the Version to run, and the PXI gets its INI reset and rebooted.  If they forget to set it back, well, let's say they only make that mistake once ...

The key difference between our approaches, I think, is that these routines only modify the INI file -- they never mess with the contents of the Startup folder, which is being used to house the current copies of all the LabVIEW RT routines (including the default startup.rtexe) that can be run, depending on which is selected by modifying the INI file.

Bob Schor

Bob Schor

[1984]

While I appreciate your thoughts this doesnt solve my problem. Changing the ni-rt.ini to point to the right rtexe can only be done once the right rtexe is on the controller and copying the right file to the RT is exactly what I'd like to automate.

BTW I do the same what you have described as query-clear-set with the ni-rt.ini (accidentally refered as ni-rt.exe in my post), so once I have the right rtexe in the startup folder I check the ni-rt.ini and change the startup file name if neccessary.

We have dozens of RT targets around the globe. Most of them are not even accessible thru internet/intranet, but even if they would it is a time consuming and error prone to copy the rtexe to each one of them manually. (plus it requires trained operators to perform this kinda sensitive action) So I decided to go down the road I have explained above when the application checks if it uses the right RT files (belonging to the executed host application). If the controller already has it then fine, no action required. If the controller has something else then delete the entire startup folder and copy the most uptodate files to the RT. This requires 2 restarts, one in safe mode and one to get back from the save mode, and it seems the SVE doesnt like it too much.

As I dont expect that this question gets answered anytime soon I decided to stop the app if the RT had to be reimaged with a descriptive popup message. Once the user restarts the app the RT will already has the right files so after doing the check it no reboot is needed so the app can continue its execution.

[Bob_Schor]

While I structured my scheme so that I didn't have to move the various RTEXE's to the Remote, but only dealt with the .INI file through FTP Reads and Writes, if I have the RTEXEs on the Host, along with their support Folder and Files, there's no reason I couldn't extend my scheme to check for the presence of the RTEXEs on the Target and, if missing, FTP them over (thereby "deploying" them.  It's only a question of who does the work and when.

The scenario I described basically has three computers -- the Development PC, with the sources, where the Host and RTEXEs are built, the Host PC to which the Host EXE and its support Folder and Files are copied (and, typically, a Shortcut to the EXE placed on the Public Desktop), and the Target PC, to which the Development PC "deploys and sets as Startup" the RTEXE.  This assumes that the Development PC has network access to both Host and Target (but this could also be done "manually" using a USB Stick, for example).  Additionally, the "Reset Target" utility that I previously described is placed on the Host to allow it to switch the code running on the Target.  My routine runs "manually", but it could also be written as a callable VI that each Host routine calls to ensure that the proper Target code is running.

I'm not sure why you feel the need, at Run Time, to have the Host deploy the Target's code.  It seems to me that this just results in having to manage three copies for the Target -- the original RTEXE built by (and on) the Developer PC, the copy loaded onto the Host in order to serve as the source to be subsequently FTPed (at run time) to the Target, and the copy that is actually living on and executing on the Target.  Seems unnecessary (and slow -- my Students get impatient enough when the PXI reboots itself at the end of the Experiment, but if they had to wait for several FTPs and reboots at the beginning of an Experiment, they would really bug me to fix it ...).

But I'm pretty sure that your scheme will work, so if it fills a requirement that you have (network topology, lack of direct access to Target machines, whatever), go for it.

Bob Schor