Encoder counting randomly off by x4 factor

[jgeorge]

Hi all,

I am using Grayhill 63K64 because I have a high speed shaft, 2000rpm, and wanted the ball bearing version of encoder. I am running it directly from the encoder to the 2006 RC input (no flip flop to buffer B phase) using two 3' servo cables. I am also using Kevin's latest version of encoder code (BTW, thanks Kevin, it is good stuff). The interrupt stuff is as is. In the slow loop, I read the encoder counts, do a delta between readings to get velocity at 26.2ms rate, and try to make decisions. Everything compiles and counts except.....

Every time I start the RC, I am never sure if the encoder will count a magnitude off by 4 times or not. For example, when measuring the rotation of spinning beam, I sometimes read vel of 16 ticks/loop or 64 ticks/loop for the same PWM setting to the motor. It appears random, possible related to software changes, but I have not isolated it to whether it is due to my changes or inherent in my hardware setup.

What I mean by random is that with one version, but multiple resets, it appears error repeats itself, always 16 or always 64. When I rewrite code and download, it could change but between resets, the new factor sticks. I do not know why main line coding should affect it because counter is in interrupt. Unless it is because I am using printf statement and the serial drivers (Kevin's, not IFI's) is using interrupts and is higher priority than the encoder interrupt and interfering somehow. I am only printing out about 25 chars every 26.2ms at 115K baud.

I also tried reversing the input 1 and input 11 signals, no luck. I tried moving to encoder 3 (pin 3 and 13, no luck). I have not tried short cable.

Any ideas?

Thanks in advance.
Jacob

[Kevin Watson]

Hi all,

I am using Grayhill 63K64 because I have a high speed shaft, 2000rpm, and wanted the ball bearing version of encoder. I am running it directly from the encoder to the 2006 RC input (no flip flop to buffer B phase) using two 3' servo cables. I am also using Kevin's latest version of encoder code (BTW, thanks Kevin, it is good stuff). The interrupt stuff is as is. In the slow loop, I read the encoder counts, do a delta between readings to get velocity at 26.2ms rate, and try to make decisions. Everything compiles and counts except.....

Every time I start the RC, I am never sure if the encoder will count a magnitude off by 4 times or not. For example, when measuring the rotation of spinning beam, I sometimes read vel of 16 ticks/loop or 64 ticks/loop for the same PWM setting to the motor. It appears random, possible related to software changes, but I have not isolated it to whether it is due to my changes or inherent in my hardware setup.

What I mean by random is that with one version, but multiple resets, it appears error repeats itself, always 16 or always 64. When I rewrite code and download, it could change but between resets, the new factor sticks. I do not know why main line coding should affect it because counter is in interrupt. Unless it is because I am using printf statement and the serial drivers (Kevin's, not IFI's) is using interrupts and is higher priority than the encoder interrupt and interfering somehow. I am only printing out about 25 chars every 26.2ms at 115K baud.

I also tried reversing the input 1 and input 11 signals, no luck. I tried moving to encoder 3 (pin 3 and 13, no luck). I have not tried short cable.

Any ideas?

Thanks in advance.
JacobAs I pointed out in the encoder_readme.txt file, you may need a line driving circuit at high count rates (2100/sec is high) to drive the capacitance of the cabling. Try it at lower spin rates and see if the problem goes away. If you can find a way to gear it down, that would be good. You can also use a 74ACT244 or 74LS244 IC mounted close to the encoder to send the signals through the cabling.

-Kevin

[Alan Anderson]

Just to reduce the number of variables, try putting in some code to toggle an otherwise unused output every time you compute the delta. Look at that output with a scope to see that you're actually doing it every 26.2 milliseconds. That'll help tell you where to focus your attention.

Look at the encoder output with the scope too, just to make sure that it stays consistent.

[jgeorge]

Alan, Thanks for good suggestions. I will try to wrangle a scope from somewhere into the school to check encoder signals. And do the output bit test trick as well. Should give a good picture of situation.

Kevin, Thanks for reply. I will build the board. But, why does it work sometimes? Just marginal you think? I was going to stop all prints and see if it works better as the TX buffer intr. taking too long might interfere with the encoder phase B read causing the problem. Maybe in some versions of code, the print time is synched with the encoder phase B just right! In any case, I agree with you that it appears I will have to build board.

[Jared Russell]

I would guess it is marginal.

[Kevin Watson]

Alan, Thanks for good suggestions. I will try to wrangle a scope from somewhere into the school to check encoder signals. And do the output bit test trick as well. Should give a good picture of situation.

Kevin, Thanks for reply. I will build the board. But, why does it work sometimes? Just marginal you think? I was going to stop all prints and see if it works better as the TX buffer intr. taking too long might interfere with the encoder phase B read causing the problem. Maybe in some versions of code, the print time is synched with the encoder phase B just right! In any case, I agree with you that it appears I will have to build board.Yeah, it would be great to put a scope on it and see what's happening. Make sure you look at the signals at the robot controller (sorry if I'm pointing out something obvious). If you figure out what's going on please post your findings.

-Kevin