Bugfix: support spiral lift Z hop without timelapse enabled (fix stringing)

[ziehmon]

This is the successor of #4611, which was just another workaround after detailed analysis.

Problem

As outlined in the original PR, BambuStudio will not use a spiral Z hop for layer changes when timelapse is disabled and there is no infill. Actually, it will not use a spiral Z hop in other scenarios too (whenever timelapse gcode is injected), but they don't matter as much as the layer changes.

• Find a slow-motion video here: imgur
• Find a .3mf / gcode file here: missing_spiral_z.zip

Screenshot show the model's missing spiral Z hop:

Screenshot after successful fixing of the bug (see "Solution/PR Content"):

Cause

Timelapse gcode is injected into the model and Bambu Studio is technically not aware what it does - the user can change it individually. That means the position is changed without the gcode processor in Bambu Studio knowing or causing it.

It's quite important for Bambu Studio to know the position of all axes. Most importantly to:

1. prevent the collisions, e.g nozzle scratching when moving to next position because assumed position is wrong
2. do safety checks, e.g. if a spiral Z hop would move an axis out of its physical limits

For the Z position (2.), BambuStudio already extracts the last position from the timelapse_gcode and writes it to its internal state (get_last_z_from_gcode). But for X and Y, it is not implemented. We don't know why and there actually was comment suggesting to do it ("TODO") in a previous commit, but it seems it was forgotten.

Instead, a flag was implemented that marks the position as unknown/unsafe after importing timelapse_gcode and additionally set the Z hop type to normal. This definitely prevents collisions but ultimately causes stringing.

Solution/PR Content

To make layer changes use spiral Z hop, we need to do two things:

1. Change lift mode to spiral (the easy part)
2. Flag the position as safe, so import the axis positions after timelapse_gcode execution (the hard part)

So this PR does the following:

• Extent the GCodeProcessor::get_last_z_from_gcode method to support X and Y coordinates
• Change the usage of this method in timelapse handling to retrieve X and Y position too
• Remove the flag m_writer.set_current_position_clear(false); that sets the position as unknown/unsafe
• Use the optimized method/approach for other gcode injection too (change_filament_gcode)

[Roemer]

Respect for your work. Hope this can be finished and merged anytime soon as I also suffer from some stringing.

[ziehmon]

Respect for your work. Hope this can be finished and merged anytime soon as I also suffer from some stringing.

I just finished it and the compiler ran fine. I'm still doing some final test but would you be interested to test an AppImage for me, if you're able to run one?

Edit: test are completed, I have a working AppImage/binary. Ready for review.

[Roemer]

I just finished it and the compiler ran fine. I'm still doing some final test but would you be interested to test an AppImage for me, if you're able to run one?

Edit: test are completed, I have a working AppImage/binary. Ready for review.

If you could provide a Windows binary, I could give it a run.

[XunZhangBambu]

@Roemer Good Job.I also want to know why you abandoned the previous PR. Extract the lift operation from the gcode is a simpler approch. Even if you record the position in code, the timelapse gcode will be skipped during actual printing if you disable timelapse, and the state recorded in the program will still be inaccurate.

[Roemer]

@XunZhangBambu The PR is from @ziehmon , I just volunteer to test if needed.

[XunZhangBambu]

@Roemer Haha, sorry, I asked the wrong person. @ziehmon Please look at the question I raised above.

[ziehmon]

@Roemer Good Job.I also want to know why you abandoned the previous PR. Extract the lift operation from the gcode is a simpler approch.

The answer is simple: because the original approach in the previous PR causes a second, unrequired Z hop.

BambuStudio always inserts a Z hop after timelapse_gcode insertion. If we always add a Z hop in the timelapse_gcode (previous PR) too, this adds a second hop to the existing one. The Z hop in timelapse_gcode (previous PR) would be is a spiral, which fixes the problem, but the normal Z hop in BambuStudio (before this PR) continued to exist. This caused stringing for me too, maybe because of interruption of retraction.

Also, by triggering spiral Z hop inside the gcode parser, we can utilize collision avoidance, feedrate generation etc.

However, even with this PR, there is a second Z hop: when timelapse is actually enabled, the one that is written in timelapse_gcode after the condition M1002 judge_flag timelapse_record_flag. This is not easily solvable because the gcode parser could not possibly know if it has to insert the Z hop at all - the user could disable timelapse after the gcode has been generated already. It's the best we can do for those, who don't have timelapse enabled. If its enabled you would have a wipe tower and if there is no wipe tower, the users need to accept stringing/oozing as stated in the Wiki.

Even if you record the position in code, the timelapse gcode will be skipped during actual printing if you disable timelapse, and the state recorded in the program will still be inaccurate.

You are correct. It is a worst case assumption! It just checks if a collision could happen when the user enables timelapse, not if it actually will happen. Think about it as simulation if the timelapse would be anbled at any point. But true, the position is not fully accurate. I think thats the best we could do :)

Hope this makes it clear. Thank you for your review!

[ziehmon]

After thinking about it again, we could remove the get_last_pos_from_gcode entirely, because the spiral Z hop in timelapse_gcode does not do it too, right? That's your decision. I tried to keep the code the way you originally implemented, I thought you implemented gcodegen.writer().set_current_position_clear(false); and the check in travel_to_xyz for a reason but since its not chcked in timelapse_gcode at all, maybe we can omit it.

[lodgnewt]

@ziehmon could you send this pr to orcaslicer?

[ziehmon]

@ziehmon could you send this pr to orcaslicer?

@lodgnewt Will look into it. The PR for Orca needs to be different because they integrate the upstream code from Bambu Lab manually with modifications to support other printers but it shouldn't differ too much. Orca definitely has the bug too, I checked that.

[ziehmon]

@lanewei120 since this PR is approved, do you think we can ship it into 1.9.4.59? I saw you're building this version right now.

[lanewei120]

@ziehmon I am afraid it can not catch up with 1.9.4.59 for limited time

@XunZhangBambu please continue this discussion

[XunZhangBambu]

@ziehmon The operation of get_position does not need to be removed, as at least when timeplase is enabled, we can obtain the correct position.In your test, does the spiral have less wire drawing compared to the normal lift?

[ziehmon]

@XunZhangBambu

The operation of get_position does not need to be removed, as at least when timeplase is enabled, we can obtain the correct position

Perfect, that was my idea too.

In your test, does the spiral have less wire drawing compared to the normal lift?

Absolutely, yes. Especially with short layer times. I attached the .3mf of my test model. Stringing was gone entirely after the modification.

It is also noted in the Bambu Studio UI, that spiral Z hop will prevent stringing. Also stated in Bambu Wiki.

[tsmith35]

@ziehmon did you notice that "timelapse" was misspelled as "timepals" in the old code? Just noticed yesterday while digging through OrcaSlicer code.

[ziehmon]

@ziehmon did you notice that "timelapse" was misspelled as "timepals" in the old code? Just noticed yesterday while digging through OrcaSlicer code.

Yes, noticed this and fixed it together with my other changes. I looked into Orca too and I think I remember it being misspelled there too. Just a small typo, I guess.

Edit: look like the typo does not exist in Orca. @tsmith35 thanks for porting this to Orca (looks like you are about to do it).

[sydude]

Is the modified g-code compatible with the A1 Mini as well? I’m experiencing the exact same stringing issues.

[ziehmon]

Is the modified g-code compatible with the A1 Mini as well? I’m experiencing the exact same stringing issues.

@sydude the modified G Code was not continued due to causing other problems. This MR solves the actual issue and is compatible with all kind of Bambu Lab printers. The bad news is, to test it, you need to compile. Right now, I can only provide linux executables for testing.

[ziehmon]

@XunZhangBambu was my answer to your questions sufficient? Do you need any other details?

I can recommend looking at the slow-motion video I did at imgur to see it yourself.

[ZackySteel]

Just trying to come up to speed, since the issue I was experiencing was merged into the same topic. I really haven't experimented with the various types of Z-hops, as I never tended to use them even before moving to Bambu/Orca, but I was still experiencing massive surface blemishes and knocked-over/failed prints due to what I've seen others have discovered to be missing retraction moves in the G-Code generated. I believe it was 1.8.1 people mentioned being the last release before this issue began, but I haven't gotten much of a chance to test with that version yet. I would have thought the only connection between these two topics would be that Z-hops are often done when retraction moves are scheduled to happen and that, as such, the slicer not generating G-Code for retraction moves would also mean it might not generate a Z-hop there either, but I feel that can't be the reasoning behind the merge. From what I have understood thus far (and I'm sure I don't have all the information), it seems like the missing retraction-moves are the core problem, rather than the missing Z-hops, so it seems odd to merge it into the Z-hops topic rather than vice-versa or even at all.

Just trying to make sure I understand everything here, so info from anyone more in-the-know than I am would definitely be appreciated! I'm really hoping this gets solved soon, as I'm up to my eyeballs in under-performing printers at the moment and want to get this A1 working so I can actually complete some of the prints that have been piling up!

[ziehmon]

