Page 2 of 2

Re: ExtInt problems

Posted: Sat Mar 07, 2015 9:12 pm
by Jonas
I know they dont output step and dir, but while trying to learn python3, this was the best I could come up with. The code I'm using makes one channel a direction output. The variable forw is always a 1 or a 0 depending on direction, making counter1 count up or down. This is probably not the best way to do this, but for now it's all I could do. Please ignore my simple code for now, it's going to be alot different with the timer class.
So lets take a step back. On the output side, you're trying to generate step/dir for a servo/stepper and monitor using quadrature with your encoder.
On the input side, are you taking gcode in? Or step/dir signals?
Yes you're right. It's step and dir signal in, not g-code. I'm taking step and dir signals from the pc that run the cnc-program mach3 in to the pyboard. I'm also taking in signals for the real actual position from the quadrature encoder to the pyboard. This will be compared by the pyboard, making sure the next change in position the cnc-program makes can't be executed before the pyboard confirms from the encoder value that the real actual position has been reached. The pyboard should output the same step and dir pulses as those that came in, adjusting for any errors by checking the encoder for real actual position, and when it matches up it's time to run the next line of pulses stored in the pyboard.
This I think should happen near simultaneously as the pc outputs it's signals, but if there is any position adjustments to be made, the pyboard will lag a bit. Maby a function can be made to rise an alarm if it lags, say more then half a second, if it does you sure know that it hit something it should not.

Thanks alot for your input!

Re: ExtInt problems

Posted: Mon Mar 09, 2015 3:53 pm
by dhylands
The latest MicroPython should now have quadrature encoder support.
https://github.com/micropython/micropyt ... eba9c4d7aa

Unfortunately, there are only 3 pin pairs on the pyboard which support this:

X1/X2 - Timer 2 or Timer 5
Y1/Y2 - Timer 8
X9/X10 - Timer 4 (updated - thanks @pythoncoder)

A couple of sample scripts which I used for testing this:
https://github.com/dhylands/upy-example ... ncoder2.py
https://github.com/dhylands/upy-example ... ncoder3.py

Re: ExtInt problems

Posted: Mon Mar 09, 2015 10:55 pm
by Jonas
This is great!!
Can't thank you enough for all the hard work you do.

To bad I have to wait until friday to try it out...

Re: ExtInt problems

Posted: Tue Mar 10, 2015 6:00 pm
by pythoncoder
That is excellent! A couple of minor points: Timer 4 pins are X9, X10. Secondly your first example mentions debouncing. This shouldn't normally be necessary: if the signal on one channel toggles while the other is static, the count will jitter by one LSB but there shouldn't be any cumulative error. I've verified this by toggling a pin several times after a transition and the cumulative count is correct so the hardware guys have got it right ;) So I'd save the analog components and use the built in pull-up or down resistors.

The single LSB of uncertainty is inherent in the process as even an ideal encoder can be positioned at the very edge of a transition point. If the aim is to work out the position of a manually operated quadrature encoded rotary mechanical switch the code needs to include hysteresis to avoid the risk of the reported switch position being affected by the proverbial butterfly in China. In practice a little hysteresis coupled with some kind of feedback to the user gives the interface a natural "feel" (in my view, of course).

Re: ExtInt problems

Posted: Wed Mar 11, 2015 12:45 am
by dhylands
Without the debounce stuff I was getting wild counts while using the rotary switch. I suspect that it has a pair of wipers moving over a moving circuit board or something which can cause noise on both channels while moving.

But I didn't rip the switch apart to see how it worked, nor did I check it on my logic analyzer.

With the optical encoders on my motor, I didn't observe any issues even with nothing extra connected.

Re: ExtInt problems

Posted: Fri Mar 13, 2015 1:39 pm
by Jonas
Now I have tried it!
Can't get my motors to spin so fast that it freeze up, maby I'll try with my dremel :twisted:
It detects all 4 edges, giving me 4096 pulses per rev.
I will now try to connect a linear encoder to find out if it miss any pulses, I bet it wont.

Again thank you so much.

Re: ExtInt problems

Posted: Fri Mar 13, 2015 7:01 pm
by dhylands
pythoncoder wrote:That is excellent! A couple of minor points: Timer 4 pins are X9, X10.
Thanks - i edited my post and changed it.

Re: ExtInt problems

Posted: Sat Mar 14, 2015 9:46 am
by Jonas
Is it possible to calculate the maximum number of counts per second? It's not as simple as 168 Mhz divided by 4 I guess...

Re: ExtInt problems

Posted: Sat Mar 14, 2015 4:47 pm
by dhylands
The fastest timer clock is 84 MHz. So it should be able to be clocked at least that fast.

Beyond that, it probably depends on the silicon design.

For quadrature you're providing the clock edges and its just using some simple logic to determine if the counter should be incremented or decremented on each clock edge.

Re: ExtInt problems

Posted: Sun Mar 15, 2015 9:06 am
by pythoncoder
It's likely that the hardware uses synchronous logic. So the quadrature signals would be clocked in by one of the internal clocks of the chip - very possibly 84MHz which would set an upper bound of 84/4 = 21M edges/sec. But without detailed hardware knowledge it's guesswork. Damn fast in terms of practical encoders is my guess ;)