Encoder direction loss?

[ayeckley]

Has anybody seen the same problem that we are currently experiencing? We think we've applied all of the various LabView updates properly (we've passed multiple inspections, at least). What we're seeing is that we get good measurements from our encoders, but all four of them report "forward" rotation even when rotated backward. This doesn't seem like the bug that has already been discussed. Any ideas?

[billbo911]

Originally Posted by ayeckley

What we're seeing is that we get good measurements from our encoders, but all four of them report "forward" rotation even when rotated backward. This doesn't seem like the bug that has already been discussed. Any ideas?

Can I ask what type of encoder you are using? Is it a quadrature encoder or a simple single phase encoder? Both will give accurate distance, but only a quadrature can give distance and direction (Well, unless you play a little magic with your code on the single phase.)

[Mark McLeod]

What Mr. Bill said.
A Quad encoder will have two DIO connections. The second is used to tell direction.
An encoder that has only a single DIO connection (including a quad encoder with one phase disconnected) can only count up.

[ayeckley]

These are all true quadrature encoders (having two output phases). So far in our troubleshooting it looks like the sub.vi is giving properly signed outputs, but that we've made a mistake somewhere between the sub.vi and the indicator in our main .vi. The good news is that it looks like we didn't physically damage the encoders as I'd initially feared.

[billbo911]

Originally Posted by ayeckley

These are all true quadrature encoders (having two output phases). So far in our troubleshooting it looks like the sub.vi is giving properly signed outputs, but that we've made a mistake somewhere between the sub.vi and the indicator in our main .vi. The good news is that it looks like we didn't physically damage the encoders as I'd initially feared.

I guess the only question I have left is: "Does the distance display accurately when moving both forward and backward?"

[ayeckley]

Problem solved:

Apparently our programmers had initialy written their traction control software to address a bug in the initial encoder routine. Then, in one of the updates the bug was addressed by NI (or whomever). We left our fix in place not realizing the original bug had been addressed. The net result was that we took the absolute value of the direction vector (multiplying -1 by -1). We've removed our fix leaving only the NI fix, and now things are working properly.

Thanks for following along with our little drama

[billbo911]

Originally Posted by ayeckley

Problem solved:

Apparently our programmers had initialy written their traction control software to address a bug in the initial encoder routine. Then, in one of the updates the bug was addressed by NI (or whomever). We left our fix in place not realizing the original bug had been addressed. The net result was that we took the absolute value of the direction vector (multiplying -1 by -1). We've removed our fix leaving only the NI fix, and now things are working properly.

Thanks for following along with our little drama

OK, now that sounds better.

When I originally started my first post, I was going to tell the tale of my first experience with the "Early shipment" controller. I too had an issue with direction and distance for the encoder example, but couldn't remember exactly what I did to resolve it. So, I looked at the most recent encoder example and found that it looked normal. Therefore, I just asked a couple questions. I was even going to ask you what version of the FRC Labview you had originally created your code in.

Bottom line, you figured it out on your own. BRAVO!!!