bridging issue

[arhi]

not directly same as viewtopic.php?f=9&t=1456&hilit=bridzing+bridging#p5386 but partially similar ...

ideally visible on the whistle print ...

the bridge just don't have enough overlap on the sides and it fails to hang on the to side and it drops ..

just touching the perimeter, what the heck is that filament supposed to connect to ?!

I gave it 45% outline overlap, 3mm "extra inflation distance" ?!?!? and ziltch, nada, nothing changed

edit:
attached factory and fff files, also if makes any difference the part is : http://www.thingiverse.com/thing:403012

[emkay]

Hi. Not sure I can help, but thought the discussion was interesting to try and work towards a solution. It seems to me that the behaviour you're running into is the fact that "Tops" and Bottoms" are always inside perimeters. And what you're doing is a "bridge" of sorts, but even more significantly/specifically it's more of an "Unsupported Top". Which is an overall limitation of this manufacturing process and is partially the reason for supports/infills/etc. The design doesn't necessarily take into consideration the limits of FDM in a few areas.

A few solutions could be a) design the model with thicker walls so that it can accommodate your chosen number of perimeters, but also more so that it can build a structure onto which identified bridges can be built. Since the software will rightfully never compromise the number of perimeters, there simply is no room to incorporate your chosen overrides. And even then, the size of the model may be asking a lot for the bridging capabilities of your material choice. B) Print with thinner perimeters for the same reason as A. You'll notice though that you'll still have a problem in sections that are true bridges (at the air entry and exit points of the whistle)...more on that below. C) Use some sort of support. Yes, this is tricky in this case since it's inside and needs to be removed. Unfortunately that's one of the biggest puzzles when working with FDM. Things like dissolvable support materials are some of the more complicated solutions to this problem. D) Design and assemble it completely differently

I thought I'd also point out that for some reason the model still has flipped normals despite being marked as "fixed".

I also wanted to point out that this also demonstrates the major broken feature in that other post you linked to. Even if you, for instance, modelled it with thicker walls, or used some other solution: Simplify3D still won't identify the more common "bridges" that are at the air entry and exit points of the whistle. So no matter what we do, we don't have control over those areas until this feature is developed to completion.

[arhi]

Hi. Not sure I can help

even just bouncing ideas helps so thanks

It seems to me that the behaviour you're running into is the fact that "Tops" and Bottoms" are always inside perimeters. And what you're doing is a "bridge" of sorts, but even more significantly/specifically it's more of an "Unsupported Top". Which is an overall limitation of this manufacturing process and is partially the reason for supports/infills/etc. The design doesn't necessarily take into consideration the limits of FDM in a few areas.

yes, and no. for start, to remove the "limits of FDM" thing - let's say that cura and slic3r print this without a problem .. so I would move to limits of s3d and how to overcome them as FDM prints this, without a problem, when sliced differently.

I found few threads that talk about this perimeter / bridge issue with s3d but I hoped that 50% of overlap would solve that problem. if there's a 50% overlap between infill and perimeter the "line" of the infill should start at the middle of the perimeter and end at the middle of the perimeter on the other side. what I see in g-code preview is that infill goes up to perimeter so .. where's overlap? (might be bug in g-code preview and not in slicing as I was not looking at g-code but only at preview, but again, I see that in print they don't overlap so..)

if I make a wall thicker wrt "min extruded line" (without changing model just reduce the extruded line width) then it prints 2 perimeters and then lays the bridge over the rest of the wall, so the algo here is almost decent, but why not going over perimeter if perimeter overlap is set is imo bug.

design the model with thicker walls so that it can accommodate your chosen number of perimeters, but also more so that it can build a structure onto which identified bridges can be built. Since the software will rightfully never compromise the number of perimeters, there simply is no room to incorporate your chosen overrides. And even then, the size of the model may be asking a lot for the bridging capabilities of your material choice.

why "rightfully never compromise number of perimeters", I doubt that's rightfull in most cases. in most cases it would be better to cut on a perimeter or two and print infill .. in my experience in 99% cases when you print a "solid layer" only 1 perimeter is best option.. it increases many quality aspects of the print. so feature request separate number of perimeters for "solid layers" and rest of the print .. even better separate top layers, bottom layer, solid layers and other layers

Use some sort of support. Yes, this is tricky in this case since it's inside and needs to be removed. Unfortunately that's one of the biggest puzzles when working with FDM. Things like dissolvable support materials are some of the more complicated solutions to this problem. D) Design and assemble it completely differently

