Servo motors on Prusa i3

I have done a proof of concept modifying some of the available code and writing some new one so each servo motor mimics the motion of a stepper and reacts to the step and direction signals of Marlin firmware. For the moment only X and Y axis are changed: [www.youtube.com]

Additional software [www.youmagine.com]

Parts for i3: [www.thingiverse.com] and [www.thingiverse.com]

Please note my approach uses a new Arduino Pro Mini per axis for the closed-loop logic (encoder and step counts and motor location PID loop).

Nice. I like a lot.

What sort of step/mm setting does that work out to be?

I started my tests having just 2x encoder resolution and that turned out to be 31.189 steps/mm. It does not sound like much, but I reckon these values are actually accurate, while microsteps do no always correspond to real positions (there is a bit of lag between real and commanded position at the microstep level) . I am moving to 4x encoder resolution which should hopefully double that.

Impressive demonstration!

For the future I think you can drop that part with calculating from wanted position to step pulses in Marlin, then back to wanted position in your stepper driver Arduino. Putting this algorithm directly into the firmware should work even better.

Big question here, too: how accurate is this?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

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.

I'm working on a similar project - I'm working on using a Adafruit Trinket Pro (ATmega323) for my ink sprayer control for my powder bed - Y axis is a DC motor + encoder (600 DPI) with a InkShield.

The DC motor is velocity, not position, controlled which makes it simpler to manage - I just bump up the PWM if going too slow, bump down if going too fast.

For accurate fast positioning, you will need to do inertial calibration - given velocity X of the printhead, how much force Y do you need to apply to get the head to stop.

This part (positioning) is not well suited for PID control, however. You don't want to bounce back and forth, you just want to accept a (small) amount of overshoot and apply that as an error factor into your next movement.

You will need to know the mass of the printhead, it's velocities, and how PWM relates to velocity.

The last part (PWM to velocity) *is* a good place for PID control.

i'll be following this topic if you wish to discuss more.

I am in the process of migrating to a powerful 32-bit platform that will integrate motion planning and control loops. Most likely, control loops will take into account position and speed control, with acceleration feedforward to take into account the physics of moving mass. I have found quite a lot of interesting information here: [www.pmdcorp.com]

misan: Thank for the PDM Corp URL - very good information!

/me bookmarks...