Stepper Driver type "SERVOSTEPPER"

[TheSFReader]

Marlin is usually used as a 3D printer firmware, but also sometimes for driving different types 3D enabled actuators. In some cases, a full stepper weight is too much and a more lightweight control of an axis position is needed. (For example to control a laser cutter/vinyl cutter, drawing machine, foam cutter etc.)

This PR proposes to add a feature that enables the use of servos in place of one or more axes' steppers.

It implements a "servo_stepper" type of stepper driver, which emulates a driver's interface and by redirecting the pins activations to the servo_stepper drivers class, which in turn translates them to activating one of the servos connected to the board.

In the case of a foam cutter, a drawing machine etc. it allows the depth component to be managed without any specific gcode modification by a servo instead of a full vertical stepper controlled axis, and hence can use a marlin compatible CAM's output without specific post-processing.

(see ESTLCam, and many MPCNC inspired projects which use marlin as a default firmware)

[TheSFReader]

It looks like the teensy uses its own internal Servo class. Does anyone know how its implemented ? Is there some source code available ? Or is it the "standard" arduino Servo code ?

[thinkyhead]

It looks like this may be the class you're looking for:

• https://www.pjrc.com/teensy/td_libs_Servo.html
• https://github.com/PaulStoffregen/PWMServo

[TheSFReader]

I "faked" the method I wanted to implement by wrapping around the one already existing, so that'd be good to go.

[davidelang]

when you talk about servos here, are you talking about a hobby-type PWM driven servo where the position is set by the PWM duty cycle? or are you talking about a servo in terms of a motor/encoder combo where the motor is driven (usually via PWM one direction of another) and then an quad encoder reports what movement actually takes place? David Lang

[Roxy-3D]

Yikes!!! I see all kinds of topics (issues) I want the experts to discuss before this gets merged!!!!

For starters... You do realize that Marlin (or really GRBL) coordinates the movements of all the stepper motors so they make a linear movement from one location to the next.

If a new servo frequency is sent at the start of a movement... You are making an assumption that the servo will move at the correct rate such that it will finish its movement at the same time the stepper motors finish the movement.

Or... If the X & Y are controlled by servo's also... You are making the assumption that each servo will move at the correct rate so the line stays linear....

It maybe I'm worried about something that is already accounted for. But I would feel much better if we can have a discussion about this with the various experts weighing in on it. @AnHardt for example.

[davidelang]

If the feedback is via encoders, then the motor power will need to be continually adjusted in a PID loop (which can run its checks in a similar way to the loop that issues the stepper pulses) If there isn't feedback, then this isn't going to work well, hobby servos just aren't consistant enough (load vs no load, or one servo vs another) with just open-loop PWM control.

[TheSFReader]

Yes, I talk about hobby type PWM driven servos, the "feedback" being internalized by a local potentiometer as far as I I understand.

Since the feature intercepts and changes the PWM at each step impulse received, the servo frequency is changed all along the move, the movement is nearly continuous, and can stay synchronized with the other axes, be they servos or real steppers.

As I understand the Servo implementation (for arduinuino at least), the PWM is commanded by a timer that reads a command value (ticks betwee, impulses), and PWM adjustment is only by changing that command value/attribute of the servo (see ServoInfo_t.ticks in servo_private.h).

@davidelang is right, linear change of the PWM -> physical rotation of the servo is not guaranteed, and that can be a problem. (ie A given 300 steps delta is not guaranteed to give the same displacement around 1000 microseconds and around 1500 for example), but I think the "system's designer" need to make sure that is acceptable for his system.

I also make the assumption that each servo axis has its max feedrates , jerk, and steps/units configured so that the servo can do a (physical) step in the corresponding maxfeedrate /step units time even under the load the system is designed to sustain.

Clearly, this is for lightweight axis, and I would think that people who design a machine that use the servo_stepper feature take it into account, by either use a servo that can keep up with the load, if the load is incompatible with physical servos, the feature isn't a good solution there.

The same configuration / load hypotheses are made with actual steppers, where step skipping is far from unheard of.

However, the servo-stepper feature is one that needs "machine system" design (if used for X, Y or Z axes), and for machines "architectured" with the feature in mind. So the decision to use the feature is wholly on the "designer's" shoulders. Actually, I put the enabling configuration in configuration_adv.h as I don't think it's 1) for everyone's use 2) for everyone to tinker with...

[davidelang]

On Mon, 5 Mar 2018, TheSFReader wrote: Yes, I talk about hobby type PWM driven servos, the "feedback" being internalized by a local potentiometer as far as I I understand.

