Encoder trouble

[Integral]

Flameouts Mentor here,

Our wiring is correct and sound, as is the condition and installation of the encoders themselves.

We currently appear to have a good reading from the right encoder and for the left we get a flat 0. Perhaps more of an error condition? I have not been able to find any sign of an error thrown by any of the encoder vis.

I note in the first block (from the begin vi) of code flameout posted that neither of the encoders are set for reverse. Could this cause an error?

It really does not matter how we are viewing the output of the encoders, the posted code shows how we first initialise the encoders then how we read them. Can someone comment on the correctness of this code?

[apalrd]

I'm looking at how you calculated the scaling...
8*pi = circumference of wheel
divided by encoder counts (360)
divided by feet
multiplied by gear ratio (15/22)
The result of that calculation is 0.00379
My math says 0.05 inches - same as yours except yours is in feet.

Scaling is correct.

Which brings us back to - Where is this get code. It is in a while loop. Is it in Teleop.vi? Is it in Autonomous Independent.vi? You can call Encoder:Reset before you enter the while loop if you are doing this in Autonomous.


EDIT - after looking at that get code, I see a possible problem. You are feeding the difference from this get and the last get (speed) and using that to determine your position with the help of the gyro. It would be much simpler to just reset the encoders at each turn, and add the position change in each segment of your journey, assuming you never turn and drive straight at the same time.

[Alan Anderson]

Originally Posted by Integral

It really does not matter how we are viewing the output of the encoders, the posted code shows how we first initialise the encoders then how we read them. Can someone comment on the correctness of this code?

It might not much matter how, but it certainly makes a difference when and where you read them. The while loop worries me, but I can't comment on whether the code is correct without knowing the context. My earlier question remains: where is it?

[flameout]

This is in a VI that is in Periodic Tasks.vi (we use our own loops, not the built-in loops.) This is a timed loop, which I believe is set with a delay of 20 milliseconds.

We now have one working, and one not. The one that's not may or may not be plugged in (I don't recall for sure.)

Thank you.

[Integral]

Originally Posted by Alan Anderson

It might not much matter how, but it certainly makes a difference when and where you read them. The while loop worries me, but I can't comment on whether the code is correct without knowing the context. My earlier question remains: where is it?

Please note that the right encoder is functioning as we expect, the left is not. Again it really does not matter where the code is. If one is working the other should also be.

Once again, does one encoder NEED to be set for inverse operation?

I have operated the right encoder from the both sets of assigned DI/O,s and have installed a new left encoder. The encoder change made no difference.

[apalrd]

You don't NEED to set one inverse. If it runs inverse, then set it inverse. The software sees it as yet another encoder, one of many. If you swap the A and B channels it will have the same effect, so it is possible you might have to invert one, none, or both, not necessarily the right one. Yes it does matter where the code is; if that code were in Teleop then the while loop would cause problems. When the right encoder is set run on either set of IO, does it work? When you plug it into the ports for the left encoder, does the left show change? If so it is certainly a hardware problem. If not, then it is either a problem with software or the 37-pin cable.

[Alan Anderson]

Originally Posted by Integral

Please note that the right encoder is functioning as we expect, the left is not. Again it really does not matter where the code is. If one is working the other should also be.

It really does matter where the code is. Context means a lot when trying to determine what might be going on in a real time system.

For example, if it's in a parallel task outside the Robot Main event loop, and if it is not in a sequence enforced by the "error out" connection from Begin.vi, the Refnum Get for your left encoder might be getting executed before the Refnum Set for the encoder has been done.