Discussion of new M600 Change Filament command in Marlin firmware

This is a continuance of a discussion regarding the M600 Change Filament command which was recently added to the Marlin firmware. I have move the discussion here so that it has wider visibility.

Details of change: [github.com] ... 872588ad4b

Quote

Added a feature to have filament change by gcode or display trigger.
[default off for now]
syntax: M600 X[pos] Y[pos] Z[relative lift] E[initial retract] L[later retract distance for removal]

if enabled, after a M600, the printer will retract by E, lift by Z, move to XY, retract even more filament.
Oh, and it will display "remove filament" and beep like crazy.

You are then supposed to insert a new filament (other color, e.g.) and click the display to continue.
After having the nozzle cleaned manually, aided by the disabled e-steppers.
After clicking, the printer will then go back the whole shebang, and continue printing with a fancy new color.

Hi Bernhard,

I had a look at the link you posted in your comment here: [github.com]

My problems with the command as it is currently implemented:
a) it has been designed to only work with LCD based panel printers. If we are designing and adding new features as important as this then they should be generally usable - or at least it should be clear how it would be used without LCD displays. I.e., consideration for use without an LCD is given during feature design (even if its only implemented for LCD initially).
b) the command is restricted to only doing a forward extrude which is equal to the final retraction, this makes use of the command seemingly a bit clunky (as far as I can currently see), you will likely need to do a much longer retraction simply to ensure that your forward extrude flushes out previous filament. Why not set the forward extrude length explicitly?
c) the command seems likely to ooze filament on the print because it doesn't do a small retraction before moving back into position.
d) doesn't consider multiple extruder issues (where you want to change over the filament on one the extruders but keep the filament fresh in the other)

I suggested having a variable forward extrusion amount would make this command easier to use because you don't need to work-out through trial and error how much you need to extrude to flush out all the older filament.

You said 'Please not, this can also be abused as a "pause" function, e.g. for emergency nozzle cleaning, ...'. Can you please expand on your thinking here? Why should we intentionally implement the change filament command in a less useful manner (imo) just to prevent people from doing this (or am I misunderstanding you)?

Edited 2 time(s). Last edit at 01/27/2013 10:06PM by buildrob.

Consider that this functionality could more generally be implemented through adding the following commands:
- save position command (saves xyze position)
- restore position command (moves back to saved position)
- wait for button press while sounding beeper command

Then all other functionality can be (more flexibly) driven through insertion of standard Gcodes rather than a specific 5+ argument command.
I think smaller general-purpose commands should be preferred over complex single purpose commands (where possible and appropriate).
This approach would also solve the problem of trying to do this from a host program, i.e., kill two birds with one stone.

The more I think about it, the more I think this is the approach that should be used.

