Bingo! Something happened during that match. A hard hit or bounce, etc.
I have seen this behavior, now that Eric mentioned the “phantom power”, I remember this during our build season.
The three LEDS might be lit, but weakly. Check the power (+12v) coming in. Maybe a bad breaker or bad connector on the PDC. Move to a new slot on the PDC and new breaker on the PDC and you may have better luck.
So after we were eliminated and went to the practice field to diagnose, everything worked fine – we plugged 'em back in to start troubleshooting and it simply worked; indeed, we couldn’t recreate the problem. This is troubling because we didn’t actually diagnose and solve the problem, so it’s far too likely that it will reappear at a particularly inconvenient time (say, Buckeye). I’m happy if it doesn’t, but don’t trust that it won’t.
A hypothesis (based on, as far as I can tell, a hunch and nothing more from one of my students talking with another mentor) is that the encoders spin so fast that they are generating too constant a high voltage signal, and that this is tripping some kind of internal breaker in the sidecar or module. I don’t even know how I’d begin to test that hypothesis, or what we could do about it if it were true – seems fishy to me anyway, as many other teams are using kit encoders on their shooters without the same problem.
Thanks so much, everyone, for taking the time to ask and answer. We’re hoping we can narrow it down fast so practice day results in a fast fix!
I’m answering all questions below; please forgive the terse tone – I’m exhausted and going to bed just as soon as I finish replying to this!
Correct.
Also correct.
Yes. We successfully used encoders last year, and they were working through weeks of testing. The wiring was double-triple-quadruple checked for continuity, shorts, and correct pin positions. DSC pins were checked for shorts.
Yes. We use some digital photoelectric sensors on our ball management system, and they’re working fine (as long as the encoders are not plugged in).
Correct – and all Victors start flashing the “no signal” flash.
Module, sorry – the DIO module has no bumper, and I know that.
Yes.
Yes.
We repeatedly verified that they are not reversed.
Only the 5V shuts down. The 6V and 12V LEDs stay bright and solid – and we can still fire relays (the compressor doesn’t run because of the pressure switch not working, but our LED ring on our camera lights up as normal. Swapping the two caused the compressor to run.).
“Run at startup” from the problem-free night before.
Yes.
Done and done and done.
I’m not sure what you mean here.
Yup, we know all that. There are no shorts anywhere that we can find, either on the encoders, the sidecar pins, or the cables.
Done and done; same problem.
Wouldn’t the latter cause a loss of functionality altogether, and not just when the encoders are plugged in? We had full pwm functionality when the encoders weren’t plugged in, and none when they were.
As to the former: that was our bet, too, but we cannot find any evidence of a short on any component.
Perhaps, though not that we recall – either way, it’s odd that the short (if it is indeed a short) seems to be undetectable by mortal (that is, 1551) means.
I saw that last year and looked for it. Our LEDs are not weak, they’re bright and strong as normal. And as I said before, we can fire Spike relays.
Thanks and goodnight!
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?