Digital Side Car Issue with Encoder

We are having an issue with a USDigital S4 encoder… when the A channel is plugged into the DSC DIO port 1 and the B channel plugged into port 2 it properly provides an output using getRaw() when the DS is disabled. As soon as the DS is enabled, the output count oscillates between the last disabled value and last disabled value + 1. If we plug the same encoder into ports 9/10, 11/12, or 13/14 it works fine both disabled and enabled.

I checked the wiring twice for both continuity between ends and the proper pin order. The voltage at the +/gnd pins is 5v for all ports when the DS is both disabled and enabled.

Any ideas what might be going on?

Is this happening all the time, or is this a one off occurrence?

If it’s one-off, I kind of suspect the encoder was sitting on a rising/falling edge.

IF you have an oscilloscope, I would suggest probing the A and B channels to make sure you’re getting a clean signal. Probe it from the DSC connectors, that way you simultaneously check your pinout and wiring (you can never be too sure). My thought right now (but it doesn’t exactly fit with the problem description) is that one of the channels is continuously low or high instead of oscillating like it should, so the count only oscillates.

I’ve tried it 3 times plugged into ports 1/2 and each it’s same behavior… fine in disabled, crippled when enabled. I’ve tried it once in port 9/10, 11/12. and 13/14 and these all worked fine. I have two identical encoders and both exhibit the same behavior when plugged into the same wiring.

We don’t have an oscilloscope. I checked the voltage using a multimeter on the A and B channels and both where 2.5v when the encoder was spinning.

When the encoder is plugged into 1/2, can you read increasing/decreasing counts (more than +/- 1 in any direction)?

What else do you have plugged into the digital sidecar? What additional things are you doing in the code when you’re enabled?

Actually, you’re not shorting the SIG and GND pins on 1 or 2, are you?

My guess is a chassis isolation fault is affecting one of the encoder channels. Something down stream of an actuator controller (Jaguar, Victor, Talon, Spike, Solenoid Breakout, etc) is asserting a voltage on the chassis (hopefully the battery return voltage).

The value “chatter” tells us two things: The software is fine, since things are moving, and one pin is stuck in one position (high or low).

The compressor switch is plugged into port 5, that’s it. Nothing different in code happens between disabled and enabled.

initialize in chassis constructor:
m_encoder = new Encoder(aChannel, bChannel, true, CounterBase.EncodingType.k4X);

each period output to SmartDashboard:

I unplugged everything (4 talon + compressor relay PWMs) from the DSC except the encoder and removed the circuit breakers for everything except the cRio and DSC. Same problem.

I then tried different combinations of pins for channels A/B and found that pins 2, 3, 4 work when the DS is disabled but not when enabled. If I have one good pin and one bad, I get the “chatter” as you described, two bad pins = nothing, two good pins it works fine disabled and enabled.

Neat! Sounds like an interesting break inside the DSC then: Haven’t seen this one before. You are listed as being in texas - If you are headed to an Austin kickoff I’d love to take a look at it.

Are you doing any encoder resets? (In LabVIEW, there is a Reset Encoder vi that resets the encoder counts to 0 and stops the encoder, you then need to do an Encoder Start. I’m assuming there are equivalent methods of doing this in C++ and Java.)

I found a bug with the Encoder Reset / Encoder Start / Encoder Stop functionality in the 2012 firmware. The bug caused it to act exactly as you’re describing. We lost days trying to track that down.

We are going to the Dallas kickoff. Once we get a replacement I could mail it to you if you PM me your address.

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 inside of 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.

It looks like other posters have a more likely explanation. If switching the DSC for a different one cures the problem, I’d like to see it. If it doesn’t, I’ll gladly point the finger at software and walk away whistling.

With the encoder plugged into “good” DIO ports I tried calling reset() during each periodic cycle and it worked fine. I then added a call to start() after the reset() and that worked fine as well. I tried each case 5-6 times. We used the reset() call last year on our shooter encoder and never had a problem. It may be a LabView thing or just that I haven’t run into the unlucky set of circumstances.

It’s definitely the DSC. I tried the compressor switch in DIO ports 2, 3, and 4 and it curiously it did not work. Works fine in all the other ports.

This last report mimics a DSC problem we had last year. About half the board went bad. It was mounted vertically in our robot. If we lifted up on the wiring it would work, when gravity took over it wouldn’t. I visually inspected the board and could find no obvious damage, i.e. broken traces, or cracked circuit board. I would bet that maybe a through hole didn’t fully plate or part of the board had too low a flow temp for the solder.