LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

automating cRIO build, deploy, and restart process

Solved!
Go to solution

I want to automate the process of building, deploying, setting the run at startup flags, and rebooting the cRIO.

 

This is for a continuous integration project. The end goal would be to take new code, deploy it to a test setting and perform simple automated tests.

 

Does anyone know of example code that automates this process, or white papers or other documents that discuss the needed steps.

 

For reference, the project I want to automate this for is in LabVIEW 2009. If this is not possible in 2009, then I would still be interested in solutions in more recent versions.

0 Kudos
Message 1 of 8
(3,113 Views)

For LabVIEW 2009, I would refer to the source code of the LabVIEW Real-Time Application Deployment (RTAD) Utility; I linked you to the 2009-supported version.

 

You'll probably need to add code for the automated testing, but you can leverage VI Server for that.

Message 2 of 8
(3,105 Views)

Hi smoot,

 

This seems an odd suggestion to me. Sure I can create an image of a cRIO and deploy it via RTAD, but how do I take the binary I have created and put it in the image file? RTAD is great if you have an image or a cRIO to update, but that is not my situation.

 

I want to automate something I do repeatedly when I develop. I build code. I deploy code. I set via the right click menu, the deployed code to run at start-up. This is finally followed by a reset.

 

RTAD is all about image management. How do I get the build product in to the image file that RTAD will deploy? How do I generate the ni-rt.ini file that has he startup settings?

0 Kudos
Message 3 of 8
(3,062 Views)
Solution
Accepted by topic author cgibson

I apologize, that was definitely not a helpful an answer as I hoped, but RTAD uses a lot of the RT Utility VIs  that will help you control the target.  As a disclaimer, I don't have 2009, so I'm not sure what VIs you have access to.

 

To automate a build specification, you should be able to leverage VIs in the vi.lib\AppBuilder folder, particularly BuildTargetBuildSpecification.vi (later versions of LabVIEW have these VIs accessible from the palette at Programming»Application Control»Application Builder).

 

Deploying to the real-time target is a bit trickier; if you have it, Deploy.vi in the vi.lib\AppBuilder\AB_API\DSDIST directory will let you deploy your build spec to the specified target.  Otherwise, you can FTP the startup files (/c/ni-rt/startup) to the target.

 

Here is a list of tokens for the ni-rt.ini file.  "RTTarget.LaunchAppAtBoot=true" will configure the startup application (which is all the Run at Startup right-click option does).  I would get a copy of the ni-rt.ini from a target that you can modify during the build and deploy with the application to the target.  You can make other edits to the ni-rt.ini file if you needed to configure target IP settings.

 

Message 4 of 8
(3,059 Views)

This is what I was looking for.

 

Deploy.vi is not part of the AppBuilder API in LV 2009. (There is no DSDIST folder.) So that step has to be handled via FTP.

 

 

0 Kudos
Message 5 of 8
(3,055 Views)

So I have a set of automation steps now.

 

From a batch file I can build the build spec, FTP the generated files to the cRIO, ftp the ni-rt.ini file and then reset the cRIO.

 

It doesn't work. Specifically the program never runs on the cRIO. (My program lights up the 4th LED on the cRIO to let me know it is running. It also communicates with an HMI.)

 

Possibly the "Run as Startup" does more then deploy the ni-rt.ini file and reboot the cRIO?

0 Kudos
Message 6 of 8
(3,034 Views)

I would start by checking the cRIO console out for messages; I believe there should be a print out stating the startup exe is running.

0 Kudos
Message 7 of 8
(3,024 Views)

One of my steps used the LabVIEW FTP functions to move files from the build machine to the cRIO. For some reason, the startup.rtexe file was not being copied correctly. Instead a 0 length file would be in the cRIO.

 

There is an option on the FTP function call to choose either passive or active connection. Active is the default. Changing this to passive apparently fixed the issue and now my automation works.

 

 

0 Kudos
Message 8 of 8
(3,018 Views)