Labview Programming Computer Features Recommendations

[Qbot2640]

Our week one event showed, among other things, that we desperately need a better laptop for programming and deploying code changes.

A couple questions - considering that this laptop will be primarily used for programming, but our programmers are both team leaders, so there may be other lower-priority uses as well.

Do I choose a smallish SSD (128 G or so) or a larger HHD (250 - 300 G)?

Is processor speed all that important. I'm looking at Intel Core I3's (dual core) with around 2.5GHz?

How important is memory for quick builds and deploys? Our "dinosaur" laptops are taking forever to do this. My current list of three all have 8GB of RAM?

Finally are there some magical properties that prevent some computers from connecting? I offered my brand new work laptop...Quad Core I7, with 8GB of RAM...and it wouldn't connect.

Budget is somewhat limited...we're purchasing from the money we saved vs. budget on our week 1 trip.

[Kevin Phan]

There really shouldn't be any magical properties that your computer shouldn't connect to the roboRIO. Make sure that the laptop has LabVIEW 2014 installed with the most recent frc update suite. The issues could be coming from that the roborio doesn't have the most recent image, the usb cable could be having trouble, the ethernet cable could be in bad shape or your work laptop could have restrictions on it if you received it from your employer. If you still want to buy a new laptop I will recommend at least 200 gb of space, an i5 on the laptop and around 6gb of RAM. If it is going to be used for CAD also, you might consider getting a graphics card along with it.

[marccenter]

Qbot2640,

Did you disable your wireless communication and disable the Windows firewall when connecting to the Field Management System (FMS) on the playing field?

If not, you will have connection issues. My corporate issued laptop does not allow the Windows firewall to be disabled, causing me to have to reboot before every match at the Southfield district event and add to field delays (sorry teams).

On Saturday I brought in another laptop with the Windows firewall disabled and had no FMS connection issues.

[MrRoboSteve]

Kevin is right -- 3081 uses 7 year old Dell Latitude laptops as our programming and DS machines and they work fine.

If you're having build perf issues, and have at least 2GB RAM, you should upgrade your disk to an SSD -- http://www.newegg.com/Product/Produc...8484 600038478 lists a bunch of choices in 120GB size. I'd consider the Kingston one at $59 with free shipping.

[Qbot2640]

Originally Posted by marccenter

Qbot2640,

Did you disable your wireless communication and disable the Windows firewall when connecting to the Field Management System (FMS) on the playing field?

If not, you will have connection issues. My corporate issued laptop does not allow the Windows firewall to be disabled, causing me to have to reboot before every match at the Southfield district event and add to field delays (sorry teams).

On Saturday I brought in another laptop with the Windows firewall disabled and had no FMS connection issues.

I am sorry - I was not clear enough. Our Driver Station Laptop is connecting to the field just fine...this was a laptop to push the program, and it wasn't connecting (via USB cable) to the RoboRIO. My questions are all about quick program build speed and quick push to the RoboRIO. We're making multiple small tweaks to the program, and each one has a 5 to 10 minute build, then a long deploy as well. It makes dialing in an auto distance or other small movement really tedious.

[Alan Anderson]

Originally Posted by Qbot2640

My questions are all about quick program build speed and quick push to the RoboRIO. We're making multiple small tweaks to the program, and each one has a 5 to 10 minute build, then a long deploy as well. It makes dialing in an auto distance or other small movement really tedious.

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.

[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.