search

slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.34k stars 1.3k forks source link

Holes to small #1588

Closed tmorris9 closed 9 years ago

tmorris9 commented 10 years ago

All versions of Slic3r up to and including 1.0

All holes be they round, square or in between slice too small. It's been reported on RepRap forum many times by users.

Same on Mac and Windows versions. Non machine specific, non object specific. All holes, openings print smaller than designed yet outer walls are +/- .01mm accurate.

Example a test piece with 16mm round hole 36 sided prints with an opening of 13.15mm. A 10mm hole prints with 9.5mm opening.

Kisslicer slices within the same tolerance as Slic3r does for outside tolerances.

MaJaMo commented 10 years ago

From the dimensioning issues I reported 2 months ago I found that Slic3r insets with 'build spacing' but prints with a normal thread width. On a 0.25 layer height this adds 0.053mm to the exterior perimeters. This is obviously not the whole problem, as you are out by more than 0.1mm.

Did you do the normal trick of compensating for the CAD dimensioning to the points rather than the flats of the circle.

alranel commented 10 years ago

Slic3r insets contours by half the extrusion width, no more no less.

Thank you!

MaJaMo commented 10 years ago

Hi Alex,

From my experiments Slic3r appears to inset perimeters by the build_spacing rather than the build_width.

There is not much in it but here is a decode of what I get from slicing a simple 20x30x5 cube…

The –xml.gcode file has been refactored for controlling speeds and adds analysis comments which help to do the maths.

If you look at the perimeter part on line 505 you can see that the head travels 29.214. Add onto this the build width of 0.84 and you get 30.053 not 30 as expected.

I would expect the perimeters to be inset by half the build_width rather than half the build_spacing.

Any fill should then use build_spacing.

In the wider scheme of things it’s not much but if you calibrate to the outside of you object them the insides will be 0.1mm out on each side so 0.2mm in diameter.

Hope that helps,

Mandy

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

Thank you!

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206 .Image removed by sender.

qharley commented 10 years ago

I am doing an experiment, using Slic3r, Cura and Kisslicer with exactly the same filament width and flow settings, and default print programs.

Will let you know what I get...

On Sun, Dec 8, 2013 at 10:26 PM, MaJaMo notifications@github.com wrote:

Hi Alex,

From my experiments Slic3r appears to inset perimeters by the build_spacing rather than the build_width.

There is not much in it but here is a decode of what I get from slicing a simple 20x30x5 cube…

The –xml.gcode file has been refactored for controlling speeds and adds analysis comments which help to do the maths.

If you look at the perimeter part on line 505 you can see that the head travels 29.214. Add onto this the build width of 0.84 and you get 30.053 not 30 as expected.

I would expect the perimeters to be inset by half the build_width rather than half the build_spacing.

Any fill should then use build_spacing.

In the wider scheme of things it’s not much but if you calibrate to the outside of you object them the insides will be 0.1mm out on each side so 0.2mm in diameter.

Hope that helps,

Mandy

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

  • If you think this behavior is not correct, please tell what you would like it to do.
  • If you think this behavior would be correct but Slic3r does not actually do it, please show a G-code file demonstrating the wrong inset.

Thank you!

— Reply to this email directly or view it on GitHub < https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206> .Image removed by sender.

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

qharley commented 10 years ago

Results as follows, for today anyway.

Using the Perimeter width test block from the "Essential calibration set"

Ouside of block, inside of tray.

Slic3r: 10.08 9.80 Cura: 10.3 9.84 Kiss: Could not get it to stick to the print surface.... yet.

It is clear that in Cura the flow rate is too high, causing the outer perimeters to be 0.3mm too thick. With slic3r there is an offset towards the inside. This is on the same machine, with the same firmware...

On Sun, Dec 8, 2013 at 10:53 PM, Quentin Harley quentin.harley@gmail.comwrote:

I am doing an experiment, using Slic3r, Cura and Kisslicer with exactly the same filament width and flow settings, and default print programs.

Will let you know what I get...

On Sun, Dec 8, 2013 at 10:26 PM, MaJaMo notifications@github.com wrote:

Hi Alex,

From my experiments Slic3r appears to inset perimeters by the build_spacing rather than the build_width.

There is not much in it but here is a decode of what I get from slicing a simple 20x30x5 cube…

The –xml.gcode file has been refactored for controlling speeds and adds analysis comments which help to do the maths.

If you look at the perimeter part on line 505 you can see that the head travels 29.214. Add onto this the build width of 0.84 and you get 30.053 not 30 as expected.

I would expect the perimeters to be inset by half the build_width rather than half the build_spacing.

Any fill should then use build_spacing.

In the wider scheme of things it’s not much but if you calibrate to the outside of you object them the insides will be 0.1mm out on each side so 0.2mm in diameter.

Hope that helps,

Mandy

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

  • If you think this behavior is not correct, please tell what you would like it to do.
  • If you think this behavior would be correct but Slic3r does not actually do it, please show a G-code file demonstrating the wrong inset.

Thank you!

— Reply to this email directly or view it on GitHub < https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206> .Image removed by sender.

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

nophead commented 10 years ago

I think Cura uses the same flow rate for the outlines as it does the infill, which is wrong. Outline flow rate should be 1 - (pi/4 -1) T / W relative to W x T rectangle.

On 8 December 2013 22:16, Quentin Harley notifications@github.com wrote:

Results as follows, for today anyway.

Using the Perimeter width test block from the "Essential calibration set"

Ouside of block, inside of tray.

Slic3r: 10.08 9.80 Cura: 10.3 9.84 Kiss: Could not get it to stick to the print surface.... yet.

It is clear that in Cura the flow rate is too high, causing the outer perimeters to be 0.3mm too thick. With slic3r there is an offset towards the inside. This is on the same machine, with the same firmware...

On Sun, Dec 8, 2013 at 10:53 PM, Quentin Harley quentin.harley@gmail.comwrote:

I am doing an experiment, using Slic3r, Cura and Kisslicer with exactly the same filament width and flow settings, and default print programs.

Will let you know what I get...

On Sun, Dec 8, 2013 at 10:26 PM, MaJaMo notifications@github.com wrote:

Hi Alex,

From my experiments Slic3r appears to inset perimeters by the build_spacing rather than the build_width.

There is not much in it but here is a decode of what I get from slicing a simple 20x30x5 cube…

The –xml.gcode file has been refactored for controlling speeds and adds analysis comments which help to do the maths.

If you look at the perimeter part on line 505 you can see that the head travels 29.214. Add onto this the build width of 0.84 and you get 30.053 not 30 as expected.

I would expect the perimeters to be inset by half the build_width rather than half the build_spacing.

Any fill should then use build_spacing.

In the wider scheme of things it’s not much but if you calibrate to the outside of you object them the insides will be 0.1mm out on each side so 0.2mm in diameter.

Hope that helps,

Mandy

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

  • If you think this behavior is not correct, please tell what you would like it to do.
  • If you think this behavior would be correct but Slic3r does not actually do it, please show a G-code file demonstrating the wrong inset.

Thank you!

— Reply to this email directly or view it on GitHub < https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206> .Image removed by sender.

— Reply to this email directly or view it on GitHub< https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30091802> .

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

qharley commented 10 years ago

What should I do in my slic3r settings to keep the outside of the block at 10, and get the inside of the tray up to 10 as well? I think my flow rate is correct. Lower flow makes solid fill a bit sparse.

Sent via my BlackBerry

