OrcaSlicer 1.9.0 adds codes that breaks printer.

paralepsis

@droftarts It depends on what happens to be in those boxes. I found I got unreasonable jerk/accel settings that really messed things up (some time ago, in my case with PrusaSlicer). Skipping steps all over the place, etc.

dc42

@paralepsis I've had it in mind for some time to add an option for RRF to ignore M201, M203 and probably also M566/M205 commands in print files. IMO print files have no business messing with machine limits.

Exerqtor

Even if "Emit limits to G-code" is ticked or not Orcaslicer still hammers in M204 & M205.

I guess M204 is ok, but M205 should be left out. Shouldn't it?

I'll open an issue on their GIT to see if this is intended or a bug, imo it shouldn't send those commands when the box is unticked.

dc42

@Exerqtor yes M204 is fine (RRF will apply the M201 limits if they are more strict). M205 is questionable because it could exceed what the printer can do. One possibility would be to treat it like M204, i.e. treat the M566 settings as machine limits and not allow M205 to set higher limits.

paralepsis

@dc42 makes sense to me!

paralepsis

@Exerqtor M204 is leveraged by PrusaSlicer for feature-based acceleration control, is useful to have around.

Phaedrux

@dc42 said in OrcaSlicer 1.9.0 adds codes that breaks printer.:

@paralepsis I've had it in mind for some time to add an option for RRF to ignore M201, M203 and probably also M566/M205 commands in print files. IMO print files have no business messing with machine limits.

As long as it's optional. I use Cura and set independant speed, accel, jerk values for different move types. First layer, external perimeters, infill, travels.

Firefly

@droftarts it was bad for my printer, it slammed the hot end to the right and forcing the belt to grind/skip. It moved the opposite direction it was suppose to go, very weird and not making any sense to me.

DocTrucker

@Phaedrux Parsing gcode files to use M201.1 or M204 would help control acceleration on the fly. Not sure why they'd want to change max speed on the fly rather than just use feed rates?

As for variable jerk/instant speed on the fly I'm not sure there is a way to deal with this with the current gcode library?

As there are already slicers in the wild using these gcodes badly perhaps it may be easier to have new gcodes for use in config files that can't be overriden in build files?

Edit: Whats the market share of Duet equipped/reprapfirmware compatible machines like vs Prusa compatible systems now?

Phaedrux

@DocTrucker said in OrcaSlicer 1.9.0 adds codes that breaks printer.:

Not sure why they'd want to change max speed on the fly rather than just use feed rates?

I think the only gcode limit Cura changes now is M566 for jerk. Feedrate is handled by G1 and for acceleration I believe they use M204.

I can't say what other slicers do. Last I checked Prusa didn't allow for on the fly jerk changes at all without post processing.