Quote:
Originally Posted by Greg McKaskle
If the Communications and Robot Code light are on, that means that the cRIO has a startup app and image that is self consistent, and that the code is running. If the PWMs aren't being updated, that could be due to a number of reasons.
The analog breakout in slow 1 needs to have power and a breakout in order to return something other than 0.0. I don't know of anything a cRIO can do alone to melt a breakout board, but I could see how a faulty breakout, one that had power and ground pins shorted together might build up enough heat to melt, and clearly wouldn't measure anything useful while that was going on.
If you did something to your cRIO so that it is no longer valid for competition, I'm not sure that sharing that approach with other teams is the most helpful thing to share. Swapping cRIOs actually swaps lots of stuff including FPGA images and other libraries. Did you check what error messages were on the Diagnostics screen? Did you verify that the versions of the cRIO image and FPGA image were as expected?
Finally, would you please explain what was done to the cRIO to "fix" it but make it illegal?
Greg McKaskle
|
Thanks for the reply! This is meant to help teams that would use the robot in demonstrations, as we will be using ours, where FIRST rules don't necessarily have to be followed to the letter. The only thing that makes this cRIO ineligible for competition is the fact that Slot 1 is busted (the cRIO took quite a hit in competition in 2010 and so several things were bent, but worked until now). Otherwise, the cRIO works. The point was not to share how we busted the cRIO (we drove up a ramp and the circuitboard flipped over and landed on the cRIO
), but to share how we made it operational so that we would not have to spend several thousand dollars on a new cRIO (we already bought one at the FIRST price, so we would have had to buy one full price). This was not a software issue (I can verify that, the code we were using was a simple tank drive and I ran through it at least 8 times during the debugging process), but a hardware issue. The software was only modified to adjust to the adapted hardware configurations we used. cRIO image and FPGA version were as expected. The only errors on the diagnostics screen had to do with the analog inputs, which was to be expected, seeing as both the cRIO slot that they were attached to and the analog breakout chip were busted. After examining the cRIO, we think the issue is in the board in the cRIO, which is probably cracked or corroded due to the bangs it has taken over the years. I would imagine this is a rare issue based on the difficulty I had finding documentation on a lot of the problems we had. I hoped to offer some documentation through this thread.