Thanks for your input!
Heres the datasheet: http://dlnmh9ip6v2uc.cloudfront.net/dat ... coders.pdf
It's the incremental one i have. Not to bad quality for china made encoders. I think sparkfun sell these.
I'm using one channel for direction and the other for position. Not sure its the best way, but since I will later compare the encoder output with the cnc-programs G-code output, it might be easier to separate the two from start.
The cnc-program first outputs a high or low for direction on one pin and then starts the pulses on a second pin.
I need to somehow save or buffer the g-code output on the pyboard in two files or buffers, one for clockwise and one for counter clockwise.
Thats why I thought of using one encoder channel for direction and the other for position.
The stepper motors have 200 steps/rev, but I can also make them run at halfstep, quarterstep and so on to increase precision. That means I can't compare the signals directly, I must scale the encoders output to a distance, a number of pulses for each millimeter.
I used @pythoncoder's code alot as a reference,(thanks alot for that), otherwise I had no idea where to begin. When it froze on higher rpm's I tried to scale it down to a minimum, get rid of classes and other things I thought might slow it down. But the result was the same.
A few missing edges is not to much of a problem, but the aim has to be that no pulse will be missed. I dont have any problems as I have it now with the stepper motors. It can run for hours and still spit out parts well within the given tolerance. But stepper motors never really know where they are and no alarm is raised if things goes wrong. And its always possible to call G28 to return to reference position and reset.
The hardware acces is way over my head for now. I can only hope someone else gets to it and wright an understandable tutorial