OrcaSlicer icon indicating copy to clipboard operation
OrcaSlicer copied to clipboard

Bridges being sliced as Overhang wall

Open blownupp opened this issue 1 year ago • 11 comments

OrcaSlicer Version

1.7.0-beta

OS version

Windows 10.0.19045

Additional system information

CPU: 13th Gen Intel Core i5-13600k RAM: Corsair 64GB GPU: EVGA 3080TI

Printer

Voron 2.4

How to reproduce

Slice this bridge test: - checking/unchecking Slow Down For Overhang/Classic Mode doesn't change the result.

Actual results

Bridged gaps are sliced as overhangs:

image

image

Expected results

The bridged perimeters should be sliced with "Bridge flow", "Bridge density" and "Thick bridges" enforced per slicer settings.

Project file & Debug log uploads

Attached is the STL and a saved project file with the issue prevalent.

bridge_test_orca_errors.zip

Here's a log file including the color change bridge issues described in my comment below:

debug_Tue_Nov_21_09_24_08_41440.log.zip

Checklist of files to include

  • [x] Log file
  • [X] Project file

blownupp avatar Sep 26 '23 03:09 blownupp

Might my request/issue have to do with this?

https://github.com/SoftFever/OrcaSlicer/issues/2227#issue-1911382256

Lt-Kammello avatar Sep 26 '23 11:09 Lt-Kammello

(OrcaSlicer 1.7.0 on linux)

I think this is the same issue here.

Benchy inner ceiling sliced wrong. (classic and arachne same result) Screenshot_20231010_015729

Screenshot_20231010_015802

Unchecking "Detect overhang walls" seems to fix it. Screenshot_20231010_021306

floorcat avatar Oct 09 '23 23:10 floorcat

still happening as of 1.8.0-rc2

floorcat avatar Nov 12 '23 16:11 floorcat

