RRF3 seems to ignore PrusaSlicer Acceleration Control

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 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.
post process.JPG

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