Feedrate M600

[maukcc]

Is there an option to set the feedrate for X,Y and Z in change filament? I used to set it by changing the fr60 value, but it gets its value from somewhere else in the RCbugfix. It is now getting the value from the feedrate it is printing with at the time the buffer is cleared.

[Roxy-3D]

I ran into this issue a few weeks ago. I agree it is not doing the 'right' thing. But in my case it was the feed rate for the filament retraction that was wrong.

I'm not sure this is the right thing to do. But it would be better (than what it is currently doing) to save the current feed rates, and use the default feed rates for the duration of the command. And then when leaving the M600 command, restore the feed rates back to what they were.

I don't think we want the extra complexity of allowing each axis to have its feed rate set. And in fact, that doesn't really help the problem because until you tell an axis to move, you won't know the feed rate is wrong and at that point it is too late.

@maukcc would just using the default feed rates avoid an issue for you?

[maukcc]

I used to set the fr60 to 150 and that gave good results. But this is now only done for the delta bots for some reason. I can live with default feed rates. What is considered default feed rates? HOMING_FEEDRATE or MANUAL_FEEDRATE or something else? Is the extruder effected by this also?

[Roxy-3D]

We better get some other opinions on what to do. But "Yes!" the extruder is affected by this also. I didn't really care that it took the Z-Axis a long time to move up out of the way. It was the fact the extruder could not unwind the filament that was a problem for me.

HOMING_FEEDRATE won't work for the extruder because that is typically set at zero. I'm not entirely comfortable with using the DEFAULT_MAX_FEEDRATE either. But DEFAULT_MAX_FEEDRATE should be a 'safe' number.

#define HOMING_FEEDRATE {50*60, 50*60, 50, 0} 
#define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec

I think we better get some other people's thinking on the subject before we make the change.

[thinkyhead]

Something physically safe, such as 2mm per second. I'm sure there's a range considered "generally safe". Some of the PRs related to this feature may actually have this covered by adding settings for the M600 move rates. Take a look at #3662 and #3605.

[maukcc]

2mm/sec is very unsafe as I will get very aggravated :) I think 1/2 max feedrate will be a good value. Setting it with a define(and afterward go back to original value) will be better. Preferably X,Y a value and Z a separate value(E is already separate), as I still do not like slicers seeing a Z movement as travel and try to do that at ridiculous speeds (if your machine motors/drivers/firmware have not been setup properly that means lost steps).

[Roxy-3D]

I could live with 1/2 of Max Feedrate. Should we consider putting an E number in that set of numbers? If we did that, we would have all the numbers to control the M600 behavior.

[petrzjunior]

As an co-author of #3662 it must say (again and again), that this function (in RCBugbFix) is not working. I not only omits various settings, but also retracts the wrong direction. So we started that rewrite. Go ahead and check. If you want to try it out (highly recommended, since we're looking for testers) check thinkyhead's branch in #3662. We use values defined in Configuration_adv.h. Current M600 uses parameters of that M-code. Might be also good idea to include in further version of this function.

[thinkyhead]

@maukcc As suggested, take a look at #3662 and #3605. The current M600 is a dead horse.

[Roxy-3D]

The current M600 is a dead horse.

Why do you say M600 is a dead horse? I use it all the time on my i3 without an LCD Panel! I hope we are not abandoning it!

[thinkyhead]

Why do you say M600 is a dead horse?

Because #3662 replaces/augments/supplants/enhances it.

[Roxy-3D]

This will work without an LCD Panel, right?

[petrzjunior]

This will work without an LCD Panel, right?

No, it is waiting for user response, to insert filament. Have no idea how to do it without LCD.

[Roxy-3D]

Two comments:

• Let's not pull the current M600 until we have a fully functional alternative. A lot of people are using M600 to make multi-color prints on a single extruder machine.
• To support the confirmation that the user is ready to continue, you can look at one of the end stops getting pressed and not just look for lcd_clicked() to be triggered. Seeing an end stop get pressed is easy. The only extra thing is you should call: endstops.hit_on_purpose(); after the end stop gets pressed to tell Marlin that what happened was OK. If you do this, somebody without an LCD Panel can use the feature too! Please consider adding this!

Thanks!

[petrzjunior]

you can look at one of the end stops getting pressed

:laughing: Oh, what a clever workaround, I would never thought of it.

Let's not pull the current M600

I don't say it's working, it is working for me and is waiting for someone to test it. But the matter of merging is the work of others.

