Interesting
If you inspect it in the slicer preview, is the “support transition” the topmost interface layer, or the bottommost one? What is its layer height? Does it run at a different speed/fan?
its the darkest of the greens, the “bottom” of the interface sandwich
Layer height appears to be .16 with independent support layer height off
and 0.30something with ISLH turned on
Additionally the support interface seems to ALWAYS be vertical to the support structure lines, in these screenshots i set pattern angle to 45 degrees, expecting only the base pattern to rotate, but all of them did.
The interface does rotate with the pattern in Orca
But it stays under angle to the structure
I suspect thats what cause the support structure to collapse under its own weight?
I’m not sure what a good solution is. It would be nice if we could change the speed selectively on different parts of the print to accommodate these kinds of failures. For instance, imagine you could “paint” a speed onto different parts of the pre-view print.
I don’t know if this is what you had in mind and my memory is a bit hazy here but you can change the speed temporarily on layers. Something like, you add a cube to the part and make it a certain height. Then you add a speed modifier to it I think. Someone feel free to correct me. You may also be able to do it using the layer hight feature where you input a layer hight and it shows it in green then choose an effect.
Sadly im out of time for testing for now. I spent nearly 30 continuous hours on troubleshooting this, and now my production is way behind, so i need to marathon a bit ahead. Will certainly try again soon , but for now i resorted to tree supports. Its close to the bridging layer so ill post results with that too, soon, but itll be a bunch of hours before i have the h2d free for testing again .
And honestly… Thats not why I paid 2.5k…
Yes, tree supports work as expected. Issue lies only with normal, and im becoming sure its something to do with that additional layer
I notice that I sometimes get 2 interface layers while asking for 3.
However, so far no issues with supports.
But then again, I don’t use the same material for the support interface. I simply use a PETG interface for PLA parts, and PLA for PETG parts.
I only need a shadow (support) profile and match the bed temperature to the material it supports.
This is one of the reasons that I wanted a dual nozzle machine.
I also have the feeling that material profiles that have been modified earlier for a different Bambu machine interfere with the H2D material profiles.
Something that I can’t prove because the H2D is my first Bambu Labs printer.
It might bug out if you enable independent support layer height iirc.
However, we have to admit that the current status of support generation is a hot mess. It has went completely garbage since 2.1.0 as default tree supports would now grow into the model. The normal support would also be generated very unreliably causing the kind of failure that OP is having, unless you tune the support settings carefully to avoid long straight single layer lines. It’s not only just bugging H2D, but also other bambu machines.
E.g., for this print this support would highly likely to fail because it’s basically printing 1 single layer of support line that is weak, and potentially get not enough cooling or too much cooling at the same time!
My current solution for this particular issue is to either adjust pattern angle for a specific part, or change the base pattern type to either Rectilinear Grid or Honeycomb. Honeycomb is a bit too slow and using too much filament, so most of the time I just use rectilinear grid instead.
This is what rectilinear grid looks like. Much less likely to cause that issue.
Update:
Tree supports worked better but still not perfect. Again where in other machines the job is done perfectly everytime, here the supports failed to 100% support the bridge and thats visible on the failing ironing on top (ironing normally gives me a nearly seamless surface that you cant say is printed)
Moreover, another attempt , using snugg normal supports under 45 degree pattern angle.
The pictures speak for themselves.
Also this is without indepedent support layer height.
I’m not sure what the print is so forgive my blunt question, but have you tried printing it in another position? Like stand it up and print vertically with tree supports?
Νo, doesnt work, doesnt need to. The question here is why a 2.5k machine is struggling with the exact same jobs that far cheaper ones have printed 1000s of times…
I am not sure what material you are printing, but have you considered support material for the interface? I use PETG for PLA and vise versa. You might want to read the wiki on that.
You have a dual nozzle machine that is perfect for this.
You have zero gap and therefore a firm support.
I presume you have the ironing tuned on an unsupported piece.
I personally don’t like ironing. To much hassle to tune it perfectly.
Its all ABS. Again, this is not a “help I cant print this model from Makerworld” … Its a production line, products I have printed and am printing time and time again, which have a certain quality, and no less is acceptable. The dual nozzle is for another purpose much more complicated than the current issue, which honestly if even the supports dont work as expect, im not gonna reach that point.
Ironing is tuned and should produce the wanted results, IF the layers are supported as expected.
Again , P1P, Neptune 3plus, Nep4Max, Voron Trident 300, all these print the EXACT same jobs even as we speak. Not once not twice. Again and again and again every day, nonstop. Theres a good reason im not disclosing more information, but its not needed. When all these machines print these without issue to the actual models, but the H2D just struggles, Im starting to wondering what did I pay for? Its not an asset anymore, it was supposed to assist boost and debottleneck my production and instead im wasting more time and materials trying to figure out why something that worked EVERY damn time since my original ender , is not working on the PROSUMER machine…
And on top of that, ignoring fails, clumps on nozzle, debris on bed, printing on air, spaggheti yada yada, the H2D AI didnt even flinch… not even a notification . Im tempted to deliberately grease the bed so it results in a massive failure and see if the AI is gonna even do anything now…
To clarify, advise such us “slow down overhangs” , “use trees” , “change orientation” “use support material” no. Thats not how it works. These are answers from 2010… OBVIOUSLY if i want to use the machine succesfully and not just have a huge cube of garbage metal and glass, i need to make these adjustments but this is H2D we are talking about. THERES ABSOLUTELY NO REASON that the most “advanced” Prosumer printer cant print something that its cheapest predecessor prints succesfully again and again. Yes the machine works amazing if no supports are needed but thats virtually impossible for my models, and thats not how the machine was advertised, they didnt say “yeah its advanced but be warned the most basic and needed function is impossible because reasons” . Its supposed to be a tool, not an obstacle
On a side note, why am I suspecting that Bambu Studio might be actually slicing and expecting support material , while I just slice for one material ?
Like, I havent used supports material before, dont need to, my tuning results in almost seamless supported layer, but on a machine and slicer that work as expected (i.e P1P and Orca). Here bambu just decides to put an addional support layer , and i cant help but think that its calculated based on printing properties of a support material its “EXPECTING” but ultimately not availble in the end as it was never specified and never supplied, if that makes any sense.
I mean if the slice calls for a material that wouldnt shag under heat/weight but would instead fuzz it makes sense if its printing abs to fail it. But I cant make any other sense really. Even the fact that in Orca and BS rectilinear and rectilinear interlaced seem to have switched places , and one generates them under angle and the other vertical to the support structure… BAH…
Answering the question as to why it fails on the H2D and not the other machines is going to require diagnosing exactly why the failure is happening in the first place. That seems to be the question you want answered more than how to workaround the problem and move on. Maybe if you could watch the failure happen in slow motion it might help determine exactly how the failure happened? The camera records every frame to your USB drive, assuming you have one installed. If you move the part of the model where the failure is happening close to the camera, you could step through each frame on playback to watch it happen (28 frames per second). You have to load your usb drive into a computer to do this kind of playback, as the Bambulab interface doesn’t support it directly. However, they are ordinary video files, so playback on the computer won’t pose any challenges.
Τhats exactly what I do , but real time, I just watch and note. Remember, im 100% of my time here, so thats not unfeasible. Its exactly what it sounds like, the trees either are coming out of sync as to what Z the nozzle expects, so it just pushes them down, BUT this is not the case, as there is not nozzle drag, no scrapping, and no fusing.
Instead its the opposite, so I conclude its a heat issue. The structure either does not get enough cooling , probably due to speed in combination with heated chamber. I tried dropping the plate to 90 from 100-105, no change. I actually more and more suspect that extra layer of interface that Bambu Studio Insists on adding, will try to set it to 1 and test again after i get a bit of slack from the bottleneck in the line.
1 Like
sounds like a promising line of inquiry based on an already identified difference.
It’s a pity we don’t have access to Orca slicer for H2D.
1 Like
Ιm trying to find a way to Export the supported model straight from orca, and import it in bs, and see what happens. Might actually just pull the gcode and reverse it into an stl, it will be lower ress but might work, will try in about 8 hours that the current job ends.
1 Like
Given that you’re printing just a single color–i.e. fairly generic g-code–it seems like it should work. I suspect there’s something in the file which identifies which printer it’s intended for, so you may have to locate that and change it to complete the spoof. Probably somewhere near the beginning of the g-code file. You might also need to insert some g-code near the beginning telling it which print-head to use, but maybe you’ll get lucky and it will default to one or the other without demanding that you say which.