Updated CAN Jaguar Issue

Hey y’all! Question… (correct me if this should go in the Java section)

During the offseason, our team got an old swerve chassis up and running with five black jags hooked up to the cRio via the serial interface. We programmed the whole setup using Java. After kickoff, we moved the controller board to a new prototype chassis–all CAN and encoder wiring stayed exactly the same. We then updated:

  1. cRio -> image v25, with black jag serial plugin selected
  2. Driver station
  3. Black jags -> firmware version 92
  4. Netbeans plugins

Now, all our code (which is also exactly the same) fails at jag initialization with an UncleanStatusException. In the past, this problem had to do with a low battery, but we hooked up a fully charged one and the problem still persists. We also tested the jags with BDC-COMM v92, and they work perfectly. Is there anything else that needs to be updated/changed to get these working?

Please excuse my unhelpful and indeed useless post in advance, and PLEASE do not follow this advice. Thank you.

Wash the jaguars so they are clean again.:eek:

We tried that, but it resulted in a WetStatusException; we let them dry, but apparently they got dirty again…

Time to go home, Don.

Unclean can be caused by multiple issues. When we first dabbled in it we cam across three. Cant recall the numbers but one was that the jag plugin wasn’t loaded. One was because one of the students loaded the serial plugin and the 2can plugin. The last error was because there was a short on the can bus (particularly the serial plug terminating resistor)

So to summerize …

Check your can network
Check to make sure you have added the plugin to the cRio
Check that it is loading
Make sure you don’t have both plugins loaded

Does your code retry when getting the exception, or just give up without retrying? Last year we noticed that we’d occasionally get the UncleanStatusException at initialization of the first Jag, and as best we could tell seemed to do with sensitivities with all the inter-task communications - i.e. the WPI library calls FRC_NetworkCommunication, which in turn calls the plugin main task, which calls send/receive tasks… - I’d have to check with the team to see exactly where the diagnosis led.

In any case, we solved it by wrapping the constructors in a try block, and putting that in a loop so that we kept retrying the initialization until successful. The first Jag would occasionally have to be tried a couple of times before success.

  • Ron
    Team #2607 controls mentor

Please let me know what the actual status code is. I’m also in the process of cleaning up the exception handling in the Java implementation. I know it is not good at the moment.


The status code is -52007.

That’s a timeout. It may be that you are trying to talk to a device number that you haven’t assigned on the bus or have a problem with the bus termination or there is a bug in the CANJaguar class. Have you tried it in LabVIEW or C++?



Did you try the setup after transferring the parts and before updating the firmware/software? When it comes to designing complicated systems only change one (or as few as possible) thing(s) at a time before testing again. This may seem like it takes longer, but it’s worth it. It’s like writing all of your code for the year without testing it at the end. Test the components along the way and you’re likely to end up with a fully functioning design.

Now aside from that, I’ve got nothing helpful :). Sorry.

  • Bryce

I assumed that the CAN wiring (and all the IDs) were fine because a test with BDC-COMM yielded good results, i.e. everything worked. I have not tried it in any other languages, when I get over to the school I’ll hack together some C++ code. As a side note, is there a list of status codes and what they mean anywhere?

To Bryscus, we performed limited testing (running one Jag in position control mode) after the move but before the firmware/software updates, and it worked fine.

Thanks for all the help so far!

Whoops, missed your post. Our code gives up without retrying–that’s a good idea. I’ll test that when I get there today.

Also, thanks for the hints, drakesword.

Check out the \src\com
i\rio\NiRioStatus.java in the WPILibJ source. It has most of the errors that you’re likely to run across in v25.

The next version of the cRIO image will have more custom error codes so it should be more clear what they are when you see the errors in the DS errors window.


[quote=“Alexander Meyer,post:12,topic:107953”]

Whoops, missed your post. Our code gives up without retrying–that’s a good idea. I’ll test that when I get there today.

Also, thanks for the hints, drakesword.[/quote]

At the risk of stating the obvious :smiley: - of course give the loop a max number of retries…that way if there is something else going on and it never succeeds, you’ll be able to see that rather than just continuing to try indefinitely…

  • Ron
    Team #2607 controls mentor

We would also advise that you run PWM cables to your jags so if the CANBUS goes down you can still control your motors. Just have a reduced functionality mode.

That is disallowed by the rules. Rule R58-A

The Jaguar must receive signals via either a PWM cable -OR- a CAN-bus connection. Both may not be used simultaneously.


Alright, I tried looping the Jag initialization in Java until the exception went away…we let it go for about a minute then figured it wasn’t going to fix anything. We reflashed the cRio for C++, wrote some test code, loaded it, and voila! Working robot. We figured all our problems were solved, shut off the robot, and continued where we left off. BUT…

…next time we powered up, we got the same exception. Drat. We checked the code, redeployed, and still nothing. We rebooted via the driver station a couple more times…and the third or fourth time, it worked. Weird. It continued functioning well for about an hour through numerous code changes/redeploys/reboots, then crapped out on us again. We hard rebooted via the breaker, then rebooted twice via the driver station, and we had control again.

So…we’re still scratching our heads. Any ideas?

And all of this was while using C++?

Can you try power-cycling the Jags in the case where it fails? I’d like to identify if the jags that stop responding or what.



We tried that multiple times, and it never worked. The only time it worked is when we soft-rebooted the cRio a couple times after a power cycle.

Please double check your termination and wiring.