Multiple quadrature encoder issue?
kwagner
Posts: 48
I got a handful of the quadrature encoders from parallax (https://www.parallax.com/product/ky-040-rotary-encoder-module-15x16-5-mm-with-knob/ ) to use for a project.
I hooked one up and ran the quadrature example from here https://github.com/parallaxinc/propeller/tree/master/libraries/community/p2/All/jm_quadrature and everything worked great.
I then added a second encoder and made a second instance of jm_quadrature so the demo had two encoders at the same time. For some reason, the accuracy isn't as good now. For example, moving the encoder one tick might increase the value by 1, go backwards by 1, not move at all, move by 2, etc.
Initially I thought this might be the pin placement (I had one on even pins and one on odd in the same 8 pin block), but moving the second one to a different set of pins, as well as changing the hardware thinking I might have a dud, didn't change the outcome. It's a simple program with the smart pin doing a lot of the work, so I'm not sure what else to check. Has anyone else run into issues with multiple encoders?
Comments
I have 3 motors/encoders behaving beautifully.
@Ariba (Andy) helped me out:
https://forums.parallax.com/discussion/173953/flexbasic-and-quadrature-decode#latest
Craig
I suspect a program flow issue. It might be that you're using blocking wait loops or accidentally reusing and overwriting variables?
Can we see your code, or a cut down version that still exhibits the issue?
And there's the rub: the smart pin handles all of the tricky stuff. That said, the version of the object you're using doesn't include pin filtering. This was suggested by another forum member and seems to help with low-cost encoders. My latest object is attached.
I second this request.
After you've compiled a Spin2 program, you can then select File\Archive(P2:file_name)\Project...
You can then upload the zip archive.
Mickster,
Ariba's example smartpin/pin mode config has an issue in that prior topic. The pull-up won't work because
PINHIGH()can't reach the output. Use this instead:Or just this if no pull-up is needed:
And Jon will be very correct about the debounce "filter". Very much needed for mechanical switched inputs.
Another possibility is the rotary knob is not quadrature at all. The description says clock and direction, "... encoder outputs pulses on two pins for direction and counts.", like a stepper.
Quadrature encoders do not need debouncing.* Jitter on one pin will settle before the other pin changes state. You might get a little back-and-forth by one count before the jitter settles, but it's not something that accumulates, so you won't lose position information as a consequence.
-Phil
@evanh
Much appreciated
Not had a problem so far and I'm doing all kinds of gearing and coordination. Things might change when I get this stuff on this machine
I always worry when things go too smoothly
P2 is cooperating with this hack of a programmer way too easily 
Craig
This is my understanding as well. As long as the encoder produces valid encoder logic, any jitter should cancel itself out.
I've be very curious if filtering helps. It sure seems like something is wrong with the system if jitter in the encoders doesn't cancel automatically.
I would call it a fake-bug. I set the OUT bit to High, while evanh leaves the OUT bit Low and inverts the output to get a High.
Andy
Thanks all for the input. I modified my code to use the filter version from JonnyMac, and I don't have the issue anymore.
In theory, yes, the Quad state follower should simply count rapidly +/- 1 on a series of edges.
However, there may be scope in the real world for aperture issues to creep in, around pin sampling levels and times.
Good news. I wonder if the revised/new code is used, with just the filter mode setting changed, if the problem comes back ?
I didn't set OUT high because OUT is overridden when using a smartpin. The only way to get the pin drive set high, when the smartpin isn't using its output (smartOUT), is by inverting the smartOUT low to a high at the low-level pin mode config.
Your solution doesn't effect a pull-up, it stays driven low at full drive strength.
I'm guessing Mickster just used it as an input only - removed the P_OE and associated pull-up config.
It's not overriden when you use a smartpin, it's the pinstart() function that needs to choose eighter high or low for the OUT state.
Chip decided to set the OUT low on pinstart(), but you can change this afterwards, if you need a high. If you don't use pinstart() but do the smartpin initalization by hand, you can use also pinhigh() (or DRVH pin in PASM) to enable the DIR bit as the last step.
Andy
DIR is separate signal to OUT. OUT is totally overridden by configured smartpin in hardware. There is no getting around it.
I've recently tested this very issue, of achieving a pull-up on the DO pin of SD cards, which is missing externally on both the Eval and Edge boards. Which, in turn, is why I immediately knew now what was wrong with the listed mode.
Can confirm, if I set the filter value to -1 (disabled), the problem returns. Setting it to 0 fixes the issue.
Just out of interest. I am limited by the 10Mb/s of my MC3486 line receiver. Not that this is a practical limitation
But if asked, what is the maximum quad counts/sec of the P2?
Craig
Probably sysclock, maybe sysclock/2 at worst. EDIT: It's asynchronous, therefore Nyquest says keep it lower than sysclock/2.
Thought so...it's ridiculous but at least it's safe for my spec-sheet to claim 40,000,000 quad counts/sec
Many thanks.
Craig
You should also check the pin-filter settings, and any external R-C filters + hysteresis.
If a system has a known lower edge-edge timing limit, set by clocks/filters, it is common to see an external Schmitt + RC added to ensure nothing, (not even spikes), coming from the real world, can exceed that timing limit.
Not an issue with encoders in motion control. All we have is differential line-drivers/receivers.
Industrial rotary encoders tend to max out at 500KHz (2M quad counts/sec).
The big name in motion-control boasts 22M quad counts/sec as if it could ever be utilised. Just one-upmanship on my part when I promote the Prop
Craig
You might be surprised.
I had a friend who changed from a mid stream quad part to his own CPLD solution, which was about 10x faster.
His difficult field usage involved ropes and some whiplash, and the part that 'looked just fine on paper', simply did not work as well as his solution, with higher headroom.
He also applied my suggestion of R/C/Schmitt to ensure nothing (not even spikes) could go outside his improved CPLD timing handling.
JMG is saying that noise immunity gets improved by matching the Prop2's performance to the encoder used. Another one to enable is low-level I/O pin registering.
Is this a P2 thing?
Another puzzler:
I came across a Maxim differential line-receiver app-note, regarding encoder interfacing and they show the typical RS422, 120R terminating resistor. Yet I have a number of high-end, off-the-shelf motion controllers and none of them have this and there is no mention in the documentation.
Interesting....sounds like pretty erratic encoder behaviour. Isn't spike immunity the whole point of balanced lines?
Craig
Yep, symbol name is
P_SYNC_IO, which sets the C bit:%0000_0000_000_0000100000000_00_00000_0They probably should have the resistor. The longer the cable, the more it's needed to shut down reflections.
Yes, but differential without electrical isolation doesn't have the same common mode immunity you get with a balanced transformer coupling. I think the main advantage is the symmetrical currents of differential eliminates the very problematic self induced ground bounce. Which I guess is like a reflection but in the power supply conductors.
@evanh
I dunno. Noise on encoder lines only ever cropped up for me, back in the 80's, prior to balanced lines. Today, the only problems we experience is with fractured cables. 11 and 9 axes is common and we have cable chains all over the place, bending around some pretty tight radii.
One thing that amazes me; separation is impossible with a servo-motor. Two cables need to go the motor, power and feedback. I had my head stuck in a control panel and there was barely any light. When the 100HP AC-Vector-Drive came under load, I could see this, like, plasma on the motor cable
The encoder cable runs right alongside this thing and never skips a beat.
Craig
Shielded cable is the other part of reliable differential operation. The shield absorbs all the external RF. Take that away and you hit trouble pretty quick in a noisy environment.
Good idea for the motor cables to be shielded and earthed too. It really shouldn't be lighting up. That's losses right there for a starters. Any idea why? Must be higher Volts at least.
At least 480V. All big-name kit and with their supplied cabling and massive grounding clamps. I'd produced dozens of these machines but this was the first time that anybody had stuck their head inside the cabinet during a production run. I freaked at first but the suppliers told me that it was normal due to the high frequency PWM. My standard was Emerson-Control Techniques but this customer specified this package (forget the name) because it was their in-house standard.
Craig
Big stuff should have some filtering on the drive's outputs to take the edge off the dV/dT. The cables must be getting hot. And the motors don't really like it either. The steep slope creates leakage through the bearings, destroying the lubricant.
In fact such drives often switch at 4 kHz to keep the dV/dT lower. Makes the motors whine a lot of course.
Wait… say what? I think I’m a about to learn something important here.
Can you explain the bearing issue?