REV Encoder no feedback/signal LabVIEW

Hello! Our FRC team (3484) has recently encountered some troubles incorporating encoder functionality into our LabVIEW project for the 2021 season.

We are currently unable to read any of the pulse feedback from the encoder (REV Through Bore Encoder). When we try to move our device, the encoder output does not change.

We have made a handful of attempts towards troubleshooting our issue:

  • We have tried changing the DIO of the encoder on the RoboRIO
  • We have tried changing the RoboRIO entirely
  • We have even tried using a different encoder (another REV Through Bore Encoder)
  • We have also tried using both quadrature and absolute methodologies for reading the pulses

We now wonder if this issue potentially lies within our LabVIEW code…

Here is what the current state of our LabVIEW code looks like:

Does anyone see an issue with our code, or has anyone encountered a similar issue?

Thank you very much,
Team 3848

So there doesn’t appear to be enough information to help much. Some questions and thoughts…

  1. What are you getting when you read the values?
  2. I assume you aren’t using both DI and encoder at the same time (although the DI are different so there really wouldn’t be a conflict.)
  3. When reading the values you are writing them to front panel indicators. Can you write the values to network table variables so you can see the values while the robot is executing?
  4. Did you try the encoder without the Config Timer VI? The minimum rate value seems fairly large…
  5. What are your units for the distance/count value? They could be inches for a 3 inch radius wheel, but the count value appears odd. I don’t believe you have to multiply the value by 4 like is done for the Talon motor controllers
  6. The ref names must match EXACTLY, including training spaces, capitals, etc…
  7. Are you getting any error from either the routines in BEGIN or the routines in TELEOP?
  8. Are the encoders wired correctly !!!
  9. There is a very nice sample LabVIEW encoder program. They can be found here.

Something like this appears. You may have to find the FRC section.

Then scroll to the Encoder example.

This is the front panel of the example.

  1. We are seeing 0 (zero) on the encoder when we move our mechanism, or the separate encoder. Sometimes we get a small number, but it doesn’t change when moving either encoder.

  2. I’m not sure what you mean by using both DI and encoder at the same time, but what we have shown above in the picture was done for the sake of posting our problem here. Only one of the two approaches (absolute or quadrature) are active at a time.

  3. I can have the students try putting them to network tables and deploying to the robot instead of running from robot main and see if there is a difference. The students have been running the program from robot main and not deploying the project to persistent memory, so they are able to look at the front panel to see the outputs.

  4. Yes. The students declared it without it initially. After some research on google, they found some examples where it was used, so they put it in to see if it made a difference. The minimum rate was set to 10 initially, and was increased to see if it made a difference (it didn’t).

  5. The count was set to 4x initially. Again, we were changing things to see if they made a difference. The distance/count calculation is also incorrect for our mechanism, but I had them copy the configuration 1:1 as they found it online to ensure it wasn’t just something they had done wrong in the code. Are the REV through bore 1x encoders, I assumed they were 4x for quadrature input.

  6. We can double check the refnum names on Monday, I’m pretty sure the students have the names exactly the same.

  7. Would these errors show up in the driver station, or are you referring to build errors here?

  8. That was the first thing we checked. We have extensions on the wires for the encoder mounted on the robot, but this behavior is the same when we test our spare REV through bore encoder (both purchased in February) wired directly to the RoboRIO without the extensions.

  9. We tried the example earlier this week (both the absolute/duty cycle encoder and the quadrature example) with no success.

Hopefully this gives you more information to go off of.

P.S. I’m the software mentor for 3484.

Thanks. The extra information helps a lot.

Based on 9, it seems to me that you might have a wiring or electrical issue, not a programming one. I realize that was already checked. I believe that encoder comes with a couple of different cables. Make certain you have the correct cable. Make certain the connectors are plugged with the correct polarity. I don’t think this should be an issue, but it could be that some other sensor that isn’t properly wired could be causing this one to fail. If possible try disconnecting all other sensors and outputs (or use a spare roboRIO) – with some way to remember where to connect things back up – and try the example with the encoder without the extension wiring.

To answer your other questions. 2 - I thought you might have tried using a DI and Encoder with the same I/O channel number… 6. We have had refnum naming issues in the past. I usually ask them to copy the string constant that has the name in it just to be certain… 7. I’m not certain, they might show up in the drivers station log. If you are running interactively, you can put an error indicator on the front panel and see it that way.

Hope this helps.

1 Like