Firmware suggestion: variable microstepping

Current boards (RAMPS, RUMBA etc) seem to have microstepping enabled via dip switches/jumpers on the board. Would it not be better if these were GPIO pins and could therefore be set via firmware? That would allow a firmware to enable microstepping when extruding shells and then disable it when performing fast traverses and maybe on infills if you have a powerful hot-end. Even a simple full-step vs 8x-microstep bit would be a really good start, but wiring up all the pins of course means you can change the step rate in software and maybe have a speed/quality tradeoff in software.

I guess there might be some dependency on the driver chips in terms of their behaviour when the microstep mode changes but my guess is that this could be minimised by only changing modes at whole-step points in the microstep sequence.

Do you think there would be any advantage to not using microstepping? Holding torque is better on full steps than on microsteps, but I'm not sure that torque while moving would be better.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Most people use microstepping to make it quiet!

making it go loud makes no sense.

no one is printing fast enough to actually use this... and it would require that you update your steps/mm every time also...

Also there are some board that have this already, so you could use one of those.. see Rambo

Edited 1 time(s). Last edit at 09/21/2014 05:46AM by Dust.

The advantage is higher speed traversals, especially on stepper drivers and/or firmware where the step rate is limited. For example, those Toshiba drivers can do only 30kHz or something like that, and some of the Arduino-based firmware is limited in its step rate.

Consider the case where people are using screw drives, e.g. 4mm pitch on a 200-step motor would be typical, for a step size of 0.02mm (single) or 0.0025mm (8x micro). At 30kHz and 8x-micro, max traversal is 75mm/sec but if the firmware can switch the microstep mode, then you can do 600mm/sec... assuming you've got enough voltage on the power supply.

your working with theoretical... the real world doesn’t really work that way

With a 3d printer you also need smooth moment, with full stepping every jerk and lurch would be visible in your plastic.

But as I said, some board already have this. the firmware already supports it.

see M350 and M351 codes

Go and have a play.

If the problem is the rate at which the Arduino based firmware can step, then IMO you should ditch the Arduino for something faster. I use the Duet board (with 84MHz ARM processor) and my own fork of the Duet firmware. Having worked with this and seen the benefits of greater processing power, there is no way I would try to use Arduino based firmware now. The benefits of having a web interface to the printer are immense. I am about to modify the move code to compensate for lag in my Bowden extruder and reduce ooze. The calculations required for this are non trivial and need the extra processing power.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It seems most people are happy with 8x microstepping, in terms of precision, speed and noise. I've heard that beyond 32x, you don't necessarily gain any extra precision, because the change in torque between each microstep, individually, isn't always enough to overcome the force of friction (if I understood that correctly), and speed might be limited by the stepper driver and/or controller board. However, when homing, or doing auto-calibration, results will likely be better when using 32x vs 8x. So I can see how one might benefit from 32x microstepping on a homing and calibration routine, while using only 8x everywhere else.

The Duet electronics uses 16x microstepping all the time. There has been some discussion on the Ormerod forum about whether it is beneficial to print with a layer height that corresponds to a whole number of full steps.

Edited 1 time(s). Last edit at 09/22/2014 01:49AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Holding torque is better on full steps than on microsteps

Holding and moving torque is identical, no matter which microstepping you use.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
polyglot
Current boards (RAMPS, RUMBA etc) seem to have microstepping enabled via dip switches/jumpers on the board. Would it not be better if these were GPIO pins and could therefore be set via firmware? That would allow a firmware to enable microstepping when extruding shells and then disable it when performing fast traverses and maybe on infills if you have a powerful hot-end. Even a simple full-step vs 8x-microstep bit would be a really good start, but wiring up all the pins of course means you can change the step rate in software and maybe have a speed/quality tradeoff in software.

I guess there might be some dependency on the driver chips in terms of their behaviour when the microstep mode changes but my guess is that this could be minimised by only changing modes at whole-step points in the microstep sequence.

the problem you'll find is that you'll loose step position when changing between the different micro-stepping rates, there are drivers that do support this kind of use and also offer other features which make things interesting

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

... it's a bit tricky to change microstepping without losses - you have to store the actual position with highest resolution, then move the motor to the next fullstep position, change the resolution, calculate the (fractured or reduced) last position to the nearest microstepping position, then move there ... and, when reducing the resolution, store the deviation from the real position to correct this offset with the next switching to higher resolutions ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
VDX
... it's a bit tricky to change microstepping without losses - you have to store the actual position with highest resolution, then move the motor to the next fullstep position, change the resolution, calculate the (fractured or reduced) last position to the nearest microstepping position, then move there ... and, when reducing the resolution, store the deviation from the real position to correct this offset with the next switching to higher resolutions ...

Spelling it out that way makes it sound much more complicated than it really is.

With decently written firmware, variable microstepping without software-induced losses in precision/accuracy could be coded in < 100 lines of code. I think the issue right now is just how well the stepper drivers can handle variable precision and whether or not the feature is genuinely useful enough to justify the effort & slight increase in required code maintenance/testing.

Drivers should handle microstepping changes well, it's stated in the A4983/A4988 data sheet and some others. 100 lines of code is a lot, though, about as much as what currently makes the whole step interrupt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

100 lines are not 100 lines. The stepper ISR should be well though about lines. In other places 100 lines are faster added then there.

One should also think about moves that involve several Axis and how to manage that there. Should all axes switch resolution, or only some.

Probably best to add these 100 lines before the planner buffer, after decoding the G-Code. There the infomation is available if the move is short, or long, slow or fast,...

