RRF3 seems to ignore PrusaSlicer Acceleration Control

[toskium]

Hello everybody,

I am having an issue with my current delta printer running RRF 3.1.1 and acceleration control via PrusaSlicer/Superslicer.

In the slicer I can set different acceleration type values like so:

unfortunately my printer uses the default value for everything which results in quite a bit of ringing/ghosting.

The gcode flavor is already set to "RepRap".

Dropping the default acceleration to 1000 solves the issue but makes acceleration for the other features quite slow and adds up to print time.

Am I doing something wrong or is this some feature only Marlin understands?

Cheers, Markus

[Veti]

please set the g-code flavor to reprap/sprinter

[toskium]

Sorry for not mentioning this in my original post: G-Code flavor is already on RepRap.

[toskium]

While digging around in the gcode I found that the slicer uses the following gcode to tune acceleration:

M204 S5000

According to the Duet documentation this is wrong, it should instead be

M204 P5000

since all values represent print moves.

@dc42 could you please verify my findings before I am filing a bug-report over at PrusaSlicer/Superslicer?

[Veti]

i just checked. prusaslicer generates commands like

M204 S435

and and they are not supported by duet firmware

https://duet3d.dozuki.com/Wiki/Gcode#Section_M204_Set_printing_and_travel_accelerations

[toskium]

@Veti seems so, I guess it's bug-reporting-time

[bot]

This is specific to SuperSlicer. PrusaSlicer does not generate or allow anything to do with the machine-limits for reprap/sprinter flavour.

I think somebody has already reported this on the SuperSlicer GitHub repo. It may already be fixed in the current release, or for the next one.

[Veti]

i can set it in prusaslicer 2.2.0 with reprap flavour

[toskium]

@bot I am able to create the same gcode with PrusaSlicer. It seems to be a bug that both slicers have.

Over at superslicer someone reported something similar, he wanted travel acceleration added as a parameter, if I remember correctly.

[bot]

Interesting. I was under the impression that those controls in PrusaSlicer were only used for the print time estimates or something. Thanks for the info. [Edit: I think I was confused by SuperSlicer's former approach: it was in SuperSlicer where the reprap/sprinter flavour did not generate the M204 commands, previously. Too many slicers and too much code makes my brain numb.]

[toskium]

FYI, here's the link to the relevant SuperSlicer issue:

https://github.com/supermerill/SuperSlicer/issues/450

toskium created this issue 5 Sept 2020, 18:17 in supermerill/SuperSlicer

closed G-Code flavor RepRap produces wrong M204 commands #450

[Phaedrux]

@bot said in RRF3 seems to ignore PrusaSlicer Acceleration Control:

Interesting. I was under the impression that those controls in PrusaSlicer were only used for the print time estimates or something.

These acceleration settings are from the speed tab, not the machine limits thing. They have been there since OG Slic3r.

I just started using Super Slicer and I hadn't noticed that the acceleration control isn't working.

[toskium]

@Phaedrux this seems to be an issue for a long time now. I remember this having me confused when I was building my last corexy but it fell of the stack and I worked around it... Today it resurfaced

[Phaedrux]

Well at least if you set your own M204 P T values in config.g or the filament specific gcode section the firmware will still use that for print and travel, but you won't get specifics per move.

[OwenD]

There are a couple of things that aren't handled properly for RRF.
M104 is output instead of G10 as well.
I just run a script to post process them.
I'm not a python programmers, so there could be bugs in the code under some circumstances, but it works for me.
Prusa Slicer treats everything as a travel move in this instance. Or at least it sets the acceleration to the "default" value.
I guess it would have to output G0 for travel moves instead of G1 for the M204 T parameter to come into effect.

#RRF-fixes.py
# Save in Prusa Slicer Scripts folder
# Add to Prusa Slicer post processing scripts
 
import sys
 
f = open(sys.argv[1],"r")
filedata = f.read()
f.close()
 
newdata = filedata.replace("M104 S","G10 S")
newdata = filedata.replace("M204 S","M204 P")
 
f = open(sys.argv[1],"w")
f.write(newdata)
f.close()
 

Edit:
Add script to post process list.
Set python and script location according to your installation.

[Wally]

@OwenD - Thanks!

I've also found that Prusa Slicer doesn't handle layer cooling fans in RRF, missing the tool number, in my case "P0" but depending on your setup these may change to something different.

So depending on what tool # you have for your cooling fan you may want to add something like this after line 12 in your Python script.

newdata = filedata.replace("M106 S","M106 P0 S")
newdata = filedata.replace("M107","M106 P0 S0")

[Wally]

@OwenD - Looking at your "G10 S" code, it should be "G10 P0 S" where "P0" is the tool/extruder being used, this could be harder for folks with multiple extruders, so if you are using more than one extruder, the Python script will need additional edits to seek and correct for each tool.

Also, while looking at & trying your Python code, I found these changes to get the gcode edited, probably the way Python handles variables.

f = open(sys.argv[1],"r")
filedata = f.read()
f.close()
 
newdata = filedata.replace("M104 S","G10 P0 S")
newdata1 = newdata.replace("M204 S","M204 P")
newdata2 = newdata1.replace("M106 S","M106 P0 S")
newdata3 = newdata2.replace("M107","M106 P0 S0")
 
f = open(sys.argv[1],"w")
f.write(newdata3)
f.close()
 

[OwenD]

@Wally
Oops,
I had only just added the extras. I originally only had M104 - > G10

Multiple tools could probably be handled by something like (Untested)

newdata = filedata.replace("M106 S","M106 P{tools[(state.currentTool)].fans[0]} S")

[dc42]

RepRapFirmware implements M204 as defined at https://reprap.org/wiki/G-code#M204:_Set_default_acceleration. The specification comes from Marlin.

EDIT: RRF does in fact support the legacy M204 S parameter, in both 2.05.1 and 3.1.1.

[dc42]

@Wally said in RRF3 seems to ignore PrusaSlicer Acceleration Control:

@OwenD - Thanks!

I've also found that Prusa Slicer doesn't handle layer cooling fans in RRF, missing the tool number, in my case "P0" but depending on your setup these may change to something different.

So depending on what tool # you have for your cooling fan you may want to add something like this after line 12 in your Python script.

newdata = filedata.replace("M106 S","M106 P0 S")
newdata = filedata.replace("M107","M106 P0 S0")

You can map the print cooling fan using the F parameter in the M563 command. On machines with only one print head, fan 0 should be the print cooling fan to make things easier.