Feature Request: Support for standard Marlin accelerations/M204

[hexane360]

Version

commit 78a8acf

Operating system type + version

Ubuntu MATE 18.04

Behavior

The recent acceleration and print estimate additions currently rely on a legacy form of M204 and accelerations in general. Vanilla Marlin (1.1.x and 2.0.x) has used a command of the form M204 P[print] R[retract] S[travel] since March 2015, while Slic3r outputs and processes using the old form, M204 S[print] T[retract].

This problem can't be ignored because Slic3r inserts a mandatory M204 at the beginning of each gcode export. This means that Slic3r overrides Marlin's travel acceleration with its filament-only acceleration.

I think the best course of action would be to create a new G-code flavor, "Prusa", and fork the time estimate code and machine limits configuration accordingly. Alternatively, Prusa-Firmware could be modified to adopt the new standard put forward by Marlin.

I can work on a PR to do so, but would like to hear the input of the maintainers first.

Is this a new feature request? Yes

[bubnikv]

The problem is caused by the Marlin guys, who changed the definition of that particular M code, which was a bad idea indeed. So we did not break it, but the problem is now on our shoulders. There is a workaround for you. Just override that single M code in your custom start G code, you can even use the macro processing language to pull the acceleration values from the parameter layer.

…

On Sun, Jul 29, 2018, 00:48 Colin Gilgenbach ***@***.***> wrote: Version commit 78a8acf <78a8acf> Operating system type + version Ubuntu MATE 18.04 Behavior The recent acceleration and print estimate additions currently rely on a non-standard form of M204 and accelerations in general. Vanilla Marlin (1.1.x and 2.0.x) uses a command of the form M204 P[print] R[retract] S[travel], while Slic3r outputs and processes using M204 S[print] T[retract]. AFAIK only Prusa printers use the latter form. This problem can't be ignored because Slic3r imports a mandatory M204 at the beginning of each gcode export. Currently, Slic3r overrides Marlin's travel acceleration with its filament-only acceleration. I think the best course of action would be to create a new G-code flavor, "Prusa", and fork the time estimate code and machine limits configuration accordingly. Alternatively, Prusa-Firmware could be modified to adopt the standard put forward by Marlin. I can work on a PR to do so, but would like to hear the input of the maintainers first. *Is this a new feature request?* Yes — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1089>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5IyYN2rFQ6ckQAGya8GgQyEHzPVfPks5uLOokgaJpZM4VlNdH> .

[bubnikv]

I have to discuss the situation with our firmware team. I personally woud like to unify with Marlin, but we have to thing through all the scenarios of firmware versions and customer lehacy G codes.

…

On Sun, Jul 29, 2018, 08:09 bubnikv ***@***.***> wrote: The problem is caused by the Marlin guys, who changed the definition of that particular M code, which was a bad idea indeed. So we did not break it, but the problem is now on our shoulders. There is a workaround for you. Just override that single M code in your custom start G code, you can even use the macro processing language to pull the acceleration values from the parameter layer. On Sun, Jul 29, 2018, 00:48 Colin Gilgenbach ***@***.***> wrote: > Version > > commit 78a8acf > <78a8acf> > Operating system type + version > > Ubuntu MATE 18.04 > Behavior > > The recent acceleration and print estimate additions currently rely on a > non-standard form of M204 and accelerations in general. Vanilla Marlin > (1.1.x and 2.0.x) uses a command of the form M204 P[print] R[retract] > S[travel], while Slic3r outputs and processes using M204 S[print] > T[retract]. AFAIK only Prusa printers use the latter form. > > This problem can't be ignored because Slic3r imports a mandatory M204 at > the beginning of each gcode export. Currently, Slic3r overrides Marlin's > travel acceleration with its filament-only acceleration. > > I think the best course of action would be to create a new G-code flavor, > "Prusa", and fork the time estimate code and machine limits configuration > accordingly. Alternatively, Prusa-Firmware could be modified to adopt the > standard put forward by Marlin. > > I can work on a PR to do so, but would like to hear the input of the > maintainers first. > > *Is this a new feature request?* Yes > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1089>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFj5IyYN2rFQ6ckQAGya8GgQyEHzPVfPks5uLOokgaJpZM4VlNdH> > . >

[hexane360]

There is a workaround for you. Just override that single M code in your custom start G code, you can even use the macro processing language to pull the acceleration values from the parameter layer.

