Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support for standard Marlin accelerations/M204 #1089

Closed
hexane360 opened this issue Jul 28, 2018 · 31 comments
Closed

Feature Request: Support for standard Marlin accelerations/M204 #1089

hexane360 opened this issue Jul 28, 2018 · 31 comments

Comments

@hexane360
Copy link
Contributor

hexane360 commented Jul 28, 2018

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
Copy link
Collaborator

bubnikv commented Jul 29, 2018 via email

@bubnikv
Copy link
Collaborator

bubnikv commented Jul 29, 2018 via email

@hexane360
Copy link
Contributor Author

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 added a commit to prusa3d/Prusa-Firmware that referenced this issue Aug 3, 2018
M204 S.. T..:
T is interpreted the old way (as acceleration when retracting)
only if an S code is found at the same line.
This allows PrusaResearch to interpret the legacy G-codes generated
by our older Slic3r with older Slic3r profiles.

M204 P.. R.. T..:
T is ignored, P is interpreted as acceleration when extruding,
R is interpreted as acceleration when retracting.
This will be the format the Slic3r 1.41.0 will produce from
the Machine Limits page.
In the future both MK3 firmware and Slic3r will likely be extended
to support the separate travel acceleration.

This change will help us to solve the following Slic3r issue:
prusa3d/PrusaSlicer#1089
@bubnikv
Copy link
Collaborator

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 added a commit that referenced this issue Aug 3, 2018
Fix of #1089

M204 S.. T..:
T is interpreted by the firmware and Slic3r time estimator the old way
(as acceleration when retracting) only if an S code is found at the same line.
This allows PrusaResearch to interpret the legacy G-codes generated
by our older Slic3r with older Slic3r profiles.

M204 P.. R.. T..:
T is ignored, P is interpreted as acceleration when extruding,
R is interpreted as acceleration when retracting.
This will be the format the Slic3r 1.41.0 will produce from
the Machine Limits page.
In the future both MK3 firmware and Slic3r will likely be extended
to support the separate travel acceleration.

This change is in sync with the Prusa3D firmware:
prusa3d/Prusa-Firmware@dd4c4b3

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

oki doke.... no rush

better wait and make it right

@hexane360
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link
Collaborator

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?

@bubnikv bubnikv reopened this Aug 4, 2018
@boelle
Copy link

@hexane360

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

@boelle
Copy link

@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
Copy link
Contributor Author

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
Copy link

:-) 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
Copy link

thinkyhead commented Aug 7, 2018

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
Copy link
Collaborator

@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
Copy link
Collaborator

@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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

@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
Copy link

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
Copy link

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

@eschulma
Copy link

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
Copy link

swilkens commented Aug 28, 2020

@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:
image

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
Copy link
Contributor

wavexx commented Sep 21, 2020

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants