Deploying Code Shortcut

[scienceguy22]

Isn't it a hassle having to redeploy code every time you make a change, well I can't fix that, but I can make it take less than half a minute. Inside every cRIO module there is a fpt server. fpt stands for file transfer protocol, and you can use this to your advantage. Using the fpt server allows you to directly place your robot's start up code directly into the cRIO device. Before you do this, however, you will need two things, a hard wired connection to port 1 of the cRIO along with the location of your built code, and yes you still have to build your code.

The first thing that you will do is open the command prompt. Type fpt 10.xx.yy.2 (xxyy being your team's number), then press enter, and this will establish a connection to the fpt server. The command prompt will then tell you that you need a username, it is anonymous, after that a password, there isn't one so just press enter. Now you have access to the files inside your cRIO. Then type cd ni-rt and press enter, to open the directory housing your real time code, (if at any time you would like to see the list of files type dir). After that it will give you a line saying you're in directory /ni-rt/. This means you're doing it right. Then type cd startup and press enter. It will again tell you you're in directory /ni-rt/startup/. Now type put and the path to you're built startup code (most often it resembles C:\...\builds\c\ni-rt\startup\startup.rtexe). The command prompt will display a message saying that it has established a connection and is transferring data, start up code already exists at this location but the actions you are performing overwrite that code. If you did it right then it will tell you so, and most often this process takes a couple seconds. When finished type close and the command prompt will "Thank you for using National Instruments". Close out of the command prompt and restart your robot, your start up code will pop up and after a couple of times of doing this you'll have it so that minutes of deploying will turn into about 10 or 15 seconds. :D

[Andrew Lawrence]

Don't you mean ftp?

[Arjun Namineni]

I personally think it would be easier to just undeploy and deploy my code. It literally only takes 30 seconds extra and doesn't require me to memorize the whole command prompt sequence or the file location. :P

However, that was a very interesting post!

[kjohnson]

Don't you mean ftp?

Yeah that should be FTP.

I haven't tried this method, but you should be able to create a batch (.bat) file to run all these commands for you. Just enter each command in order on a new line. Use the PAUSE command to check your progress if something goes wrong.

[Cecil]

or.. you can take the easy way. Download FileZilla and use the simple drag and drop method to move the files..

[2611.Shooter]

or, you could just use windriver. our code deploys in 15-20 seconds over wireless. makes getting access to the robot much easier,, and we have never had a corruption problem so far.

[kjohnson]

or.. you can take the easy way. Download FileZilla and use the simple drag and drop method to move the files..

I like the FireFTP extension for Firefox. Works great from right inside the browser and is already compatible with Firefox 4.

http://fireftp.mozdev.org/

[Robby Unruh]

When deploying code from the classmate, our team had to wait nearly a minute and a half. Once we switched over to our competition laptop, it took nearly half as long. We saw much more of an improvement after switching computers, so I think the problem lies with the hardware the computer relies on.

[scienceguy22]

sorry about the typos, I haven't slept much, and I do mean ftp. In the case of my team this works really well for us, but to each his (or her) own.

[mobilegamer999]

Well, as far as deploying code actually goes, the times to deploy vary based on programming language, and I have worked with all 3, in my experience in order quickest to slowest is

Java - seconds + reboot time
C++ - seconds + reboot time
Lab-View - Minutes + reboot time

With all programming language, they do exactly what your doing, they Compile, connect to the FTP, copy the files, and reboot. And they optimize it as much as possible so making a batch file isn't going to speed it up any more. Also, theres a little more to it than JUST uploading to the FTP, but if there were an effectively faster way of doing it, they would have done it.

[beth_hadley]

Thanks for posting - you were a great team to work with this weekend at the Ann Arbor regional. We will definitely look into using this or a similar protocol for deploying code. Good luck in your future endeavors! GO FIRST!

~Beth

[WizenedEE]

I don't really get it. Building the code takes longer than deploying does, and deploying is much more useful in terms of debugging.

Several other things:

I'd assume (or at least hope) that all teams know how to do this or something equivalent already, or else they wouldn't be able to compete.

There's no reason to hard-wire the C-RIO to do this, unless you want the downloading time of two or three seconds to be improved.

Doesn't the "run as startup" option in labview do the same thing?

Windows Explorer is also an ftp server... just go to the address bar and type in "ftp://10.xx.yy.2"

I never thought about making a batch file though -- that sounds like a great idea.

[mandrews281]

or, you could just use windriver. our code deploys in 15-20 seconds over wireless. makes getting access to the robot much easier,, and we have never had a corruption problem so far.

That's our experience too, and wired is even faster. We can deploy code in the pits in mere seconds after the compile succeeds. Compile and deploy speed is one of the biggest advantages we have seen from the switch from Labview to C++.

[spacepenguine]

I agree with Arjun and 2611.Shoorter. Deploying code from Wind River/C++ seems much faster than deploying from LabView. I haven't worked with LabView personally, but I always joke with the programmer on our sister team when it takes forever for them to deploy code.

[johnmaguire2013]

I don't really get it. Building the code takes longer than deploying does, and deploying is much more useful in terms of debugging.

Several other things:

I'd assume (or at least hope) that all teams know how to do this or something equivalent already, or else they wouldn't be able to compete.

There's no reason to hard-wire the C-RIO to do this, unless you want the downloading time of two or three seconds to be improved.

Doesn't the "run as startup" option in labview do the same thing?

Windows Explorer is also an ftp server... just go to the address bar and type in "ftp://10.xx.yy.2"

I never thought about making a batch file though -- that sounds like a great idea.

> Windows Explorer is also an ftp client... just go to the address bar and type in "ftp://10.xx.yy.2"
FTFY.

Also, Windows Explorer lacks many of the features a client such as FileZilla offer.

[msulaimain]

or.. you can take the easy way. Download FileZilla and use the simple drag and drop method to move the files..

I have been using FileZilla for like forever. It is the way to go. It's basically a organized/program that is very similar to the way that is expressed above.

[wireties]

The download tool in Workbench uses FTP. All it does is automate the process for you. It should be no slower or faster than FileZilla or any other FTP client.

HTH

[Mk.32]

hm
is there another way to do this besides being connected to Port 1 on the Crio, like using the bridge or port 2?

[wireties]

hm
is there another way to do this besides being connected to Port 1 on the Crio, like using the bridge or port 2?

All that is required is for the robot (the FTP server) to have a IP path to the FTP client. The physical path does not matter, only that a logical path exists. It can definitely go through the bridge but am not sure about cRio port #2. The FTP server on the robot might be listening on port 2 (it certainly is capable of it) but I've never tested this configuration.

HTH

[Mk.32]

All that is required is for the robot (the FTP server) to have a IP path to the FTP client. The physical path does not matter, only that a logical path exists. It can definitely go through the bridge but am not sure about cRio port #2. The FTP server on the robot might be listening on port 2 (it certainly is capable of it) but I've never tested this configuration.

HTH

Recently I tried that however was unable to get it to work with the IP, 10.36.47.2 (our team number) however using Port 1 with the same IP works fine. And Suggestions on what ip? or is there some router config we need to do?

[Greg McKaskle]

The second IP port is normally configured to 192.168.0.xxx. It can be changed via Max, but I suspect that the imaging tool will put it back. I'm not sure if an ftp server is active on the port. I suspect it can be configured if needed.

Greg McKaskle

[Zach O]

Our team has actually set up a sweet system for autonomous that concurs the task of not having to deploy code.

Our autonomous code actually parses an text file found on the robot that we transfer using FTP. This makes for a quick and easy way to change autonomous' and helps to avoid touching or changing code on the robot, that might affect our teleop code.

We determined we can change our autonomous code from one to another in 11 seconds.

[wireties]

Recently I tried that however was unable to get it to work with the IP, 10.36.47.2 (our team number) however using Port 1 with the same IP works fine. And Suggestions on what ip? or is there some router config we need to do?

You need to have the ftp client on the same subnet. Port 2 is on subnet 192.200.0.0 I think. Access the console on the robot and type 'ifconfig' or 'ifShow'. That will tell you the IP address of the robot on both port 1 and 2. So if the robot is 192.200.0.1, use 192.200.0.100 or the computer running the ftp client program.

HTH

[Mk.32]

ah that makes since, quick question how do you access the console on the robot?

[wireties]

ah that makes since, quick question how do you access the console on the robot?

Get a copy of the GettingStartedWithC.pdf file from the WPI web site. It explains how to setup a debugging session with the robot. With the debugging session working, right click on the target server (in the remote systems dialog), choose "Target Tools' then 'Target Console'.

Plus I think you can telnet directly to the robot (debugging session or not) if you checked the 'Enable NetConsole' check box from the cRIO Imaging Tool applet. (not 100% sure about this, no robot to check it out on). You can telnet from any Windows command line, just issue the command 'telnet 10.12.96.2' (for our robot).

HTH

[Fletch1373]

Get a copy of the GettingStartedWithC.pdf file from the WPI web site. It explains how to setup a debugging session with the robot. With the debugging session working, right click on the target server (in the remote systems dialog), choose "Target Tools' then 'Target Console'.

Plus I think you can telnet directly to the robot (debugging session or not) if you checked the 'Enable NetConsole' check box from the cRIO Imaging Tool applet. (not 100% sure about this, no robot to check it out on). You can telnet from any Windows command line, just issue the command 'telnet 10.12.96.2' (for our robot).

HTH

Just something to note: Windows 7 has telnet functionality disabled by default. To enable it, go into Control Panel, click the category "Programs", and click "Turn Windows Features on or off". A smaller window should open up with a series of options. Search down the list for "Telnet Client" and check the checkbox to the left of it then click "ok".