There are a max number of counter channels of different types, is it possible you you exceeded them?
Monitor the crio console as it boots. Any error or diagnostic messages?
Try a new digital module?
Good luck!
From your description of the diagnostic LEDs, this is an electrical problem in either the DSC or your encoder: Your 5V rail is getting shorted out. You can eliminate any theories related to software, the PD, or the cRIO.
I’m betting you have an intermittent short in your encoder wiring. This would explain why it magically fixes itself.
Perhaps accumulated static electricity? It’s a ridiculous hypothesis, but it’s all I can think of.
The 9403 can withstand ±30V, and since the encoders are just a digital signal, I can’t see how this would cause a problem.
The only suggestion that I have is to prepare a secondary system with Jaguars on CAN (the black ones, not the tan ones) for the explicit purpose of encoder input (and if so desired, to use them to control your shooter as well) in the event that this problem recurs.
Maybe try replacing the encoders? (Didn’t see it suggested here, sorry if it was). It could be something inside the encoder shorting that may have broken from a hard hit. Try borrowing one or just plugging an extra one in using the same wiring to your current encoders and see what happens?
See the OP.
Does the issue persist when the encoders are plugged in but not mounted to the robot?
Good question – we don’t know. We did test to see if the encoders (and everything else) were electrically isolated from the frame, and they are. If the problem pops up again as I suspect it will, that’s something new we can check.
It looks very much like, as you said, a short in either the encoder wiring or the DSC – which is why it’s frustrating that we replaced both encoders, their wiring, and the digital sidecar and yet still had the same problem.
We’ll try another set of brand new encoders with brand new wiring when we get to Buckeye and can take the bot out of the bag.
Meantime, does anyone have any suggestions on alternate sensors we could easily adapt to get rpm values?
Thanks for the help everyone!
Honestly, I don’t recall where you were using the encoders, but I guess it really doesn’t matter.
Banner makes several sensors that could be adapted. As an example, you could use a Retro sensor and a small piece of the retro tape to create a counter.
Then just use a little math to calculate your RPM.
Are they fast enough? We were thinking of using the optical sensors (included in the kit last year, and FIRST choice this year) to count either spokes or white/dark coloration, but we don’t know if they have a sufficient response time to do the job.
From the specs page.
Output Response Time Opposed:750 microseconds ON; 375 microseconds OFF
All others:600 microseconds ON/OFF
Delay at Power-up 100 milliseconds; outputs do not conduct during this time.
It looks like they are able to count, at minimum, up to approx. 888 Hz. Therefore they should be able to track a wheel turning at up to 53.2K RPM. Surely you are not tracking anything that fast! 
1712 uses the QS18 retroreflective sensor for our RPM and a piece of retro tape included in the kit. It has worked great for us after nothing but problems with the USDigital encoders.
Great to know, guys, thanks! I’ll discuss this with my teams on Tuesday.
Patrick,
I will bet dollars to doughnuts that your have some wayward metallic debris in the DSC. I helped a team with a similar situation locate one single metal flake that had fallen down between pins on the DSC. You need a very bright light. You might have to remove the DSC from the robot, remove the cover and check inside but I am betting that is what you will find. It is likely it is right next to the pins for your encoders.
Even the brand new, still-in-the-antistatic-bag one we replaced the first one with? Metal shavings was one of our first investigatory culprits; we found none.
Patrick,
Did you tell us the model number of the encoders you are using? I did a quick check but didn’t see a number in your earlier posts.
We had a very similar problem in Portland. We burned through three DCS’s, and no one could figure out the problem. All of a sudden in a match, our robot would quit driving. We checked all of our connections, changed the PDB, swapped DCS’s, and checked for metal shavings, yet nothing helped. The only thing that fixed the problem temporarily was a new DCS.
Sorry, I was out sick yesterday – feel much better after having spent 20 of the past 24 hours asleep!
We are using these: http://www.andymark.com/product-p/am-0791.htm
Pat,
These encoders are virtually indestructible but there are a few peculiarities. The first is the encoder base is molded so that the encoder PCB only fits in one way. The other way causes the PCB to be bent due to the through hole electronics not fitting into the recess in the base. When you mount it, and hog down on the screws, it is possible to bend over the through hole leads or damage the PCB itself. Since the PCB does not have conformal coating it is of course easy to get shavings inside. The LEDs internal to the encoder are visible and can easily be seen when the encoder is correctly powered and the cover is off. It is also easy to bend over one or more of the pins in the white connector.
Cierra,
Is it possible you wired the DSC to the 24 volt power on the PD and not from a simple 12 volt output on the PD?
I’m 99% certain none of that is the case here, but will double-check all of the above when we unbag at Buckeye. Thanks!
Pat,
I should have also mentioned that while extremely hard to do, it is possible to plug the white connector in backwards. I think you only hope is to recheck everything at this point, including the encoder wheel position relative to the board.