I’ve been having trouble with the “run as startup” deployment not being non-volatile; when I shut the robot off and start it up later, it doesn’t start the Labview Real-Time engine. I was originally having trouble with our first cRIO, but I haven’t recently. I’m currently using our second cRIO, which has only been in use for a week.
Also, one of the volatile deployment methods deploys, but doesn’t run either. It’s the method where you right-click on “Robot Main.vi” and select “Deploy” from the menu.
I assume you’re following the procedure given in Using the LabVIEW FRC Framework found at http://www.usfirst.org/frccontrolsystem, “BUILDING AND DEPLOYING A STAND-ALONE APPLICATION” on pages 13-14.
Have you re-imaged the cRIO, telling it you’ll be using LabVIEW?
Yep. The problem isn’t the program not running. The problem is the EEPROM seeming to erase after losing power. (I don’t believe it loses power when the cRIO reboots; I think it only loses power when the cRIO itself loses power)
To debug this, you may want to ftp to the bot and see the files after a deploy, and look again when it doesn’t run.
The LV RT environment uses an ini file to tell it what to do on power up. In that file it will point to the latest LV deployed project, and another entry will indicate if it is still supposed to run at startup. So you may want to diff your ini file in the two states too.
Finally, there is an RT behavior that takes a bit of getting used to. The controller’s ini file will be modified when a different project us run in RAM. So the confusing outcome of this is … you build project A, deploy and set it to run at startup. You reboot the controller and it runs A – Yay! It should work like this every time you reboot. Then you do a bit of development using project A and running interactively. Reboots run the original version of A on Flash – Yay! Now you open a project B and run a VI for testing, calibration, etc. The next reboot will not run A, even though you didn’t explicitly set anything else as the startup.
The rationale for this has to do with which project has ownership of the cRIO.
The latest update added a feature to choose the alternate behavior. If you image the cRIO and tell it to retain the startup app, it will still find your A app on the controller and restore the ini, and boot again. The only downside is that undeploy won’t work anymore, you’ll need to ftp and delete the file.