For instance, it also means that if you need to do something with the second extruder during the change-over, then this printer-specific knowledge is not required to be hardcoded in the firmware command. [For instance if the change-over delay is more than a certain period you may need to extrude and retract on the second extruder before moving back into position (this may not needed but I'm just thinking of some of the issues which might arise). At the very least you probably don't want to disable the other extruder stepper as you haven't retracted the filament in it. So as you can see you don't want to hardcode this complexity in firmware.]

Coding the commands this way would also give the ability to resume printing later pretty much for free (i.e., instead of just changing filament you could turn off the hot ends and motors). So now one general purpose set of commands have given you lots of functionality (for printing from an SD card you would need to optionally save and restore the line number as well).

For instance:
M600 [S1] - save X, Y, Z & all extruder position, M82/M83 state, G90/91 state & Line number to EEPROM. If S1 is specfied and supported then all system state is stored to allow for full shutdown and resume.
M601 [X1] [Y1] [Z1] [L1] [P1] [S1] - selectively restore X, Y, Z position or Line number, print state (i.e., extruder position, M82/M83 state, G90/91 state) or other system state from EEPROM (and then clear settings in EEPROM)

To ensure that Z is restored before X and Y then issue two M601 commands: e.g., M601 Z1; M601 X1 Y1 E1
(if the change-over was done in the middle of a layer then you probably want to restore X and Y first and then Z - assuming you have raised the head beforehand).

So your current M600 complex command would be achieved by the Host or Slicer plugin. For instance

M600 X1 Y1 Z1 E1; Save XYZ and extruder positions (only needed if using absolute E positions)
M82 ; Set E relative mode
G1 E-2; Retract slightly
G91; Use relative coordinates
G1 Z1; Raise head slightly
G90; Use absolute coordinates again
G1 X0 Y0; Move to dump position
G1 E-50; Retract 50mm
M603 E0; Turn off extruder T0 motor (new command)
M602 S1.0 D"Change Filament"; Beep buzzer at 1 Hz rate, display message and wait for LCD button to be pressed (new command)
M604 E0; Turn on extruder T0 (new command)
G1 E80; Extrude 80mm to flush old filament
G1 E-2; Retract a little
M601 X1 Y1; Restore X & Y position
G1 E2; Extrude a little again.
M601 Z1 P1; Lastly restore Z position and print state (i.e., extruder positions and all abs/rel coordinate modes). If printing from SD card you would also restore line number.

Again this is preferable because it is under full control of the Host or Slic3r. For instance if you have dual extruders you may not want to disable steppers as you need to keep extruding filament slowly from the other extruder (and then retract slightly before moving back into position so as not to trail filament).

Saving to EEPROM also reduces the RAM requirements of the feature (I think the 100000 EEPROM write cycle is high enough not to worry about wearing it out after each filament change). Daid has said previously that we need to be serious about reducing RAM requirements. It would also allow you to turn of the printer and resume at some later time for free.

Edited 10 time(s). Last edit at 01/28/2013 06:52AM by buildrob.

TLDR but from the first sentence you say it should work without the LCD. But if you do not use an LCD then you are using a host program that allows you to pause, retract, extrude and move around the axis so you should not need this function. It is there because you can NOT pause and manually do these things from the LCD easily.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

buildrob Wrote:
-------------------------------------------------------

> a) it has been designed to only work with LCD
> based panel printers. If we are designing and
> adding new features as important as this then they
> should be generally usable - or at least it should
> be clear how it would be used without LCD
> displays. I.e., consideration for use without an
> LCD is given during feature design (even if its
> only implemented for LCD initially).
I have no way of sending a "click" from a host software to the printer, without heavy invasion and touching the many different host implementations. My first approach was to send another M600 as a click, its impossible. The second approach was to send a special character. Well, not very nice either.
That is also why there is no nonLCD M0 implementation in Marlin nor Sprinter nor any other reprap firmware i know.
I see no problem of having this at least work with the LCDs, since there are already many things that you can only do with the LCD interface I initially created. A new feature needs some basis, so it can either die unused or develop. Its not necessary to solve all the problems at once.
From my point of view there is absolutely no reason for a printer not to have a lcd+encoder. Its cheap, its superuseful. The last time I printed using a cable was 18 months ago. Even laser 2d printers have an LCD interface, to tell you to feed new paper. Its something people are expecting when having a 3d printer.


> b) the command is restricted to only doing a
> forward extrude which is equal to the final
> retraction, this makes use of the command
> seemingly a bit clunky (as far as I can currently
> see), you will likely need to do a much longer
> retraction simply to ensure that your forward
> extrude flushes out previous filament. Why not set
> the forward extrude length explicitly?
There are two extrudes. One is done instantly, and could equal the retraction length on normal printing. I could have made this depend on the prime/deprime nozzle i coded months ago, and decided against, since its hardly used. This is for avoiding oozing.
Then there is a long one, to eject the filament.
After manual insertation, the user will clean the nozzle and extrude manually. However, there will be a second between the priming and the end of the first re-positional move.
Hence I initially thought its good to prime the nozzle again, using the oozing retraction length specified by user.

> c) the command seems likely to ooze filament on
> the print because it doesn't do a small retraction
> before moving back into position.
that could be added. maybe thats a useful idea. However, I think its better to start with the new filament with too much extrusion than too little. Probably the prints surface has cooled a lot, and sticking is even worse if underextruding.
> d) doesn't consider multiple extruder issues
> (where you want to change over the filament on one
> the extruders but keep the filament fresh in the
> other)
no it does not address multiple extruders currently. it could be possible to only disable the current extruder. Not sure what would be a good move there, my dual setup is still not working. Do you need to have an additional retract on the other extruders or not? Does one want to change the filament of a different than the currently used extruder? I don't know.

> I suggested having a variable forward extrusion
> amount would make this command easier to use
> because you don't need to work-out through trial
> and error how much you need to extrude to flush
> out all the older filament.
>
well, lets do some more thinking first, because to implement your wanted retract before return, two more values are needed, if you don't want to omit the additional length after retraction that is often offered from slicers.

