CRITICAL ISSUE: Missing Z hop: Nozzle Collision Issues During Movements

[amzaldua]

OrcaSlicer Version

1.9.0

OS version

Mac OS Sonoma 14.2.1

Additional system information

Apple M1 Macbook

Printer

Bambu Lab A1

How to reproduce

Printing a G-code generated with Orca Slicer with a non planar superior surface. I attached an example.

Actual results

The nozzle scratch over piece. Check the movement in layer 142 between 59672 and 59674 lines, there is no a Z hop movements.

Expected results

The nozzle should be retract in Z axis between movements in the same layer and in the same type of line. Always.

Project file & Debug log uploads

issue nozzle dragging.3mf.zip Archivo.zip

Checklist of files to include

• [X] Log file
• [X] Project file

[amzaldua]

Please, check this as soon as possible. I came from BambuStudio because of the same issue, and to my surprise, your software has exactly the same problem. This issue damages our nozzle and ruins our projects because the piece is scratching and detaching from the bed. Bambu Support is missing.

[CCS86]

It's called Z-hop. Retraction is an extruder move in the negative direction.

[amzaldua]

It's called Z-hop. Retraction is an extruder move in the negative direction.

Updated. In the context of CNC machining, it is accurate to use the term "Z retractions," but I acknowledge that in the world of 3D printing, it might lead to misunderstandings. Thank you for the correction.

[tsmith35]

@amzaldua you left out the forum link with the expanded description. I will attach the link at the bottom.

Here is my comment from the same issue in Bambu Studio:

I think I understand the issue related to the nozzle scratching. It seems that the slicer doesn’t generate retractions when it moves rapidly within the same type of line. In other words, if the nozzle quickly moves from one XY point to another XY point, at the maximum feed rate, and both points belong to the same type of line, the slicer doesn’t {hop} in the Z-axis, even if the trajectory passes through lines already deposited in the same layer.

It is quite fortunate that you have "extensive knowledge of G codes and the kinematics of complex 5-axis machines" as you stated in the forum. The overwhelming majority of users would not have been able to debug as effectively at the gcode level.

https://forum.bambulab.com/t/a1-and-bambu-studio-issues-z-retractions-and-axis-limits/48872

[amzaldua]

You are right. Thank you!

[Loriborn]

I wanted to verify that I am experiencing this issue with OrcaSlicer as well, after trying it out due to this issue while using Bambu Studio.

[ReinhardC]

Try removing the checkmark on Process settings>Others>reduce infill retractions. This helped me get rid of some nasty infill collisions.

[amzaldua]

Try removing the checkmark on Process settings>Others>reduce infill retractions. This helped me get rid of some nasty infill collisions.

Thank you. I'm going to test this option. It shows promise.

[Loriborn]

Try removing the checkmark on Process settings>Others>reduce infill retractions. This helped me get rid of some nasty infill collisions.

Thank you. I'm going to test this option. It shows promise.

I have tried using this setting, and still experience the issue.

[Snelso91]

I have the exact same issue, and currently I have also disabled reduce infill retractions, but that only helps the printer avoid infill collisions. The main area I'm having problems with the nozzle colliding due to lack of z hop, is at the end of each layer when the nozzle travels to the prime tower (if you are doing a multimaterial print or using smooth timelapse this will be enabled), as I detailed in this related issue: #3656 Because the nozzle does not z hop when travelling to the prime tower, it often scrapes on several parts on the way there, including delicate structures such as regular grid supports that can easily be knocked over by the nozzle.

[ReinhardC]

Try removing the checkmark on Process settings>Others>reduce infill retractions. This helped me get rid of some nasty infill collisions.

Thank you. I'm going to test this option. It shows promise.

I have tried using this setting, and still experience the issue.

Try changing z-hop type to normal (move up, travel, move down). The default z-hop type is slope (moves up while traveling). If this doesn't help try increasing the z-hop distance.

[ReinhardC]

I have the exact same issue, and currently I have also disabled reduce infill retractions, but that only helps the printer avoid infill collisions. The main area I'm having problems with the nozzle colliding due to lack of z hop, is at the end of each layer when the nozzle travels to the prime tower (if you are doing a multimaterial print or using smooth timelapse this will be enabled), as I detailed in this related issue: #3656 Because the nozzle does not z hop when travelling to the prime tower, it often scrapes on several parts on the way there, including delicate structures such as regular grid supports that can easily be knocked over by the nozzle.

Could be worth a try testing z-hop type 'normal' here too, but I suspect this is a different issue maybe due to a bug in gcode construction.

[sheikoner]

I have the exact same issue, and currently I have also disabled reduce infill retractions, but that only helps the printer avoid infill collisions. The main area I'm having problems with the nozzle colliding due to lack of z hop, is at the end of each layer when the nozzle travels to the prime tower (if you are doing a multimaterial print or using smooth timelapse this will be enabled), as I detailed in this related issue: #3656 Because the nozzle does not z hop when travelling to the prime tower, it often scrapes on several parts on the way there, including delicate structures such as regular grid supports that can easily be knocked over by the nozzle.

Could be worth a try testing z-hop type 'normal' here too, but I suspect this is a different issue maybe due to a bug in gcode construction.

I´ve the same problem sience 21 Dec. I tried all the things. Changing infill type, turning on z hop on filament and extruder settings, increasing the distance, normal z-hop, cleaning the surface multipe times, lot of different filament brands and temperatures, re calibrating the machine, reset factory values, trying again. Always the nozzle ruin my prints, specially when have supports or printing multiple pieces at the same time.

It´s not just the z-hop the problem, i thing the Z steps motor dont work fine at the same height than layers. It looks like z axis dont go up 0,2mm, maybe 1,98 or something, and after few lyers, the nozzle starts scratching and ruins the print.

I´ve tried lot of public profiles, testing my own, and still happens. Its maybe defective machine or firmware bugs, i dont know, because if this is the same for everyone, i dont understand why people dont report it. Maybe printing simple forms without supports they have success prints, but my experience is so bad since the first print i tried.

Some prints finished, poor quality and top layers looking horrible and scratched. Here some pictures and videos.

sheikoner - Gloom Hand - GitHub test.zip

https://github.com/SoftFever/OrcaSlicer/assets/116770291/c3644a3f-53d9-4bec-939c-27e001952dd2

https://github.com/SoftFever/OrcaSlicer/assets/116770291/672ed359-9321-472f-814b-d346a43addc0

[CCS86]

You guys should report this issue in the Bambu Studio repo

[sheikoner]

I did it on the repo, and the costumer support. Just adding some info because the op suggested me.

El mar, 23 ene 2024, 14:55, CCS86 @.***> escribió:

You guys should report this issue in the Bambu Studio repo

— Reply to this email directly, view it on GitHub https://github.com/SoftFever/OrcaSlicer/issues/3747#issuecomment-1906110041, or unsubscribe https://github.com/notifications/unsubscribe-auth/A324L42LVBSVRY6P4CFS7H3YP66MPAVCNFSM6AAAAABCCQ4OO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBWGEYTAMBUGE . You are receiving this because you commented.Message ID: @.***>

[amzaldua]

You guys should report this issue in the Bambu Studio repo

The problems are exactly the same with both slicing programs. In fact, when I detected the issue with Bambu Studio, I turned to Orca Slicer and encountered the same problem. What is reported here pertains to Orca Slicer.

[CCS86]

You guys should report this issue in the Bambu Studio repo

The problems are exactly the same with both slicing programs. In fact, when I detected the issue with Bambu Studio, I turned to Orca Slicer and encountered the same problem. What is reported here pertains to Orca Slicer.

That's my point. The bulk of the code is from Bambu Labs, so if the issue exists there, it's probably their bug. Orca slicer is just a modified version of Bambu Studio, with added features. It's not really the volunteer developers of Orca slicer's job to fix paid Bambu Lab employees bugs... not as a first course of action anyway.

[MatzeX71]

Same Issue for me. Im new to github. Do i need to open a new issue for that? Or can i +1 this one?

[sheikoner]

You have to post in the Bambu slicer thread, they are just volunteers developers from open source software that is not official of the brand.

El mar, 23 ene 2024, 15:18, MatzeX71 @.***> escribió:

Same Issue for me. Im new to github. Do i need to open a new issue for that? Or can i +1 this one?

— Reply to this email directly, view it on GitHub https://github.com/SoftFever/OrcaSlicer/issues/3747#issuecomment-1906153002, or unsubscribe https://github.com/notifications/unsubscribe-auth/A324L4ZPNXF42PMKAPAN5VDYP7BDFAVCNFSM6AAAAABCCQ4OO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBWGE2TGMBQGI . You are receiving this because you commented.Message ID: @.***>

[amzaldua]

You guys should report this issue in the Bambu Studio repo

The problems are exactly the same with both slicing programs. In fact, when I detected the issue with Bambu Studio, I turned to Orca Slicer and encountered the same problem. What is reported here pertains to Orca Slicer.

That's my point. The bulk of the code is from Bambu Labs, so if the issue exists there, it's probably their bug. Orca slicer is just a modified version of Bambu Studio, with added features. It's not really the volunteer developers of Orca slicer's job to fix paid Bambu Lab employees bugs... not as a first course of action anyway.

