RRF3 seems to ignore PrusaSlicer Acceleration Control

[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 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.

[Wally]

@dc42 - thank you for the note, the F parameter is indeed in the M563 notes but is buried in the text, probably why I missed that. Can the gcode note be updated in the Wiki to make this more noticeable? That note / coding isn't formatted like other examples in the text. Something like this?

M563 P0 D0 H1 F0:1     
; tool 0 uses extruder drive 0 and heater 1. Fan 0 and Fan 1 are mapped to tool 0

[dc42]

There is already this example:

M563 P2 D0:1 H1:2 X0:3 F0:2 ; create a tool using extruder drives 0 and 1, heaters 1 and 2, with X movement mapped to both X and U axes and fan 0 mapped to fans 0 and 2

[toskium]

Just as a heads-up for you all, Merill acknowledged the issue and will have it fixed in Superslicer in the upcoming release.

See: https://github.com/supermerill/SuperSlicer/issues/450#issuecomment-687650047

toskium created this issue in supermerill/SuperSlicer

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

[garethky]

Just ran into this while debugging a print time discrepancy. There is an issue open with Prusa Slicer so hopefully it gets fixed soon: https://github.com/prusa3d/PrusaSlicer/issues/5599

natthapolvanasrivilai created this issue in prusa3d/PrusaSlicer

closed RepRapFirmware Flavor add faulty Acceleration Control G-Code (M204) #5599