OrcaSlicer does not respect travel acceleration outside printing movements

[HakunMatat4]

Is there an existing issue for this problem?

• I have searched the existing issues

OrcaSlicer Version

2.0.0, 2.2.0

Operating System (OS)

Linux

OS Version

Mint Cinnamon 21.3

Additional system information

No response

Printer

Voron Trident

How to reproduce

1. Print as usual
2. Travel acceleration isn't respect after the purge line.

Actual results

This problem has been driving me nuts but I couldn't figure out the root cause until today while trying to get the latest OrcaSlicer release to work.
I had to use PrusaSlicer and like magic, after the purge line the toolhead traveled at 6000mm/s instead o 10mm/s like OrcaSlicer does. It is painfully slow.

This has always being a problem when printing many objects, by the time the toolhead reaches the starting point, there is enough oozing to destroy the first layer.
To minimize that, I start from as close as to the purge line as possible. That option isn't always available and affects printing quality.

Notice how PrusaSlicer sets the accel globally at the very start and yet OrcaSlicer has not set it.

The only time OrcaSlicer uses the acceleration is during the printing and that is wrong.
Basically, OrcaSlicer won't use the values set for non-printing movements like after purge line or PAUSE/START while PrusaSlicer set those globally so any movement will use the values set.

Expected results

Respect the values of acceleration set for ANY movement, not just during printing.

Project file & Debug log uploads

logs.zip

Checklist of files to include

• Log file
• Project file

Anything else?

No response

[igiannakas]

That is odd...

For me Orca sets the acceleration immediately before the first XY move after the print start macros. Could you post a project file?

[igiannakas]

Below is the gcode used above for closer inspection :)
Cylinder - Polyterra White - High Temp Plate.gcode.zip

[HakunMatat4]

@igiannakas I found, I think, the root cause of this and why both slicer behave differently.

This is my start G-Code, I only pass the values to Klipper and PRINT_START macro processes everything as it should be.
That also allows you to paste the same instruction into no matter the slicer you are using and you should expect the same behavior:

PRINT_START HOTEND={first_layer_temperature[initial_extruder]} BED=[first_layer_bed_temperature] ZOFFSET=-0.495 MATERIAL=[filament_type] SIZE={first_layer_print_min[0]}_{first_layer_print_min[1]}_{first_layer_print_max[0]}_{first_layer_print_max[1]}
M82

Both OS and PS knows nothing about the purge line declared within PRINT_START macro:

    ## Purge line
    G92 E0
    G1 X3 Y20 Z0.3 F5000.0
    M109 S{hotendtemp}      ;start heating hotend and WAIT
    G1 X3 Y120.0 Z0.3 F2000.0 E15
    ## End purge line

Here is the twist.
Even so PS does not know about the purge line, it does have a virtual travel from the very front left corner of the bed to the actual object.
The blue/red lines is the Pressure Equalizer aka Smoothing, speed gradually before going full throttle, then slow down gracefully.
Pay attention to that 500mm/s at the top left corner, that is happening at 6000mm/s travel.

Because of that virtual travel, the travel speed values are activate, both the speed for non-print moves and acceleration.

Orca does not do that, it does set the accel but since it cannot see the actual purge line and itself does not have a virtual one like PS does, idk what it does.
After the retraction on line 1460 ( G1 E-F3000 ) I have no idea what speed it uses to travel.
All I know is that it is slow and gives me headache lol

Project
project.zip

[HakunMatat4]

I checked everything again, both slicers do have the same virtual travel, but yet, both behave differently.
That travel tho is not registered.

Whatever is happening, lies here, there is no accel set here, OS and PS are using different values in my case.

G1 Z.65 F30000
G1 X164.475 Y158.947

OrscaSlicer

PrusaSlicer

[Ergonomicmike]

I'm not a coder, nor dev, etc. So I don't know what "Best Practice" is for Orca/Klipper. But after floundering around in my first ever dive into Klipper last year, I found it best to move the Line Purge part of START_PRINT to a separate call in Filament (Materials)>Advanced>Filament start G-code.

 ; filament start gcode
_LINE_PURGE_TPU

This solved a lot of problems that I was having by burying the Line Purge in START_PRINT.

And, as a bonus, this allowed me to call different Line Purge macros for different materials. (TPU needing a much slower extrusion speed than PLA, for example.)

I'm not sure if I should call my method a "work around" if this isn't a bug in Orca. Regardless, it might solve the OP's instant issue.

[HakunMatat4]

And, as a bonus, this allowed me to call different Line Purge macros for different materials. (TPU needing a much slower extrusion speed than PLA, for example.)

That alone explains why your solution isn't a workaround but an actually nice solution.
Why does your macro starts with underscore??

In my case tho, the entire leveling and all happens with the nozzle at 150c, only then it parks at the front left corner to fully heat the nozzle.
I do that to avoid oozing and it works wonderfully.
I wonder if the printer will have those values in place in time, based on your experience, that shouldn't be an issue.

    ## Purge line
    G92 E0
    G1 X3 Y20 Z0.3 F5000.0
    M109 S{hotendtemp}      ;start heating hotend and WAIT
    G1 X3 Y120.0 Z0.3 F2000.0 E15
    ## End purge line

I will try to create a [PURGE_LINE] macro and set it like you did, hopefully, that will solve the problem.
The problem tho is that OrcaSlicer prior to the actual print, it does not use the accel values.
It is worth a try.

[HakunMatat4]

The above is actually an old code, this was my current code and an attempt to fix it: The last line.
PS sees that while OS does not.
I will try the have a purge line macro instead.

    G92 E0
    G1 X3 Y20 Z0.3 F5000.0
    M109 S{hotendtemp}      ;start heating hotend and WAIT
    G1 X3 Y125.0 Z0.3 F2000.0 E15
    G0 X3 Y130.0 Z0.3 F6000

[Ergonomicmike]

The underscore before the macro name is, per Klipperscreen documentation, to hide macro names from the Interface. (I don't see a need to call Line Purge from either Mainsail or Klipperscreen.)

Hope my "workaround" works for you.

[HakunMatat4]

@Ergonomicmike , your approach although it is nice to know, it did not solved my problem :(
Ohh yes, I forgot that detail to hide it from KlipperScreen, thank you.

I recorded both prints from both slicers.

OrcaSlicer does process G0 X3 Y130.0 Z0.3 F6000 but from there to the center of the bed, it does not use my travel settings.
https://github.com/user-attachments/assets/5b6c3b26-5c15-41ec-81cf-5cc788827619

PrusaSlicer on the other side is day and night difference.
https://github.com/user-attachments/assets/341d57e0-7839-4e07-9e46-95eda116c8f9

[Ergonomicmike]

Sorry it didn't fix your instant issue.

AFAIK, I don't have this issue. Since you have the issue, and since it seems to be following the Slicer, my WAG is that your ultrahigh settings (compared to mine (Ender 3 v2)) hits/triggers some kind of limit in Orca. (Kinda the way that volumetric speed limit can slow print speed down.)

But the dev's here are very good at solving puzzles. I'll watch as they figure this one out.

(As a small aside (and it probably doesn't make a difference) but I have
G92 E0 ; Reset Extruder
at the end of my Line Purge macro. You don't.)

[HakunMatat4]

You don't

It is within PRINT_START macro after the purge line.
Those 2 prints above were performed as it is ( after I did the PURGE_LINE test ) so that is not it.
So both slicers are using the same PRINT_START, the same macros, same speeds but different behavior.

For many people this isn't an issue, when printing lots of objects, ASA-CF at 260c and so on, this creates annoying headache with the oozing getting stuck on the first layer.

For this alone, I would rather use PS.
You have no idea for how long I have been trying to solve this, that is why the line G0 X3 Y130.0 Z0.3 F6000 with the intention of making OS to use the latest travel speed loaded but nope.

I use OS since the very first release when we ( Linux folks ) had to manually compile our slicer.
I always encountered occasions where OS would not behave as expected driving me nuts.
One time it was not triggering the retraction so my prints were looking like dogsh1t, countless hours and filament wasted thinking that it was my printer, long story short it was indeed OS misbehaving and required a hotfix.

That was one example, there were others so I know that this is not me but OS doing.

    ## Purge line
    G92 E0
    G1 X3 Y20 Z0.3 F5000.0
    M109 S{hotendtemp}      ;start heating hotend and WAIT
    G1 X3 Y125.0 Z0.3 F2000.0 E15
    G0 X3 Y130.0 Z0.3 F6000

    G90 ; absolute position mode
    G92 E0 ; Reset Extruder
    M83 ; use relative distances for extrusion

    STATUS_BUSY # LED Effect

[Ergonomicmike]

Another WAG: I've noticed that Linux users sometimes have problems that Windows users don't with Orca. Can you run the portable Window version of Orca in a VM to slice your model just to see if it's a Windows/Linux issue?

[igiannakas]

I'm not a coder, nor dev, etc. So I don't know what "Best Practice" is for Orca/Klipper. But after floundering around in my first ever dive into Klipper last year, I found it best to move the Line Purge part of START_PRINT to a separate call in Filament (Materials)>Advanced>Filament start G-code.

 ; filament start gcode
_LINE_PURGE_TPU

This solved a lot of problems that I was having by burying the Line Purge in START_PRINT.

And, as a bonus, this allowed me to call different Line Purge macros for different materials. (TPU needing a much slower extrusion speed than PLA, for example.)

I'm not sure if I should call my method a "work around" if this isn't a bug in Orca. Regardless, it might solve the OP's instant issue.

This is fine as long as you don’t use multi material printing - if you do, this is called every time the filament swaps.

[igiannakas]

Any chance you can post the two gcode files? @HakunMatat4

I haven’t personally noticed this but, I do reset the printers acceleration to the default value in printer config at my print end macro, so I think that one is used.

a workaround would be to set manually an acceleration value in your print start macro right after the purge line. This would set the correct accel for the first travel move and then the slicer would take over and replace it.

but do please post the gcode files from orca and prusa so I can take a closer look if you can

[HakunMatat4]

a workaround would be to set manually an acceleration value in your print start macro right after the purge line. This would set the correct accel for the first travel move and then the slicer would take over and replace it.

@igiannakas This is what I have in place but OrcaSlicer refuses to stick to it lol

    ## Purge line
    G92 E0
    G1 X3 Y20 Z0.3 F5000.0
    M109 S{hotendtemp}      ;start heating hotend and WAIT
    G1 X3 Y125.0 Z0.3 F2000.0 E15
    G0 X3 Y130.0 Z0.3 F6000

I sent the log and both gcodes when I opened the ticket lol
The only time OS will use my speeds for the first time is at the line 1468.
PS calls it at the line 782 but it respects the F6000 above.
I don't know what is going on haha

Thanks man

logs.zip

[igiannakas]

Do me a favor, sorry I haven’t checked the zip file yet but does it also include the orca project?

im suspecting I don’t see this because I am always using a skirt.

[HakunMatat4]

Do me a favor, sorry I haven’t checked the zip file yet but does it also include the orca project?

Yup, I sent the project.

project.zip

im suspecting I don’t see this because I am always using a skirt.

I see what you mean but that would make no sense.