Please consider adding this!

OK, now I am working on some improvements, but nobody says it's only me working on it. If you got certain idea on how to do it, improve my commit. After all, you're much more Marlin than I am...

[jbrazio]

Just one remark, if the FEEDRATE the OP refers to is the global FEEDRATE multiplier (the same one we find on the LCD as a percentage) then ALL feedrates should be adjusted by it with no exclusions.

[thinkyhead]

This will work without an LCD Panel, right?

Only if it is broken up into separate steps so that the host can control the process. For example:

• M600 S1 - Retract, lift Z, move XY, eject filament
• M600 S2 - Insert filament
• M600 S3 - Move back and resume print

The current implementation of M600 requires an LCD controller.

[petrzjunior]

But then, I could be series of G-codes (heat, wait, extrude, etc.). I think, that M600 is mainly because of the comfort of one click on the LCD.

[Roxy-3D]

Right now people edit their GCode to do a M600 at the right layer height. They just stick a M600 or sometimes M600 Z50 (to raise the nozzle some extra amount) at the right place.

If they have to insert 3 lines (as shown by ThinkyHead) that is not a big deal.

[thinkyhead]

Well the idea is that if you lack an LCD controller, you would have to issue M600 S1 first, to get the initial ejection. The machine would have to go into "filament change mode," so that if you're printing from SD it will keep the print paused. If printing from host, the user would have to manually pause and resume the print there. (Although presumably a host can fully control filament change without M600.)

You would then issue M600 S2 to pull in the filament, and finally M600 S3 to exit "filament change mode" and resume normal operation. You would never have this in GCode:

M600 S1
M600 S2
M600 S3

…but if you lack an LCD controller, a normal M600 would have to act like M600 S1 since it has no way to get user feedback.

The tricky thing is that we need to be able to pause the machine (SD printing, at least), and while paused the machine needs to be able to receive and process commands. Hosts need to know if the machine is paused (a place where "keepalive" messages can help). I'm not sure if this can be done with what is in place currently.

[Roxy-3D]

…but if you lack an LCD controller, a normal M600 would have to act like M600 S1 since it has no way to get user feedback.

We can get user feedback via an end stop switch. We should be able to click through all three phases of the command.

[thinkyhead]

I'm not fond the hack of re-purposing endstop switches for user feedback. That should never be a standard feature or behavior.

[maukcc]

The way I see this, is that this is all "things to do while the machine is paused".

1 give a pause command and tool/extruder goes to a defined position(out of the way or stay in place) 2 give the user the option to do something(change filament, change extruder, do something else, do nothing,...) (how these options are handled through host is another thing) 3 when change filament is chosen the tool/extruder comes front and centre and you go through the routine 4 when finished "doing something" (see 2) you have to press resume(like is done now for pause) (and not hold a magnet to an endstop or whatever)

[thinkyhead]

you have to press resume

Part of the topic is how to manage that without an LCD controller, and possibly during times when serial commands may not be incoming. M600 (as an automated function) presents an interesting challenge.

[maukcc]

when finished "doing something" (see 2) you have to press resume(like is done now for pause)

Either on LCD or host. Can you combine this? Do host and LCD know when 1 of them has paused? So can you pause on LCD and resume on host, or visa versa. So when paused(and only when paused) you can give the M600, and then something else, and then some more elses, and finally a resume print. As long as your coordinates do not get mangled this should work, right??? :)

[thinkyhead]

Well the thing is, M600 (like G29, M48, and others) is a "blocking" command. So no commands can be processed from any source until the gcode_M600 function exits.

Meanwhile, Marlin is not "modal." There is no "pause mode" in Marlin. You can pause the SD card sending commands to Marlin, but Marlin is not literally "paused" by this. Marlin can announce that it's "waiting for user" while a command is blocking. But the host has no way of providing a "faux click" or user input to Marlin at that point because, again, serial commands are blocked.

So to support user interaction without an LCD (thus, from the host) we would really need to re-work how Marlin manages a command that is blocking, such that it can keep processing incoming commands, but (for example) ignore or reject all commands from the host that aren't a "resume", "user click", or "user input" commands of some kind. (We have discussed this at length quite a bit, with somewhat pessimistic conclusions.)

Generally speaking, the best way for a host to handle a filament change is to avoid sending Marlin any M600 commands and handle all the interaction and movement for the filament change itself, maintaining its own "pause" state by not sending further commands to Marlin until the filament change procedure is done.

