cRIO Image? Need help soon!!

[nighterfighter]

Hi-

Ever since we have updated to v20 of the cRIO, our Jaguars have been hating us.

We are using CAN, but the Jaguars are intermittently cutting out, at a seemingly random order. We are using the exact same code, and sometimes it works, sometimes it doesn't.

We have tried changing out cRIOs, and created multiple workspaces (C++) and to our frustration, nothing seems to work.

Edit:

All of our Jags are blinking a very fast yellow, something that is not listed in the Jaguar PDF chart...

[Robototes2412]

try replacing the cables

[jhersh]

Originally Posted by nighterfighter

Hi-

Ever since we have updated to v20 of the cRIO, our Jaguars have been hating us.

We are using CAN, but the Jaguars are intermittently cutting out, at a seemingly random order. We are using the exact same code, and sometimes it works, sometimes it doesn't.

We have tried changing out cRIOs, and created multiple workspaces (C++) and to our frustration, nothing seems to work.

Edit:

All of our Jags are blinking a very fast yellow, something that is not listed in the Jaguar PDF chart...

Do you get this behavior with v19? What version of the Jag firmware are you using? Are you using the 2CAN or the BlackJag bridge?

[Radical Pi]

We had this exact same problem. The root of it is there is something with your robot that is causing WPILib errors at an extremely high rate, which slows down the code enough to cause the jags to miss their internal watchdog and freeze up (as far as I could tell). Our exact problem was our camera mount was constantly pressing the camera reset button, causing the cRIO's camera init to fail and fail again until the system just gave up.

Also, if any jags are messed up (reset IDs, no breakers, broken cable, etc) and you are sending commands to them, if enough are down then I've found the intermittent trouble and sluggish controls (another symptom btw) shows up too.

To the folks at WPI if you are reading this: Please cut down on your errors. At the very least, put a timer on them to limit the rate of errors being thrown. They seriously are a problem for anything that can cause an error on every single Teleop loop. In the time between cRIO finishing boot and camera finishing boot, we can still sometimes have this problem (NetConsole definitely shows the overflow of errors).

[AmoryG]

Originally Posted by Radical Pi

To the folks at WPI if you are reading this: Please cut down on your errors. At the very least, put a timer on them to limit the rate of errors being thrown. They seriously are a problem for anything that can cause an error on every single Teleop loop. In the time between cRIO finishing boot and camera finishing boot, we can still sometimes have this problem (NetConsole definitely shows the overflow of errors).

Yep. Part of the code I wrote had to be commented out because number of errors that were popping up was causing serious lag (NetConsole was displaying errors faster than the eye can see).

[MattD]

Originally Posted by Radical Pi

Our exact problem was our camera mount was constantly pressing the camera reset button, causing the cRIO's camera init to fail and fail again until the system just gave up.

To the folks at WPI if you are reading this: Please cut down on your errors. At the very least, put a timer on them to limit the rate of errors being thrown. They seriously are a problem for anything that can cause an error on every single Teleop loop. In the time between cRIO finishing boot and camera finishing boot, we can still sometimes have this problem (NetConsole definitely shows the overflow of errors).

I'm not really sure what "errors" you're talking about.

How is it WPI's fault if your camera mount causes it to continually reset? Isn't that your mistake?

What kind of errors are you seeing in every teleop loop? If it's something wrong with the WPI library, they're probably going to be able to fix it faster if you can provide some more details.

[Radical Pi]

It's not the errors themselves that I'm complaining about, the problem is how wpilib handles those errors. There is nothing limiting the rate of errors being printed to stdout, so repeating errors slow everything down