Showing results for 
Search instead for 
Did you mean: 

Graceful deploy to cRIO

Is there a more graceful way to deploy a built executable to cRIO? Is that what the new Undeploy feature of LabVIEW 2021 is all about?


I keep getting this dialog on deployment.




Attempts to programmatically end the execution of the Real-Time Startup Application prior to new deployment do not seem to work.

The next issue is that clicking OK on that dialog always leads to this next one.



Which leads to...


...making me have to do the Deploy again. That brings up this one which is somewhat similar to the first, but this time there is an Apply button.


At that point, I see some Deployment progress with a bunch of files scrolling by. Often, I also see the Waiting dialog like this.


After that, the deployment succeeds we reboot the cRIO to run the new Startup Application.


I have been living with the behavior for some time. Is there a better way?


0 Kudos
Message 1 of 8

I haven't looked at deployment in LabVIEW 2021, but from what I remember for LabVIEW 7, LabVIEW 12, and LabVIEW 19, building and deploying a Real-Time app (on both PharLap and Linux RT) has the same four commands (not always clearly spelled out:

  • Build -- creates the Executable.
  • Set (or UnSet) as Startup -- sets a flag on the Target to name the Executable to be run when the Target boots up.
  • Deploy -- copies the Executable to the Target.
  • Run as Startup -- not 100% certain about this, but see below ...

Here's how we are currently doing this (with LabVIEW 2019:

  1. When we create a Build Spec, we never name the Executable "startup.rtexe".  Instead, we give it the name of the Top Level VI, e.g. "Battery Monitor.rtexe".
  2. We might have several routines we want to run on the Target -- we create a Build Spec for each, and give each a unique name (just not "startup").
  3. We then Build.
  4. If we want this Build to be the Startup, we then "Set as Startup".  Note that this puts a (subtle) Box around the chosen Build Spec indicating it is Set as Startup.
  5. We then Deploy.  This downloads the Executable from the Host to the Target.
  6. We then (typically) do Run as Startup.  This causes the Target to reboot, and when it comes back up, it is running the just-Deployed Executable.
  7. If we later decide to have the Target boot, but not run any special code, we click on the Build Spec that has been marked as Startup and choose "Unset as Startup" (and re-Deploy, for "good luck").

We may be indulging in a little bit of "Magical Thinking" here, using the sequence Build, Set as Startup, Deploy, Run as Startup.  But it works!  [I think I used some other order last week, and nothing happened on reboot, but I didn't experiment further because once you have a system that works and seems semi-logical, why mess with it?].


A decade (and PharLap) ago, I wrote a little utility that let me decide, from the Host PC, which deployed Executable I wanted to have the Target run.  I've toyed with trying to do with with Linux RT, but for now, while developing, we're content to do this "manually, when necessary ...".  Note that if you are dealing with a single RT Executable, and you've set it as the Startup, when you need to rebuild, you only need to Build, Deploy, and Run as Startup (or, alternatively, you can run the Utility that reboots the Target, but since you are already in the Build Spec, it's much quicker to use the "Reboot" action of Run as Startup ...


Bob Schor 

0 Kudos
Message 2 of 8

... and we have Lift-off!  


Here's what I did.  I built a LabVIEW RT Top-Level VI, chose "Set as Startup", "Deploy", and "Run as Startup".  It rebooted, and promptly "did nothing".  Oops!  So I ran it "manually", opening the Top-Level VI, and clicking the Run Arrow.  I watched it Deploy, and (again) nothing.  The first thing it does is start the FPGA, so I looked at the Error Line coming out of that VI and saw Error -61017, which is an "inconsistent" error associated with Open FPGA VI Reference.  Configuring this Function gives you two options -- point to the FPGA VI, or point to the FPGA  Bitfile.  I usually choose to point to the VI (it looks "cleaner" to me), and this usually works (except when it doesn't).  The fix, of course, is to point to the Bitfile, and after a PC reboot or two, you can change it back.  I don't know why this function (mis-)behaves this way, but maybe it is a LabVIEW 2019 "feature".


