So this morning’s been long, at 9 AM I was told to come in to “fix the code” immediately I came across an error where, even after deploying, the driver station said “No Robot Code”.
So I copied last year’s code and edited it to this year’s code. Then whenever I built the code it would just load the old code and our new code couldn’t be built.
Then I made a new project and put the new code in and that gave me the original problem; the last year’s code was built again.
After manually editing the old code directly and uploading that on the robot, it seemed as though the code ran only once and didn’t loop.
I tried to change the properties and the target file of the project but they didn’t help either.
Is there anybody who knows what to check??
Whenever I try to deploy the code on cRIO, the driver station says “no robot code” and I cannot use my latest code.
I suppose an older program is still on the robot.
To make sure my interpretation is correct, the original problem was that the driver station was showing “No Robot Code”. In an attempt to remedy this issue, you took your old code and edited it. When you deployed this “edited” code, the driver station recognized that there was code on the robot, however, it was the old “unedited” code.
Then I am a little confused on what came next. You say that you made a new project with the new code and this resulted in the original problem; deploying the program would give the robot the old code. This is confusing to me because you said the original problem was that the driver station not seeing code. So if you could maybe clarify a little on what exactly happened after each action that would be great. Also, maybe some specifications on what language you are using along with whatever else you have even the slightest suspicion of being the root of the problem. These things will really help us help you solve this problem.
Unfortunately, I do not have an exact answer to this. Here is what I would do if I were in your situation. 1) Ensure I am seeing Robot Communication in the driver station (if not there is another problem) 2) Check to make sure I am deploying everything properly from the correct files. 3) Restart both the computer and the robot. 4) Reformat the cRIO 5) Replace the ribbon cable 6) Post my updated findings on CD
This is the third time you have posted this. It’s really hard for anybody to help you, as this could be caused by a large number of things. Try loading a new default robot project on the robot.
The original issue I am still on is when copying the project, the old code is being built. This in Windriver C++. The only thing I haven’t done on the checklist is reformat the cRIO, because whenever I reformat it, it never reformats. I stay on the same image and it only displays “Rebooting cRIO…” I have to end the process because it will do so forever. Thanks, that may be the underlying problem.
I apologize in advance for suggesting something really lame for the
“Rebooting cRIO…”
problem. We struggled with the same thing (using LabView) and it turned out our laptop switched to a different WiFi hotspot following the re-image, or somewhere along the way.
i.e. we were connected to the cRIO with the imaging tool, started the Format process, stuck on Rebooting cRIO for a very long time. Turned out we were now connected to the School’s WiFi instead of the robot WiFi.
(this sort of thing often happens when robot power is cycled, taking down the D-Link too. I can’t explain why it happened in this case).
If you are stuck there again, check that you can ping the robot:
cmd> ping 10.xx.yy.2
or see if you can get to the dlink
cmd> pint 10.xx.yy.1
Keep in mind this may not be the issue at all. It could be something so simple that it keeps getting overlooked. C++ is the only setup I am not familiar with unfortunately. Hopefully someone with experience on this specific issue will chime in soon. Until then, keep updating CD with new, worthwhile discoveries. When you do figure this out (and you will), be sure to post the solution in case one of us finds ourselves in a similar situation. Wish you the Best!
If I recall correctly, when ever we fully deploy code onto our robot, we have to restart it before the driver station indicates that code is on the robot. We are using labview.
You didn’t say what programming language you’re using. My advice in this post applies only to LabVIEW. If that’s not what you use, ignore it.
When you copy a project’s folder, the build destination doesn’t change. You have to open the FRC Robot Boot-up Deployment properties and change the Information category to have the correct Local destination directory.
You are building the code by right-clicking on the FRC Robot Boot-up Deployment line and choosing Build from the menu, and then installing it on the robot by choosing Run as startup, right?
When you download the code and reboot the cRIO, open up netconsole and look at the output when the cRIO boots up. If there is an error within the code the code will not run, so check the output which will show what the error is. This is what I do whenever it happens to me, and I use C++ as my programming language. It may or may not work for you, but you can try. I’m not sure if netconsole works with the other programming languages.
I’d like to apologize in behalf of Reed. He was a bit flustered due to the issues we were having yesterday.
A clarification for all of you that are kind enough to help. We programmed in C++. Sadly I have next to no knowledge in programming so there isn’t much else I can tell you. All I know is when we use a basic code that we wrote to see if the code was being properly uploaded, everything was good on the Driver Station. We were also able to do the same once adding basic drivetrain code to (coded 6 talons). However our issue came up when we attempted to add pneumatics onto the code. Whenever we tried to activate the compressor there was no signal on sidecar. The solenoids were getting signal though!
Again I would like to sincerely apologize for the minor post spamming, I hope that you guys are able to help.
When deploying code from WindRiver, have you gone into Window->Preferences->FIRST Downloader Preferences and made sure the right file is selected? Simply creating a new project or building a different one doesn’t change this setting. Also make sure that the project was built – just deploying code doesn’t automatically rebuild for you.
The original problem posted by the OP re: no code was figured out (though Reed may not be fully aware as he was offline today). The problem is as discussed here where code errors/issues are not surfaced when compiling or linking or deploying. They are only surfaced in Netconsole after you deploy and then restart crio (when using WindRiver c++, not sure about elsewhere). So, if you are not paying attention to Netconsole you could be led to believe that you have deployed code, but you haven’t. The code seems to get FTPd to crio, but not implemented on crio restart.
This being a “single-mode OS” seems to be the underlying force behind this happening. At least in some cases.
If you run into this kind of problem (where you successfully deploy code, but DriverStation continues to say no robot code) then check Netconsole for hints as to why.
Unfortunately my previous post was not entirely correct. Although that was a problem we encountered it was not actually the first problem related to the symptom first reported by the OP. The initial problem was that clicking “deploy” resulted in nothing happening. The code was not getting sent to crio. This problem still happens. Although we have messed about and can sometimes circumvent the problem we have not yet figured exactly why it happens.
When we click deploy, the deploy window appears very, very briefly. This is clearly different than when we have a successful deployment where the window appears and shows the progress bar during the activity. Netconsole shows nothing during this time (though I don’t know if it is supposed to show anything).
Try turning off the Windoze firewall or create a rule that allows access to a FTP server (which is what really happens when you download code). We have to do this in order to download code.
There is a fundamental misunderstanding in this thread about what “deploying” really means. The transfer is from an FTP client (Windoze) to an FTP server (the robot). The file you are transferring is NOT a fully linked executable. It is code to be dynamically linked and loaded to the VxWorks/FIRST/WPI infrastructure on the robot. So every unknown symbol in the deployed .out file must be satisfied in the text and data segments of the VxWorks/FIRST/WPI/NI code already on the robot (put there when we image the cRIO). This dynamic linking loader is a single pass algorithm, not a dual pass linker like the one we use when combining multiple objects on our development station (where the WindRiver 3.3 is running).
So how does one make sure their code will load and run (2 distinctly different issues)? Most FIRST programmers simply deploy and debug using print/log/smartconsole output. But without using the debugging interface to the robot, you will miss messages about the unresolved symbols and/or tasks getting suspended for various violations (memory access, divide by zero etc). Instead create a target server and load and run your code using the debugging tools and you will see these errors and fix them. FIRST has a tutorial that covers this procedure. NetConsole MIGHT catch them depending on how badly the errors cripple the OS on the robot.
Many of you might think this is a lame setup. But I remind you this exactly how adding code to the Linux kernel (and many other operating systems) works. WindRiver and VxWorks are not unusual in this respect.
I noted in the list of posts here that the cRio may not have been updated to this years image yet? Is that correct?
We had issues with is running by on the format and update image that it had the rebooting crio and did not take any time on the other steps. I know we had struggles with it and had to do the following.
Make sure all network interfaces were disabled, then only use the wired net connection and plug into the bridge/AP. Make sure the firewall is off.
Make sure you can ping the cRio.
open the imaging tool.
See that the cRio is found.
On the 8 slot crio change the switch to safe mode
On the 4 slot do it on the imaging tool.
Make a minor update (change name, change language, add the can) for instance, do not choose format cRio.
Safe mode will prompt to image cRio. Say yes. This should take a little while and not jump right to rebooting crio message.
After it is done turn off the safe mode switch and then in the imaging tool choose to format the cRio with the new image.
Then the code will need to be deployed.
This was the only way we were able to get both cRio’s we have to the current software revision.
If you are still having issues with the C++ code deploy then maybe try jumping over to a labview of java code set and see if that will work for something as simple as reading the joystick value. If you can get that to work, then maybe something is incorrect in the WindRiver setup.