Deploying Code...

[Landonh12]

Originally Posted by pastelpony

With an i7, it still takes us about 2-3 minutes to build/deploy code with LabVIEW.

You do know that you don't have to build the code every time you want to run it, right?

You can simply go to Robot Main.vi and run it from there. It takes us about 15 seconds to deploy the first time, and around 3 seconds after that until we reboot.

You only need to build/deploy/run as startup when you are done with your code.

[pastelpony]

Originally Posted by Landonh12

You do know that you don't have to build the code every time you want to run it, right?

You can simply go to Robot Main.vi and run it from there. It takes us about 15 seconds to deploy the first time, and around 3 seconds after that until we reboot.

You only need to build/deploy/run as startup when you are done with your code.

I've known about the run from robot main.vi but I never really used it. I've just got used to the whole build/run as startup protocol. I'll actually try to start running through there. Thanks.

[TogetherSword8]

Another LabVIEW trick, code in dashboard variables for any variables you have in your code (works out really well for autonomous). This allows you to easily test your autonomous code and modify any values without having to stop and change in your code. Once you hit the right combination, screenshot your dashboard, and go back to your code and replace the dashboard variable receive function with the variable it is supposed to be. This is useful in competition, we were able to fully debug an autonomous in one practice field time in this method, and we ran it 5 times in a row during this same session to make sure it would run consistently on the field.

The running from robot main method works great when you are in your shop, i just get a little wary about possibly forgetting to rebuild and redeploy the code before we go out onto the field.

[pastelpony]

Originally Posted by TogetherSword8

Another LabVIEW trick, code in dashboard variables for any variables you have in your code (works out really well for autonomous). This allows you to easily test your autonomous code and modify any values without having to stop and change in your code. Once you hit the right combination, screenshot your dashboard, and go back to your code and replace the dashboard variable receive function with the variable it is supposed to be. This is useful in competition, we were able to fully debug an autonomous in one practice field time in this method, and we ran it 5 times in a row during this same session to make sure it would run consistently on the field.

The running from robot main method works great when you are in your shop, i just get a little wary about possibly forgetting to rebuild and redeploy the code before we go out onto the field.

I've been doing that for a while and had that set up this season, though from it's usage, I found that using time controls with autonomous has proven to be unreliable and will in the future try to use encoders + PID.

[cjl2625]

I need one of these.
Too often I have mechanicals yelling at me, "What's the hold up?" when they're waiting for the robot to do something.
Darn mechanicals.

[Alan Anderson]

If you're using LabVIEW and trying to "Deploy" code, you're doing it wrong. There are legitimate reasons to use "Deploy", but I can't think of any that would be of use to an FRC team.

It takes only about ten seconds to send a LabVIEW program to the robot using "Run as Startup". Doing the "Build" beforehand can be several minutes, but it doesn't interfere with anyone running the robot. You don't even need to have the robot connected, or even present, to "Build" the code.

When you're doing interactive development/debug sessions by "Run"ning the Robot Main vi, sending all the code to the robot does take about the same amount of time as compiling it with "Build", but only once at the beginning of the process. Thereafter, it is only a few seconds to send only the changed code and run it again.