Programming Error

Help, We are getting the following error when attempting to run our code (which was made in Labview).

We have update it with version 3

It says on our DS 2009-10a3





You likely need to reimage your cRIO with the image installed with Labview Update 3. As I recall the image should be v11.zip

You also should upgrade your DS firmware to the latest version which can be found (along with instructions for updating) here

We have 2009-10a3 on our DS.
Our first program works just fine - just using the joysticks to move the wheels.

When we try to RUN the new version we get this error. We did not want to put the new program on as run at startup because we want to test it for errors.

The cRIO and the DS have independent firmware. I apologize for suggesting you update your DS, I did not examine the number you posted closely enough.

The latest version of the cRIO firmware is FRC_2009_v11.zip. You can update your cRIO by running the FRC cRIO Imaging Tool. This tool should detect the cRIO automatically and show it in the small window at the top of the tool. If it does do the following to update your cRIO firmware:

  1. Select Labview as the “Development Environment”. I recommend checking the box to always run deployed code at startup. This will not affect the code that you Run with the white arrow, only code that is deployed.
  2. Click the “Format Controller” checkbox.
  3. Select FRC_2009_v11.zip as the image.
  4. In the Device name box enter “FRC-cRIO-1254” without the quotes
  5. Enter your team number in the “Team ID” box.
  6. Click Apply. This will start the firmware update, the process will take 5 or more minutes to complete. When it completes it will say that it is successfully updated and you may then click “Close”.
  7. Turn your robot off, wait ~15 sec., then turn it back on to load the new firmware into the cRIO.

After the cRIO is updated try opening Labview and running your code again. Post back on whether the error is resolved or not.

You’re not accidentally trying to run the code on your PC rather than on the cRIO, are you? Make sure the VI is under the correct target in your project.

Okay, so now we are having more trouble.

We reimaged the cRIO and that had no effect. The behavior was the same as before.

Then we loaded a different VI it deployed, but then nothing worked.
When we power cycle the robot the previous program does not come up.
Isn’t there supposed to be a default code?

By deploying a VI is it possible to overwrite the non-volitile memory?

Help, we leave for TC tomorrow AM.

UPDATE: 11:02 am

We got it back so it runs the code we had in there that just uses 2 joystick to
run the wheels in tank mode.

We cannot get it to accept the new program which does that as well as runs
our chain and dumper.

HELP? Please.

We are able we think to deploy another program -
it gives many pages of output and the last line it gives us is:

deploy send images to PC.vi

Did it finish?

The orange light and the jaguars are still flashing and we cannot run the joysticks.

Not enough information to tell.
What is PC.vi for instance? Are you streaming camera video back to your PC?
What is the many pages of output?
How do the pages of output differ from downloading your first program that just has the joysticks?

What are the buttons and menu choices you are making to download your program?
Are you using “run as startup” from the Project Explorer Build Specifications?

If you post a zip of your project that fails to download we might be able to help.

See error file:
We get this and then it goes through and it loads 100’s of vi’s.
We press okay and then it appears to have deployed but then the robot is not responsive.

This is just joystick tank drive only, but we get the same error when we run the
program with the dumper.

All we are doing is trying to get a program onto the cRIO.

We have followed the directions step by step

We have reimaged the cRIO also and it did not change the behavior.

error 2-25-09 a.doc (103 KB)


error 2-25-09 a.doc (103 KB)

If you “run as startup” and it does not work can you get back to the one that worked or has it overwritten non-volitile memory?

Here is the step by step process we used and where the error appeared.

Procedure followed to deploy VI.doc (738 KB)


Procedure followed to deploy VI.doc (738 KB)

I see you’re just using the Tank Drive Example project.
Did you create a new project after the last Update 3a was installed?

P.S. I note that in the second procedure you’re using the Basic Framework.

The pop-up window with the warning messages is normal and can be ignored. Every LabVIEW program will download 100’s of vi’s, so that’s normal too.

“run as startup” means this is the program that will run when the robot is turned on. So it would replace the default project.

Just pushing the “Run” or “Run Continuous” arrows on the top-level vi will only be temporary and won’t be around after the robot gets reset or power cycled. I assume this is what you want to do, so that’s okay.

So using “Run” you get “No Code” displayed on the Driver Station?
Do you let it sit for a few minutes after you see “No code”?
You will get “No code” for a brief period after the cRIO resets or is started, but then if you’re restarting the cRIO then you wouldn’t get to see your program running anyway.

Thanks

The “Run” button turns black and stays that way?

Do the controls on your Robot Main.vi Front Panel respond?

I’ll be back in a few minutes. I have to get a root canal done…:frowning:

Thanks

If the Run button doesn’t stay black, then it might have run through a single pass then stopped.
In any case that’s certainly why your joysticks don’t respond. The program isn’t running.

Try pushed the run continous button instead. It should look something like this while it’s running:

ContinuousRunBlack.jpg


ContinuousRunBlack.jpg

You have a While loop that should normally, by default, keep you running when the Run button is pushed.

The default for such a loop is “Stop if True” (looks like the left picture below).
Did you by any chance change it to a “Continue if True” (the middle picture)?

Either type can be used, but you have to be careful to have the correct default value going in. In one case it should default to True, while in the other it should default to False. That’s a common reason for the program to run only once (taking only milliseconds to complete). People sometimes change the loop type, but forget to reverse the default True/False. In the middle case below, the loop will run only once (very fast) because the button feeding it would have to be held down to make it loop.

For instance, the third picture is what the Basic Framework uses and it keeps the loop going because it defaults to True and uses “Continue if True.”

StopIfTrue2.jpg
ContinueIfTrue.jpg
ContinueIfTrue2.jpg


StopIfTrue2.jpg
ContinueIfTrue.jpg
ContinueIfTrue2.jpg

We have no idea why but it seems to be working now. We are deeply mystified by the complexity of this black box.

A special thanks because except for a constant change the code worked the first time out, including the autonomous. When we get back from Traverse City I will email to talk about a switch box on the robot for autonomous.

We did have to replace both the spike relay’s as pop riviting them is not good for them.

Thanks so very much.
We would have never gotten it without you.
I hope your root canal went fine.
What events are you going too?

It’s easiest to take a black box one small piece at a time as you are doing.
Understanding then has a chance to grow.

Practice making the download of your code permanent before you get there tomorrow.

My root canal went quickly. When you need to have root canal it’s a relief to get it. I was in quite a bit of pain this past week. I feel great ever since they gave me novocaine. It’s wearing off, but all the pain is gone. :slight_smile:
One of my teeth got damaged when I unwisely had a wisdom tooth removed, but now they fixed it.

We’ll be at NYC, then SBPLI, and finally Championships.
It’s hard to raise all the money necessary, but well worth it

Good luck at Traverse City!

I’ve seen this, or a very similar, error message when working with one of the former teams I used to mentor. They had removed all of their modules from the cRio and then replaced them in random locations. (They thought the slots were all on a bus and didn’t realize the FPGA was coded for specific modules in specific slots.) Could this be happening here?