Nozzle strikes main part after XL switches to 2nd tool head to print support material

[mbarritt]

Description of the bug

While printing a part with organic supports (using extruder one for the main part, and extruder two for the support material) the extruder two nozzle strikes the main part. This occurs just after the switch to extruder two, after it prints one layer on one of the tree supports and then crosses a wall of the main part on the way to the next (internal) tree support.

As the slicer prints two layers between tool changes the result is that the wall between this one tree support and the support inside the model is one layer higher than the current printing layer on the supports. (Just after the tool change, so while the support material extruder is printing the first of the two support layers it will print before the next tool change). I'm assuming the problem is that there is no z lift in the gcode before the tool makes this transition across what is at that moment a one-layer higher part.

See this image with explination:

Project file & How to reproduce

Prusa Slicer project that generated this gcode: Salon Side Table v1 wMoats & inner brim - PSP.3mf.zip

Checklist of files included above

• [X] Project file
• [X] Screenshot

Version of PrusaSlicer

2.7.4+MacOS-arm64

Operating system

macOS 14.5

Printer model

Prusa XL - 2 head

[u89djt]

Hi there, I'm a fellow XL user looking to be aware of potential glitches, so happy to dig around. When I load up your 3mf file there, the travel includes a lift and the infill structures look different to your photo of the print bed.

Have I misinterpreted that?

[mbarritt]

Dave,

That image looks like it is in the second pass of tool head 2 after the layer began printing, but otherwise it looks like the correct travel move. However, the collision is only happening just after the layer is started (on the first layer toolhead 2 lays down after the tool head change). Here is, I think, the correct spot:



Thanks for looking,

• Matthew

On Jun 11, 2024, at 3:49 PM, Dave T. @.***> wrote:

Hi there, I'm a fellow XL user looking to be aware of potential glitches, so happy to dig around. When I load up your 3mf file there, the travel includes a lift and the infill structures look different to your photo of the print bed. image.png (view on web) https://github.com/prusa3d/PrusaSlicer/assets/75209005/031490f0-7324-459a-9ca7-9a30a2899f6a Have I misinterpreted that?

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/12804#issuecomment-2161495917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVQL7P5OYP7WGOVBZ57D5P3ZG5IGDAVCNFSM6AAAAABJEYSB5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGQ4TKOJRG4. You are receiving this because you authored the thread.

[u89djt]

@mbarritt the image seems to have failed as a strange rectangle: 

[mbarritt]

Here is another attempt at sending the image:

[u89djt]

Yep, that works! When I slice the 3mf file you posted, the inner support is extruded before the outer support, so it seems like you posted a different version of the project? Unless there's a substantial difference between the mac and windows builds. I loaded it up in windows 64 bit 2.7.4 - here it is saved out again saved by u89djt.zip

[mbarritt]

Interesting. Perhaps it is a difference between the Mac and Windows builds. I opened up the 3mf file I sent earlier and looked again, it does print the outer support first on this layer. Here it is again and with a new image from it. I opened it, sliced, created this image, then compressed the 3mf so am sure this is the version that created gcode that prints the outer support first on this layer (9.48(30)) on my Mac. I'm running Prusa Slicer 2.7.4+macOS-arm64.

Salon Side Table v1 wMoats & inner brim - PSP 2nd.3mf.zip

[mbarritt]

Not sure if that 3mf file attachment worked. Another try: Salon Side Table v1 wMoats & inner brim - PSP 2nd.3mf.zip

[u89djt]

Hokydoky, this is what I get from slicing your new 3mf file (came through on the other try), and it's definitely doing things in a different order, and indeed the support structure is different. Do you want post the gcode from yours? Ah, the gcode is huge. Can you cut down your model so the same clash happens, but the gcode can be zipped and posted? If you look at the preview at a lower angle, does it look like the travel is passing through an existing extrusion? Maybe make the smallest possible object that makes it happen for you.

[u89djt]

I've cut it down and found it does the outer support first. Here's the 3mf file and the gcode it slices to for me: u89djtwindows.zip Can I get a sanity check from someone on the team? Are we doing the right stuff?

[mbarritt]

Ah...glad you could cut it down. I did as well and have just been looking in vain for anything "wrong" with the tool movement at this point. It does lift a bit before moving across the main part body. I can upload my cut-down model 3MF and the resulting smaller gcode file (10MB), but perhaps what you already have covers it. Here are two more images, one from the original 3MF and the other from the cut down version, both are the same at the point the toolhead does this travel move after laying down the first layer of filament on the outer support after the tool change. (Note, I've gone a couple layers up from where we were looking before, though the behavior seems the same):

At this point I'm doubting my interpretation of the collision (which occurred repeatedly, once for each layer printed, but a glancing contact that did not cause the print to fail). Could my part have warped up off the bed just enough to allow the contact, but not so much that I could see it? This is possible but not what I thought at the time with careful observation. I hope I haven't raised a false alarm here (though perhaps better to have it been my error than there being a subtle bug to track down).

[u89djt]

Will have a closer look tomorrow - there's a lesson or two wherever it all lands, I'm sure. Hopefully we'll get some more folk looking.

[mbarritt]

One more data point: I just checked the part I was printing when these once-every-layer collisions. It is truly flat on the surface that was against the plate. It is a big part. I checked it with a long machinists straight edge (known to be very flat) and there was zero lift off the plate by the part, no warping. So whatever caused the glancing hit on the main body of the part it was not it warping off the plate and rising up into the path of the tool.

[u89djt]

Right, so I always assume I haven't dried my filament enough when there are ticking noises - the extrusion swells and splatters a bit when moisture is being boiled out of it during extrusion. The extrusions don't look rough per se, but there's one spot where it looks like the kind of rough that could catch the nozzle; here: How's the surface of the object where you got the catches? It's covered by a helpful arrow :)

[mbarritt]

Thanks for the suggestion, but unlikely to be the issue here. I keep filament in a humidity controlled workflow (taking this variable out of my printing equation). When new I dry rolls in a 2% EDry cabinet for a week or two (or old fashioned dehydrator if I'm in a hurry), then into individual dry boxes (with rotated desiccant containers if/when they begin to change color), and printed directly from these containers. Filament goes back into the EDry periodically if there is any reason to. I've created "holsters" for the XL so I can use individual dry boxes close to where the original spool holders would be. The hydrometers in the containers only go down to 10%, but that's where they stay. So filament (of every sort I print) is always at 10% or lower. Removes a whole set of possible issues.

In case your curious:

Here is the best image I have of this portion of the print. Unfortunately the camera focused further forward and that back portion of the print is out of focus. A bit of shadow makes it hard to conclude anything:

I went back a couple days in the archive and pulled a few second clip of video from the collision. It is a solid "thunk" as the nozzle passes over the piece: https://github.com/prusa3d/PrusaSlicer/assets/90226623/5fb15ed7-2dc9-4f5b-9fb3-f95010eb8b00

I've redesigned this object to no longer require supports and am producing it. So, this isn't critical for me. Does it demonstrate some error in the gcode generation that might need to be corrected? Seems a bit unlikely at this point, which leaves no good explanation for the observed behavior. But, I'm guessing not worth pursuing further at this point. Thanks for jumping in and taking a look!

• Matthew

[u89djt]

I like it! That's more organized than my setup - I've got individual SUNLU dry boxes standing next to the printer and routing the filament over the posts so far. I'll take a look at the other gubbins I see there. I've had no luck sourcing the rubbermaid boxes over here in the UK. Vacuum bags and boxes with added gaskets at this point. That is a solid bang! Here's hoping you don't hit that problem again :) Cheers!

[mbarritt]

Dave, Glad you like the filament set up (I need to post about it as some point). Yeah, being able to buy the Rubbermaid 21 Cup containers at the local hardware store for $7-8 apiece is critical for this being a practical design. I've modified the spool and desiccant holder from the online designs (which I will post on Printables sometime before too long). I use good quality vacuum bags as well for overflow (filament goes into the dryer and if there is no Rubbermaid dry box available it goes into a bag. I love never having to think about whether the filament is dry.

Yeah, the bang was noticeable. I work near the printer closet and my morning was punctuated with a good solid thunk from the closet every few minutes. All quiet now.... Thanks, - Matthew