I haven’t seen this error… If all of the jaguars work with BDC-COMM, then it’s probably safe to assume that the jaguars and cables are right. The problem is likely the CRIO or something with the software.
Are you running the latest version of WPIlib? (aka is the Eclipse or Netbeans plugin up to date?)
Is the CRIO imaged to version 27? (as opposed to version 25)
Is the Console pin on the CRIO on? It should be off.
See if that helps, I’ll see if I can find anything else that might be helpful. Good luck.
Yes we updated the cRIO to the release that just happened this week.
yes the console out pin is set to off
So we have tried everything I can think of, has anyone else had this problem with the latest Java updates? I would really love to get this working so we don’t have to run our own velocity controllers on the cRIO, I would rather only do the tuning once and not have to redo it once we get CAN working.
Sorry, I haven’t had a chance look at all today, but two more ideas. Do you have a second CRIO or a nearby team willing to let you borrow a spare CRIO? We had networking issues with one CRIO last year, but everything worked fine on another.
Along the same lines can you flash it with a non-CAN image and and print to the serial port and read that in? Does it give you what you print or gibberish? If it gives you gibberish, then it’s probably an issue with the CRIO’s serial port.
I’m afraid that -1 is not really referring to the DMA error that you referenced since the error you reference is “kRioStatusOffset - 1” where kRioStatusOffset != 0. It is probably an error code that was never created. Are you using the 2CAN or the Black Jag Bridge?
We are using the Black Jag Bridge. And I’m relived that it is the wrong error code because I was really unsure of how to fix that problem.
Here is the full error
[cRIO] Default IterativeRobot.disabledContinuous() method… Overload me!
[cRIO] edu.wpi.first.wpilibj.util.UncleanStatusException: Fatal status code detected: -1
[cRIO] at edu.wpi.first.wpilibj.can.CANExceptionFactory.checkStatus(CANExceptionFactory.java:46)
[cRIO] at edu.wpi.first.wpilibj.can.JaguarCANDriver.sendMessage(JaguarCANDriver.java:29)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.sendMessage(CANJaguar.java:567)
[cRIO] at edu.wpi.first.wpilibj.CANJaguar.updateSyncGroup(CANJaguar.java:1342)
[cRIO] at edu.wpi.first.wpilibj.RobotDrive.setLeftRightMotorOutputs(RobotDrive.java:527)
[cRIO] at edu.wpi.first.wpilibj.RobotDrive.arcadeDrive(RobotDrive.java:372)
[cRIO] at edu.wpi.first.wpilibj.RobotDrive.arcadeDrive(RobotDrive.java:382)
[cRIO] at Breakaway.Main.teleopPeriodic(Main.java:117)
[cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetition(IterativeRobot.java:141)
[cRIO] at edu.wpi.first.wpilibj.RobotBase.startApp(RobotBase.java:154)
[cRIO] in virtual method #10 of javax.microedition.midlet.MIDlet(bci=17)
[cRIO] at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(64)
[cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(110)
[cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25)
[cRIO] at com.sun.squawk.Isolate.run(1506)
[cRIO] at java.lang.Thread.run(231)
[cRIO] in virtual method #47 of com.sun.squawk.VMThread(bci=42)
[cRIO] in static method #3 of com.sun.squawk.VM(bci=6)
[cRIO] WARNING: Robots don’t quit!
[cRIO] —> The startCompetition() method (or methods called by it) should have handled the exception above.
I hope this is something simple that we have just missed.