This is definitely true, and what I'm doing in the meantime. However, this doesn't solve the problem of print estimates, as there is no travel acceleration. Maybe a good first step would be to add a travel acceleration option that's ignored in g-code but respected in time calculations. For Prusa printers, this can be set to print acceleration, while newer printers can vary it accordingly.

This would provide full functionality for everyone now, while also laying the foundation for an easy upgrade if/when Marlin is unified.

but we have to thing through all the scenarios of firmware versions and customer legacy G codes.

Yeah. It reminds me of a synchronization point in multithreaded coding. Every part (g-code/slicer, firmware, documentation) needs to be either before or after the change. Maybe Prusa firmware could temporarily process M204 the old way if S is supplied and the new way otherwise.

[bubnikv]

I have checked our MK2 / MK3 firmware and the current Marlin
https://github.com/MarlinFirmware/Marlin/blob/f816d6f70fd15b351634d0545ef2b8302853bf46/Marlin/Marlin_main.cpp#L9158

The Marlin guys made the porting process to the new format quite ugly as they changed the meaning of the T value: It used to be the retract acceleration, now it is the travel acceleration.

We decided to solve it by producing the new "M204 P R T" format by Slic3r, while exporting the same acceleration value for the P and T values, and we changed our MK3 firmware to interpret the T the old way only if its preceded with S.

prusa3d/Prusa-Firmware@dd4c4b3

So Slic3r will now export
M204 P[machine_max_acceleration_extruding] R[machine_max_acceleration_retracting] T[machine_max_acceleration_extruding]
before the custom start G-code, which will be correctly interpreted by both the new Prusa3D firmware and the Slic3r's time estimator.

To support our legacy MK2 firmware before we merge the commit above, we may just insert the following line into the custom start G-code section to override the block inserted by Slic3r automatically before the custom start G-code:
M204 S[machine_max_acceleration_extruding] T[machine_max_acceleration_retracting]

[bubnikv]

Implemented with 0454adc
It will be part of the upcoming beta. You will have to define the machine limits table, and for now the "acceleration when extruding" value is exported for the travel acceleration as well. If you don't like it, you will have to override the M204 code in your start G-code.

Please note that as of now the Slic3r's time estimator does not support the separate "acceleration when extruding" and "travel acceleration", so if you override the M204 code in your start G-code, the time estimate will be less accurate.

But also please note, that Slic3r generates the M204 S code between extrusions if you happened to define a non-zero acceleration value in the print profile -> speeds -> accelerations, and the current upstream Marlin interprets the M204 S code the same way as the current Slic3r simulator: The current Marlin will set both the "acceleration when extruding" and "travel acceleration" values with the M204 S value, so you will lose the distinction between the "extruding" and "travel" acceleration.

What a mess. I wonder why the Marlin guys did not contact the Slic3r team when they changed the M204 code.

@thinkyhead Scott, we need to talk. Excuse my rumbling.

[boelle]

when the next version comes what do i need to do so that marlin does not go bananas ?

of course i insert the firmwares limits under machine limits, but then there was the override section at the top of the gcode that screwed up things...

i agree its a mess and i'm just happy that i keept a backup of the slicer settings and the version i used to have

[bubnikv]

of course i insert the firmwares limits under machine limits, but then there was the override section at the top of the gcode that screwed up things...

I hope the "override section that screwed up things" is the G-code block that Slic3r generates from the machine limits table, and the upcoming release will produce a block, which is understood by the current upstream Marlin.

[boelle]

yeah, i'm not good with words so "screwed up" might not have been the best way to say it

of course the easy "fix" would be to have an option in the slicer that does not put in the block

again i would have picked prusa firmware but there are a few features i would miss, dual z stepper drivers and endstops are the most important one, full graphic display would be the next, not sure if prusa flavour of marlin still has an option for electronics fan?

but a big plus would be that i would have the 9 point probing like the prusa machines has, mainstream marlin does not have that still.

do you know how long it takes before the next version of the slicer is there?

[bubnikv]

do you know how long it takes before the next version of the slicer is there?

We wanted to release another alpha (or beta?) today, but we did not manage yet.

[boelle]

oki doke.... no rush

better wait and make it right

[hexane360]

@boelle just as a side note, Marlin definitely does have 9-point probing, with any of the bed leveling options. Take a look at GRID_MAX_POINTS_[XY], and the options to G29

[hexane360]

