Can't read encoder - LabVIEW

Hello everyone,
We are currently experiencing an issue with our encoders. We couldn’t read the encoders’ (Through Bore encoder in incremental mode and Grayhill 63R) value using the encoder get.vi on LabVIEW. We tried everything we thought about: changing the RIO, the DIO ports connected, the cables, the encoders, etc. After trying to read using a code only with the encoder.vi and the encoder example itself, we tried reading it as DIO and it worked. We think it might be the encoder VIs on the WPI Library. Does anyone know how to solve it?

Are you saying the DIO example worked with the encoder connected but not the encoder example? That would be odd. If the DIO example worked, I would expect the encoder one to work, though possibly the reading would just go back and forth between 0 and 0.25.

Are you certain the DIO ports were set BEFORE you clicked run on the encoder example?

Screenshots of the running front panels and block diagrams may help. It is unlikely to be a bug in the WPI Library.

Definitely something funky going on.
I just tried it (Greyhill 61K) on a 2020 install and the provided encoder example works.
On a 2022 install it does not seem to work.
2022 DIO does work although it was very laggy on first starting up.

I suspect the Counter class, but haven’t looked yet.
Nope, the Counter works too.

It’s just the 4x that’s broken (which uses the Encoder.Output from the FPGA).
The 1x and 2x work fine (which use Counter from the FPGA).

Encoder0.Output is not being updated by the FPGA.
Seems to be an image problem.

I’ve reported it to FIRST and NI.

In the meantime just use 2x.

1 Like

Thanks, I just checked this morning the encoders in our oscilloscope to make sure it wasn’t a hardware problem and they worked fine.

I would think there’d be a lot teams noticing this if it was an image problem that affected Java and C++.

Agreed, there is still something odd going on here.
Battery is topped off.
Happens on both a roboRIO 1.0 with a CTRE PDP and on a roboRIO 2.0 using a Rev PDH setup both on 2022 images.
Happens on two different encoder types: Grayhill 61K and Rev Through Bore.

NI has figured out the problem and will have it fixed.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.