[Roxy-3D]

So when paused(and only when paused) you can give the M600, and then something else, and then some more elses, and finally a resume print.

A lot of people need precise control over the height when they switch filament (to do a color change). So they edit a M600 command into the GCode at the right place. The problem is, once you are in the M600 code... Nothing else happens until the M600 code is told by the user that it is OK to continue (and start processing more GCode commands).

[petrzjunior]

@Roxy-3DPrintBoard Could I ask you for little hint, how your M600 is working without LCD? I think, @thinkyhead is right. It is designed to change filament with very easy command from LCD. If you use computer to contol it, you have the option to make your own G-code macro (set of codes, the software will send), so I see no benefit in using this Marlin function. It depends on LCD and is blocking.

[clexpert]

In this century, is there anyone who uses RepRap 3D printer without LCD? Really???

[Roxy-3D]

@Roxy-3DPrintBoard Could I ask you for little hint, how your M600 is working without LCD?

What I did was wire up an extra switch (and printed a bracket to hold it). So I have a small LCD_clicked() function that just looks at that pin for the switch to be pressed. Here are a couple of threads published over at 3D-Print-Board about it. Users are doing that:

http://3dprintboard.com/showthread.php?3023-Filament-Change-Command-for-Non-Ultipanel-Users

http://3dprintboard.com/showthread.php?8191-Doing-Filament-Change-Command-(M600)-using-limit-switches

I wired up an extra switch originally just because I was trying to figure out how to identify GPIO pins (because of the confusion Fast-IO causes in the numbering). So I had a switch already connected. In hindsight, it would have been simpler to make the changes to indicate user confirmation by using an end switch.

(I realize it is a bit of kludge. But people are using it and it was done in the spirit of RepRap where everybody gets to modify their printer to do the things they want it to do.)

Maybe we should change the confirmation to call some thing like User_Confirmation_to_Continue() and if a user has an LCD Panel it defaults to LCD_clicked(). But we let the user decide what mechanism they want to use for confirmation?

[Roxy-3D]

In this century, is there anyone who uses RepRap 3D printer without LCD? Really???

My first printer does not have one and I have no intention of adding one. I'm very sentimental about that printer. I'm going to keep it running as long as I can.

And actually... On a related topic... You probably know I'm getting close on my Unified Bed Leveling code. I'm doing extra work to make sure people without LCD Panels can use the Mesh Editor just because I want everybody to benefit. An LCD Panel will be the easiest way to edit the Mesh. But just using PronterFace to do it is fully thought out.

Really, this topic isn't as important to me as all this text would lead you to believe. I can certainly patch what ever code I need into the Golden release. Mostly, I'm trying to raise awareness that in general, we should try to fully replace old functionality as we clean up the code and add new functionality. Some times we do need to throw old, clunky code over board to make room for the new code. I just want those decisions to be made with careful thought.

[petrzjunior]

Oh, pretty nice story. :smile: I wonder if there is anyone else, who has no LCD, but wants to do M600 so solderes a switch....

[clexpert]

Just one remark, if the FEEDRATE the OP refers to is the global FEEDRATE multiplier (the same one we find on the LCD as a percentage) then ALL feedrates should be adjusted by it with no exclusions.

That is a stupid idea for M600 filament change function. The user will be set 200% feedrate for bad created g-code (too slow so speeds up). And automatic filament change function (filament runout sensor for example) will cause problem when use 200% speed. M600 filament change function uses firmware configured values - printer constructor or manufacturer knows which speed values are the best for good process of filament change. Speed feedrate is absolutely useless in this function.

[petrzjunior]

@Roxy-3DPrintBoard Btw. speaking of filament change without LCD: Me with @clexpert are working on harmonization of Filament Change, Load and Unload, so if there were g-codes for that unload and load, you could easily do the same without LCD, just with codes: Unload > -manually change- > Load

[Roxy-3D]

are working on harmonization of Filament Change, Load and Unload, so if there were g-codes for that unload and load, you could easily do the same without LCD, just with codes: Unload > -manually change- > Load

And maybe we could add a parameter to one of those commands to specify what type of user confirmation is necessary to continue? By default, lcd_clicked() makes sense for most people. But it would be nice to accept a continue generated by PronterFace (or Gaaasppp!!!! an endstop!!!!)

Mostly, I'm just asking that we try to make new code be flexible.

[Blue-Marlin]

