The encounter counts up and down correctly. We have power wired to +, ground wired to -, one signal on DIO 3 wired to A, and one signal on DIO 13 wired to B.
However, there appear to be ‘dead spots’ on the encoder. If we rotate the encoder slowly, we find locations where it starts counting up just as if it were unplugged.
What might be causing this behavior? We have 6 of them, and they all seem to act the same way. We have removed all the wiring and plugged them into the digital sidecar with short pigtails, so I’m fairly sure there isn’t any wiring problem. Unfortunately the counting is in the FPGA, so I can’t really see the code to debug what is causing it to count up.
I’m not sure I understand this statement. An unplugged quadrature encoder should provide no output to the FPGA, and the FPGA should not count when an encoder is unplugged.
Can you scope the signals when it’s working and when it’s not?
I’m sorry Joe, I was incorrect. It stops counting when unplugged. In the areas I’m calling ‘dead spots’, it will sit and count upwards as if the encoder is being turned, when it is not. It counts at a constant rate.
Thank you Joe. Your comment that they should not be counting up took us back to our own code (no real surprise…).
It turns out the encoder “start” was put at the start of teleop, and that was causing the upwards counting we were seeing as it restarted every loop. That does however raise another question in my mind: why would the start command cause it to count up?
I have no real insight into the FPGA code, so this is just a guess based on the reported behavior. It could be completely wrong.
When you Start an encoder, it presets some internal registers. The FPGA is doing quick sampling of the encoder signals, going through something like a state machine to do the up/down counting. If one of the channels is high while the other is low, the first sample will end up making the FPGA think it just counted up one tick. If you Start on a regular basis, it will end up counting that fast.
The answer is, of course, not to do that.
(The true solution might be to search for, find, and fix a possible bug in the FPGA code. Or it might be for someone at NI to slap me for presuming to have anything useful to say on the subject.)