Encoder Glitchy Issue, Help Needed

[seg9585]

Hi all, we are using LabView to run 2 encoders (currently) for our drive system, and we are having issues with glitchy incrementing values returned from the digital inputs or the code (the encoder distance counters increment when the encoder is stationary). Info below:

Configuration:
DIO 1 -- Ground, Power, Signal A for Encoder 1
DIO 2 -- Signal B for Encoder 1
DIO 3 -- Ground, Power, Signal A for Encoder 2
DIO 4 -- Signal B for Encoder 2

Observation:
When one single encoder is plugged into the above digital inputs (DIO1+DIO2 in use, with DIO3+DIO4 unplugged), the encoder works nominally. This is indicated by a healthy distance and direction indicator on our Dashboard and accurate readings when driving the robot.

HPlugging in either single encoder works correctly, however when we plug in the second encoder to our Digital Inputs, both encoders start outputting glitchy data.
Each encoder distance indicator quickly increments as if the robot is moving forward, and the direction indicator blinks erratically. We noticed that only one encoder will glitch at a time -- when the robot is stationary, Encoder 1 will quickly increment distance, and a few seconds later Encoder 2 will issue the same symptom.

I have attached the applicable code -- Begin.vi initates and resets the encoder. Teleop.vi does a GET then processes the output.

Has anyone run into this problem? I don't want to automatically suspect there's a problem with our Digital Sidecar, but we can't find an issue in code that would cause this problem since simply unplugging one of the encoders allows the other to run perfectly with the same code.

Note: Changing the "decoding type" does not resolve the issue.

Thanks for any help!

[Alan Anderson]

I imagine that could happen if connecting two encoders is causing issues with the 5 volt supply. Is the Digital Sidecar correctly powered, with the BAT, 6V, and 5V LEDs all lit brightly? What is the Robot Signal Light doing while you are having these issues?

[seg9585]

Will check tonight. Meanwhile --

If the LEDs are not brightly lit, does this indicate a problem with the digital sidecar? The sidecar is wired properly and outputs PWMs (and a single encoder) fine.

If the LED's are brightly lit, what do you recommend as follow-on troubleshooting steps?

Thanks.

[seg9585]

Update on this issue:
When both encoders are plugged in, the sidecar LEDs remain brightly lit, so the sidecar must be healthy. When I plug the second encoder into unused digital IO ports, the correctly mapped encoder works fine. So, electrical interference on the DS is not the issue. When I map the second encoder to the new IO ports in code (previously unused) the problem with the incrementing encoder count returns.

What else can I try???? Any more tips?

[seg9585]

FYI, Issue resolved by moving the encoder processing code from Teleop.vi to Routine Task VI, where it should have been all along. I suppose lag associated with receiving DS packets knocked the timing off the encoder's calculations.

Why a single encoder always seemed to work okay, that will remain a mystery (maybe the amount of code processed pushed the Teleop VI beyond the Watchdog timer limit?)

[Ether]

Originally Posted by seg9585

FYI, Issue resolved by moving the encoder processing code from Teleop.vi to Routine Task VI, where it should have been all along. I suppose lag associated with receiving DS packets knocked the timing off the encoder's calculations.

Did you try reading the encoder count in TeleOP, and computing

(change in encoder count)/(elapsed time since previous encoder count was read) ?

That should be reasonably insensitive to variations in the timing of receipt of DS packets, no?