How about seeing M108 as a universal 'break waiting' command? Breaking the waiting for M109, M190, M303 and waiting for user input. (For example in M0/M1 or M600)

How about a 'one button panel' defined like the other panels, where you can define the pin to trigger the 'click' ?

[Roxy-3D]

It wouldn't take any arm twisting to get me to agree!

How about seeing M108 as a universal 'break' command?

But I have a question. I think you are suggesting M108 would just wait for the user to confirm it is OK to continue. (Usually via an LCD Panel click) Is that correct? Mean while, it would keep all the heaters stable while it waits.

Breaking the waiting for M109, M190, M303 and waiting for user input.

I think you are suggesting we add a small amount of code to allow these commands to abort the wait and to let things continue. Right?

[Blue-Marlin]

I hope if you all are convinced to want to have M600 with host interaction before Marlin x.y.z @AnHardt will modify an publish a PR for MarlinFirmware based on https://github.com/AnHardt/Marlin/tree/miniparser-in-MarlinSerial. (https://github.com/AnHardt/Marlin/pull/40. See also related discussions about M108) Than only the hosts have to send this commands regardless of, if they think the buffers are full or not. Marlin would be prepared. Up to now he is quite sure this is not suitable for a RC.

[thinkyhead]

you could easily do the same without LCD, just with codes: Unload > -manually change- > Load How about seeing M108 as a universal 'break waiting' command?

Currently, when a command is blocking, no commands can be received via serial. Marlin has no "pause mode." It just sits in a tight loop inside the command handler calling idle().

[Roxy-3D]

Currently, when a command is blocking, no commands can be received via serial.

Yes. But we can change the rules. I would vote against this idea. I bet this group of people can find a more elegant solution. We need to think outside the box. It might be possible for PronterFace to drop CTS and/or RTS and this can be watched by the firmware. (After all... It is supposed to be a Serial Interface. Are the rest of the control signals there???) All we need is a flag to tell us it is OK to continue. It doesn't have to be complicated. We just need a flag to say: Continue!

[thinkyhead]

But we can change the rules.

It would seem to open a can of worms, with hard-to-predict implications for the command buffer and for hosts.

[Roxy-3D]

I did say "I would vote against it!" I'm just suggesting that we have a lot of top shelf minds here. If we all think outside the box, there may be an elegant solution.

[thinkyhead]

there may be an elegant solution

Being lazy, I suggest waiting for other firmware projects to work it out, then "steal" all their best ideas.

[Blue-Marlin]

@thinkyhead You have not to wait. Have a look into grbl. They successfully parse one byte codes in the rx-interrupt since ages. Because of comments and M117 we need a bit longer strings. (https://github.com/grbl/grbl/blob/master/grbl/serial.c#L159-L191)

[Roxy-3D]

You have not to wait. Have a look into grbl. They successfully parse one byte codes in the rx-interrupt since ages. Because of comments and M117 we need a bit longer strings.

We would also need support from the host programs. They will have to allow the user to jump ahead of all the GCode that the host program has queued up and is trying to send to the printer. Obviously, the user's command is more important and needs to happen first.

I wonder if the host programs would work with us on that?

[thinkyhead]

As long as it maintains backward-compatibility. Then we don't have to bump the protocol version to 2.0.

[Roxy-3D]

I guess my point is it would not be backward compatible. The host program would need to know how to send these magic 1 byte commands and that they are more important than any GCode lines it has already read from the file and is in the process of sending. These magic 1 byte commands have to moved ahead of anything the host is ready (and waiting) to send. And of course, on our side, we have to do the same thing. We have to detect and take action on these magic 1 byte commands immediately instead of wait for them to bubble up to the top of the list.

[thinkyhead]

"Backward compatible" simply means that with the new code, you could use older hosts that don't know about any of the new stuff and Marlin would function the same as always.

[Roxy-3D]

OK. I agree.

[jbrazio]

@thinkyhead @Roxy-3D what is the outcome of this issue, can we close it or do we still need to act ?

[thinkyhead]

…can we close it…

The issue of setting feed rates for M600 is much improved. We now have…

FILAMENT_CHANGE_XY_FEEDRATE
FILAMENT_CHANGE_Z_FEEDRATE
FILAMENT_CHANGE_RETRACT_FEEDRATE
FILAMENT_CHANGE_UNLOAD_FEEDRATE
FILAMENT_CHANGE_LOAD_FEEDRATE
FILAMENT_CHANGE_EXTRUDE_FEEDRATE

I'd say this closes the issue.