Internal voids ignored #1472

Closed
T3P3 opened this Issue Oct 3, 2013 · 13 comments

Comments

Projects
None yet
4 participants
@T3P3

T3P3 commented Oct 3, 2013

@alexrj Alessandro sorry for the first communication after the TCT show is to re-open an old issue (#216) but I have discovered that handling of internal voids is still a problem (at least in the limited area I have tested so far).

Slicing the new Mendel90 parts, specifically the X-Motor bracket and X-Idler bracket (eg https://github.com/nophead/Mendel90/blob/master/dibond/stls/x_idler_bracket.stl) the nut trap at the top of the model is ignored and treated as a solid part. The link to the part allows you to use a wireframe to see the internal void for the nut trap, also the attached picture which shows a visualisation of the Gcode output by slic3r 0.9.10b:

slic3r_internal_void_filled

And a visualisation of the code as produced by an alternative slicing program:
alternative_correct_handling_of_internal_void

In summary my slicing settings:
2+ perimeters
2/3 bottom/top layers
0.2 line infil
no support.
but I have tried some variations on these without seeing a difference.

Cheers Tony

@T3P3

This comment has been minimized.

Show comment
Hide comment
@T3P3

T3P3 Oct 3, 2013

Update

I have made a tiny hole(0.2mm) through the void which is too small to affect the output but as the void is no longer completely enclosed Slic3r handles it correctly and it slices fine.

I have uploaded the STL file with the modification here:
https://github.com/T3P3/Mendel90/blob/LaserCut/lasercut/future_developments/x-idler-bracketv1.1.stl

Attached picture of the gcode visualisation:

slic3r_internal_void_work_around

So still an issue but at least there is a work around that can be used.

T3P3 commented Oct 3, 2013

Update

I have made a tiny hole(0.2mm) through the void which is too small to affect the output but as the void is no longer completely enclosed Slic3r handles it correctly and it slices fine.

I have uploaded the STL file with the modification here:
https://github.com/T3P3/Mendel90/blob/LaserCut/lasercut/future_developments/x-idler-bracketv1.1.stl

Attached picture of the gcode visualisation:

slic3r_internal_void_work_around

So still an issue but at least there is a work around that can be used.

@nophead

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Oct 3, 2013

It is actually a bug in OpenScad openscad/openscad#495, The walls of internal cavities face the wrong way. Skeinforge doesn't seem to care but Slic3r does.

I also tried a small hole to work round it but then Skeinforge tries to extrude the outline of the hole in mid air so I kept it completely enclosed.

nophead commented Oct 3, 2013

It is actually a bug in OpenScad openscad/openscad#495, The walls of internal cavities face the wrong way. Skeinforge doesn't seem to care but Slic3r does.

I also tried a small hole to work round it but then Skeinforge tries to extrude the outline of the hole in mid air so I kept it completely enclosed.

@T3P3

This comment has been minimized.

Show comment
Hide comment
@T3P3

T3P3 Oct 3, 2013

Cheers @nophead I will close this issue then and hope OpenSCAD can get fixed instead!

As an aside the small hole worked in slic3r without the printer trying to print a tiny perimeter.

T3P3 commented Oct 3, 2013

Cheers @nophead I will close this issue then and hope OpenSCAD can get fixed instead!

As an aside the small hole worked in slic3r without the printer trying to print a tiny perimeter.

@T3P3 T3P3 closed this Oct 3, 2013

@nophead

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Oct 3, 2013

I think SF must just count outlines to decide if it is inside or outside and ignore winding order and face normals, which would explain it why it is more robust in this case.

Logically if you have an infinitely small hole the outline is still finite when expanded by half the filament width. That is why SF tries to extrude it, Not sure Slic3r ignoring it is correct as it is sometimes used as a trick to get stronger parts by adding solid vertical columns as in the Prusa I2 x ends.

nophead commented Oct 3, 2013

I think SF must just count outlines to decide if it is inside or outside and ignore winding order and face normals, which would explain it why it is more robust in this case.

Logically if you have an infinitely small hole the outline is still finite when expanded by half the filament width. That is why SF tries to extrude it, Not sure Slic3r ignoring it is correct as it is sometimes used as a trick to get stronger parts by adding solid vertical columns as in the Prusa I2 x ends.

@jem-tech

This comment has been minimized.

Show comment
Hide comment
@jem-tech

jem-tech Oct 28, 2013

nophead i am having the same problem printing the part.i do not slice with SF. when i print the part the T3P3 posted with the small hole it sliced and printed fine but the part he posted is different from yours. i tried to add the same hole but had some problem adding it was wondering if you could add the hole and post the stl. not sure what i am doing wrong

nophead i am having the same problem printing the part.i do not slice with SF. when i print the part the T3P3 posted with the small hole it sliced and printed fine but the part he posted is different from yours. i tried to add the same hole but had some problem adding it was wondering if you could add the hole and post the stl. not sure what i am doing wrong

@nophead

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Oct 29, 2013

Not much point because Slic3r doesn't get the size parts accurate enough for them to work on Mendel90. People sell plastic parts on eBay where the nut traps are too small, the bearing holders crack, etc, because they used Slic3r instead of Skeinforge.

Not sure what Tony has changed? Perhaps changed the sizes to compensate for Slic3r.

nophead commented Oct 29, 2013

Not much point because Slic3r doesn't get the size parts accurate enough for them to work on Mendel90. People sell plastic parts on eBay where the nut traps are too small, the bearing holders crack, etc, because they used Slic3r instead of Skeinforge.

Not sure what Tony has changed? Perhaps changed the sizes to compensate for Slic3r.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Oct 29, 2013

Member

Oh hi Tony, I completely missed this issue as you closed before I could read about it. :)

Yes, the issue is caused by the nut trap being a separate shell with wrong normals, as can be seen in this section:

screenshot 2013-10-29 08 45 44

Slic3r just respects the original normals. This behavior also allows to handle intersecting solids gracefully, as described in openscad/openscad#350

OTOH, it would be nice if the built-in model repair would fix such normals automatically. I will open a separate issue to track that development.

Regarding sizes, Slic3r just offsets the shapes by half the extrusion width, nothing more, nothing less. :)

