Are these encoders working right?

[Sylvie]

Is This Encoder Working?

[2775Josh]

I think so. Best way to know for sure is to code it.

[Martin]

Yes they are working correctly. Basically the encoder disk has 90 slots with 2 sending reciving units.
The to recever units can count 360 deg by having 4 possible situations with the slot. On on , On Off , Off Off, Off On. That is why when you spin the encoder , the count synchronizes in that pattern. High for on and low for off.
The computer computer that into degre count on their side.

In V5text there is a possible glich that may appear that is weird and I will describe what I think is happing next. Ok so In V5text you can make items by clicking on the icon on top right hand corner then selecting 3 wire then selecting encoder, then it promps you to choose two 3wire ports that have to be side by side. When after you define the encoder then make a program that says encoder deg value =0 then inside a following while loop say brain.screen.print(endodervalue) it will sometimes print 0 and change like normal when you turn the encoder, and somtimes it will say an obsurbly large number that seems to most of the time land around 68,000 for the encoder deg count. And then count like normal from there. Why this happens I do not know for sure, but I think that it has to do with when you are asking for the encoder value ,it will think to use the analog value maybe , instead of the deg count. Why I think it does that is because when the encoders are defined in the box in top right hand corner, one can’t defing what value to be looking for. So when the brain is asked on the value it gives a number that is not on deg then counts deg after that. A possible way to maybe fix it is to define the encoder in degrees, not using the box in top right hand corner. I actually didn’t fix it that way, but found another way to prevent the “glich” from ever happening. I told one motor to move one deg, not enough to even be visible. Then wait for 101 milliseconds. I still had the glitch happen without the wait , or without the move motor command or with a shorter wait of 68 milliseconds. I think by saying motor do something then wait that on the vex side of the program, by the time I am actually using the encoder value , the brain had a “promt” from motor command and “time to prosses” that the encoder value is zero.