inconsistent wireless code downloading

[nickmagus]

Has anyone else encountered the error that when you download code the code does not change. I usually have to download code 4-5 times before the code actually changes on the cRIO. Does anyone know whats up with that?

[Greg McKaskle]

Which environment were you using, and can you describe your test so that we can try to replicate?

Greg McKaskle

[Alan Anderson]

Originally Posted by nickmagus

Has anyone else encountered the error that when you download code the code does not change. I usually have to download code 4-5 times before the code actually changes on the cRIO. Does anyone know whats up with that?

If you download to the cRIO's flash, you have to reboot it in order for the fresh copy of the code to be run. If you download to RAM, it should run immediately.

(If you are experimenting with both LabVIEW and C++ programs, you might accidentally end up with two different programs running simultaneously, with obvious confusion. Don't do that.)

[willson.thomas]

Originally Posted by Alan Anderson

(If you are experimenting with both LabVIEW and C++ programs, you might accidentally end up with two different programs running simultaneously, with obvious confusion. Don't do that.)

I thought you had to change the development environment using the cRIO imaging tool before loading a program from the other development environment. Wouldn't this some how prevent the above from happening? If not, shouldn't it?

[Greg McKaskle]

Originally Posted by willson.thomas

I thought you had to change the development environment using the cRIO imaging tool before loading a program from the other development environment. Wouldn't this some how prevent the above from happening? If not, shouldn't it?

Changing the development environment is really only necessary to get the debugging systems fully functional. It is possible to run LV on a C system, C on a LV system, and yes, both at once. After all the LV system is just a C program that is making calls into generated LV code, so the OS doesn't know the difference.

The debugging differences have to do with how exceptions are caught, or something like that. I have never looked at the details. I normally run the tool.

Greg McKaskle

[nickmagus]

So I did some testing and here is what I found. I'm using windriver and C++. If I use the debug method of running code on the robot through the RAM everything works fine however if I download the code and reboot the robot the two modes (teleop and autonomous) dont change until the robot is not in their mode. I did a really simple test (switching joysticks in teleop) and found that if i reboot the robot in teleoperated mode the joysticks wern't switched but i switched to autonomous and back it worked. the same thing happened with autonomous. any ideas whats up?

[Alan Anderson]

Originally Posted by nickmagus

...if I download the code and reboot the robot the two modes (teleop and autonomous) dont change until the robot is not in their mode.

I'm sorry, but I have no idea what this means. Can you give a less general description?

I did a really simple test (switching joysticks in teleop) and found that if i reboot the robot in teleoperated mode the joysticks wern't switched but i switched to autonomous and back it worked. the same thing happened with autonomous. any ideas whats up?

The term "switch" apparently means more than one thing here, and I can't tell what is intended. Let me rephrase my question. Can you give a more step-by-step description of what you did, what you expected to happen, and what happened instead?

[nickmagus]

sry i forgot to post that i figured out what was happening. thanks though.