Organic support prints higher than print itself, print crashes, and nozzle melts onto print 3 hours into print

[b4de4nd]

Description of the bug

So print is based with organic support for an overhang at 75mm from build plate. Support looks okay in slicer

However on the right side of the print, support was so filled up that the Pinda crashed into it and took the model of the bed, but not more than the nozzle could dig in, an the print was almost turning to a blob. Lucky for me i was sitting right next to the machine and saw it happening.

I have had a lot of random crashes on prints on alpha versions, but ive never managed to tell why before today where i saw the support being build higher than the print itself.

Prusa c920 Camera Y Axis v4.zip

Project file & How to reproduce

Prusa c920 Camera Y Axis v4.zip

Printed from file through octoprint 1.8.7 stable version

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.6.0 Alpha 6

Operating system

Windows 10

Printer model

i3mks+ with revo six

[kubispe1]

Hope I understand clearly... That's quite common, cause in settings there is a Top contact Z distance 0.2 in support settings (to separate support and model).
You can decrease it to 0.1 or even use 0 - for soluble support. Do you mean this?
More or less the nozzle should not crash into the model....

[b4de4nd]

HiNo the print is not the top Z distance. The settings are 0.2 and they work fine, however it printed the support higher than the print itself, so the supports would get higher than the model and therefore the nozzle hits the support. Before it Melted into the model it looked like the support was somewhat ingrown to the model, and the print suddenly contained support materiel on that side as well. The crash happened after the layers for the top part was done and it was no longer during the bridgepart of overhang.Regards KenthDen 2. apr. 2023 kl. 22.42 skrev kubispe1 ***@***.***>: Hope I understand clearly... That's quite common, cause in settings there is a Top contact Z distance 0.2 in support settings (to separate support and model). You can decrease it to 0.1 or even use 0 - for soluble support. Do you mean this? More or less the nozzle should not crash into the model.... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[b4de4nd]

On the right side the model had filament as High as 1mm before the crash, unfortunaly the image is hard to tell from since the nozzle melted most of it Down.

But it happened on top of the layers that was made on top of the organic support. Hope this makes sense :)

[kubispe1]

I also try to print. Seems to me ok. But let's open the issue. I inspected also the travels and toolpath. I cannot find any problem that caused the nozzle to crash. Have you tried to print it multiple times or just once with this result?
Hope I did not overlook something...

[freakydude]

Hi,

I also have a interesting finding in relation to that.
I printed something an my tree support got knocked off to. In my case, I think not that it was to high. As always a fresh small obstacle curle sometimes.

I was wondering, why the experimental option

was still crashing into the tree support.
That screenshot shows why:

And this thread here shows the reason
With

the option "Avoid crossing curled overhangs enabled" works as expected - but I will get z contact.

So 2 points:

• Maybe this would be also a solution here?
• Maybe the Avoid crossing curled overhangs: enabled must take that into account - or at least a option to take it into account?

[jamincollins]

I believe I'm also being hit by this, while printing with organic supports I can sometimes hear an impact with part of the model and periodically find a tree support has failed.

[jamincollins]

I managed to capture video of 4 supports being knocked down by print head impacts. The first two happen shortly after the beginning of the video. The head move is due to taking a timelapse frame. The third happens around 6:43 into the video, with a head move that should be part of the generated gcode. The fourth happens around 8:04 and I believe it is the clearest example as the video even shows the print head jump from the impact.

Sharing via Google Drive as the video is ~345M:
https://drive.google.com/file/d/1GzxYO_MI3YeJvioT_kAL4hD4yzM80hCl/view?usp=share_link

Edit: adding the generated gcode for the print from the video.
gcodes-202341-8175.zip

[istvanovics]

Same problem here guys! After everything was fine-tuned on my printer this problem happening with every print with organic support. I tried a lot of options but unfortunately, the problem is still there.

[jamincollins]

This might be fixed by the changes in 2.6.0-beta4. Specifically:

PrusaSlicer now performs a check for colliding toolpaths after slicing. This prevents print failures when multiple objects (or their supports) intersect and would be printed one over the other (e.g. #316, #10148 and many others).

Needs further testing/verification.

[freakydude]

Sorry, my settings or the tree generation seems to be different since my last example.
With the same object to print, i got another toolhead path.

But for at least one point, the problem still exists:

Regards

[jamincollins]

Can confirm the problem still exists, reprinted the same model as before and several supports were broken when the print finished.

[jamincollins]

I'm still experiencing this on 2.6.1, as demonstrated in the attached image: