Tsmith35 per BS PR4631

[tsmith35]

Description

Porting BS PR 4631 to OrcaSlicer.
Bambu Studio PR#4631 was authored by @ziehmon

Screenshots/Recordings/Graphs

Bambu Studio after PR4631 top, OrcaSlicer after ported changes bottom

[SoftFever]

Thank you.

Cloud you add the original author as the co author?

[tsmith35]

Thank you.

Cloud you add the original author as the co author?

I made an additional commit (minor text changes) and added @ziehmon as co-author. Hopefully that will do it, but I added credit in the PR description as well.

[SoftFever]

Seems like Orca don't have this bug from the first place.
Following is the screenshot from Orca nightly build, seems all fine to me.
Can you verify?

[ziehmon]

@SoftFever: to reproduce this, you need to remove timelapse_gcode in extruder settings. This is because the nature of the bug: Bambu inserted the spiral lift inside the timelapse_gcode, but it won't be executed if timelapse is disabled. By removing the timelapse_gcode, you'll simulate gcode generation without timelapse enabled, since Bambu Lab/Orca assume it is enabled for the gcode preview. I reproduced this with nightly.

Also by looking at the code, you can spot that Orca has this issue:

gcode += this->retract(false, false, LiftType::NormalLift); e.g. in https://github.com/SoftFever/OrcaSlicer/pull/6709/files#diff-cb3d09d2073b6e9032c65d07aa8f10d166324a53136b2aa1288f7b76f7d94319L4033, which is ultimately caused by: m_writer.set_current_position_clear(false); e.g. in https://github.com/SoftFever/OrcaSlicer/pull/6709/files#diff-cb3d09d2073b6e9032c65d07aa8f10d166324a53136b2aa1288f7b76f7d94319L4038

[ziehmon]

I only spotted the two sections I commented to be different to the original PR, besides that, LGTM.

[SoftFever]

@ziehmon Thank you for the explanation and code review!
Yeah, I can repro it after deleting the time-lapse custom gcode.

@tsmith35 All good for me. Thank you very much!

[ziehmon]

My pleasure @SoftFever, super nice to see the fix in Orca. Will update the reddit post about this and ask for some before/after photos. Also thanks again to @tsmith35 for porting!

[ziehmon]

Hi @SoftFever, hi @tsmith35,

unfortunately we need to revert this MR. There is a bug when AMS is used, since the position after changing filaments will be at X asis boundary and a spiral Z hop will move the axis out of physical boundaries. Details here: bambulab/BambuStudio#4841 (comment)

I am working on fixing this and will provide the fix here too. Sorry, I should've bought an AMS...

[ziehmon]

New PR: bambulab/BambuStudio#4848

Let's wait for review and testing. Will surely take some time, but at least that's fixed again...for now

[SoftFever]

Hi @SoftFever, hi @tsmith35,

unfortunately we need to revert this MR. There is a bug when AMS is used, since the position after changing filaments will be at X asis boundary and a spiral Z hop will move the axis out of physical boundaries. Details here: bambulab/BambuStudio#4841 (comment)

I am working on fixing this and will provide the fix here too. Sorry, I should've bought an AMS...

No sorry at all!
You are doing angle's work here. 👍

[ziehmon]

Hi @SoftFever, hi @tsmith35,
unfortunately we need to revert this MR. There is a bug when AMS is used, since the position after changing filaments will be at X asis boundary and a spiral Z hop will move the axis out of physical boundaries. Details here: bambulab/BambuStudio#4841 (comment)
I am working on fixing this and will provide the fix here too. Sorry, I should've bought an AMS...

No sorry at all! You are doing angle's work here. 👍

Hi @SoftFever,

I'm verry sorry to necro bump this, but I need your opinion and I think you are be the best person to ask right now.

The reason why we had to rollback the change was that the injected filament change gcode from BambuStudio ends in an inconsistent and unsafe position at the bed boundary, instead of x=0,y=0. Other gcode (e.g. timelapse) ends at x=0,y=0.

I raised a PR to fix this behavior here bambulab/BambuStudio#4848, which includes a full write up (it literally just moves the print head to the safe position x=0,y=0 in filament change gcode).

However, Bambu seems to be unwilling to merge it and asks for position validations instead. Weirdly, they ask to only validate non-injected gcode (so, invalid position data since injections happen afterwards, e.g. by filament change) and I can't make a sense out of it. Maybe it's communication issues, but anyway, not your project, not your beer.

Now, my question to you as a maintainer of Orca: would it be enough from your perspective to simply change the filament gcode to end in x=0,y=0 and re-introduce the PR that adds the spiral Z hop? This is the one solution that makes sense considering the design choices that were made for injection. Anything else is a fundamental change since the injections happen after the whole layer has been processed (which is technical debt, but works and is intended design).

I am just asking for your thoughts, I'll implement this myself - promise. If we can't fix this nasty stringing bug in BambuStudio, maybe we can do it in Orca.