Still happening on official 1.8 release (and on upstream Bambu Studio - you can't print overhang walls on thin air!)

EDIT: I've noticed that color painting is messing this up. Here's a print with a couple letters on the left colored in and a letter on the right without a color change - all the letter features have the same draft angle and extruded cut depth:

image

Here it is by feature type:

image

After coloring in the letter that had proper bridging:

image

image

When using the "height range" color paint tool this does not seem to be an issue, it's only when using the fill/brush color paint tools that the bridging is sliced like overhang walls and tries to print in air.

I'm attaching a log file and the project file for reference:

debug_Tue_Nov_21_09_24_08_41440.log.zip P000113.zip

blownupp avatar Nov 21 '23 23:11 blownupp

@SoftFever this causes huge problems and seem FAR worse in 1.8.1 and 1.9 beta and it seems there is no workaround. I have mini figures that have 6 to 10 mm bridges that fail because Orca does not treat them as a bridge. Please fix.

Ltek avatar Dec 31 '23 19:12 Ltek

Hey guys,

There are different questions and cases involved in this thread. I will reply to the first one here. The reason it treated as bridge perimeter instead of bridge infill is because it's a narrow bridge and you have specified 4 wall loops, so no bridge infill is generated. If you change the wall loops to 2, you will be able to see it: image

SoftFever avatar Jan 01 '24 07:01 SoftFever

@SoftFever what if Orca had the option like "Make overhang wall printable" -- the current "Make Overhang Printable" doesnt work at all for the model attached; it will plug the bottom hole completely with infill. In other slicers I've see this add a bridge or two under overhang wall, against the current solid wall to help it cantilever out.

I'm seeing the largest issue on miniature models and/or areas where the thickness changes from high to lower (area that can sustain 3,4,5 walls to and area that can only sustain 2. Orca is making that transition using Overhang Wall, and they are failing every time for me. These are only 4mm long + 10mms + 100% cooling. Bridging is nearly perfect on that same filament doing the orca temp tower -- I did the temp tower after about 6 failed Overhang Wall attempts.

I've attached my STL so you can see it for yourself.

I modeled multiple version and printed ~20 various ones and the problem is always Overhang Walls fail (I get filament strands falling). I had to completely redesign my part so I could avoid overhang walls and make the entire model sustain 3 walls to avoid the transition to 2 walls. If someone wants to add strength to an STL they inherited (did not design themselves), the print will fail (or at least in part) every time if it does a transition like this.

Figure_1wall_overhang Figure_3wall_overhang turned Precise Wall on... Figure_3wall__PreciseWall_overhang issue.zip

Ltek avatar Jan 01 '24 18:01 Ltek

playing more today Now with this newer model, it creates a full overhang wall "layer" image

project file attached Figure_FullOverhang Wall.zip

Ltek avatar Jan 01 '24 21:01 Ltek

Here's one where there are more walls below than above but it still adds an Overhang Wall where its not needed at all, or a bridge would have been better. I've tried printing this a few times, 100% fan and it fails every time.

It adds the Overhang Wall even I change to 0% infill for the model.

3 layers in order bottom to top...

Layer28 Layer29 Layer30 Figure_topple_MyKlipper_Hyper_30-MyKlippe__Tapered-test1.zip

Ltek avatar Jan 02 '24 04:01 Ltek

Bump. Walls that are part of bridges print at overhang wall speeds rather than bridge speed causing the print to fail.

image

SadBones avatar Jan 03 '24 04:01 SadBones

Hey guys,

There are different questions and cases involved in this thread. I will reply to the first one here. The reason it treated as bridge perimeter instead of bridge infill is because it's a narrow bridge and you have specified 4 wall loops, so no bridge infill is generated. If you change the wall loops to 2, you will be able to see it: image

The problem is the "bridge perimeters" are being sliced at the "overhang 75% - 100%" speed, rather than the "bridge" speed. You would want a 90% over hang to be printed extremely slow, but the perimeters of a bridge need to be printed quickly.

SadBones avatar Jan 03 '24 15:01 SadBones

All I know is what I see... and its creating really odd overhang walls (see my prior screenshots) where it makes no sense at all (like covering holes with a concentric pattern "wall").

No matter what I try, even on overhang walls that are 3 to 4mm long (see screenshots below) they fail every time. I printed over 60 miniatures with multiple different wall speeds... the last 20 were at 40mms wall speed and this is what it happens...

20231230_173549

Ltek avatar Jan 10 '24 04:01 Ltek

I had this bug get me good today, was printing a case and the part of the wall that the slicer thought was bridge was not being printed before the bridge was started so the bridge just fell off into air. Turning off "Detect overhang walls" fixed it.

riddlemd avatar Jan 26 '24 23:01 riddlemd

I had this bug get me good today, was printing a case and the part of the wall that the slicer thought was bridge was not being printed before the bridge was started so the bridge just fell off into air. Turning off "Detect overhang walls" fixed it.

I dont see that as a real fix? The point of detecting them is so the slicer can slow the print down, and increase the cooling, for those areas that need it. There seems to be 2 actual problems here (maybe separate bugs, not sure)...

  1. Orca is simply not always correctly detecting overhang walls and placing them in odd spot.
  2. When it does properly detect them its not using bridge settings and they fail to print properly. Evidenced by printing success with much long/harder bridges using the same filaments.

Ltek avatar Jan 30 '24 20:01 Ltek

I ran into this today (V1.7---the issue made me look for a new version/why I'm here) when using some built-in supports on a part I designed. The workaround I used was to place a modifier at the bridge location and change the settings to have 0 walls. As expected it wouldn't create an overhang wall if walls weren't being generated.

This is the first time I've experienced this but I looked at it as more of a "bridges not reaching walls" problem rather than a "bridges sliced as walls" problem. In the future it would be great to not need to create modifiers to fix the problem because built-in support can save time and material over slicer generated support if done correctly.

CaptainFalcon63 avatar Feb 02 '24 05:02 CaptainFalcon63

I've noticed enabling "Classic mode" in the dynamic overhang speed settings still slices bridges as overhang walls, but it causes them to use the bridge speed setting rather than the overhang speed setting for 75%-100%:

Screenshot 2024-03-04 113957 Screenshot 2024-03-04 114010

danno131313 avatar Mar 04 '24 19:03 danno131313

Same issue here - v2.0.0-beta linux. Bridge is being marked a bridge but speeds are set to those of overhang I guess. In the case below, speed goes down to 2 mm/s! image

If I check the 'Classic mode' under 'Overhang speed', I get a 30-50 mm/s as expected.

Note: result is the same with v1.9.1

obertini78 avatar Mar 20 '24 17:03 obertini78

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds.

Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge.

Screenshot 2024-05-25 at 9 52 52 PM

Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

kpipes556 avatar May 26 '24 02:05 kpipes556

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds.

Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge.

Screenshot 2024-05-25 at 9 52 52 PM Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

This is most likely min layer time slowdown. Try to set the "slow_down_layer_time" to 0 and try again

SoftFever avatar May 27 '24 16:05 SoftFever

Same problem here. Trying to do a temp tower and the overhangs were too slow because they were using bridging speeds. Turned off "Detect overhang walls." This fixed the overhang issue but created a bridging issue: outer and inner wall speeds were applied to the bridge. Screenshot 2024-05-25 at 9 52 52 PM Classic mode or not, I couldn't find a combination of settings to fix this and allow changing overhang and bridge speeds independently.

This is most likely min layer time slowdown. Try to set the "slow_down_layer_time" to 0 and try again

I tried turning off the min layer slowdown time and turned up the max volumetric just to take them out of the equation and it is still doing the same thing.

image

No matter what setting I try, it either adds walls to the bridge or doesn't let me set the overhangs independently and sets them equal to the bridge speed. For TPU, this just isn't working :(

2.0.0 on M1 Mac

kpipes556 avatar May 27 '24 18:05 kpipes556

Same issue on 2.1.0-beta linux. I have noticed that quite often orca slicer will try and print into thin air, sometimes even trying to make the first layer of a hole using a concentric pattern starting from the center of the hole working out towards the hole edge, which is just extrude a bunch of plastic into thin air and do nothing.

image

Turning off Extra Perimeters on Overhangs appears to make it stop while still allowing Detect Overhang walls to be on. image

mfish38 avatar Jun 16 '24 17:06 mfish38

I have the same issue in 2.1.1-1

image

It prints a completely hanging bridge, and I can't get rid of it.

Buse_V6_BLT_ED3V6.tar.gz

Felixoid avatar Jul 12 '24 19:07 Felixoid

This issue causes issues with bridging. Notably, my bridge speed is very fast, at 150mm/s, but regardless of whether "detect overhang wall" is checked or not, these "walls" are printed at 25mm/s, which is too slow for bridging in this case, as I am printing very hot at this time. It is important that all bridging occurs at the same speed. Even if this is part of a wall, it is still a bridge. It is a bridge wall, not an overhang wall.

vadixidav avatar Aug 10 '24 21:08 vadixidav