Okay, I understand, but if another user of Orca Slicer only has the same problem, do they also have to go to Bambu Studio support? I created this issue post to help people with the same problem from other brands of 3D printers. I don't want to undervalue the work of the volunteers, of course, but I believe that if I have a problem with software, I should report it to the responsible party for that software, not another one.

[Snelso91]

Could be worth a try testing z-hop type 'normal' here too, but I suspect this is a different issue maybe due to a bug in gcode construction.

@ReinhardC Thanks, this worked! For some reason, setting z-hop type to Auto, Slope or Spiral fails to generate a z hop entirely, which definitely seems like a bug, but switching to Normal strangely brings back the missing z hop when travelling to prime tower at the end of a layer.

For example, here is the gcode and preview with spiral z hop selected (note the lack of spiral hop on the pink retraction dot and travel move in the bottom right):

And here is the exact same file sliced with z hop type set to Normal (the z hop is added before the travel this time):

Obviously this is only a workaround, as it replaces all the slope and spiral z hops that would normally be generated by the auto setting with a normal z hop instead, so I'm expecting to see some increased stringing, but that is better than having a print failure from no z hop at all.

[AndreySemjonov]

I think avoid printed parts should be made better in OrcaSlicer. Same as it is in Cura. But still collision shouldn't be a problem with correctly calibrated flow rate?

[tsmith35]

I think avoid printed parts should be made better in OrcaSlicer. Same as it is in Cura. But still collision shouldn't be a problem with correctly calibrated flow rate?

I agree that collisions shouldn't be a problem if everything is set correctly, but that is not always the case. For example, I am extremely cautious when setting up prints, but I'm not perfect by any means. So I make mistakes. Z-hop is intended to provide a level of tolerance for non-ideal conditions. If everything worked as intended (desired), Z-hop would be totally unnecessary.

Imperfection in real-world conditions is why an interstate highway lane in the US is 12 feet wide, even though a typical sedan is 6 feet wide, and a typical SUV is 7 feet wide. Germany allows 12.3 feet for the right lane and 11 feet for other lanes. The extra room is to allow for human error.

[AndreySemjonov]

I think avoid printed parts should be made better in OrcaSlicer. Same as it is in Cura. But still collision shouldn't be a problem with correctly calibrated flow rate?

I agree that collisions shouldn't be a problem if everything is set correctly, but that is not always the case. For example, I am extremely cautious when setting up prints, but I'm not perfect by any means. So I make mistakes. Z-hop is intended to provide a level of tolerance for non-ideal conditions. If everything worked as intended (desired), Z-hop would be totally unnecessary.

Imperfection in real-world conditions is why an interstate highway lane in the US is 12 feet wide, even though a typical sedan is 6 feet wide, and a typical SUV is 7 feet wide. Germany allows 12.3 feet for the right lane and 11 feet for other lanes. The extra room is to allow for human error.

Yes I totally agree. But I mainly wanted to tell it is nice to have same functionality of avoiding printed parts as Cura have. If you prints fast 200mm/s z hop ads to much extra time.

[tsmith35]

Yes I totally agree. But I mainly wanted to tell it is nice to have same functionality of avoiding printed parts as Cura have. If you prints fast 200mm/s z hop ads to much extra time.

Agreed. Having non-perpendicular z-hop (slope, spiral or auto) does save a lot of time. I wonder what causes Normal z-hop to work fine, but any other mode seems to miss spots? I don't know if that's a bug or intentional.

[Till-print]

salut! J'ai exactement le même soucis, bien que j'ai réglé le zhop sur normal , il y a certain moment ou la buses vient frotter le remplissage et ou des support!

quelqu'un aurrais une solution SVP! j'ai lu la page entière et se serais un bien default dans Orca ? cimment réglé cela? si a chaque impression il faut modifier le gcode cest pas terrible non? deplus j connais pas grand choses en vode xD x)

MERCI D'AVANCE POUR VOTRE AIDE

[Iridium-IO]

Try resetting your Z offset to 0 if you've changed it in OrcaSlicer. I had a similar issue and that seemed to do the trick for me at least. See here #3108

[sheikoner]

Try resetting your Z offset to 0 if you've changed it in OrcaSlicer. I had a similar issue and that seemed to do the trick for me at least. See here #3108

That´s so interesting and makes sense. I detect that the nozzle kicks more on solid infill layers after touching z-hop distances on the slicer, but i´ve not investigate about z offset, because i don´t know whats the value that the printer puts on automatically. I´m deffinetly going to check this.

Thanks!

[Meth0d007]

Finally an explanation why prints get kicked of the plate by the nozzle in Orca 1.9 and work fine in 1.8. I will try the z-hop normal workaround.

[Meth0d007]

The z-hop normal workaround did not work for me, i am still slicing with 1.8 because of this issue. Otherwise i have large slim Objects that are located close to eachother kicked over by the nozzle. Any other workarounds you guys are using?

[Exeu]

I have the same issue. There is simply no ZHop on travels (regardless what i change in settings). This leads to the nozzle scrachting quite hard over the printsurface and specially it collides often with the infill. Now there was a collision which was so heavy that it bended my Revo Nozzle.

I am considering to switch back to PrusaSlicer since i had no luck with orcaslicer so far. Maybe it is a candidate for porting the whole ZHop stuff back from PrusaSlicer instead of going over BambuStudio? I dunno @SoftFever @Noisyfox

[Sekilsgs2]

same here Nozzle scratch when moving from 7108 to 7109 position without retracts.. This 100% bug! Please fix this!

[Sekilsgs2]

same here Nozzle scratch when moving from 7108 to 7109 position without retracts.. This 100% bug! Please fix this!

:) This no bug this i'm enable feature decrease retracts on infill layers :-D Sorry!! All good now!!

[Novichek-13]

The problem is still relevant, I thought that I had something wrong with the position of the z-axis beam or the bed. The nozzle was constantly hitting the model and the supports. Having discovered this topic, I checked the ways of moving the head in ORCA and found that the code for lifting the nozzle does not work when moving. Going into PrusaSlicer 2.7.4 and slicing the model there, I found that everything works as it should. Will there be a solution to this problem in the coming releases? My printer is Anycubic Kobra 2 Pro

[Silvenga]

It might be useful to note that this occurs with the calibration models generated by Orca too. The top layer is scraped by the head during travel, for example, in the retraction test.

I can also confirm that for a given model, Prusa Slicer doesn't produce the same scraping. Although, I suspect bed leveling on the MK4's 6.0 firmware might have been causing problems - I'm planning on running the same g-code on the new 6.0.1 release which fixed load cell issues.

[SoftFever]

I will take a look later. Sorry for not being very responsive on issues here. Life and my day job have kept me very busy, so I can't devote too much time to reading issues. My initial impression is that it's not a bug; the absence of z-hop for moves from infill to infill is by design, a behavior derived from PrusaSlicer. However, this can certainly be improved, especially for top surfaces. I'll provide more updates once I’ve had a closer look at the problem.

[Novichek-13]

It might be useful to note that this occurs with the calibration models generated by Orca too. The top layer is scraped by the head during travel, for example, in the retraction test.

I can also confirm that for a given model, Prusa Slicer doesn't produce the same scraping. Although, I suspect bed leveling on the MK4's 6.0 firmware might have been causing problems - I'm planning on running the same g-code on the new 6.0.1 release which fixed load cell issues.

I spent a couple of hours checking that it might be an error in any configuration of the rod or print profile I created. But in the end it turned out that this was a printer profile error! ORCA does not have a profile for my Kobra 2 pro, I took it from the network. I can't explain what happened to it, I changed all the values and cut it and nothing helped. After that, I just deleted the profile and imported it again, and everything worked. Moreover, after spending a little more time and changing different settings and performing cuts, I have never encountered a repeat bug.

[SoftFever]

same here Nozzle scratch when moving from 7108 to 7109 position without retracts.. This 100% bug! Please fix this!

Have you tried to disable the "reduce infill retraction" option?

[SoftFever]

I can't reproduce the problem you mentioned. In the attached project, retraction and z hop are properly performed once you turn off the "Reduce infill retraction" option

[Meth0d007]

Im not sure that this reduce infill retraction was the real issue here. In my uneducated opinion it just works around some other problem introduced in Orcaslicer 1.9. I cant really pin down what might be the issue but i here is what i can observe: I initally encountered this problem because all of a sudden the same project started to knock over large parts at the end of a 10 hour print where literally nothing had changed BUT the orcaslicer version. So if i compare these 2 versions (1.8.2 - 2.0) with my 10h project i can see an increase of print time for about 45 minutes using the same filament setting and the same default 0.2mm Standard @BBL X1C profile. That is with the default "reduce infill retraction" setting checked, remember it does not knock over / scratch infill when sliced with 1.8.2. Print time again changes alot between the two versions with unchecking / checking just the "reduce infill retraction" setting. So there must be alot more going on "behind the scenes" in orcaslicer or regarding the default 0.2mm Standard @BBl X1c profile ...

PS: i just noticed i cant Login no more once i revert back to 1.8.2v ... i hope thats just a temporary issue

[Meth0d007]

@SoftFever maybe there is some more information that might help about this here: https://github.com/bambulab/BambuStudio/issues/3423