So I changed Open FPGA VI Reference to point to the Bitfile, did a "Build", "Unset as Startup", "Set as Startup", "Deploy", and "Run as Startup".  [I actually didn't need to do the latter -- within a minute of doing the Deploy, the FPGA code was running].


I now start the Host Top-Level VI.  In its Initialization routine, it does (as you do) a Find Systems call.  Unlike you, I do not precede it with an Initialize Session function, and I use all of the default settings (that is, I don't wire any of the inputs) to Find Systems.  I do one more thing with the Detected Systems returned by the Find Systems command:  If there are 0 Systems returned, I pass on a Blank string; if 1 System is returned, I pass on its String, and if >1 Systems are returned, I populate a Combo Box and let the User choose which System to use.  Note that I'm using the default Find Systems output of Hostname and IP -- some of my Targets have both a Wired and WiFi IP, so I need to choose the right one.


Fortunately for this Story, with the Target supposedly running (because it rebooted and was set to Run as Startup), it should have been "listening" for the Host to try to make a Network Stream connection with it.  I ran the Host, it waited about 5-10 seconds, popped up a Dialog Box asking me to choose which Target to use, "found" the Target, established Network Streams, and we were off and running.


Bob Schor

0 Kudos
Message 3 of 8

Thanks for the reply. I like your approach to having multiple possible executables on the RT system and selecting which one to launch using Set as Startup.


However, that is not the issue I am describing. My issue happens on Deploy. It is being caused mostly from the fact that there is already an executable running. In the past the applications I have deployed have been tolerant of being terminated when a new version is being deployed. These recent ones are less so. It might have something to do with the EtherCAT stuff that we have or something like that.


I understand the need for a dialog to confirm that we want to terminate the execution of a running application prior to deployment. I do not understand why it doesn't succeed in "Updating settings" the first time and then drops the connection.


One other method that has worked.... until it didn't... was to do the Build and then manually copy the *.rtexe file to the RT system. After that a reboot will now launch the new executable. That did work for a while, but then all of the sudden I started getting file permission errors when trying to copy the executable to the system. I tried WebDAV and the web interface (that only works in Internet Explorer). Examining the folder permissions in an SSH session did not help. So... it needed a reformat and back to the old double-deploy and lots of dialogs.

0 Kudos
Message 4 of 8

Your second response appears to be for a different topic.

0 Kudos
Message 5 of 8

@Photon_Dan wrote:

My issue happens on Deploy. It is being caused mostly from the fact that there is already an executable running. In the past the applications I have deployed have been tolerant of being terminated when a new version is being deployed. These recent ones are less so. It might have something to do with the EtherCAT stuff that we have or something like that.


I don't recall your stating what version of LabVIEW (year and 32 or 64-bit) you are using.  My test this morning was with LabVIEW 2019 SP1, 32-bit.


Open your Project.  Go to the Build Specification.  Do you have a Build Specification that has a slightly-larger box around it (indicating it has been "Set as Startup"?  [If you have only one Build Specification, go with that one].  Select it, "Unset as Startup", and then Deploy.  Now if you restart your cRIO, it should just sit there, not running any Startup code.


Bob Schor

0 Kudos
Message 6 of 8

I appreciate the attempts to answer so far. It is looking more like a bug in LabVIEW.


The issue I am having on LabVIEW 2020 SP1 is that the Deploy will complete with errors (failed to deploy target settings). That includes the Deploy that is required in order to "Unset as Startup". I can work it through the same way as before by repeating the Deploy, but then instead of one reboot I get to wait through two. I'm trying to figure out if there is a way to deploy a new build knowing that a reboot is required, but without going through the whole bunch of waiting and dialogs and repeating the Deploy command twice.

0 Kudos
Message 7 of 8



     I may have (slightly) misled you.  I've "been away" from LabVIEW RT for about 8 years until recently -- I was formerly using PharLap on a PXI, now I'm using Linux RT on a myRIO.  I believe (but haven't tested it yet!) that Set as Startup and Unset as Startup make "tiny" changes in the Target (like setting or clearing the name of the Startup RTexe), while Deploy actually moves the Build from the PC side over to the RT side, which is why it takes longer.


     Run as Startup, if memory serves, does two things -- a Set as Startup, followed by a Reboot of the Target (so that it actually runs what was Deployed under that name).  Since you can have several RTexe routines on the Target, if they are all Deployed, you only have to open the Build Specs, choose the one you want to run, and click "Run as Startup" on it to get the Target to reboot and run it.


     Since I haven't rigorously "proven" to myself that this is, in fact, the way things (still?) work, and am working with colleagues who've never done LabVIEW RT before, I adopted the simpler rules you refer to where you may do one-too-many Deploy or RT Reboots than necessary.  In particular, you should not need to do a Deploy to do an Unset as Startup -- just find (in your Build Specs) which Build Spec has the box drawn around its icon (saying it is Set as Startup), and UnSet it.  Once the box disappears, when the Target reboots (for whatever reason), it should not automatically run anything.


Bob Schor     

0 Kudos
Message 8 of 8