Feedback loop introduction

Hi all.
I am working on DC motor replacement for printer servos.
Thanks to some genious code from github user Misan (https://github.com/misan/dcservo/) I was able to use some old inkjet printer DC motor and its positional encoder to get correct movements for a single axis.
This works great - if I try to stall the axis, it will always get to its correct position later, as soon as I release it.
As I am using the encoding strip and reading direct position of the print head, I am not impacted by any sort of motor slips or belt problems - I really do know the actual position and drive the DC motor to achieve it.
For now, the source of the target position is taken from the stepper driver on RAMPS board - I am using the DIRECTION and STEP pins to get the input.
This got me thinking - as Arduino Mega on RAMPS has enough pin change interrupts available, it should be possible not only to drive the steppers, but to provide direct feedback to the firmware about the actual position.
And, should something go wrong, to perform corrective actions or, worst case scenario, to perform something like "pause" in printing without loosing the model.
I was reading the code on github and found one interesting candidate for this - the updateCurrentPosition method (https://github.com/repetier/Repetier-Firmware/blob/master/src/ArduinoDUE/Repetier/Printer.cpp#L659).
I am searching for an advice from more experienced devs (as I am more of a tester than a developer) - is this a good place to start, or am I on a wrong path?
Is there some feedback-loop behavior already implemented within Repetier and I just did not found it yet?

Side notes:
1. This will be usable also with steppers - you pass the number of steps and check the destination direction afterwards to ensure your move was done properly, so the DC part is not 100% mandatory here
2. This will be usable also with Delta printers - the feedback strip can be placed on all 3 towers to get real position of the system components
3. I'd like to do it in a way to utilize current RAMPS shield - therefore I am already testing a possible replacement for the stepper drivers by chips similar to TB6612FNG. Even now I should be able to replace 2 steppers with a single TB6612FNG and 2 ATtiny85 chips (tested only for single stepper)
4. I am also thinking about some feedback possibility from the extruder - as the inkjet printers also have the ability to "read" the position of paper feeder, I will think of some way how to re-use the rotational encoder for this sort of feedback. And as I checked the code, there seems to be already some sort of "jam detection" facility within the firmware...

Comments

  • Unfortunately it is not that easy. We have no feedback and normally also do not track positions. We have the main thread where we push new moves. The updateCurrentPosition you mentioned is just computing floating point position form step position using the steps where all queued moves will end. It is not necessary that the moves have ended. So reading at that point is wrong.

    Using hardware interrupt pins to signal changes is the only real way to get it right, but that could conflict with time depending on speed. We use up to 100% cpu on high speed and do double/quad steps in one interrupt. What happens if this results in multiple interrupts from the feedback strip? I'm not so familiar with the system but I guess it is like a encoder with 2 signals per strip so you get position and direction from the order? What would the resolution be? 

    So what is possible is stopping print until queue is empty and do a position comparison. If there is a error correct it and then continue. A good point would be after a retract as the motion is stopped there anyway and oozing is least. Only you loose the precomputed path planned normally so you get a extra delay everytime.
Sign In or Register to comment.