> You said 'Please not, this can also be abused as a
> "pause" function, e.g. for emergency nozzle
> cleaning, ...'. Can you please expand on your
> thinking here? Why should we intentionally
> implement the change filament command in a less
> useful manner (imo) just to prevent people from
> doing this (or am I misunderstanding you)?

its very likely you misunderstood me here. It _is_ useful as a emergency pause, better than a pause sd print, because there will be less visible marks on the print. But its not the primary purpose, hence I wrote abuse.

buildrob Wrote:
-------------------------------------------------------

>
> For instance, it also means that if you need to do
> something with the second extruder during the
> change-over, then this printer-specific knowledge
> is not required to be hardcoded in the firmware
> command.
>
I disagree. Gcode should be absolutely printer independent, which is hindered by the current microcontrollers limit. The interpretation and hence the firmware should be printer dependent. The firmware is for a special printer, the gcode is generic. Also with the idea to have printer internal settings tuneable interactively.

bkubicek Wrote:
> I have no way of sending a "click" from a host
> software to the printer, without heavy invasion
> and touching the many different host
> implementations. My first approach was to send
> another M600 as a click, its impossible. The
> second approach was to send a special character.
> Well, not very nice either.

I agree it's messy - which is why I think splitting out the specific "wait for click" as an separate command is the right way to go (as I suggested in my alternative). Then the host can intercept this and perform the "wait for input" locally before sending the next command if it supports this (independently of other functionality).

> I see no problem of having this at least work with
> the LCDs, since there are already many things that
> you can only do with the LCD interface I initially
> created. A new feature needs some basis, so it can
> either die unused or develop. Its not necessary to
> solve all the problems at once.

The problem is that you are establishing a precedent with the Mcode usage which is LCD specific. It can be difficult to change this later because you then break older implementations. Because you can't change it then the firmware begins to collect arcane commands. For instance, if you want to use the LCD to it then you have to use one command, but if you want to implement the feature on a LCD-less printer then you have to do it another way.

This is way generic simpler commands are preferable.

> From my point of view there is absolutely no
> reason for a printer not to have a lcd+encoder.
> Its cheap, its superuseful. The last time I
> printed using a cable was 18 months ago. Even
> laser 2d printers have an LCD interface, to tell
> you to feed new paper. Its something people are
> expecting when having a 3d printer.

That might be your opinion but I am guessing there are still a lot more printers out there without LCD than with. Also I see quite a number of people are now attaching Raspberry Pis to their printers rather than LCDs so that they can drive there printers through a web server or thin server (e.g., the new Repetier-Server for Raspberry Pi) so that they can check their printer from their phone, etc. Or people just have a spare laptop next to their machine and so don't feel the need for a LCD.

> > I suggested having a variable forward extrusion
> > amount would make this command easier to use
> > because you don't need to work-out through
> trial
> > and error how much you need to extrude to flush
> > out all the older filament.
> >
> well, lets do some more thinking first, because to
> implement your wanted retract before return, two
> more values are needed, if you don't want to omit
> the additional length after retraction that is
> often offered from slicers.

I'm now think that this functionality should implemented using the save and restore commands suggestion. These are generic commands which can be used to on both LCD and LCD-less systems for changing over filament. For planned changes of filament which are inserted as a post slicing step. Or for unplanned changes of filament due to end of reel. Or for unplanned stoppages to turn off the printer and resume later. With flexibility to handle dual extruders in whatever way is deemed desirable by the slicer profile. It also can work for SD card prints.

Doesn't solving all these problems and environments sound like a better idea than the rather limited/fixed single command, single purpose proposal?

> > You said 'Please not, this can also be abused as
> a
> > "pause" function, e.g. for emergency nozzle
> > cleaning, ...'. Can you please expand on your
> > thinking here? Why should we intentionally
> > implement the change filament command in a less
> > useful manner (imo) just to prevent people from
> > doing this (or am I misunderstanding you)?
>
> its very likely you misunderstood me here. It _is_
> useful as a emergency pause, better than a pause
> sd print, because there will be less visible marks
> on the print. But its not the primary purpose,
> hence I wrote abuse.

Agreed. Sorry.