Member

alexrj commented Oct 29, 2013

Oh hi Tony, I completely missed this issue as you closed before I could read about it. :)

Yes, the issue is caused by the nut trap being a separate shell with wrong normals, as can be seen in this section:

screenshot 2013-10-29 08 45 44

Slic3r just respects the original normals. This behavior also allows to handle intersecting solids gracefully, as described in openscad/openscad#350

OTOH, it would be nice if the built-in model repair would fix such normals automatically. I will open a separate issue to track that development.

Regarding sizes, Slic3r just offsets the shapes by half the extrusion width, nothing more, nothing less. :)

@T3P3

This comment has been minimized.

Show comment
Hide comment
@T3P3

T3P3 Oct 29, 2013

Hi Alex. Yeah I closed it because it was an OpenSCAD bug that Chris had
already reported rather than a Slic3r issue. I would be great if this was
added to the list of auto repairs thought.

Regarding the nut trap sizes I added a modifier to the nut traps in my fork
of the Mendel90 to tweak them to fit. Chris has a good calibration object
to check the fit. I know you get loads of "advanced" feature requests but
it would be good if there was somewhere to enforce a W/T as SF does.
On 29 Oct 2013 08:10, "Alessandro Ranellucci" notifications@github.com
wrote:

Oh hi Tony, I completely missed this issue as you closed before I could
read about it. :)

Yes, the issue is caused by the nut trap having being a separate shell
with wrong normals, as can be seen in this section:

[image: screenshot 2013-10-29 08 45 44]https://f.cloud.github.com/assets/594957/1426571/87ac888a-4070-11e3-9122-be727c5b31b5.png

Slic3r just respects the original normals. This behavior also allows to
handle intersecting solids gracefully, as described in
openscad/openscad#350 openscad/openscad#350

OTOH, it would be nice if the built-in model repair would fix such normals
automatically. I will open a separate issue to track that development.

Regarding sizes, Slic3r just offsets the shapes by half the extrusion
width, nothing more, nothing less. :)


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27284436
.

T3P3 commented Oct 29, 2013

Hi Alex. Yeah I closed it because it was an OpenSCAD bug that Chris had
already reported rather than a Slic3r issue. I would be great if this was
added to the list of auto repairs thought.