-----Original Message----- From: Chris notifications@github.com Date: Sun, 08 Dec 2013 15:09:45 To: alexrj/Slic3rSlic3r@noreply.github.com Reply-To: alexrj/Slic3r reply@reply.github.com Cc: Quentin Harleyquentin.harley@gmail.com Subject: Re: [Slic3r] Holes to small (#1588)

I think Cura uses the same flow rate for the outlines as it does the infill, which is wrong. Outline flow rate should be 1 - (pi/4 -1) T / W relative to W x T rectangle.

On 8 December 2013 22:16, Quentin Harley notifications@github.com wrote:

Results as follows, for today anyway.

Using the Perimeter width test block from the "Essential calibration set"

Ouside of block, inside of tray.

Slic3r: 10.08 9.80 Cura: 10.3 9.84 Kiss: Could not get it to stick to the print surface.... yet.

It is clear that in Cura the flow rate is too high, causing the outer perimeters to be 0.3mm too thick. With slic3r there is an offset towards the inside. This is on the same machine, with the same firmware...

On Sun, Dec 8, 2013 at 10:53 PM, Quentin Harley quentin.harley@gmail.comwrote:

I am doing an experiment, using Slic3r, Cura and Kisslicer with exactly the same filament width and flow settings, and default print programs.

Will let you know what I get...

On Sun, Dec 8, 2013 at 10:26 PM, MaJaMo notifications@github.com wrote:

Hi Alex,

From my experiments Slic3r appears to inset perimeters by the build_spacing rather than the build_width.

There is not much in it but here is a decode of what I get from slicing a simple 20x30x5 cube…

The –xml.gcode file has been refactored for controlling speeds and adds analysis comments which help to do the maths.

If you look at the perimeter part on line 505 you can see that the head travels 29.214. Add onto this the build width of 0.84 and you get 30.053 not 30 as expected.

I would expect the perimeters to be inset by half the build_width rather than half the build_spacing.

Any fill should then use build_spacing.

In the wider scheme of things it’s not much but if you calibrate to the outside of you object them the insides will be 0.1mm out on each side so 0.2mm in diameter.

Hope that helps,

Mandy

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

  • If you think this behavior is not correct, please tell what you would like it to do.
  • If you think this behavior would be correct but Slic3r does not actually do it, please show a G-code file demonstrating the wrong inset.

Thank you!

— Reply to this email directly or view it on GitHub < https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206> .Image removed by sender.

— Reply to this email directly or view it on GitHub< https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30091802> .

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

Reply to this email directly or view it on GitHub: https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30095933

MaJaMo commented 10 years ago

I’ve had some success by getting openscad to make the outsides a tad smaller and the insides a bit bigger before Slicing with Slic3r. The amount to compensate by changes with layer height the formula is complicated (the difference between the shapes (circles or ellipses) on the end of the model of your thread and the width of a rectangle of the same height). So I made a lookup table instead, this is only really worth doing on precision parts you don’t want to do any hand finishing on. If you treat the printing like a casting then you just drill out the holes.

As nophead eludes, the other way is the extrude less plastic on the perimeter to make them thinner. But don't think Slic3r does this either.

//Slic3r correction factors for Nozzle Diameter 0.5 mm

function S3r_corr(h) = lookup(h, [ [0,0], // 00 value to cater for heights les than 0.1 [0.1,0.021460184], [0.11,0.023606202], [0.12,0.02575222], [0.13,0.027898239], [0.14,0.030044257], [0.15,0.032190275], [0.16,0.034336294], [0.17,0.036482312], [0.18,0.038628331], [0.19,0.040774349], [0.2,0.042920367], [0.21,0.045066386], [0.22,0.047212404], [0.23,0.049358422], [0.24,0.051504441], [0.25,0.053650459], [0.26,0.055796478], [0.27,0.057942496], [0.275,0.058472806], // limit value between circles and elipses [0.28,0.05498901], [0.29,0.048381811], [0.3,0.042215091], [0.31,0.036446225], [0.32,0.031037912], [0.33,0.025957377], [0.34,0.021175696], [0.35,0.016667254], [0.36,0.012409281], [0.37,0.008381469], [0.38,0.005365046], [0.39,0.005365046], [0.4,0.005365046] ]);

//echo (S3r_corr(0.275));

// values for Nozzle Diameter 0.3mm

function S3r_corr03(h) = lookup(h, [ [0,0], // 00 value to cater for heights les than 0.05 [0.05,0.010730092], [0.06,0.01287611], [0.07,0.015022129], [0.08,0.017168147], [0.09,0.019314165], [0.1,0.021460184], [0.11,0.023606202], [0.12,0.02575222], [0.13,0.027898239], [0.14,0.030044257], [0.15,0.032190275], [0.16,0.034336294], [0.165,0.035083684], // limit value between circles and elipses [0.17,0.031640874], [0.18,0.025329055], [0.19,0.019681638], [0.2,0.014598963], [0.21,0.010000352], [0.22,0.005819797], [0.23,0.003219028], [0.24,0.003219028], [0.25,0.003219028], [0.26,0.003219028], ]);

//echo (S3r_corr03(0.15));

MaJaMo commented 10 years ago

Was looking through the source to understand something else……

Is a fix as simple as replacing the line in bold below in make_perimeters in Region.pm

    # do one more loop (<= instead of <) so that we can detect gaps even after the desired

    # number of perimeters has been generated

    for (my $loop = 0; $loop <= $loop_number; $loop++) {

        my $spacing = $perimeter_spacing;

        $spacing /= 2 if $loop == 0;

with

        $spacing =$self->perimeter_flow->scaled_width/2 if $loop == 0;

Perl is not my kind of language (FORTRAN->C->C++->gap of 10 years->Python) so may be being a complete novice…

From: Alessandro Ranellucci [mailto:notifications@github.com] Sent: 08 December 2013 19:35 To: alexrj/Slic3r Cc: MaJaMo Subject: Re: [Slic3r] Holes to small (#1588)

Slic3r insets contours by half the extrusion width, no more no less.

Thank you!

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-30090206 .Image removed by sender.

mrbi11 commented 10 years ago

Regarding perimeter width and other widths, it appeared to default to the the layer height in some cases, which never seems the right choice. (but I am kind of new).

I have also observed the inner hole width round or square is approximately 0.6 to 0.7 mm too small, and does not scale with hole size. A 2 mm hole is 1.3 mm a 10 mm hole is 9.3 mm.

While trying to build a test case, I found some other anomalies where fill density cannot be set to 100% or rather setting it there yields a clearly less dense fill than the perimeter. Some evidence was again layer height being confused with print width. The floor of a fill was like a screen, not solid fills.

If I get time I will try and finish making a simple test case to reproduce, but just in case my comments make a light bulb come on... i dont have enough to file a report yet.

It may be as simple as a typo confusing height and width in the start up.

arildj78 commented 10 years ago

I'm experiencing a similar problem. When printing a test object, the straight edges are pretty much correct dimensions, so is a 13mm peg. However, a 13mm circular hole prints at 12.5mm.

image

My machine is a Prusa i3, with Marlin 1.0.0 firmware and I'm slicing with Slic3r 1.0.0RC3.

Skeinforge had a setting for stretching the inner and outer perimieter, however it seems that Skeinforge is dead and bugs in the stretch routine prevents me from using it.

I understand a lot of the factors that contribute to this problem such as those described in https://dl.dropboxusercontent.com/u/3775100/Slic3r%20-%20Dimensional%20Errors.pdf

POSSIBLE CAUSES

HOW THEY APPLY TO ME

To summarize the problem.

The object that gets printed is different from what I designed in SolidWorks.

Solution

One of the tools between designing and printing should correct for the errors, no matter what the cause of the error is. I think the slicer is the best place to correct for this. It has been suggested to the Marlin developers that they correct for this (https://github.com/ErikZalm/Marlin/issues/678) but they also think it belongs with the slicer software.

At the time of writing, these are related issues: Open: https://github.com/alexrj/Slic3r/issues/418 and https://github.com/alexrj/Slic3r/issues/426 Closed: https://github.com/alexrj/Slic3r/issues/491 and https://github.com/alexrj/Slic3r/issues/1613

neodavid315 commented 10 years ago

I’ve experienced this one also… After a lot of work trying to print a usable linear bearing, I’ve given up and am having to learn Blender and enough detail to resize the holes and get the right size by trial and error.

This one would really be a major fix for getting holes right when printing a new printer, or especially designing your own new version (which I had to give up on for now until I get a true understanding of hole size… haven’t found the pattern yet… I need to create a test pattern of holes).

Just for the record, otherwise, when printing a test pattern made by others, my printer is accurate to .4 or so on a 50 x 60mm rectangle of pyramided rectangles.

From: arildj78 [mailto:notifications@github.com] Sent: Thursday, March 13, 2014 6:09 AM To: alexrj/Slic3r Subject: Re: [Slic3r] Holes to small (#1588)

I'm experiencing a similar problem. When printing a test object, the straight edges are pretty much correct dimensions, but a 13mm circular hole and peg in/on the object prints at 12.5mm.

[image]https://f.cloud.github.com/assets/3500321/2407901/3dca2dd8-aa94-11e3-8dd0-b469d4386135.png

My machine is a Prusa i3, with Marlin 1.0.0 firmware and I'm slicing with Slic3r 1.0.0RC3.

Skeinforge had a setting for stretching the inner and outer perimieter, however it seems that Skeinforge is dead and bugs in the stretch routine prevents me from using it.

I understand a lot of the factors that contribute to this problem such as those described in https://dl.dropboxusercontent.com/u/3775100/Slic3r%20-%20Dimensional%20Errors.pdf

· Low quality filament

· In my case, I don't think shrinkage is the problem since my long edge is pretty close to the 50mm in the design.

To summarize the problem. The object that gets printed is different from what I designed in SolidWorks.

Solution: One of the tools between designing and printing should correct for the errors, no matter what the cause of the error is. I think the slicer is the best place to correct for this.

At the time of writing, these are related issues: Open

418https://github.com/alexrj/Slic3r/issues/418

426https://github.com/alexrj/Slic3r/issues/426

Closed

491https://github.com/alexrj/Slic3r/issues/491

1613https://github.com/alexrj/Slic3r/issues/1613

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

neodavid315 commented 10 years ago

Just a note to also say that this is an area where I see no possible resolution in any of the design tools I’ve tried, without adding errors or difficulties in further aspects of the design.

And with no help in the printer itself, the slicer might take a good leap forward here with some manner of ‘hole fudge factor’ to be changed for each type of printer… I’m not savvy enough to say what other factors this might interact with, like layer thickness, extrusion speed, etc.

Something simple, like a percentage change… or if more consistent, a generic ‘add to diameter’ for holes during the slicing would really give us a neato tool to create more accuracy than holes currently let us (how’s that for good English).

From: arildj78 [mailto:notifications@github.com] Sent: Thursday, March 13, 2014 6:09 AM To: alexrj/Slic3r Subject: Re: [Slic3r] Holes to small (#1588)

I'm experiencing a similar problem. When printing a test object, the straight edges are pretty much correct dimensions, but a 13mm circular hole and peg in/on the object prints at 12.5mm.

[image]https://f.cloud.github.com/assets/3500321/2407901/3dca2dd8-aa94-11e3-8dd0-b469d4386135.png

My machine is a Prusa i3, with Marlin 1.0.0 firmware and I'm slicing with Slic3r 1.0.0RC3.

Skeinforge had a setting for stretching the inner and outer perimieter, however it seems that Skeinforge is dead and bugs in the stretch routine prevents me from using it.

I understand a lot of the factors that contribute to this problem such as those described in https://dl.dropboxusercontent.com/u/3775100/Slic3r%20-%20Dimensional%20Errors.pdf

· Low quality filament

· In my case, I don't think shrinkage is the problem since my long edge is pretty close to the 50mm in the design.

To summarize the problem. The object that gets printed is different from what I designed in SolidWorks.

Solution: One of the tools between designing and printing should correct for the errors, no matter what the cause of the error is. I think the slicer is the best place to correct for this.

At the time of writing, these are related issues: Open

418https://github.com/alexrj/Slic3r/issues/418

426https://github.com/alexrj/Slic3r/issues/426

Closed

491https://github.com/alexrj/Slic3r/issues/491

1613https://github.com/alexrj/Slic3r/issues/1613

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

bstott commented 10 years ago

Hmmm.... This is beginning to sound like a meld of CAD and Printing. A Geometric approach to print design. Or design to print.

I am getting the idea that this request is for a way to manipulate the design for their printer rather than learning how to use the software, tune their printer and gain that skill.

This is actually a good idea to take the power of the software and control the process directly. Print the test piece with holes, sides and shapes. Then enter into, the yet to be written, Geometry Control Panel (GCP), then adjust the geometry controls for ID, OD, triangle, curve, etc... for the Slic3r to make the gcode file specific to the actions of the printer.

The meaning above is to remove our, the operator, need to measure filament, nozzle, feedrate, and maybe some other controls and bury them beneath software human interface or more commonly Human Machine Interface (HMI). IF we print an item - measure the item - then - adjust the software to adjust to the results. This would be more human like. For example: When we reach for a glass we do not note the weight and length of our arms (directly) or the muscle strength or other factors. We pay attention to the hand and the glass. The brain, behind the scenes adjusts to what we want. Make Slic3r evolve to this as suggested.

If the hole is too small - go into the Slic3r Geometry Control Panel (GCP) and adjust the circle ID section up to 110% from default and test print again. The controls could be programmed linear so that if a 3mm hold prints as 2.5mm then the adjustment change is 3/2.5= 1.2 X 100 = 120%

I am talking about a radical change in how we are doing this ---- Not too different for the programmer but, a different use for us ---Within the GUI - Maybe have a view where we see the to be printed geometry and as each variable/feature is selected within the GCP it is highlighted on the open part being worked? Then we can adjust the feature as required and then Slic3r does its magic?

Thank you for your efforts and your excellent tool. I use it as often as I am able.

bruce356 commented 10 years ago

Hi all, bstott, this is a very necessary part that needs to be included in slic3r, I find my OD's are very close to correct size but ID's are about 0.4mm too small. I have MM2 with E3D 1.75 filament 0.4 nozzle and print at 0.25 height.

I compensate for this when creating the part in 3d drawing program.

Although Kisslicer seems to have come to a standstill it does include a setting "Inset surface" in mm, under the "Style" Tab that takes care of this problem (it seems to have for me).

I do not know how difficult it would be to implement this or similar in slic3r.

Regards - bruce

neodavid315 commented 10 years ago

That's interesting, Bruce... I too would love to keep this idea alive as a feature, although for now I will try your .4mm size change for my projects. The reason I'd like it in Slic3r is because I often download other people's stl's, and this error dimensionally prevents me from taking advantage of their development. It takes me many hours to recreate something already done, so this little addition to Slic3r would be very efficient for me.

I wish there was an open source way to edit stl's, but alas my search finds nothing that isn't far more complex than just building it yourself.

Alex, we love your work man, and it's a compliment that so many people are signed up for the long haul.

On Mon, Mar 17, 2014 at 8:41 PM, bruce356 notifications@github.com wrote:

Hi all, bstott, this is a very necessary part that needs to be included in slic3r, I find my OD's are very close to correct size but ID's are about 0.4mm too small. I have MM2 with E3D 1.75 filament 0.4 nozzle and print at 0.25 height.

I compensate for this when creating the part in 3d drawing program.

Although Kisslicer seems to have come to a standstill it does include a setting "Inset surface" in mm, under the "Style" Tab that takes care of this problem (it seems to have for me).

I do not know how difficult it would be to implement this or similar in slic3r.

Regards - bruce

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

bruce356 commented 10 years ago

Hi neodavid315, I use FreeCad to change the stl files into a solid so that the part can be edited and measured, its a free program open source and does this very well. Others charge a lot of money for this added feature like Inventor, not only is the program expensive but if you want this feature you have to pay an extra $200, so use FreeCad it will do everything you need. regards - bruce

MaJaMo commented 10 years ago

Interesting would be good to know if the correction factor changes with layer height and hole diameter. Is it caused by laying down too much plastic on the inside of an arc or is the arc being told to print in the wrong place.

This kind of information will help to build a model of what is happening.

Sent via MaJaPhone

On 19 Mar 2014, at 00:03, bruce356 notifications@github.com wrote:

Hi neodavid315, I use FreeCad to change the stl files into a solid so that the part can be edited and measured, its a free program open source and does this very well. Others charge a lot of money for this added feature like Inventor, not only is the program expensive but if you want this feature you have to pay an extra $200, so use FreeCad it will do everything you need. regards - bruce

— Reply to this email directly or view it on GitHub.

neodavid315 commented 10 years ago

@Bruce, thank you Bruce, I’d looked at freecad before, but didn’t realize it could EDIT stl’s… I’ll look at it again.

Maybe I misunderstand though… once turned solid, I guess it’s no longer an stl, but according to what you are saying, it’s then EDITABLE?

Measuring alone of course doesn’t help, in that I can do that with a number of programs… I’m downloading it now to see if I can figure it out.

Thanks,

David

From: bruce356 [mailto:notifications@github.com] Sent: Tuesday, March 18, 2014 8:04 PM To: alexrj/Slic3r Cc: neodavid315 Subject: Re: [Slic3r] Holes to small (#1588)

Hi neodavid315, I use FreeCad to change the stl files into a solid so that the part can be edited and measured, its a free program open source and does this very well. Others charge a lot of money for this added feature like Inventor, not only is the program expensive but if you want this feature you have to pay an extra $200, so use FreeCad it will do everything you need. regards - bruce

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

arildj78 commented 10 years ago

@alexrj: are you able to incorporate some setting that can adjust hole sizes (and all other internal dimensions?

bruce356 commented 10 years ago

Sorry for the delay I have been away, once turned into a solid I export from FreeCad the solid as a step file this then allows to to import to say I nventor and edit the part as I wish and then export again as a STL for printing.

Regards - Longo

From: neodavid315 [mailto:notifications@github.com] Sent: Wednesday, 19 March 2014 11:35 PM To: alexrj/Slic3r Cc: bruce356 Subject: Re: [Slic3r] Holes to small (#1588)

@Bruce, thank you Bruce, I’d looked at freecad before, but didn’t realize it could EDIT stl’s… I’ll look at it again.

Maybe I misunderstand though… once turned solid, I guess it’s no longer an stl, but according to what you are saying, it’s then EDITABLE?

Measuring alone of course doesn’t help, in that I can do that with a number of programs… I’m downloading it now to see if I can figure it out.

Thanks,

David

From: bruce356 [mailto:notifications@github.com] Sent: Tuesday, March 18, 2014 8:04 PM To: alexrj/Slic3r Cc: neodavid315 Subject: Re: [Slic3r] Holes to small (#1588)

Hi neodavid315, I use FreeCad to change the stl files into a solid so that the part can be edited and measured, its a free program open source and does this very well. Others charge a lot of money for this added feature like Inventor, not only is the program expensive but if you want this feature you have to pay an extra $200, so use FreeCad it will do everything you need. regards - bruce

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

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-38047705 .Image removed by sender.

bruce356 commented 10 years ago

The correction factor can be set to the accuracy you require.

Regards - Longo

From: MaJaMo [mailto:notifications@github.com] Sent: Wednesday, 19 March 2014 8:24 PM To: alexrj/Slic3r Cc: bruce356 Subject: Re: [Slic3r] Holes to small (#1588)

Interesting would be good to know if the correction factor changes with layer height and hole diameter. Is it caused by laying down too much plastic on the inside of an arc or is the arc being told to print in the wrong place.

This kind of information will help to build a model of what is happening.

Sent via MaJaPhone

On 19 Mar 2014, at 00:03, bruce356 notifications@github.com wrote:

Hi neodavid315, I use FreeCad to change the stl files into a solid so that the part can be edited and measured, its a free program open source and does this very well. Others charge a lot of money for this added feature like Inventor, not only is the program expensive but if you want this feature you have to pay an extra $200, so use FreeCad it will do everything you need. regards - bruce

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-38033174 .Image removed by sender.

alranel commented 10 years ago

FYI http://forums.reprap.org/read.php?263,273929

arildj78 commented 10 years ago

I have been monitoring this issue for a while and suggests that we move on to coordinated testing. I have created a testplan and hope that you all will participate so we can gather enough empirical data to come up with a list of relevant factors and how they affect the final print.

To give comparable data, we should all start with the same STL files. I have genereated 8 different files to use in different parts of the test. Please see the test-matrix for when to use them.

Please feel free to make suggestions on any changes to the test, however, as soon as testing commences we should not change the setup unless we reset all results and start from scratch.

Will you join?

The testplan can be found on https://docs.google.com/spreadsheet/ccc?key=0AiLKYAeyIMXIdHJSY0NHVmlSbG8yZ2llRUxHeDZESXc&usp=sharing

wentbackward commented 10 years ago

Hi, I am also experiencing this problem, as others have reported my IDs are 0.4mm to 0.5mm. I've tried printing almost a dozen of the same tiny pieces at fast/mid and fine settings for my printer. The consistency is remarkable. I've printed the same file on my UP plus 2 and the piece came out perfectly adequate. This all leads me to believe there is something wrong in Slic3r.

I'm happy to provide my rhino files, STL, config files and a sample of gcode files. Please let me know if there's anything I can do to diagnose the issue.

harriv commented 10 years ago

Someone thinks he knows what Slic3r does wrong: http://hydraraptor.blogspot.fi/2014/06/why-slicers-get-dimensions-wrong.html

alranel commented 9 years ago

As of today, Slic3r has an option for compensating external size. More info at: http://manual.slic3r.org/troubleshooting/dimension-errors

nicksears commented 8 years ago

Alexrj, this issue needs to stay open. I've read every forum out there and this is definitely not resolved. You've detailed many of the compounding issues in the slic3r documentation, but EVERYONE still has this issue. X-Y compensation is nice but it shrinks the outside as well so it fixes one problem to make another. With this and the gap fill error in 1.2.9, this may be a nightmare for new users. I've been looking at the the arc compensation and doing some volume calculations for swept solid of different radii to determine what the best solution might be. All the other posts for reference:

http://forums.reprap.org/read.php?263,273929 http://forums.reprap.org/read.php?263,134103 https://github.com/alexrj/Slic3r/issues/1613 https://github.com/alexrj/Slic3r/issues/491 https://github.com/alexrj/Slic3r/issues/426 https://github.com/alexrj/Slic3r/issues/418 https://github.com/alexrj/Slic3r/issues/56 http://hydraraptor.blogspot.co.uk/2011/02/polyholes.html And lastly http://hydraraptor.blogspot.co.uk/2014/06/why-slicers-get-dimensions-wrong.html

We need to get this fixed. Can anyone say they get holes within 0.25mm without compensation of one sort or another? I have a well calibrated printer that gets within 0.03mm OD, but is almost always 0.4-0.5 under in ID.

edit:links, typo

nophead commented 8 years ago

See http://hydraraptor.blogspot.co.uk/2011/02/polyholes.html for why round holes come out too small and how to get them correct. Also note that if you using multiple outlines you need to do the inner one first for a hole and the outer one first for a perimeter.

On 7 November 2015 at 15:19, nicksears notifications@github.com wrote:

Alexrj, this issue needs to stay open. I've read every forum out there and this is definitely not resolved. You've detailed many of the compounding issues in the slic3r documentation, but EVERYONE still has this issue. X-Y compensation is nice but it shrinks the outside as well so it fixes one problem to make another. With this and the gap fill error in 1.2.9, this may be a nightmare for new users. I've been looking at the the arc compensation and doing some volume calculations for swept sold of different radii to determine what the best solution might be. All the other posts for reference:

http://forums.reprap.org/read.php?263,273929 http://forums.reprap.org/read.php?263,273929,274376#msg-274376 http://forums.reprap.org/read.php?263,134103,137818#msg-137818

1613 https://github.com/alexrj/Slic3r/issues/1613

491 https://github.com/alexrj/Slic3r/issues/491

426 https://github.com/alexrj/Slic3r/issues/426

418 https://github.com/alexrj/Slic3r/issues/418

56 https://github.com/alexrj/Slic3r/issues/56

And lastly http://hydraraptor.blogspot.com/2014/06/why-slicers-get-dimensions-wrong.html?m=1

We need to get this fixed. Can anyone say they get holes within 0.25mm without compensation of one sort or another? I have a well calibrated printer that gets within 0.03mm OD, but is almost always 0.4-0.5 under in ID.

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-154714003.

nicksears commented 8 years ago

Hi nophead, thanks for responding! I've read your info on polyholes and it's a neat solution to the problem. Shaping a polygon around a hole mitigates the constant "smushing" towards the center that is caused by curving the extrudate in an arc. A polygon still has some of these effects in the corners, essentially turning them into fillets, but they don't affect fit since they're outside of the cylindrical hole we're trying to create. It's elegant that it has the relationship between the diameter and number or sides for the polygon, but it doesn't FIX the issue. It's more elegant than designing in an extra 0.5mm to the diameter of a hole, but it can get complicated when trying to create a thread or something more complex.

After addressing (or coping) with all of the other mechanical, processing, and material issues (I feel they're well summed up here and other places) we are still left with the issue of the volume mismatch between the inner and outer half of the revolved "stadium" shape that makes up our perimeters.

The first half of the issue is the compounding of the error resulting from multiple perimeters. This is mitigated reasonably well by placing outer perimeters first. Since the compounding error is now pushed inwards, I think this means that the perimeter overlap could be lower, but I have not proven this. But even a single line will "smush" towards the center (not just "dragging" or shrinking) because of the flow math.

However, to fix the other half of the issue, Slic3r should compensate for the fact that more material is deposited on the inside of an arc, possibly by offsetting the centerline based on the radius and possibly other geometric factors. This would fix the issue with a single circular perimeter, but it would probably fix the compounding issue with multiple perimeters as well. The solution is to figure out the ratio of the volume of the inner half of the path as a function of the radius. I'm no math major but I'm working it out. Hopefully I'll be back with an answer soon, because this is driving me crazy.

nophead commented 8 years ago

Dr Adrian Bowyer's maths for compensation for less flow needed inside can be found in RepRap wiki by following the link in my article. However, I think the dominant shrinking is caused by the drag towards the center, which depends on nozzle size and plastic viscosity, so would need an empirical solution.

arildj78 commented 8 years ago

Even though there have been several attempts to describe the math behind this problem, I don't think any of the solutions will give a magic solution to the problem. Circles represented by polygons are surely one factor, dragging the extrusion another. How much each factor contributes to the total error is bound to be design dependent and probably even specific to each individual printer.

I believe we can get a good approximation with a simple function and trial and error to set the constants. The best would of course be a semi automatic calibration, where measures of a testprint can be plugged into the software to figure out the constants.

I suggest examining f(x)=ax^2+bx+c where x is the design radii and f(x) is the corrected radii. a, b and c are constants to be figured out by trial and error.

The difficult part of this may be detecting a hole and modifying it with a new radius.

bstott commented 8 years ago

For hole diameter ---- use the ratio of the design diameter to printed diameter times the designed diameter for input to the printer as the new radius for the printed hole and subsequent holes. Yes? This would be the fudge factor for the specific printer and present calibration. Yes?

Example:

  1. Print test hole.
  2. Measure hole printed diameter.
  3. Adjust per: (Design_diameter / Printed_diameter) X Design_diameter OR Design_diameter squared divided by Printed_diameter for the input diameter to print on the specific printer.
  4. Adjust design for resulted hole size for stl and slicing - OR - ???

How to put into --- firmware or splicer?

nicksears commented 8 years ago

The thing is, if we get too empirical about this, the solution won't stick if any parameters change significantly. That said, I'd be fine with separate inner/outer compensation (at least that might work better than xy size compensation. I think the most meaningful thing we can do is try and fix what we know is mathematically incorrect, and we can tackle compensating for other known issues later.

I'm blaming the flow math around curves because it's a definite cause of inaccurate hole sizes. This is true even with a single perimeter on a perfectly rigid machine with perfect filament. If we fix this issue, it may not fix the entire issue with hole sizes, but it should fix the issue with multiple perimeters (we should be able to do them in any order) and it will likely make many aspects of printing more accurate.

arildj78 commented 8 years ago

(Causes are cut'n paste from my entry on this issue 13 Mar 2014)

POSSIBLE CAUSES

1 - Shrinkage 2 - More material on inside when turning 3 - Segmented polylines 4 - Filament cutting corners 5 - Z Wobble 6 - Low quality filament

Solution

I don't know how to write code to correct for these. I will however help with the math if needed. Error 4 is possibly difficult to predict and will probably be a fudge factor of some sort. Error 5 and 6 will also be a fudge factor, either separate or included in error 4.

Does anyone here contribute to the code and are able/willing to do something about this?

nicksears commented 8 years ago

I think # 1 should be ignored for now because it's a smaller/less common issue. Also, we should be able to either scale or "shrink" in X-Y to fix this (one thing that should be an easy change would be to have mm OR % in the XY compensation)

.# 2 is the issue I'm wrestling with. I think we need something like arc compensation put back in. I'm going to go back to the old version of slic3r that still has it to see how it acts. Anyone know when it was removed? I think I read ~v0.8 or so. Also, I've started evaluating toolpaths made in commercial "catalystEX" software by stratasys to try and figure out what offset they're using. I'll have more on this soon once I extrapolate nozzle size (or at least extrusion width) and see how it changes with hole/edge size.

I dont feel like # 3, segmented polylines should have much of an impact since, as nophead's post points out, only 22 lines are needed to reduce shrinkage to 1%. I can like with a 2.97mm 3mm hole.

I think with # 4, filament cutting corners, this described wrong in the slic3r manual. Either this means filament dragging towards the center, and in that case I'm having a hard time coming up with an actual mechanism of how that's happening. Or, this is actually cutting corners, which is the increased flow towards the inside that we get in issue # 2.

.# 5 and 6 are mechanical issues and while it might be good to have the ability to compensate for z wobble and crappy filament, it should be separate. You can't complain about 0.5mm hole variance with a >5% variance in filament and/or z wobbling ~0.5mm.

edit:formatting

nicksears commented 8 years ago

OK I already have some initial data. I've analyzed quite a few simple files created by CatalystEX. (I don't know if this is necessarily free software, but it's not exactly useful unless you have a stratasys printer...) I got it from some university webpage so it's out there and not hard to find. I made a range of holes (inner) and posts (outer) in square and circular form, and sliced them with the software at 0.1" (0.196mm) layers for a "dimension elite", and it exports a .cmb file. I then opened it with the cmbviewer (within the program files folder) and measured the diameter of the inner or outer square or circular toolpath (click and drag) to see if they offset the perimeter for holes vs posts vs straight edges and I can say they most certainly do NOT. While I did not know the nozzle diameter, I found the extrusion width to be around 0.5mm and the measurements were always the exact number +/- the nozzle diameter (depending if it was an inner or outer hole. This did decrease for lower layer heights to about 0.4 (I think they use a ~0.35mm nozzle).

wentbackward commented 8 years ago

Hi Nick, I have a Stratasys uPrint SE and they temp runs close to 300'C when printing, the filament is clearly far more liquid and the ABS is of a special formulation geared to their temperature and to the extrusion process. ... I think this is fortunate as I would not use any knowledge about a commercial process in an open source product unless you specifically know the legalities. The Uprint SE is remarkably accurate as well as being of heavy industrial construction, surprisingly vibration still sneaks in, but is kept to a minimum. I don't feel a specific process for a specific machine with specific materials is going to be a fruitful exploration.

You'll kick yourself but from your previous msg 0.1" is 2.54mm (0.1 x 25.4) :).

Good luck, this is definitely a required feature! I can try to provide help where I can, but unfortunately not using any open source printers right now. Paul

arildj78 commented 8 years ago

Is this a problem with other open source slicers or toolchains? As far as I can see this issue was closed quite a while ago, and I'm considering abandoning slic3r in favor of a software that don't have this problem (if something like that exists).

If we have someone here with the skills to make changes to the source, then I'll be glad to contribute. Final goal must be to be able to print a post and a hole of equal diameter that fits together.

xoan commented 8 years ago

Final goal must be to be able to print a post and a hole of equal diameter that fits together.

It is theoretically impossible, I think.

A point in space doesn't take space, but two points in the space placed in the same coordinates are, actually, the same point.

So the inner contour of the hole and the outer contour of the post can't have the same dimension, because in that case, a point in the hole contour have a coincidental point in the post contour (all of this without taking account of material tolerances and all the things described in Slic3r manual about Z errors like misaligned perimeters).

wentbackward commented 8 years ago

@xoan et al.

it is not appropriate to specify only the diameter of a circle with no mass. A pipe for example is generally described with an outer diameter (OD) and a wall thickness. A ball bearing can be described by it's inner diameter and outer diameter (along with other things). So you CAN build a model in 3D CAD representing such parts as pipes, bearings, solids with holes and you can precisely describe the dimensions such as an inner diameter.

What is more difficult to describe are the tolerances, but all this has been thought of for us too and supported within many CAD systems. For example circularity is a geometric characteristic that described how round something is and one of the ISO GT&D characteristics standardised for communicating compliance / tolerances to a standard.

Finally when melting plastic we need to carefully consider the coefficient of expansion of the material (people refer to as 'shrinkage'). Again all this has been thought of and carefully worked out by people far cleverer than I'll ever be.

I mention all this here to give the correct terms for willing slic3r programmers without engineering knowledge to be able to google the right things to understand how the eventual calculations need to be made.

ioquatix commented 8 years ago

I'd like to see progress on this issue. I just printed a hole with d=1.5 and it came out <0.5mm. I feel like the model for how plastic is deposited might be the culprit as it's probably likely that the plastic is smushing out further than slic3r might anticipate. I tried the XY compensation but it looked like it generated slightly buggy output.

lordofhyphens commented 8 years ago

Something that massive feels more like overextrusion than anything else the slicer might be doing. Does the problem follow different settings or change of slicers (like cura or Craftware)? On May 26, 2016 7:41 AM, "Samuel Williams" notifications@github.com wrote:

I'd like to see progress on this issue. I just printed a hole with d=1.5 and it came out <0.5mm. I feel like the model for how plastic is deposited might be the culprit as it's probably likely that the plastic is smushing out further than slic3r might anticipate. I tried the XY compensation but it looked like it generated slightly buggy output.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-221859538

DrLex0 commented 8 years ago

This is definitely still an issue, but if the length of this thread wasn't enough of an indication: there is no obvious cause.

I printed an object that has some internal holes of 3 and 6mm diameter, as well as one hole half-open to the outside, with an 11.25 mm diameter. The internal holes ended up about 0.4mm too small in diameter. The outside hole was printed accurately to almost 0.01mm.

So, to test the hypothesis that outside perimeters are treated differently from inside, I created a cheese-like test object, with exactly the same situation: two internal holes and two holes open to the outside, 5 and 8 mm diameters. Hypothesis debunked: all holes ended up printed too small. The degree of mismatch only seems to depend on diameter. The 8mm hole is about 0.3mm too small, the 5mm one about 0.4mm. Maybe the equation used by Slic3r ignores a certain effect that only manifests itself at the smallest diameters.

If there is no fundamental solution, it would be nice to split up XY size compensation between outside and inside perimeters, so we can independently tweak those depending on the model.

mrbi11 commented 8 years ago

I believe this may be a subtle effect of the slight miscalculation (one could argue miscalibration) of the amount of material being laid down. Recall you are not printing, your are squirting a round tube of liquid down. It needs to be slightly larger than the square it is supposed to fit in, so the walls of each liquid thread become squished roughly flat against each other. As the printing occurs usually outside to inside, the accumulation is to be shifted inwards. It cant really be "fixed" by reducing the amount of liquid being laid down, or the threads stop deforming to adhere to each other and it de-laminates.

So I dont have any uniform solution to offer, since I expect it varies from printer to printer. As a practical matter, I would print the thing with the hole and either drill it to size when that is possible, or do what I did on several pieces, measure the wrong sized hole, then reprint with a larger hole size calculated to correct the error. Neither particularly ideal.

I would note that when printing very small holes, reversing the order of printing may make it worse. Why? because you are dragging a liquid stream. If you sharply turn a corner, the liquid is viscose enough to be dragged along to the side if one turns a sharp corner. I expect if you make any sharp turn the actual effect is that the turn becomes a small radius curve. Unless the printer stopped, disengaged till it cooled, then reengaged any very fast change of direction the fluid will tend to drag along. Basically for really small holes printing inside to outside may just make it get pulled to the side instead of pushed to the side.

Good luck to all.

peace, bill kelley 512 266 1896

On 8/10/2016 1:24 PM, Alexander Thomas wrote:

This is definitely still an issue, but if the length of this thread wasn't enough of an indication: there is no obvious cause.

I printed an object that has some internal holes of 3 and 6mm diameter, as well as one hole half-open to the outside, with an 11.25 mm diameter. The internal holes ended up about 0.4mm too small in diameter. The outside hole was printed accurately to almost 0.01mm.

So, to test the hypothesis that outside perimeters are treated differently from inside, I created a cheese-like test object, with exactly the same situation: two internal holes and two holes open to the outside, 5 and 8 mm diameters. Hypothesis debunked: all holes ended up printed too small. The degree of mismatch only seems to depend on diameter. The 8mm hole is about 0.3mm too small, the 5mm one about 0.4mm. Maybe the equation used by Slic3r ignores a certain effect that only manifests itself at the smallest diameters.

If there is no fundamental solution, it would be nice to split up XY size compensation between outside and inside perimeters, so we can independently tweak those depending on the model.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/1588#issuecomment-238957698, or mute the thread https://github.com/notifications/unsubscribe-auth/AFpbfm855BdnZV1emZaG_tIiGfkZYEcMks5qehdNgaJpZM4BR8II.

mrvn commented 8 years ago

@DrLex0 How did you design the holes? What is the actual radius of the polygon and how many facets does it have (for each hole)? It sounds like you aren't correcting the polygon to be an outcircle.

@mrbi11 That idea does not track. Holes are printed as perimeters and either from the inside out (meaning outside in for holes) or outside first depending on your settings. Default is inside out.

As for draging the filament that is indeed the unsolved problem. But the rule for holes, as implemented in the polyholes openscad library) is to use less faces the smaller the hole and to make the polygon stay outside the hole. The drag effect seems to usualy cancel out the polygon being to big and give near perfect holes. But that depends on the printer speed, filament and temperature too. It just happen to accidentally work out about right for most people.

DrLex0 commented 8 years ago

I used 64 facets for the holes in this ‘cheese test,’ which means the effect of the hole being approximated by a polygon should be negligible considering the small radii. I guess I'll try polyholes next time. It would be great if we could just design models with “a hole of this diameter here” and the slicer would render this in the best way for the specific printer, instead of having to design the model with limitations of the printer in mind…

whosawhatsis commented 8 years ago

@DrLex0 If you're not doing the 1/cos(180/n) math, where n is the number of segments in the "circle", then you are actually specifying a hole that is smaller than the circle you want to fit inside. That's a limitation of the design software, and polyholes is a workaround for it.

DrLex0 commented 8 years ago

@whosawhatsis Yes, but for 64 segments, the error of not compensating amounts to 0.12%, not the +8% I measured in my test.

mrvn commented 8 years ago

@DrLex0 Slic3r can not render the hole since the stl file contains the hole already rendered. You have to do the hole right in your design software.

Another effect you have with 64 segments on a 3mm hole is that the segments get really short. So short that, at least when printing over serial, the time to transmit the gcode is larger than the time to move the head. That causes a stutter on the printer where the head moves, stops, moves, stops, moves, stop. Can't be good for print quality.