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