Deploying Code Shortcut

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
i-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. :smiley:

Don’t you mean ftp?

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. :stuck_out_tongue:

However, that was a very interesting post!

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.

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

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.

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/

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.

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.

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.

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

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.

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

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.

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

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.

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

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

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?