Emulate the Z stepper with a servo

[TheSFReader]

For usage not directly connected to 3D printing (drawing, laser / vinyl cutting, etc.), a servo would be good to use as a lightweight Z axis actuator. This would enable fast movement with small but precise Z course, and a light infrastructure.

One way to do that would be to create a new feature that emulates a stepper driver by transforming the signals to the steppers (DIR, STEP and ENABLE) to increase/decrease the microseconds as sent to one of the servos already implemented in Marlin.

This transformation can take place in the servo_indirection (.cpp/.h) files, just like the diverse drivers.

So far, I've a first implementation, that works quite well for 1 servo on the Servo0 pin, but it seems the other (RAMPS) Servo pins are used somewhere else by Marlin.

One servo is sufficient for a single axis in the use case, but could be generalized for the other axis.

I could make a PR, but don't feel my implementation is mature enough for now, and won't push it unless there is interest.

[thinkyhead]

With PINS_DEBUGGING enabled you can use M43 to see where pins and timers are allocated.

[thinkyhead]

It's a pretty interesting concept and Marlin is still built today with RepRappers very much in mind. I would like to see a PR, or at least have a look at your working branch, and see what's being developed. I can see why you'd intercept at the step-direction level, as that brings a lot of simplification to the implementation, while retaining vital axis synchronization.

Is there much community interest at the moment? Probably not. But if you posted a printer design, or even just a Z axis modification on Thingiverse to go along with it, then it would gain momentum. You might even go so far as to make a 100% servo-driven 3D printer design just to prove the concept!

Overall, I'm impressed. This shows some nice "outside the cube" thinking.

[TheSFReader]

I've made a mistake on my 2.0 branch on my repository, which ended up with integrating the work-in-progress files there.(https://github.com/TheSFReader/Marlin/tree/bugfix-2.0.x/Marlin/src/feature/servostepper.h /servostepper.cpp) and updated the module/servo_indirection.cpp/.h, so you can have a look. (No #defines in the configuration for now though)

Good idea on working /publishing about the design to generate interest.

WRT PINS_DEBUGGING, I've had troubles enabling them for the Mega2560 since 2-3 pins seem undefined (SCL/SDA and an other definition). I'll take a closer look though.

Thanks

[thinkyhead]

Pins debugging may be better now. Try again.

[TheSFReader]

Thanks :) Tried yesterday evening, worked better indeed, and am in the process of formalizing a pull request. Works well with two (synchronized) servos now (X and Z) but still need some work on the configuration side.

I guess it'd be better on the _configurationadv.h rather than in configuration.h, right ?

BTW, any idea why the delay (in the Servo::move methods) isn't a _safedelay ? I've replaced them, as I don't see a good reasonnning to use the unsafe one, and many reasons (temp control) to use the safer version...

[TheSFReader]

PR sent : #9935

[thinkyhead]

I've replaced them

That's probably fine. The main difference is that safe_delay can end up being long under certain conditions and may invoke serial output. Since the servo delays tend to be very short (50ms) and are not used (normally) during printing, delay was fine for our purposes.

[TheSFReader]

Actually, the default delay for the servo "move" was 300ms (at the end of Configuration.h) , which is WAY more than the usual "safe_delay". It's usually disabled and not many configurations use the Servo, so probably not a problem. But the i3-2020 and gMax1.5+ seem to use 300ms and 500ms ...

[boelle]

@thinkyhead since we have a PR maybe close this one too?

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.