URGENT: Code not working for various reasons

[carrud]

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

[wireties]

Originally Posted by carrud

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.

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.

HTH

[wireties]

Originally Posted by carrud

This being a "single-mode OS" seems to be the underlying force behind this happening. At least in some cases.

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.

http://wpilib.screenstepslive.com/s/...-robot-program

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.

HTH

[steinra]

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.

Hope this may help.

Randy