I have just tested it and I realized I was provided wrong information. The seller claimed the encoder had 888 lines but it turns out this is wrong. I guess it is something around 450.
Anyway, the question about accuracy is problematic: at the end of a movement, I get zero error, meaning it is right on the spot. During motion, I have posted a live capture from an analyzer that may help answer that. However, my software does not decode the quadrature signals nor counts pulses so keeping track of the instantaneous error is a bit of a nightmare.
Printed objects have a rougher appearance. Looking at the data capture I can see the speed is changing while motion is happening. The culprit is the PID has no clue about speed, it just tracks the desired position, that changes every step pulse. For a smoother behavior I reckon a second PID for speed control would be needed plus some form of speed and acceleration feedforward to the loop.
The problem is that keeping the interface being step and direction signals from Marlin (or similar) speed and acceleration are missing. However, all that info is available for Marlin every time a movement is planned, so the logic step would be to bring the control of the motor in closer relationship with motion planner. But doing so is what it is a bit more challenging than just writing about it :-)
I have learned that many Cortex 3 and 4 ARM processors do include four timers that can handle the quadrature encoder signals without processor intervention. I have a Nucleo-F401 board (that costs like $10) that should be able to do the control of four motors and g-code parsing without problems. There is an even cheaper option, the Maple mini, that can be had for $4. But one thing is to just have these boards control up to four motors and another to actually write or migrate a machine control firmware.
For the moment I am going to focus on getting the motors controlled by the same board but using the step/direction interface. But if anyone wants to try it, I reckon motion planning needs to be integrated with the control loops for the best quality output.
Anyway, the question about accuracy is problematic: at the end of a movement, I get zero error, meaning it is right on the spot. During motion, I have posted a live capture from an analyzer that may help answer that. However, my software does not decode the quadrature signals nor counts pulses so keeping track of the instantaneous error is a bit of a nightmare.
Printed objects have a rougher appearance. Looking at the data capture I can see the speed is changing while motion is happening. The culprit is the PID has no clue about speed, it just tracks the desired position, that changes every step pulse. For a smoother behavior I reckon a second PID for speed control would be needed plus some form of speed and acceleration feedforward to the loop.
The problem is that keeping the interface being step and direction signals from Marlin (or similar) speed and acceleration are missing. However, all that info is available for Marlin every time a movement is planned, so the logic step would be to bring the control of the motor in closer relationship with motion planner. But doing so is what it is a bit more challenging than just writing about it :-)
I have learned that many Cortex 3 and 4 ARM processors do include four timers that can handle the quadrature encoder signals without processor intervention. I have a Nucleo-F401 board (that costs like $10) that should be able to do the control of four motors and g-code parsing without problems. There is an even cheaper option, the Maple mini, that can be had for $4. But one thing is to just have these boards control up to four motors and another to actually write or migrate a machine control firmware.
For the moment I am going to focus on getting the motors controlled by the same board but using the step/direction interface. But if anyone wants to try it, I reckon motion planning needs to be integrated with the control loops for the best quality output.