Just trying to come up to speed, since the issue I was experiencing was merged into the same topic. I really haven't experimented with the various types of Z-hops, as I never tended to use them even before moving to Bambu/Orca, but I was still experiencing massive surface blemishes and knocked-over/failed prints due to what I've seen others have discovered to be missing retraction moves in the G-Code generated. I believe it was 1.8.1 people mentioned being the last release before this issue began, but I haven't gotten much of a chance to test with that version yet. I would have thought the only connection between these two topics would be that Z-hops are often done when retraction moves are scheduled to happen and that, as such, the slicer not generating G-Code for retraction moves would also mean it might not generate a Z-hop there either, but I feel that can't be the reasoning behind the merge. From what I have understood thus far (and I'm sure I don't have all the information), it seems like the missing retraction-moves are the core problem, rather than the missing Z-hops, so it seems odd to merge it into the Z-hops topic rather than vice-versa or even at all.

Just trying to make sure I understand everything here, so info from anyone more in-the-know than I am would definitely be appreciated! I'm really hoping this gets solved soon, as I'm up to my eyeballs in under-performing printers at the moment and want to get this A1 working so I can actually complete some of the prints that have been piling up!

Just trying to come up to speed, since the issue I was experiencing was merged into the same topic. I really haven't experimented with the various types of Z-hops, as I never tended to use them even before moving to Bambu/Orca, but I was still experiencing massive surface blemishes and knocked-over/failed prints due to what I've seen others have discovered to be missing retraction moves in the G-Code generated. I believe it was 1.8.1 people mentioned being the last release before this issue began, but I haven't gotten much of a chance to test with that version yet. I would have thought the only connection between these two topics would be that Z-hops are often done when retraction moves are scheduled to happen and that, as such, the slicer not generating G-Code for retraction moves would also mean it might not generate a Z-hop there either, but I feel that can't be the reasoning behind the merge. From what I have understood thus far (and I'm sure I don't have all the information), it seems like the missing retraction-moves are the core problem, rather than the missing Z-hops, so it seems odd to merge it into the Z-hops topic rather than vice-versa or even at all.

Just trying to make sure I understand everything here, so info from anyone more in-the-know than I am would definitely be appreciated! I'm really hoping this gets solved soon, as I'm up to my eyeballs in under-performing printers at the moment and want to get this A1 working so I can actually complete some of the prints that have been piling up!

@ZackySteel may I ask you to have look on this comment I wrote: #3423 (comment).

This issue is not related to your problem. It is about stringing and will help a lot with it, but probably not with other Z hop related issues such as surface scratching and knocking over prints.

[ZackySteel]

@ZackySteel may I ask you to have look on this comment I wrote: #3423 (comment).

This issue is not related to your problem. It is about stringing and will help a lot with it, but probably not with other Z hop related issues such as surface scratching and knocking over prints.

Ah, yes, I read that and appreciate you taking the time to provide that list! I think I may have caused some confusion though, as I followed a link from the topic I was on to this one, as it was provided by someone who said it had been merged into this topic. I may very well just be confused about something, but that is what I was trying to figure out, as the two topics don't necessarily seem to have a ton of crossover aside from the fact that z-hops are often ordered to occur during retraction moves, but that seemed a someone thin relation to completely merge the two topics for.

I've already gone through pretty much everything I can to overcome the issue I found mention of in the topic being merged into this one with, unfortunately, with no success. Now I'm just trying to make sure I understand why it is being merged into this and if the underlying missing retraction move G-Code commands have been identified as a problem (I really hope that's the case) and if we can be looking forward to a fix or at least a timeline for a fix relatively soon.

Thanks again for taking the time to check in; I appreciate it!

[tsmith35]

@ziehmon

Edit: look like the typo does not exist in Orca. @tsmith35 thanks for porting this to Orca (looks like you are about to do it).

The typo was here

I finally got a chance to spend a few minutes on the port. PLMK if you see any issues.
it's over here

[XunZhangBambu]

@ziehmon yes, we will merge the pr soon ！

[ziehmon]

@ziehmon yes, we will merge the pr soon ！

Very nice, thank you for your extensive review. I am on standby if you need anything 👍🏻

[tsmith35]

@ziehmon eh, I'm not the smartest git user ever. :-) It's now here:

PR#6709

[ziehmon]

@ziehmon eh, I'm not the smartest git user ever. :-) It's now here:

PR#6709

Nonetheless, you made it and this PR looks clean! Thanks for your work. I will have a look into it tomorrow.

[ZackySteel]

For myself and anyone else who are still mostly baffled by the workings of Github, what's being referred to in the last few comments? XD

PR mean pull request or push request? Mainly if anyone can english-ify it so I'll have that translated in my brain for when I see other stuff like it on here! Thanks!

Also, I finally got the files onto my home computer, yet realized it doesn't allow me to upload that file type. What's the normal protocol for uploading G-Code and other print-related files?

Thanks for all the help!