> > For instance, it also means that if you need to do
> > something with the second extruder during the
> > change-over, then this printer-specific knowledge
> > is not required to be hardcoded in the firmware
> > command.
> >
> I disagree. Gcode should be absolutely printer
> independent, which is hindered by the current
> microcontrollers limit. The interpretation and
> hence the firmware should be printer dependent.
> The firmware is for a special printer, the gcode
> is generic. Also with the idea to have printer
> internal settings tuneable interactively.

I agree - the Gcode should be printer independent but its what you want the system to do at a higher level is what exceeds to complexity of the firmware to always know what is best (even firmware tailored for a particular printer). For instance, that's why we have different print profiles in the Slicer programs - you can't hardcode every situation in firmware (e.g., even on a dual extruder machine sometimes you might be using both extruders, sometimes not). Leave the control to those upper layers. Firmware should have simple generic commands where possible.

Edited 2 time(s). Last edit at 01/28/2013 06:24AM by buildrob.

I was thinking more about this overnight.

Its seems that a good middle ground is that the instead of the combined M600 command is to split it into a "park printhead" command (using all the parameters you specified expect final retract) and then a "unpark printhead" command. This way the printer can do a lot of the hardwork and you can avoid the complexity of co-ordinate modes, extruder temps and everything else.

So you could have

M600 X[pos] Y[pos] Z[relative lift] E[initial retract] --- Park head saving state then doing initial retract on current extruder, lifting by Z and moving to XY. The command saves the current XYZ position, all absolute extruder positions, all abs/rel co-ordinate modes, current tool number and current line number.

M601 E[initial extrude] [L1] -- Unpark head. Checks current Z is >= saved Z. Restores XY position, restores Z position, restores saved tool number, extrudes specified initial amount on that extruder, restores any extruder absolute positions, restores XYZ abs/relative mode, extruder abs/relative mode (intentionally it doesn't restore extruder temperature). If L1 is specified then it also restores saved line number (useful for resuming SD card printing).

For your Cura plugin application you would also need the following command which should both be easy to write and generally useful beyond this application:

M602 S[0 or 1] -- Turn current extruder motor on or off. {Important for dual extruders as you don't necessarily want to turn off the other non-retracted extruders}
M603 S[beeper interval in ms] [Dtext] -- Display text, sound beeper and wait for LCD button press. Return status text to previous state after button is pressed.


This lays the groundwork for a lot of flexibility in what you do while the head is parked and in how the interaction with the user occurs.
Thoughts? I'm happy to help you code this up if you like.

Edited 5 time(s). Last edit at 01/29/2013 01:42AM by buildrob.

Hi Bernhard,

Do you have any objections in principle to this change? I'm happy to propose a pull request.

Other short comings of currently implemented M600 command is that you can't change temperature when changing filaments. Even when changing within the same brand of filament, the different colorant properties mean you often have to use a slightly different temperature.

Another application I was thinking of for this feature is to automate temperature calibration for a new filament type. Here you would print a calibration print and every so many layers the Gcode would park the head, change the extruder temperature and continue. You can then choose the temperature for the best printed band for your new slicer profile. So this is an example where even if you could change the temperature you don't want to have to press the lcd button to continue each time.

I hope this emphasizes the need for simple, general-purpose primitive commands.

If you are interested I created a change to improve the M600 command along the lines I've been proposing. Have a look and let me know what you think: (I'm actually really happy with it - I've been using it from my host as well by binding to the custom command buttons. Also still works like the old one did on the LCD menu. I think its going to be a really popular feature.)

[github.com]

LCD screens aren't that expensive. I bought the RepRap discount full graphic. Here is a link.

[www.ebay.com]

So I have tried this and it does not work for me. What I am trying to do is at layer change move the extruder to 20mm above the current print. Issue an M0 command to pause it at that point. Then replace filament. tell the machine to resume, Issue a G1 E100 F125 to purge the barrell of previous color in the code and due to the layer change have the printer resume at the location it should have if I had not interrupted it. The problem is when I do this the printer wants to retract a large amount of filament when it gets to the previous location. So much so that it ejects it from the extruder barell all together. The printer does not do this if I perform everything as stated above but leave out the G1 E100 F125 command. Why is it behaving differently in the two instances. I have tried turning off and on every retraction setting I have available but to no avail and some cause further glitches when I do this. I am using a Geeetech I3 with I believe Marlin.