[Feature Request] Add support for using G0 instead of G1 for travel moves

[ADKMechETECH]

With multi-extruder support now available (and working pretty well), I am trying to get Orcaslicer optimized for my Raise3d Pro3.

This printer seems to expect G0 for travel (rapid) moves and not G1. With files generated in Orcaslicer, all moves are G1 including travel moves. In some cases this seems to work fine, however I have noticed that the Pro3 is ignoring feedrate changes for most travel moves. I am unsure why this is and since it is closed firmware I doubt anyone will get a straight answer. What I do know from looking a the code generated in Ideamaker (Raise3d native software), testing, and my start g-code is that G0 works as expected for travel moves.

I don't like to have unrealistic expectations, but I can't imagine it would be too difficult to have a setting or check box in the machine configuration to enforce the use of G0 instead of G1 for travel moves.

[foreachthing]

I did that in post. If no E is in this line starting with G1, then replace G1 with G0. Works. But, I agree, this should be handled by the slicer.

[ADKMechETECH]

I did that in post. If no E is in this line starting with G1, then replace G1 with G0. Works. But, I agree, this should be handled by the slicer.

I hadn't looked at the Raw g-code that closely yet. Is that a safe assumption to make? Can you share whatever script you use to make those changes in post?

Edit
It is not a safe asumption, at least with the output from my configuration. Wipe moves are G1 and may not necessarily have any E move depending how you have your retract/wipe configured. I don't think having those as G0 would be a good thing.

[Rickthebig]

I was sure that this Orca idiosyncracy would become an issue at some point. See please:
https://github.com/SoftFever/OrcaSlicer/issues/5200
"Orca using G1 for travel moves instead of G0 - bad for postprocessing"
(has been just ignored).

[ADKMechETECH]

I was sure that this Orca idiosyncracy would become an issue at some point. See please: https://github.com/SoftFever/OrcaSlicer/issues/5200 "Orca using G1 for travel moves instead of G0 - bad for postprocessing" (has been just ignored).

Link is broken? - Nevermind, I found it. You are 100% correct. I would personally consider it a bug, but since Raise3d firmware is closed source I have no idea how big of an effect it actually has. I don't think Orcaslice can be considered 100% compatible unless the code generated is identical to the OEM.

I wasn't holding my breath for an answer/solution. It turns out that the Feedrate callout in the Ideamaker code is done immediately after the G0/G1 also. That appears to be the source of the issues I have been seeing.

As I didn't expect a fix any time soon, I came up with my own solution, however inelegant. I wrote some VBA code in excel to parse the exported G-code and reformat as needed. It's not pretty, but it works. It's not efficient, but it also only takes a few seconds to process. If anyone is reading this and wants my file to play with, optimize, or just use let me know.