This definitely seems like a good solution. However, we should think about adding support for travel accelerations, both in preparation for PrusaFirmware actually using the M204 T option and for current Marlin users. If not set, it can just default to machine_max_acceleration_extruding, preserving accurate time estimates for Prusa printers.

[bubnikv]

However, we should think about adding support for travel accelerations, both in preparation for PrusaFirmware actually using the M204 T option and for current Marlin users.

Yes, but as of now Slic3r generates M204 Sxx to control acceleration per extrusion type, which overrides both M204 Pxx and M204 Txx in the current upstream Marlin, so with M204 Sxx to control the per extrusion type acceleration, we would implement the M204 Txx in vain. We then would need to make decision on whether the Slic3r should only emit M204 Pxx instead of current M204 Sxx to control per extrusion type accelerations. Is it a correct solution? Or do we want another configuration key to control that?

@thinkyhead What do you think, Scott?
What does Cura do?

[boelle]

@hexane360

by 9 probe points i mean the 9 points on the mk42 bed, mainstream marlin does not support that one

[boelle]

@bubnikv if @thinkyhead does not get back to you maybe the only other way to support other printers would be to have an new firmware flavour called prusa that inserts the new gcode block in the beginning, if flavour is set to marlin it should not insert the block

just some poor thoughts from me :-)

[hexane360]

It's a bit hacky, but if travel acceleration is set by the user, a M204 T could be added after each M204 S to restore the set travel acceleration. On both current Prusa Firmware and Marlin, the M204 S would set both travel and printing acceleration, while the M204 T would only affect travel acceleration. However, it might be best to just rip the band-aid off and avoid multiple stages of behavior changes.

[boelle]

:-) well i'm not a coder so i can only chip in with that is inside my head

a small side note: i'm looking at the various projects that enables prusa version of the firmware to run on ramps, i just need to make sure all the features i need are there

again the big missing one here is full graph lcd's, i could just get the text lcd and be done with it but i refuse to put a perfect working lcd in a box, so the big task would be to get support for that. Even just 2 (or is it 4?) lines of text would make me happy

the bonus would be that i dont have to worry about compability issues with slic3r PE

[thinkyhead]

Is it a correct solution? Or do we want another configuration key to control that?

It's a bit hacky, but if travel acceleration is set by the user, a M204 T could be added after each M204 S to restore the set travel acceleration.

Since M204 S has been deprecated for a while, the sooner we all abandon it, the better. Just always use the P and T parameters, even if they're the same.

[bubnikv]

@thinkyhead

Since M204 S has been deprecated for a while, the sooner we all abandon it, the better. Just always use the P and T parameters, even if they're the same.

While I appreciate your response, before doing a decision, I would like to know:

When was that change made in mainstream Marlin?, Who did it?
Why was it done that way? (no way to keep backward compatibility due to a quite cumbersome redefinition of the meaning of T). I do not want to point fingers, but we should avoid such decisions in the future.

And most of all:
Before / after that change was done, were the authors of all the possible slicers informed about the decision?
Did anybody research, which slicers generate M204, in which format and for what purpose?
What is the current situation about M204 support by Slic3r (mainline and Prusa3D), Simplify3D, Kisslicer, Idea Maker, Craftware?

[bubnikv]

@boelle you can contact me at vojtech bubnik at prusa3d cz, but please note that I am no more involved in our firmware development and that my time to support you is very limited.

[hexane360]

I can answer a little of this.

When was that change made in mainstream Marlin?

I linked the commit in my original post. It was changed in March 2015 and included in the next Marlin release, version 1.1.0-RC2. The commit was made by @alexborro, who created the original Marlin bed leveling code.

When travel acceleration was added, it would have been very confusing to have a working T option that did not mean "travel acceleration", but instead "retract acceleration".

Mainline Slic3r currently behaves like Prusa3d when it comes to conditional accelerations. Simplify3d appears to support conditional accelerations only through post-processing targeting comments ("; outer perimeter", "; infill", etc.), leaving it up to users to give g-codes. Cura has encountered this problem, and decided to permanently ignore the new format for backwards compatibility (apparently at the sake of forwards compatibility). Kisslicer doesn't mess with accelerations at all, nor does Idea Maker. Craftware has a changelog from 2015 that says "Acceleration is not embedded in GCode by default", but it seems like their printers use a non-standard M-code for acceleration.

