Quote:
Originally Posted by btslaser
I took the code from last year's shooter encoder and it called the start() method once and reset() each cycle. It seemed to work fine in Java but I will give it a try with start() after each reset(). For this current issue I had removed all the reset() calls to make it as simple as possible.
|
If you have some time to experiment, let us know what you find.
Here is a summary of our experience with the problem:
If you look in my autonomous scripting presentation (you can find it under my whitepapers here on cheifdelphi) you can find our 2011 robot code. In the Disabled vi, any time we switched to a new autonomous script we called the EncoderReset vi and then the EncoderStart vi (it's in selectAutonMode.vi inside of Disabled.vi). This was done in order to reset the encoders back to 0 after the drive team was finished moving the robot around to set up the robot at the beginning of the match. EncoderReset->EncoderStart worked great in 2009 through 2011.
With the 2012 cRIO firmware, that exact strategy would usually lock the encoder decoding causing exactly what you are seeing. I say usually because it didn't always happen. The only remedy would be to power cycle the cRIO (i.e. the decoding wouldn't work if you simply reset the code).
The fact that it didn't always happen caused us a lot of issues. We assumed we had a problem in the digital sidecar or an encoder wire was shorted somewhere. We spent the last 3 days before ship date trying to track down the issue. I accidentally stumbled onto the fact that the EncoderReset->EncoderStart sequence was causing the issue (very thankful for the accident). We figured this out literally 15 minutes before it had to be in the bag the night before our first district event. This whole fiasco caused us to have no autonomous testing before our first event, and it severely limited the testing on our shooter since our speed control and turret control all relied on encoders.
We put in a simple workaround to reset encoder values back to zero (that didn't use EncoderReset or EncoderStart) and I never had time to experiment to figure out the exact cause and a good solution. I'm suspecting that the issue is somewhere in the 2012 FPGA firmware.
I brought the issue up to the NI representative at our first event. I don't think it ever got resolved.