Labview Programming Computer Features Recommendations

[Kevin Phan]

If you are constantly doing small tweaks I would suggest you look into using the dashboard to tell the robot how much to do its task. The risk with using this is the probability of the value being lost. It is minimal, but the more you pack into the dashboard, the more bandwidth you're using and could lag input. Again if you want to reduce build time, you could use a better cpu, or place all the values you are changing in one vi so that labview doesn't have to rebuild every vi. I used the robot global vi to do this and it's very convenient.

I also agree with Alan about using the robot main vi to make the small changes in testing and then building and deploying after you are satisfied with the results.

[Qbot2640]

Originally Posted by Alan Anderson

I don't intend this to sound condescending, but you're doing it wrong.

If you are making lots of little changes in quick succession in order to test things, you shouldn't be building the code in between each change. You should be executing it "interactively" by runnin the Robot Main VI. The first time you do that it will take about the same amount of time as a Build/Run as Startup, but every subsequent time will be a matter of a few seconds while LabVIEW "deploys" only the changed part of the program and runs it.

Once you are satisfied with all your changes and want to deploy the code so that it persists through a power cycle, only then should you finally Build and Run as Startup.

Not condescending at all....and we'll get there, but right now we have no idea how to do what you are suggesting. Lost the programming mentor, and our programmer last year and we're starting from scratch (less than scratch, acutally - since I'm involved).

Originally Posted by Kevin Phan

If you are constantly doing small tweaks I would suggest you look into using the dashboard to tell the robot how much to do its task. The risk with using this is the probability of the value being lost. It is minimal, but the more you pack into the dashboard, the more bandwidth you're using and could lag input. Again if you want to reduce build time, you could use a better cpu, or place all the values you are changing in one vi so that labview doesn't have to rebuild every vi. I used the robot global vi to do this and it's very convenient.

I also agree with Alan about using the robot main vi to make the small changes in testing and then building and deploying after you are satisfied with the results.

Again...we're forcibly reinventing the wheel with all new people. We'll walk, then run.

Still we do have to do builds, and we do have to deploy...even when we figure out how to do it right. What are the features of a computer that make these two processes occur faster?

EDIT: Your suggestions are sinking in, and I think I may understand. If we are fine tuning autonomous, though...do we still run Robot Main...and if so, how do we start the autonomous? Will the driver station still be active? Please give me more...I'm excited about this now.

[Kevin Phan]

You will still run robot main, but by clicking the white arrow in the top left corner of the front panel of robot main. This now allows you tweak settings on the robot while the code is live. This setup means the robot is connected to your programming laptop and the controls could come from the programming laptop or from the classmate that is connected to the robot. I suggest having the driver station up on the programming laptop and control the robot from there. In the driver station there are multiple modes that it can be in. The ones you want to use for auto is the autonomous mode and practice mode. Now by default the robot should be disabled and when you click on one of the two modes, make sure the robot is setup the way you want it to and have whatever you need to look at up. When you feel comfortable, click enable and the robot will execute its autonomous. If the driver station is in auto mode, it will only run autonomous until it reaches the end of your commands, this means it will not stop at a hard time limit. This means if you have a while loop in the code it will continue running until the while loop reaches its conditions. When the driver station is in practice mode it will keep running auto until it reaches the time limit on the driver station. The time can be edited, but remember to set it to the actual competition's time limit for autonomous. Once it finishes autonomous the robot will immediately go into tele-op. That means your joystick/controller will now start controlling the robot. Be very aware where are your controls or else you might accidentally control the robot when you didn't mean to. It's highly recommended that when you are about to tweak the code, disable the robot. During the entire time you are testing you can edit the values, but I recommend to do it after testing your values first. When you are done with testing, be sure to disable the robot and click the finish button on the front panel on robot main to stop the robot from running the code. When you think the values are correct, save your values and if the values are controls and are always constant, I recommend to make the values default. This can be found on the front panel from the vi where your values are located. Click edit and click "Make Current Values Default". This should keep the values the same when you deploy it to the robot.