As for advance warning, many of the slicing options didn't exist when the change was made, and even more of them didn't explicitly code in acceleration. For example, the change predates the Prusa3d Slic3r fork by almost a year. However, the latest Slic3r version, 1.2.6, did have conditional acceleration. Obviously breaking changes now need to be considered much more formally, but this specific incident is just an artifact of the explosion of slicers and firmwares, coupled with manufacturers (understandably) sticking to older versions of Marlin.

[boelle]

so i had time to update the software and the issue is still the same

the start of my gcode still have this in it:

M201 X9000 Y9000 Z500 E10000 ; sets maximum accelerations, mm/sec^2
M203 X500 Y500 Z12 E120 ; sets maximum feedrates, mm/sec
M204 P2000 R1500 T2000 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X10.00 Y10.00 Z0.20 E2.50 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

[hexane360]

@boelle

That's the correct behavior. Note the M204 line is using the new Pxxx Rxxx Txxx format instead of the old Sxxx Txxx format. Just set the "extruding" and "retracting" accelerations in Printer Settings->Machine Limits, and that'll correspond to the values given to the M204 line. Also confirm that your other machine limits are correct for your printer.

If you want to override the travel acceleration that Slic3r sets, just put another M204 in your start gcode:

M204 T3000   ; I want travel acceleration faster than my printing acceleration

[boelle]

well it just does not work with marlin firmware

i will try and double check that machine limits are the same as those in firmware, but last time i check it did matter if i set machine limits to what the firmware had

[guestisp]

So, no solution to set travel, printing and retraction speeds differently ?

[eschulma]

It is not at all obvious that "max acceleration when extruding" has such a massive influence on print time, due to that unwanted M204 line being added. I could not figure out why it was so far off until I found this issue. Slic3r was 30% faster just because of that. Please fix it!

[swilkens]

@boelle

That's the correct behavior. Note the M204 line is using the new Pxxx Rxxx Txxx format instead of the old Sxxx Txxx format. Just set the "extruding" and "retracting" accelerations in Printer Settings->Machine Limits, and that'll correspond to the values given to the M204 line. Also confirm that your other machine limits are correct for your printer.

If you want to override the travel acceleration that Slic3r sets, just put another M204 in your start gcode:

M204 T3000   ; I want travel acceleration faster than my printing acceleration

Maybe the confusion comes from the difference between the interface and the output.

The interface is currently this:

We have two fields to control the M204 GCODE output, but the GCODE generated has three variables. Additionally, the tooltip still mentions the "S" variable while we are outputting P, R, and T:

M204 P1500 R1500 T1500 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2

I realize this is a repeat of a known issue, but this might be a trivial interface modification? He said carefully...

[wavexx]

To add something to the discussion as I ran into the issue as well:

Irregardless of the M204 dialect, a separate setting for maximum travel acceleration would need to be added anyway in the machine limits.

Furthermore, a travel acceleration setting in the print profile is also required, since travel acceleration can definitely influence quality, and higher quality profiles might want to reduce it.

The starting section of the gcode can/should already use this value in M204 T since this value is ignored in old FW versions. For the MK3 (and 2.5), an implementation of M204 T can be tested here:

prusa3d/Prusa-Firmware#2838

which makes it identical in behavior to marlin. I currently post-process the gcode to change all M204 S instructions to M204 P to have separate control of travel acceleration.

Producing gcode which is compatible for both though is annoying, and might require either an option or a separate dialect.

Older FW versions will require an additional M204 S instruction before each travel in any case.

However, in newer versions we just need to use M204 P instead of M204 S and we're good.
It is important IMHO that the travel acceleration settings are not overridden (that is: no additional M204 T instructions should be generated) when using the new dialect, so that one can conveniently change the travel acceleration using some custom layer_change gcode.

[bubnikv]

The time is ripe for us at Prusa Research to implement the new behavior. We will most likely split the Marlin firmware specification to Marlin legacy and Marlin 2, we will implement the new M204 meaning for Marlin 2.

The change is certainly not a one liner though, we would have to update the parameter UI, the G-code generator, the G-code parser and print time estimator.

[wavexx]

The starting section of the gcode can/should already use this value in M204 T since this value is ignored in old FW versions. For the MK3 (and 2.5), an implementation of M204 T can be tested here:

prusa3d/Prusa-Firmware#2838

Looks like this went in, so newer MK3/S FW versions are now compatible with the marlin2 behavior too.

[lukasmatena]

This should be solved by 2418b3d. We have split the Marlin flavor into legacy (which works as it worked until now) and new one (which uses the new M204 format). Closing.