that is local feedback to the motor, but the pots are not high precision devices, and vary from servo to servo (and also over temp ranges) these services are designed to adjust the pot value to match the PWM that you send. This is (ab)used to control the speed for continuious rotation servos (because the more the PWM differs from the 'center value', the larger the error, and so the faster the motor is driven.

Since the feature intercepts and changes the PWM at each step impulse received, the servo frequency is changed all along the move, the movement is nearly continuous, and can stay synchronized with the other axes, be they servos or real steppers.

how do you decide what to change the PWM to? unless you have an encoder of some sort, you have no way of knowing that something should change

As I understand the Servo implementation (for arduinuino at least), the PWM is commanded by a timer that reads a command value (ticks betwee, impulses), and PWM adjustment is only by changing that command value/attribute of the servo (see ServoInfo_t.ticks in servo_private.h).

correct, you set the value and the library pumps out PWM at that level

I make the assumption that each servo axis has its max feedrates , jerk, and steps/units configured so that the servo can do a (physical) step in the corresponding maxfeedrate /step units time even under the load the system is designed to sustain.

it's FAR more primitive than that. Remember, this interface was created decades ago, it's just a matter of driving the motor proportional to the error

Clearly, this is for _lightweight_ axis, and I would think that people who design a machine that use the servo_stepper feature take it into account, by either use a servo that can keep up with the load, or simply using a more traditional stepper if the physical demands are too great for the servos he can/wants to use. (actually, I put the enabling configuration in configuration_adv.h)

I have two CNC machines that use servos, one with hobby servos and a magnetic sensor to provide feedback on the angle, the other with larger DC motors and encoders to provide feedback. Servos can work well, but you have to have feedback David Lang

…

The same hypotheses are made with actual steppers, where step skipping is far from unheard of. However, davidelang is right, linear change of the PWM -> physical rotation of the servo is not guaranteed, and that can be a problem.

[TheSFReader]

This is (ab)used to control the speed for continuious rotation servos (because the more the PWM differs from the 'center value', the larger the error, and so the faster the motor is driven.

But I'm not talking about continuous rotation servos here, but a "classical" one, with its limited <360degrees range

how do you decide what to change the PWM to?

For now, I start at 1500 and decrease / increase by one for each STEP pin change , depending on the DIR pin. (see servostepper.cpp)

There is no real good calibratrion for now either, but I'll work on that too. initializing min/max PWM frequency, and potentially min/max angle. This should allow for individual calibration of a servo's response to the PWM range.
The reattach method is there to ensure it's possible to re-attach a servo without having to reinitialize it with its specific calibration parameters at each detach/attach.

unless you have an encoder of some sort, you have no way of knowing that
something should change

Like "classical" stepper configuration, it's an open ended loop, a,nd we have no way of knowing that something should change. However, we can send the servo the "exact position" (or rather an approximation of that position) we want it to be at a certain time, and it'll try and do that.

If the servostepper receives a step command, it changes the PWM to reflect the new "target", and the servo will try and reach the corresponding potition, adjusting its effort until its reached that target. Like good old steppers in an open loop (which can skip steps), we have no guarantee the position is reached. But unlike the stepper, we know the servo will keep on trying to reach it ;p

Please not I'm not taking full scale CNC here, nor 3D printer, but "lightweight" machines, with minimal Z axis stress and course length (cf PR text "For example to control a laser cutter/vinyl cutter, drawing machine, foam cutter etc.")

This may be unclear, should I clarify it un the PR text ?

[TheSFReader]

Also, should there be interest, I'll also add pseudo endstops, that check the "command" PWM against the min/max configured PWM so that no "physical endstops" are needed to home correctly (will need to update the 0 position --> PWM mapping though)

[AnHardt]

Besides of the already saied:
Update rate of model servos is limited to ~20ms (50 Hz) (if i remember correct). Updating the servos at step level (up to 20,000 - 40,000Hz) makes limited sense.
Pulsewidth jitter, caused by the other IRQs, will make the servos jitter.
Servo delay will decrease the update rate further and depower a lot of servos. Needs a sanity check.
Linearity is problematic for rotating servos and linear axes.

In the configs we should explicitly talk about RC-, Model-, Toy- servos. Else engineers will expect a completely different technology with position feedback and PID to speed up position changes.

[TheSFReader]

Update rate of model servos is limited to ~20ms (50 Hz) (if i remember correct). Updating the servos at step level (up to 20,000 - 40,000Hz) makes limited sense.

You're right, but adding some kind of delay doesn't make sense either. On the other hand, one could piggyback on an existing ISR/timer and only forward the steps at a lower frequency ? (if pseudo endstops are enabled, one could use the same update calls ?) but that would add some latency/jitter in the case of fast move, wouldn't it ?

Pulsewidth jitter, caused by the other IRQs, will make the servos jitter.

Likewise you're right.

Servo delay will decrease the update rate further and depower a lot of servos.

I'm not sure I understand that one. Since I don't use the "move" function, the servo delay isn't applied. And I'm not waiting for the servo to reach a position anyway since I suppose the step' calls are consistent with the max speed of the servos (Under the load),

Needs a sanity check.

Wrote some, but could use some work...

Linearity is problematic for rotating servos and linear axes.

Absolutely, but again it's in the "designer's" hands, either to correct the linearity, or ensure it's not problematic with his design.

In the configs we should explicitly talk about RC-, Model-, Toy- servos. Else engineers will expect a completely different technology with position feedback and PID to speed up position changes.

You're right, will amend, and align with the comment in the "SERVOS" part of configuration.h, where it's called R/C Servos. Should I also impact the M280 implementation comments and documentation ?

[davidelang]

On Tue, 6 Mar 2018, TheSFReader wrote: > This is (ab)used to control the speed for continuious rotation servos (because the more the PWM differs from the 'center value', the larger the error, and so the faster the motor is driven. But I'm not talking about continuous rotation servos here, but a "classical" one, with its limited <360degrees range

That's even more limiting, and the accuracy is really poor. you have no way of knowing how far they will move for a given PWM signal, unless you make a profile (calibration) for each servo.

[TheSFReader]

@davidelang as I stated above :

There is no real good calibration for now either, but I'll work on that too. initializing min/max PWM frequency, and potentially min/max angle. This should allow for individual calibration of a servo's response to the PWM range.
The reattach method is there to ensure it's possible to re-attach a servo without having to reinitialize it with its specific calibration parameters at each detach/attach.

@thinkyhead @Roxy-3D
Maybe it wasn't clear, but the servo_stepper feature I'm proposing here is not for a "normal" 3D printer setup or even a lightweight CNC, but to use with drawing / laser (though it may lack precison)/ Vinyl cutting/ foam board cutting/sphere-o-bots applications, where Z axis movement length, strength, "linear precision" are not critical factors, but where controlling the "head" height to some degree is important and is best managed by the slicer/CAM software with G0-G1 commands rather than M280

cf . https://www.thingiverse.com/search?q=drawbot https://www.thingiverse.com/search?q=servo+actuator http://forum.flitetest.com/showthread.php?24251-Cutting-foam-sheets-with-a-needle!&p=367379&viewfull=1#post367379 http://www.instructables.com/id/Sphere-o-bot-a-Friendly-Art-Robot/ etc.

• Should I amend the PR/feature descripction ?
• Should I put that in comments in the Configuration files ?
• Does it need more work implementation-wise ?
• Or perhaps the feature simply is too limited, has no place in the Main branches of Marlin and would be better maintained outside of the official marlinFirmware repo ?

I must say, I will dimension the "effort" on being fully "Marlin compliant" (sorry thinkyhead, I forgot to update the example configurations :( ) depending on the answer to that last question : if the feature stays outside of the official repo, I won't be able to maintain fully portable code without official marlin compilation/Continuous Integration infrastructure, so probably won't bother try to be compatible to anything other than the basic RAMPS hardware I own.

[thinkyhead]

…not for a "normal" 3D printer setup or even a lightweight CNC…
Should I amend the PR/feature description…?

Don't sweat it too much. This optional feature won't affect anyone who doesn't specifically want it. My job, as I see it, is to give direction on the proper integration of the proposal, not to judge its ultimate utility. It's not disruptive for Marlin to have a little injection of Maslow as an optional feature. If this was something huge (see: the "hangprinter", for example) then there might be some resistance. But this is really a very modest thing.

Of course, now we know who to call upon when we move on to big industrial servos…

forgot to update the example configurations

Again, no worries. I see that as a "finishing touch" to be done after the feature itself has been fixed up.

[boelle]

@thinkyhead you think this will ever get merged? i was thinking if you could not go through them all and either close or merge (or comment)

[ufficioprogettiperduti]

Are there any updates on this? We are now working on a new marlin pen plotter and this could turn out super useful.

[cryptoAlgorithm]

I would love to see this merged, I'm looking to use a servo for my Z axis, which is similar in mechanism to a plotter. It needs quick and limited up/down movement, perfect to be driven by a servo.

[Mohannakum]

I am plannig to use continues servo for x,y and z axis. For the x axis i connected servo pwm pin to the x axis step signal of the RAMPS 1.4 and power and ground pin, it works well but when send command g0 X10 it rotates in correct direction but then i send g0 x0 it should rotate in other direction but in my case it rotates in same direction. Is that ok ?? I am using servostepper as driver. I am Just beginner to the marlin , so it may be silly question but i need help.