Regarding the nut trap sizes I added a modifier to the nut traps in my fork
of the Mendel90 to tweak them to fit. Chris has a good calibration object
to check the fit. I know you get loads of "advanced" feature requests but
it would be good if there was somewhere to enforce a W/T as SF does.
On 29 Oct 2013 08:10, "Alessandro Ranellucci" notifications@github.com
wrote:

Oh hi Tony, I completely missed this issue as you closed before I could
read about it. :)

Yes, the issue is caused by the nut trap having being a separate shell
with wrong normals, as can be seen in this section:

[image: screenshot 2013-10-29 08 45 44]https://f.cloud.github.com/assets/594957/1426571/87ac888a-4070-11e3-9122-be727c5b31b5.png

Slic3r just respects the original normals. This behavior also allows to
handle intersecting solids gracefully, as described in
openscad/openscad#350 openscad/openscad#350

OTOH, it would be nice if the built-in model repair would fix such normals
automatically. I will open a separate issue to track that development.

Regarding sizes, Slic3r just offsets the shapes by half the extrusion
width, nothing more, nothing less. :)


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27284436
.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Oct 29, 2013

Member

You can enforce a Width over Thickness in Slic3r just by setting the Extrusion Width values (in the Advanced section) as percent values. If you write "250%" (with the percent sign) your extrusion width will be equal to layer height multiplied by 2.5.

Member

alexrj commented Oct 29, 2013

You can enforce a Width over Thickness in Slic3r just by setting the Extrusion Width values (in the Advanced section) as percent values. If you write "250%" (with the percent sign) your extrusion width will be equal to layer height multiplied by 2.5.

@T3P3

This comment has been minimized.

Show comment
Hide comment
@T3P3

T3P3 Oct 29, 2013

Great I will have to try that without any tweaks

You can enforce a Width over Thickness in Slic3r just by setting the
Extrusion Width values (in the Advanced section) as percent values. If you
write "250%" (with the percent sign) your extrusion width will be equal to
layer height multiplied by 2.5.


Reply to this email directly or view it on
GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27293641
.

T3P3 commented Oct 29, 2013

Great I will have to try that without any tweaks

You can enforce a Width over Thickness in Slic3r just by setting the
Extrusion Width values (in the Advanced section) as percent values. If you
write "250%" (with the percent sign) your extrusion width will be equal to
layer height multiplied by 2.5.


Reply to this email directly or view it on
GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27293641
.

@nophead

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Oct 29, 2013

If it always offsets by half the extrusion width then changing the extrusion width won't fix the problem as the offset will change to match. The problem is outlines need a lower flow rate to achieve the target width and hence match the offset applied to them, or the offset should be bigger.

nophead commented Oct 29, 2013

If it always offsets by half the extrusion width then changing the extrusion width won't fix the problem as the offset will change to match. The problem is outlines need a lower flow rate to achieve the target width and hence match the offset applied to them, or the offset should be bigger.

@T3P3

This comment has been minimized.

Show comment
Hide comment
@T3P3

T3P3 Oct 29, 2013

You can set the perimeter flow rate independently... I remember you did a
blog post about this Chris. I will read that and see if I can apply the
same logic to this.
On 29 Oct 2013 12:37, "Chris" notifications@github.com wrote:

If it always offsets by half the extrusion width then changing the
extrusion width won't fix the problem as the offset will change to match.
The problem is outlines need a lower flow rate to achieve the target width
and hence match the offset applied to them, or the offset should be bigger.


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27298999
.

T3P3 commented Oct 29, 2013

You can set the perimeter flow rate independently... I remember you did a
blog post about this Chris. I will read that and see if I can apply the
same logic to this.
On 29 Oct 2013 12:37, "Chris" notifications@github.com wrote:

If it always offsets by half the extrusion width then changing the
extrusion width won't fix the problem as the offset will change to match.
The problem is outlines need a lower flow rate to achieve the target width
and hence match the offset applied to them, or the offset should be bigger.


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1472#issuecomment-27298999
.

@nophead

This comment has been minimized.

Show comment
Hide comment
@nophead

nophead Oct 29, 2013

In that case set the outline flow rate to 1 + (pi/4 -1) / (W/T). So for 2.5 is should be 0.914 relative to a 100% rectangle of W by T

nophead commented Oct 29, 2013

In that case set the outline flow rate to 1 + (pi/4 -1) / (W/T). So for 2.5 is should be 0.914 relative to a 100% rectangle of W by T

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment