Deploying code in debug vs run as startup

[MaxMax161]

Our team has used LabVIEW for many years and there are some things that I'm sure labview is capable of but we're not doing that would make life better.

For instance whenever we build the project and run as startup it takes only a few seconds to deploy but loading debug code to the robot takes roughly ten minutes (when running robot main). Why is there such a difference between these two methods of deploying the same code? Is there anyway to make deploying faster?

I also noticed that when we run robot main to deploy the code in debug mode every vi.lib is deploying as well. Why do all these need to deploy as well if they're not changing? Is it so I can debug them the same way I debug the code we wrote? Can I choose to not debug them and make the code deploy faster?

When we build the code before running as start up how much compiler optimization is actually happening? Will any of these optimizations (if there are any) ever produce a noticeable difference in how the code runs?

When we deploy code in debug mode we always run robot main and deploy everything. If I just wanted to deploy a few .vis could I just run them? What kind of problems might I encounter? I know there is an easy way to test this but I haven't had an opportunity since I had the question.

I know there's a lot of questions here and anyone shedding some light on even some of them would be wonderful.

[Rusttree]

For instance whenever we build the project and run as startup it takes only a few seconds to deploy but loading debug code to the robot takes roughly ten minutes (when running robot main). Why is there such a difference between these two methods of deploying the same code? Is there anyway to make deploying faster?

The extra functionality associated with debugging adds a LOT of overhead to the system. By the way, I learned something useful this passed weekend related to debug mode. Labview updates indicators on all front panels that are open. So if you're deep into development and you've got a ton of VIs open (even if they're minimized), the debugger will be wasting a lot of extra time updating indicators on front panels that you don't even care about.

I also noticed that when we run robot main to deploy the code in debug mode every vi.lib is deploying as well. Why do all these need to deploy as well if they're not changing? Is it so I can debug them the same way I debug the code we wrote? Can I choose to not debug them and make the code deploy faster?

The first time you run in debug mode, all of the code is loaded into volatile RAM (which takes several minutes). If you click on "Finish" in Robot Main and then click "Run" again, it should detect which VIs are already loaded and not re-deploy them. When that happens, it deploys in a matter of seconds. Is that not working correctly for you? Keep in mind, if the cRIO is rebooted or loses power, everything in volatile RAM is lost.

When we build the code before running as start up how much compiler optimization is actually happening? Will any of these optimizations (if there are any) ever produce a noticeable difference in how the code runs?

A good optimizer should not change the effect of your code one iota. It should only make changes that speed up execution without changing any functionality at all. If the optimizer DOES change something, that's a bug.

When we deploy code in debug mode we always run robot main and deploy everything. If I just wanted to deploy a few .vis could I just run them? What kind of problems might I encounter? I know there is an easy way to test this but I haven't had an opportunity since I had the question.

In typical Labview development, yes, you could run just the VI you're in. But the FRC Labview code has a lot of interdependencies between VIs and I doubt very many VIs could run completely on their own without causing lots of confusion and errors. It's probably depends on which VI you're talking about.

[MaxMax161]

First of all thank you all for your responses to my myriad questions. Although I have a few follow up questions.

Originally Posted by Rusttree

A good optimizer should not change the effect of your code one iota. It should only make changes that speed up execution without changing any functionality at all.

I wasn't worried about the compiler changing the function of the code as much as how much faster does it make it run. Say I were trying to run a PID loop at 400 hz (needless and impractical yes but for sake of example) could the difference in execution time between the compiled version and the debug deployment version ever be noticeable?

In typical Labview development, yes, you could run just the VI you're in. But the FRC Labview code has a lot of interdependencies between VIs and I doubt very many VIs could run completely on their own without causing lots of confusion and errors. It's probably depends on which VI you're talking about.

Assuming there's already a fully functional robot project on the robot would all the interdependent VIs already be there? For example could I run a VI with changed constants without issue? (yes, this is easy for me to test and I should, but I'm not near a robot atm)

Originally Posted by Doug Norman

The reason there is such a difference is actually a bug in LabVIEW RT. Here is a work around. When your robot is in "Run as startup" mode (like right after a match) try this:
...

This seemed to make things faster, thanks! Although in our last work session we only needed to load code once and didn't even close to strictly follow your instructions so I really have terrible data so my "seemed to make things faster" isn't worth anything.

Originally Posted by Greg McKaskle

A slightly faster way of working around the bug is to leave the VIs open, then connect, say OK in the dialog, close the VIs, open RobotMain, and then run it.

The method you describe seems to be very similar to the method Doug described in the post above. Could you explain the differences some more?

[Greg McKaskle]

Doug and I work together. We came up with these at roughly the same time. The only difference is whether you have the code open when you begin. I found it to be a bit faster to have it open, connect, then close it. The most important aspect is to connect so that the startup will be aborted then reload the Robot Main code before pressing run.

Greg McKaskle

[Doug Norman]

Originally Posted by MaxMax161

For instance whenever we build the project and run as startup it takes only a few seconds to deploy but loading debug code to the robot takes roughly ten minutes (when running robot main). Why is there such a difference between these two methods of deploying the same code? Is there anyway to make deploying faster?

The reason there is such a difference is actually a bug in LabVIEW RT. Here is a work around. When your robot is in "Run as startup" mode (like right after a match) try this:
1. Close Robot Main.vi (but not the project).
2. In the project, right-click on RT CompactRIO Target and choose Connect.
3. Click OK at the Conflict Resolution dialog.
4. Once connected, reopen and run Robot Main.vi.

[Greg McKaskle]

A slightly faster way of working around the bug is to leave the VIs open, then connect, say OK in the dialog, close the VIs, open RobotMain, and then run it.

This is equivalent to unsetting the startup app before doing a debug session. This is more permanent though, and you will want to be sure to make a startup app before you go to a competition.

Greg McKaskle