Time to build cRIO LabVIEW code

[Terry Sherman]

How long is it taking other teams to 'build' their code through LabVIEW? We are very concerned about the amount of time it takes. When we make a subtle change to the code (maybe change an offset or tweak a threshold, etc) and we need to rebuild the code and deploy it to the cRIO, it takes ~15 minutes to do. This seems intolerable at the competitions. Each time we do a 'build' it seems to recompile all code (instead of doing a make).

Are other teams experiencing this? How long is it?

The problem is when we get to the competition and we want to make a small tweak between matches, instead of taking a minute to compile and download our code, it takes 15+.

Thoughts on what we might be doing wrong?

[EHaskins]

In Windriver it takes < 5 seconds to do a full rebuild, and 5 to 45 seconds to deploy.

I wouldn't expect more than a 50% difference between Labview and Windriver.

In any case that is way out of line. I suggest contacting NI if you can't solve this issue.

[Uberbots]

You definitely arent the only team with this "issue"
apparently the only valid solution offered is "get a faster computer", but thats obviously not a great answer.

our labview stuff takes about 5 minutes to buildload from our programmers laptop, which is a relatively new machine. 15 minutes sounds a bit excessive.


apparently also if you mass compile the wpi robotics lib folder your compile times will drop. im not sure how significantly, though.

[Kevin Sevcik]

Anti-virus packages also seem to have a significant effect on build times. It seems to be a fairly disk-intensive process, so having Norton inspect every file will obviously slow things down.

[Greg McKaskle]

I don't know where the other posts are, but this has come up a number of times. There is a setting in the LV project which should help your build time. The problem is that for some projects it will slow them down and others speed up. On the whole, I've discovered that I'm not very happy with the app building. As mentioned, it copies and saves all files and doesn't do a good job of reusing intermediate files. It has quite of bit of overhead and I haven't been able to find the usual low hanging fruit or hot spot.

The setting to toggle is in the build spec properties. Make sure to right click all the way to the bottom on your FRC build spec. Open Properties. Click to the Additional Exclusions tab. The options to disconnect poly-vis and typedefs seem to have little effect on build time, and are for tweaking the size of the EXE versus taking along the full lib for plug-in support. Similarly, there is a setting to take along only the library elements you use or the full library.

The default for FRC is to take the entire library. This seems to be the fastest option until you start including certain VIs, especially those from the DSP libraries, then the build often balloons to around 20 minutes. At that point it is far better to flip the checkbox and take only the VIs you are using. When not using analysis, this seems to be slower than the original setting. There may also be a combinatorial effect between the lib setting and the polyVI setting. Do not check the subBox under the lib to modify the library.

Greg McKaskle

[Dave Scheck]

I would also like to voice my concerns.

There were two occasions at MWR where we were helping a team with autonomous code in LabView before a match. In one instance, we started helping them about 20 minutes before match time. The changes were in place and ready to go, but the lengthy build and deploy times were such that we were unable to get them on the field for the match. In the second case, we had a similar situation, but we got them to the field only because the match before us was foghorned which bought us a little more time.

I find this to be completely unacceptable. How can we reliably be helping people in the pits if it runs the risk of them not being able to compete in a match?

What happens in the case where a team wants to tweak something in elims during a timeout? The timeout is much shorter than the build time so don't bother.

Issues like these make me glad that we decided to stay with what would benefit our students the most, C++. They also make it less likely that I will be helping teams with LabView any time near a match.

As a fun fact, the NI rep at MWR made a comment to me that the FPGA code takes 24 hours to build...let's hope that they recognize that as an issue rather than industry standard.....

[Greg McKaskle]

Your complaints about the build time are completely valid. As I mentioned, it shouldn't be 20 minutes. If you find a team with that problem, the checkbox will fix it. It will still be longer than I'd like, but until I can rub someone's nose in it, it will take a few minutes.

As for the FPGA comment ... not so valid. The LV compilation portion of that is small. The vast majority is spent with the Xilinx compiler doing its thing. The diagram gets compiled directly to VHDL and the Xilinx compiler does the heavy lifting. I'm pretty sure that the compile time will shrink shortly after they can prove P=NP -- wiki it if that doesn't make sense. Basically it means that the layout problems are some of the most difficult and expensive problems around.

Greg McKaskle

[gwytheyrn]

For our team, on a Dell D620 core 2 duo machine, it takes roughly a 1-2 minutes, most of which is spent initializing or saying something like async agent vi (the last thing it says). On a 800mhz eeepc (1000hd, bestbuy model), it probably takes bout 5 minutes to build. Download time is probably about 1/2-1 1/2 minutes, depending.
I know HBR (1747) had some HUGE issues with build time at the beginning of buckeye and setting the build to only include needed libraries made their process much, much faster. (Or maybe not...I think that's what they did).
What would be really nice is if deploying from the front panel would work as build/download at its current speed. But that's wishing a little too much, eh?

[Greg McKaskle]

What would be really nice is if deploying from the front panel would work as build/download at its current speed.

I agree. That is pretty much the way RT used to work. It is now more capable and strips files down a bit more, but the time is much longer than I expect.

Again, don't accept 15 or 20 minutes as typical. Change the checkbox for libraries.

Greg McKaskle

[Ken Patton]

Originally Posted by Greg McKaskle

I agree. That is pretty much the way RT used to work. It is now more capable and strips files down a bit more, but the time is much longer than I expect.

Again, don't accept 15 or 20 minutes as typical. Change the checkbox for libraries.

Greg McKaskle

For those of you using Labview, listen to Greg. His advice on this is solid. Without the checkbox checked, we have a 20 minute build time. With it checked, we have a 2-3 minute build time. Still pretty long, but much better.

The other thing to remember is that you can do the build without being connected to the robot. Only the final step - right-clicking on your build and selecting Run as Startup - needs to be done while connected to the robot. And that takes only ~1 minute.

Having said all that, it does need to be improved, there is no doubt. Like Dave said, it makes it difficult to help someone who is in a bind, and it makes you not want to help them because you are afraid that they will have no code when the match starts.

Ken

[Karthik]

Originally Posted by Greg McKaskle

I'm pretty sure that the compile time will shrink shortly after they can prove P=NP

I'll get right on that...