SoftFever
CRITICAL ISSUE: Missing Z hop: Nozzle Collision Issues During Movements
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
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.
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.
@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
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.
Try removing the checkmark on Process settings>Others>reduce infill retractions. This helped me get rid of some nasty infill collisions.
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.
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.
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.
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.
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 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
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: @.***>
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.
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.
Same Issue for me. Im new to github. Do i need to open a new issue for that? Or can i +1 this one?
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: @.***>
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.
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.
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 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.
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.
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.
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
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
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!
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.
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?