Quote
JustAnotherOne
Probably best to add these 100 lines before the planner buffer, after decoding the G-Code. There the infomation is available if the move is short, or long, slow or fast,...

IMHO it doesn't matter wether a move is short or long. Current speed matters, and that changes during each single movement. Taking lookahead into account not always, but one has always to prepare to do movements without lookahead.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
JustAnotherOne
Probably best to add these 100 lines before the planner buffer, after decoding the G-Code. There the information is available if the move is short, or long, slow or fast,...

IMHO it doesn't matter whether a move is short or long. Current speed matters, and that changes during each single movement. Taking lookahead into account not always, but one has always to prepare to do movements without lookahead.

If a move is 15 steps in 1/16 micro stepping then going to full step wont be a good Idea. On a 17 Step move it won't be good either. So in this respect the length of the move matters.

Changing the micro stepping during acceleration is a reason why this is not a 10 line change. Then again longer moves will accelerate to max speed and stay there longer before slowing down at the end of the move. So a first implementation could only switch micro stepping on those constant speed phases of the moves.

Having no lookahead is like planning the last move of the print. It boils down to the max possible speed at the end of the move. With no lookahead or at the end of the print that end speed is 0 (Or whatever your jerk allows).

Switching to full stepping on short moves at low speeds makes no sense or does it?

Then again switching from micro stepping to full steps to gain higher speeds at the same limited max step/second rate of the firmware seems the point here, or am I missing something?

You're way over-complicating it, guys. No need to change gears during a move (let alone during acceleration!) or for very short moves because it's only useful when you want a big fast traversal and don't need as much accuracy during that traversal.

No change to the ISR is required, just to the step planner. The machine dynamics aren't really any different so the lookahead code would probably be unchanged.

Quote
polyglot
You're way over-complicating it, guys.

Do we? Well, looking forward to your implementation, then.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

To be able to change microstep mode without losing position requires the firmware to be aware of the driver state. That requires the reset signal of the driver to be connected to the MCU reset, or a sync pin wired to an input. Do any RepRap boards have this?

Marlin switches to outputting two or four pulses at a time when the step rate gets too high for the isr. That is equivalent to dropping the microstep divisor but doesn't need synchronisation.

Edited 1 time(s). Last edit at 10/05/2014 10:59AM by nophead.

---

[www.hydraraptor.blogspot.com]

Quote
Traumflug

Quote
polyglot
You're way over-complicating it, guys.

Do we? Well, looking forward to your implementation, then.

That's not exactly the most inviting reply - there's no need to scare people away.

Quote
polyglot
No change to the ISR is required, just to the step planner. The machine dynamics aren't really any different so the lookahead code would probably be unchanged.

I should profile some firmwares. I was under the impression that cpu usage (in the planner) was limiting fast, low precision movements in your scenario. If not, then I can't think of any reason to not just use 32x or at least 16x microstepping everywhere. A4988 stepper drivers can handle up to 500000 usteps/sec (theoretical), and I believe most firmwares out there are capable of 60k+ per axis. Even at 200 full steps/rev & 32x microstepping, that gives you 9.5 revs/sec maximum for each stepper, which I believe is enough for the majority of printers (not sure if NEMA17s can even physically reach that speed).

Nophead raises an interesting point though. Dynamic microstepping only works with dual H-bridge drivers that your microcontroller drives directly, where you always know which microstep you're at, as opposed to the step/dir drivers... Or perhaps driver chips always start at a whole-step when they're initially given power? I'm inclined to believe that they do, because when you power on a stepper motor in whole-step mode, documentation indicates that current is only sent into 1 coil at a time (meaning you're exactly at a whole step multiple, not somewhere in-between). And I believe toggling the enable pin, which is done for M17/M18, just cuts power to the motor coils - it shouldn't affect the driver's internal microstep index, which means it will be at the same microstep as you last commanded it to go to once you re-enable it. So one should be able to track driver position entirely in software.

Quote
nophead
Marlin switches to outputting two or four pulses at a time when the step rate gets too high for the isr.

Well gee, that sounds exactly like what the OP is asking for.

Just to scare you away, too, A4983 and A4988 have a reset pin which sets them back to to a full step. Damn. There is no excuse to not implement it.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

The multi-pulse solution present in Marlin is perfectly good if the stepper driver supports high microstep rates. And given that the A49xx both do, I guess there's probably not a lot of call for it from reprappers.

I'm more used to older, larger drivers like the Toshiba that are limited to 30kHz and for which the multi-pulse technique likely won't work.

@wallacoloo Do you have experience in programming for the Atmel AVR? I would really like to know how you will do "profile some firmwares" It would be really good if you could provide the information how to do that.

If you do not have experience with 8bit Controllers then I have a surprise for you. Profiling for performance is everyday business on PC applications. But it is hard or even impossible for embedded Firmware.

And just to defend Traumflug a bit: Nobody here gets paid here. So if you want us to do something: bad luck. If you want to do something then we might be willing to help, because we are nice guys. And scaring away the fools that don't understand the implications of not getting payed is actually a good thing.

@polyglot: I would not call the Marlin Stepper ISR a "perfectly good" solution. It is more a bad work around. It is not only important to do the right number of steps on the right stepper motors. The timing of the steps should also be right. And I personally like ISR's to be short, very short. A perfect ISR would be one where you can count the assembler instructions with your fingers. But perfect is undoable most of the times.

Teacup firmware has procedures in place to allow easy profiling: [reprap.org] It works so well I now use it on almost any code change where performance critical code is just touched.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY