Hey folks, here I can show you a big problem which I cannot understand, but which should be communicated to the developers on github, where I do not have an account.
The model is from printables 3D4U_Miele coffee clip (3D4U von Miele Kaffeeklammer by Mysticm82 | Download free STL model | Printables.com) and has a small lever, which stops motion of the central holed part. This small lever is turned in the printed part vs. the model in the slicer and stl as you can see in the pictures. So the printed part therefore cannot move at all. How could this happened is a myrical to me.
Is there a chance that the small lever came off of the bed during printing and was twisted by the nozzle? This would also explain why it “cannot move at all”, having a print failure inside the axle. Otherwise it should still be able to twist (slightly), just the wrong direction.
no the print itself works very well, done in ASA with only 15mm/s @ first layer, and the failure is allready in first layer, but I did not recognized it @ that moment because I only looked for the printing quality.
This is the second issue with such a fail. In another case, the line direction of a pattern was exactly the wrong way around, but this had no functional impact. It`s a major bug in the current software I guess
Can you share the gcode file? You can import the gcode into the slicer and see what it told the printer to do. If it truly is a communication/slicing issue the gcode should show the issues you mentioned as well
I can only slice it a second time and upload the gcode, with no repeat guarantee. Afaik orcaslicer has no import functions for gcode (only prusa and cura) and I don´t want to dive into gcode thematics at all thats why I bought a bambu
The gcode should still be on the bambu SD card and you can import gcode into orcaslicer. There is no perceivable way where I can see a slicer mess up geometry just right to be able to still print ok but have a part of the geometry twisted the exact right amount. So I still believe the contact patch from the lever is too small and the printer knocked it off of the build plate during printing. The lever was then stuck underneath the print, but able to twist the given amount and therefore the result was that the lever was twisted during printing (not during the first layer) and stitched back in the wrong place because it still fused with the rest of the print. Because in the photo it also doesn’t appear to lie exactly flat with the bottom of the rest of the print.
edit: and analyzing the gcode should give you the answer where in the process it went sideways (literally) and thus where you can fix the issue
Sorry you are wrong
in orcaslicer 2.1.0 you are only able to import .3mf; .stl; .oltp; .stp; .step; .svg; .amf; .obj.
You can take a look into the model and you can see that this lever could not be turned by the print head, the axis of the lever is not straight in the layer hight where in your imagination a knock must been happened and due to this, no way of turning is possible. The needed knock must affect several layers, I guess 15 to 30, thats not possible!
My way to solve the issue is bambustudio.
Just drag and drop. I just saw your misprint, have a lot of experience with print in place models and failures, recognized the issue and thought I could help. Sorry for the inconvenience
Some sections of the lever which has more the form as a ship´s rudder 15mm x 12mm x 5mm. It shows, that a turning by the print head during printing as a kind of an accident would have affected a lot of layers with I guess a deformed or even broken nozzle. In the printed part all the rudder surface is straight up to the top - only under a wrong angle.
just checked the SD card and user “Rossero” was mistaken (again), no gcode file of the coffee bag clip stored. Probably it´s stored in the bambu cloud.
The orcaslicer team should urgent repair their software!!!
I downloaded both the standard and Large STL models from the link.
Both sliced correctly in OrcaSlicer 2.2.0 for Windows.
I exported the Gcode and viewed the gcode file in OrcaSlicer (drag and drop, or right click in File Explorer and “Open with” OrcaSlicer). Both models appear to have the correct geometry.
So to see what happened I pulled the SD card out of my Bambu and pulled the Gcode file from it. Opened it in Bambu Studio and, what you know, the lever is the right way again??
This is crazy. Not sure what happened, but it couldn’t have gotten knocked over right? Bambu Studio seems a bit buggy to me.
The team should urgent repair their software!!!
@user_4114930961 I’m sorry. I really wanted to let this one rest after my last apology but this snarky comment pulled me right back in:
So I had to come back.
I really really wanted to help you. But you were really adamant about it being a slicer bug, and I’m still not convinced. A buggy slicer can cause errors and erratic print movements, but not subtle model changes.
The issue can be easily explained and reproduced with bad bed adhesion (as I have shown). This is really common with small contact patches like these, and still the most likely explanation for the geometry change you encountered.
I had turned off support display in my earlier screen capture. Orca places some support in that cavity that might prevent the lever from moving during the print??
(Tree(auto), Default(Grid/Organic))
I had a couple spool ends to use up, so I sliced and printed the entire standard model from OrcaSlicer, with supports. It turned out pretty well, no distortion of the geometry, except there was an unintended ~15 minute pause when I got distracted and forgot to replace the empty first spool. Two brands of PLA, so slight color difference, but they seem to be strongly adhered.
well @ least Rossaro is right. I sat the hole night beside the printer and at about layer 75 to 80 the lever turned arround without any knock only because of the vibrations, which are caused by printing this grid pattern in the outside walls. A vibration node must be there
I find it strange that I see tree supports in the screen shots, but no support in that little cavity - are you using manual supports?. All the Tree(auto) types put support there, which happens to brace the lever preventing it from moving and loosing adhesion. Inner brim might do the same. Only Normal(auto)/Snug does not place support next to the lever.
If you look at the nozzle movements around layers 75-85, you can see that the outer walls of that part are built in a counter-clockwise direction so that filament “drag” tends to pull on the very small plate contact area of the lever. Those are also the very same layers where the part gets larger, increasing the leverage causing the rotation.
OrcaSlicer and Studio are slicing correctly, the problem is just a quirk of the model.