soluble support is not big of a problem but support is not needed in this case (as I already said, other slicers get this done ok) and even s3d would get it done ok just if it respected the 50% overlap, I'm looking it print, it stops extruding at the edge of the print, the bridge looks perfect, and then it start printing from that side back and kills the previous line as it was not stuck to the wall properly .. adding another half of perimeter there would solve the problem in this case completely .. why is there no overlap is imo bug..

support system is why I purchased s3d really, as (I tried "fixed" version of s3d first of course) it looked like the only one that properly give you a choice where you want your support and where you don't want it .. without me having to post process the g-code, edit skeinforge source for every tricky print etc ... (and I hate python with all my heart so it's not a pleasant thing to do for me) ... and while I'm not yet tested the support system of s3d yet, so far I'm very happy with it .. just that in this case, support is not necesary and different design .. also not necesary .. this as is should work flawlessly really ... just requires calibrated machine and properly configured slicer. imo I'm having issues configuring s3d as I'm used to bit different terminology so stuff like "extra inflation distance" make zero sense to me (ok trial and error shown me what it does but.. nice that app has a small question mark in top right menu but it does nothing when you click it to a option)

I thought I'd also point out that for some reason the model still has flipped normals despite being marked as "fixed".

yeah I know, I sent object designer a (repaired) version netfabb allows you to solve that easily, but does not change the way s3d sliced it ( ... the part that's repaired is available http://infinit.io/_/ZFtQ8Qa

I also wanted to point out that this also demonstrates the major broken feature in that other post you linked to. Even if you, for instance, modelled it with thicker walls, or used some other solution: Simplify3D still won't identify the more common "bridges" that are at the air entry and exit points of the whistle. So no matter what we do, we don't have control over those areas until this feature is developed to completion.

well on this whistle object s3d properly detected all bridges! it didn't handle them the way I'd liked to but they are properly detected, that whole layer is marked in g-code as bridge (except perimeters of course, I do agree with the other bug about perimeters not being part of the bridge) and is printed slowly etc .. as bridging config sets .. and depending on how big you set the area the bridge is imo properly detected. now it only needs to be handled better .. solving that different perimeter number on different type of layers would help improve greatly, also giving few more options for bridge..

[emkay]

Glad discussing helps. Sounds like you're much more experienced than me in all of this though, so I won't contribute any more confusion to the matter in the hopes that your predicament gets solved. Well, beyond what I'm writing in this post

Thought it'd be helpful to try in Cura for instance too. And when set to the same parameters there (specifically line width and number of perimeters...perimeter width there), the toolpaths look very similar and behave the same way. Where Tops and Bottoms seems to never penetrate perimeters. Not sure if you meant that this was different there, but thought I'd try anyways.

Interestingly regarding the penetration of perimeters, I think we've run into one of the hard parts of developing software: Differences of opinion on what's right In the work that I do, I usually don't want anything interfering with the exterior perimeters for bond and aesthetic reasons. Having control of the transition point/overlap is available and works for me. Of course, you're probably doing something very different from what I do and there's the difference in needs

Also, the infill overlap parameter seems to work as follows (from my best investigating thanks to your post). It follows the concept that paths inside the model never compromise perimeters. So what I've discovered is: a) infill overlap has a range from "adjacent to the first interior perimeter" to "overlapping all the way into the first interior perimeter". Only the first perimeter layer is referred to here to control the bonding of the transitions between these two features. So b) the infill overlap parameter percentage refers to a percentage of this range. For clarity to others reading this: the Extra inflation distance is different and refers to penetration into the model in mm, but once again only up to the exterior perimeters.

In any case, hope you find a solution. Unfortunately I pretty much have only had bad experience with bridging in many materials and basically consider significant spans impossible I tend to like materials that don't bridge well either which is my struggle. This definitely makes hollow objects hard though. And when I do try to push an unsupported area, I try to make sure that the model has enough wall thickness to allow for both the number of clean exterior perimeters I want, but also enough for interior perimeters/infill where the top can grab onto. Perimeters open a whole other world of complicated factors that would be fun to discuss in another topic

Take care

[arhi]

Glad discussing helps.

always does

Sounds like you're much more experienced than me in all of this though, so I won't contribute any more confusion to the matter in the hopes that your predicament gets solved. Well, beyond what I'm writing in this post

no confusion , at least not yet, so far it's helpful very so don't give up .. experienced .. well wrote two unsuccessful skein tools (were not doing nothing close to what I needed), wrote more then 1000 scripts to generate g-code for some specialized parts I needed for myself and modified skeinforge for many years (skeinforge is still hosted on my server ) ... to summarize, I have lot of experience "seeing these problems" and very little experience solving them ... I even, few years ago, gave up on everything and purchased teartime's UP! so that I just don't waste any more time on the printer itself and just use the darn thing as that's the goal since day one.... but TT started to fail on few important things for me so I'm back in the "open" printers now .. hoped s3d will be a silver bullet.. of course it isn't (still a lightyear in front of everything I used to make myself so I'm not at all unhappy with it)

Thought it'd be helpful to try in Cura for instance too. And when set to the same parameters there (specifically line width and number of perimeters...perimeter width there), the toolpaths look very similar and behave the same way

did you seen that I wrote cura and slic3r print this ok, both respect the overlap % parameter and that's enough to get this printed ok

Interestingly regarding the penetration of perimeters, I think we've run into one of the hard parts of developing software: Differences of opinion on what's right In the work that I do, I usually don't want anything interfering with the exterior perimeters for bond and aesthetic reasons. Having control of the transition point/overlap is available and works for me. Of course, you're probably doing something very different from what I do and there's the difference in needs

but you have a parameter, how much you want overlap, you don't want overlap you set 0%, you want 100% or 20% or .. you set it. It's supposed to be overlap with the inner-most perimeter line, so if you are printing 2 perimeter line and you set 50% the infill should start/end at the middle of the inner perimeter line and your, visible, outside perimeter line will look 100% identical... only if you setup overlap to more then 100% then your outer perimeter line should be affected (if you are printing 2, if you are printing 3 then again...) ... IMO there's no "difference of opinion" if there's a parameter - let parameter do exactly what it is doing, if user want to miss configure that parameter, let it..

Also, the infill overlap parameter seems to work as follows (from my best investigating thanks to your post). It follows the concept that paths inside the model never compromise perimeters. So what I've discovered is: a) infill overlap has a range from "adjacent to the first interior perimeter" to "overlapping all the way into the first interior perimeter". Only the first perimeter layer is referred to here to control the bonding of the transitions between these two features. So b) the infill overlap parameter percentage refers to a percentage of this range. For clarity to others reading this: the Extra inflation distance is different and refers to penetration into the model in mm, but once again only up to the exterior perimeters.

dunno, maybe I'm missunderstanding the very old parameter from skeinforge that's used differently here ... I just tried to attach some images from 7-8 years ago with PP and how this overlap used to work .. but darn google ain't working any more and neither is picassa ..

In any case, hope you find a solution. Unfortunately I pretty much have only had bad experience with bridging in many materials

I think overlap is more of a problem here, if s3d ignores overlap then I'm doing about this thing all wrong .. as I also see issues with infill on solid layers not properly going up to perimeter ... this abs is bit springy and this hot end is piece of @%#& but looks like overlap just ain't doing anything..

and basically consider significant spans impossible I tend to like materials that don't bridge well either which is my struggle.

I did most of my printing with PP and HDPE and they do bridging waaaay different then abs and pla .. they do almost everything differently then abs and pla but I'm trying to understand s3d first with abs before I go and start hitting the nasty pp/hdpe

[arhi]

google started workin ...
so this is something from 2009 I think ..
default overlap:




negative overlap:




and positive overlap:




So I'm assuming this is what infill/outline overlap % settings should do imo in s3d but I might be wrong ?! is this parameter at all used when infill is bridge? is it used for solid layers?

[HexHyte]

I have the same problem..

viewtopic.php?f=23&t=5933

[arhi]

hi HexHyte, seen that one, I think it is not the same, I think your issue is actually more common and way more important then this one I'm having here now. What you explain there is fundamental issue with bridging in s3d that I didn't figure out how to solve neither tweaking s3d nor tweaking the object itself. what I'm seeing here is more issue about perimeter overlap and I can find few ways to force fix the problem (ugly work around that we discussed in topic..). I'm following closely the one you created hoping it will bring some feedback from s3d