LabVIEW Woes: Build/Deploy time too long?!

Hello ChiefDelphi forumgoers,

1318 has been programming our robot with LabVIEW. The debugging tools and graphical displays of data are interesting indeed, but one thing is causing my programming team and me considerable frustration: the inordinate amount of time it takes to run code. When we Build our code in preparation for a Deploy All, the Build process takes upwards of ten minutes. Even if we don’t Build the code and we only change one boolean constant in one little vi file and run it on the robot, it re-downloads everything onto the cRIO, wasting five minutes! Argh!

Is there any way we can reduce this wait time? This makes last minute changes during competition impossible, and I do not believe that even a compile of a C++ program takes this long (any Windriver/C++ users have any input?). If this problem simply cannot be solved, I’m just going to become more and more insistent on a move back to C++… because this is ridiculous.

Any insight on this issue would be appreciated.
~LL

I was able to significantly reduce my download time by disabling my firewall. I’m using the CA firewall on a Vista laptop.

We have a relatively significant amount of code including 7 autonomous scenarios and vision. It takes us about 45 seconds to deploy out of RAM in debug mode and about 2 minutes to do a full build and deploy. We also saw a significant improvement turning off our firewall and wireless.

I noticed this too while using Labview. It would take about a minute to ‘compile’ and send off the stock labview program.

Fortunately windriver takes no more than 10 seconds to compile, stop the task on the robot, upload, and run the new task. (on wireless) Much faster than any years before. Sorry, I don’t have any useful advice. :frowning:

Maybe it just takes longer for labview to do all those steps…

We are wired to the DS, and it takes us about 45 seconds to deploy. We did a build - once. A long time ago. We haven’t had any reason to do one again yet.

That is strange…

Building and deploying does take awhile, but that is offset by the RAM deployment not taking long.

At least for us, the running from RAM is like 20 seconds. 30 seconds? something like that. It’s not long at all.

You should be able to make things a lot faster if you make -everything- wired. That’s how it’ll be at competition.

You have your router with the 4 LAN ports on the back. Plug DS ETH1 into one. Plug cRIO port 1 into one. Plug computer into one. Everything on LAN means no interference and no wireless hops (like laptop to router to wireless bridge to robot, or laptop to DS to router to wireless bridge to robot). It’s best to minimize hops and just do laptop to router to robot. Skip the wireless unless you need to.

The building is on the computer. It might take awhile if it’s not a very fast computer. Keep that in mind.

If you’re really worrying about last minute changes on the bot… well. Sorry. Tell the people making the request how big your turn around time is, and/or don’t make mistakes when programming =P

If you use some sort of scripting technique for autonomous, you could have the scripts separate from the main labview code, meaning you don’t have to redeploy each time you want to change something in autonomous. You could also probably do something similer with variable initialization… if the they want some sensitivity variable changed, change the script file, upload that to the cRIO, and have your program read that config file on start up… I’m planning this from memory and have not thoroughly tested it. I’ll test it quickly tomorrow.

For those who don’t know, it’s possible to FTP to the cRIO (this is how deployment works I believe). I tried once, but I was able to FTP an image (for use for our target recognition calibration) to the bot and have the code read it. I just thought of using a text file for configuration. makes a note to try

These are all very good suggestions. I’m afraid that the build/deploy is going to be a bit bigger than we’d like this year due to the library collisions, number of file copies to work around the library issue, and then the size of the download.

I’ll give away one of my debug tricks. But unfortunately, it speeds up the RAM deploy which is already fast. If you open your top VI, Robot Main.vi or whatever it is, then Save As… to duplicate it to a new name such as RAMSpeedup.vi, then deploy this VI to the controller and minimize the window. Since the RamSpeedup and the RobotMain will share most of the subVIs including WPI, small VI mods will no longer kick as much stuff out of memory. Without RAMSpeedup, any change to the hierarchy of Robot Main will kick all of the hierarchy from memory. The RAMSpeedup will keep all but the modified VI in memory. If you make drastic changes to the Robot Main, you may want to redo the Save As to make it more effective.

At this point I don’t know of a way to speed up Build or Deploy steps other than to minimize the number of VIs and maximize the connection speed and computer speed.

Greg McKaskle

The previously mentioned atrocious build times may have merely been because of a slow computer. We timed the build/deploy of our code on a better computer this time. Build took 4 minutes, deploy took 2. And this was with my computer connected to the Linksys router (to which the Gaming Adapter on the robot was connected wirelessly). We will live, I suppose. People who hate LabVIEW like me are in the minority (on my team, at least).