Holes to small

[tmorris9]

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.

[DrLex0]

@mrvn My point is that if we need to design holes with limitations in mind of the particular printer they will be printed on, then there is not even a way to “do the hole right” if the goal is to publish a model that anyone can download and print on any printer, including ones where there is not even a piece of machinery that traces contours. We shouldn't be limiting models to jaggy holes just because a certain type of printer will only print those jaggy holes correctly.

Of course, there is indeed no fundamental solution for this as long as we keep on using representations that consist of pre-rendered surfaces (heck, we shouldn't even be representing surfaces, but volumes). At best, there can be workarounds, but those workarounds should not be performed during the modelling stage. A 3D model should be like a technical drawing, and a key requirement of a technical drawing is that it is independent of the particular way in which the part will be manufactured.

[nophead]

Polyholes work on any printer that gets straight lines in the right place. They may look a bit faceted on a high resolution printer but they work fine to hold a fastener or a shaft. In the former case they get covered up anyway. Since I started using them I have no problem with hole sizes.

On 18 August 2016 at 14:52, Alexander Thomas notifications@github.com wrote:

@mrvn https://github.com/mrvn My point is that if we need to design holes with limitations in mind of the particular printer they will be printed on, then there is not even a way to “do the hole right” if the goal is to publish a model that anyone can download and print on any printer, including ones where there is not even a piece of machinery that traces contours. We shouldn't be limiting models to jaggy holes just because a certain type of printer will only print those jaggy holes correctly.

Of course, there is indeed no fundamental solution for this as long as we keep on using representations that consist of pre-rendered surfaces (heck, we shouldn't even be representing surfaces, but volumes). At best, there can be workarounds, but those workarounds should not be performed during the modelling stage. A 3D model should be like a technical drawing, and a key requirement of a technical drawing is that it is independent of the particular way in which the part will be manufactured.

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

[mrbi11]

While your statement is true, I would tend to question whether any melted filament printers are capable of laying down straight lines where the head passes.

The filament must be laid down slightly oversized, and is a fluid. This may be a tiny error, perhaps 1/100 of a trace width. But to lay a solid wall, say the trace width is 0.5mm and one wishes to lay a solid wall only 5mm thick, thats 10 traces and the cumulative push of fluid to one side is now 1/10 of a trace or .05 mm x 2 for a hole. I think in fact this is an extremely optimistic with 1/100 and this would mean the round liquid filaments barely touch and this would de-laminate. This is one of the reasons its basically not possible to print large solid pieces at all, one must have fill areas with some space in them. (Its not the only reason, as the dimensions also change a lot during cooling) A more realistic case is the filament is 1/10ths to 1/5th oversized to get "good" deformation into the rectangle filament one really wants. Then the same example is .5 to 1mm x2 for a hole printed from outside in.

Printing from inside out gets a different problem I mentioned last time, the filament is molten still as the head changes direction, so is pulled to the side as the heat changes direction. I always got more repeatable results from outside in. Otherwise the tinier the hole the more likely it just disappears.

Either way, melted filament printers are not capable of precise placement of the filaments, but are always subject to drag and displacement.

There are papers out there describing this, I can't take credit for being the first to consider this, rather I'm describing (probably not well) issues that are known limitations with the methodology.

If you think not, try "printing" with a toothpaste tube. Do it on graph paper so you can measure the displacement. Make sure the traces have nice flat walls, not barely touching. Try turning a tight corner without dragging it along. I bet you always get slightly curved corners. Mark some straight traces side by side before you lay a toothpaste "wall" down. If you lay it down trace after trace, you will see the traces creep to the side.

Best wishes.

peace, bill kelley 512 266 1896

On 8/18/2016 9:56 AM, Chris wrote:

Polyholes work on any printer that gets straight lines in the right place. They may look a bit faceted on a high resolution printer but they work fine to hold a fastener or a shaft. In the former case they get covered up anyway. Since I started using them I have no problem with hole sizes.

On 18 August 2016 at 14:52, Alexander Thomas notifications@github.com wrote:

@mrvn https://github.com/mrvn My point is that if we need to design holes with limitations in mind of the particular printer they will be printed on, then there is not even a way to “do the hole right” if the goal is to publish a model that anyone can download and print on any printer, including ones where there is not even a piece of machinery that traces contours. We shouldn't be limiting models to jaggy holes just because a certain type of printer will only print those jaggy holes correctly.

Of course, there is indeed no fundamental solution for this as long as we keep on using representations that consist of pre-rendered surfaces (heck, we shouldn't even be representing surfaces, but volumes). At best, there can be workarounds, but those workarounds should not be performed during the modelling stage. A 3D model should be like a technical drawing, and a key requirement of a technical drawing is that it is independent of the particular way in which the part will be manufactured.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/alexrj/Slic3r/issues/1588#issuecomment-240729397, or mute the thread

https://github.com/notifications/unsubscribe-auth/AAijhfU5-sQY014KVTEV-m6k_hjjCMgNks5qhGO2gaJpZM4BR8II .

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

[nophead]

I always print with a single outline to get accurate dimensions. If I want it strong I use 95% infill. So there is no displacement, only drag around corners. Polyholes avoid the drag problem by having as few corners as possible so that they are far enough outside the circle to not impinge on it. That way my STL files are printer independent.

To print perfecting round circles accurately you would need a different file representation for circles and then filament type / nozzle size / print speed / layer height / etc dependent slicing.

On 18 August 2016 at 17:15, mrbi11 notifications@github.com wrote:

While your statement is true, I would tend to question whether any melted filament printers are capable of laying down straight lines where the head passes.

The filament must be laid down slightly oversized, and is a fluid. This may be a tiny error, perhaps 1/100 of a trace width. But to lay a solid wall, say the trace width is 0.5mm and one wishes to lay a solid wall only 5mm thick, thats 10 traces and the cumulative push of fluid to one side is now 1/10 of a trace or .05 mm x 2 for a hole. I think in fact this is an extremely optimistic with 1/100 and this would mean the round liquid filaments barely touch and this would de-laminate. This is one of the reasons its basically not possible to print large solid pieces at all, one must have fill areas with some space in them. (Its not the only reason, as the dimensions also change a lot during cooling) A more realistic case is the filament is 1/10ths to 1/5th oversized to get "good" deformation into the rectangle filament one really wants. Then the same example is .5 to 1mm x2 for a hole printed from outside in.

Printing from inside out gets a different problem I mentioned last time, the filament is molten still as the head changes direction, so is pulled to the side as the heat changes direction. I always got more repeatable results from outside in. Otherwise the tinier the hole the more likely it just disappears.

Either way, melted filament printers are not capable of precise placement of the filaments, but are always subject to drag and displacement.

There are papers out there describing this, I can't take credit for being the first to consider this, rather I'm describing (probably not well) issues that are known limitations with the methodology.

If you think not, try "printing" with a toothpaste tube. Do it on graph paper so you can measure the displacement. Make sure the traces have nice flat walls, not barely touching. Try turning a tight corner without dragging it along. I bet you always get slightly curved corners. Mark some straight traces side by side before you lay a toothpaste "wall" down. If you lay it down trace after trace, you will see the traces creep to the side.

Best wishes.

peace, bill kelley 512 266 1896

On 8/18/2016 9:56 AM, Chris wrote:

Polyholes work on any printer that gets straight lines in the right place. They may look a bit faceted on a high resolution printer but they work fine to hold a fastener or a shaft. In the former case they get covered up anyway. Since I started using them I have no problem with hole sizes.

On 18 August 2016 at 14:52, Alexander Thomas notifications@github.com wrote:

@mrvn https://github.com/mrvn My point is that if we need to design holes with limitations in mind of the particular printer they will be printed on, then there is not even a way to “do the hole right” if the goal is to publish a model that anyone can download and print on any printer, including ones where there is not even a piece of machinery that traces contours. We shouldn't be limiting models to jaggy holes just because a certain type of printer will only print those jaggy holes correctly.

Of course, there is indeed no fundamental solution for this as long as we keep on using representations that consist of pre-rendered surfaces (heck, we shouldn't even be representing surfaces, but volumes). At best, there can be workarounds, but those workarounds should not be performed during the modelling stage. A 3D model should be like a technical drawing, and a key requirement of a technical drawing is that it is independent of the particular way in which the part will be manufactured.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/alexrj/Slic3r/issues/1588#issuecomment-240729397, or mute the thread

https://github.com/notifications/unsubscribe- auth/AAijhfU5-sQY014KVTEV-m6k_hjjCMgNks5qhGO2gaJpZM4BR8II .

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

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

[nicksears]

Stratasys (even a cheap mojo) gets holes within 0.1mm). You need a 3mm hole? Design a 3mm hole. That's how it should be. My well calibrated reprap is typically 0.3-0.4. Poor z rods, filament, all the stuff mentioned on http://manual.slic3r.org/troubleshooting/dimension-errors are valid, but don't fully solve the problem.

Polyholes is a unique solution, but it's more an indication of the problem. It's a design constraint that you need to export an stl with quality equal to or beyond what you need. All this talk about having too many facets, or needing to design it with a certain number of facets is not necessary. With polyholes, we're essentially designing a bigger hole by circumscribing it within a polygon.

What we really need to do is modify flowrate in an arc depending on the radius. I've visually checked the gcode (line view) from stratasys machines and they have no compensation in terms of the actuall coordinates. For a .5mm nozzle and 3mm hole, the line has a diameter of .5mm (offset by half the diameter on both sides). There are other issues with the outer edge of the extruded line being undersized (in general, but also if we reduce flow) but i'm looking into how they handle this to get some ideas.

[nicksears]

@nophead You get good measurements with slic3r and one perimeter? A single outline definitely has the biggest impact IMO. Could we get the details of your setup? (slic3r ini settings) :smile:

[nophead]

No I get good measurements with Skeinforge with one perimeter.

On 18 August 2016 at 18:11, nicksears notifications@github.com wrote:

@nophead https://github.com/nophead You get good measurements with slic3r and one perimeter? A single outline definitely has the biggest impact IMO. Could we get the details of your setup? (slic3r ini settings) 😄

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

[mrvn]

@DrLex0 polyholes only fixes the design flaws of using STL as intermediary format. You are designing an hole and polyhole will make it a polygon that sits outside the hole. That it also somewhat corrects for the printer dragging filament to the inside of corners is a lucky side effect of trying not to overwhelm the printer with too short segments.

[bubnikv]

@mrvn We are going in circles. Instead of only commenting on the flaw of the current solution, please propose a better way to handle the holes.

[nophead]

So a better way: For each layer height, filament viscosity, nozzle size, print speed measure the amount that filament lags behind the nozzle. That distance makes the curve traced by the filament a tractrix. Then change the file format from STL to something that represents curves as curves. Then have a slicer that takes that format and moves the nozzle in an inverse tractrix to get an accurate desired curve.

A lot of work and a lot of extra data required but polyholes are no work and solve the problem of printing holes that things fit in regardless of all the parameters I mentioned before. They don't need a new file format or any slicer changes.

On 19 August 2016 at 15:51, bubnikv notifications@github.com wrote:

@mrvn https://github.com/mrvn We are going in circles. Instead of only commenting on the flaw of the current solution, please propose a better way to handle the holes.

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

[DrLex0]

@bubnikv Yeah, I am starting to get déjà vus too.

I have tried polyholes and initially they also came out too small, so they are not a magic bullet solution for everything. It was only after I enforced narrower perimeter extrusion widths than Slic3r's auto setting, that they came out OK. However, rounder holes (with cos(1/n) correction) also come rather close to being accurate in that case. “External perimeters first” barely makes a difference, if there is an improvement in hole accuracy it is only marginal. I am starting to prefer it though, because it does a better job at avoiding small gaps between perimeters and infill.

I have also tested the too-many-segments theory by printing holes with high and low numbers of segments in both ABS and PLA, and found no evidence that it is valid in my case (printing from SD card on a 2016 FFCP). The printer does not slow down when printing the high-resolution holes, and there is no discernible difference with lower-resolution holes. This could be because I have set a resolution limit of at least 0.02 mm in all my print settings profiles, and going above 48 segments for a 3 mm hole pushes segment length below 0.2 mm.

[mrvn]

Yes, we are going in circles. Yes, polyholes are not a magic bullet. They only fix the problems on the design side and shortcomings of STL. It's the minimum you have to do. Obviously they are no different from round holes with cos(1/n) correction. Because that's exactly the correction polyholes does.

Now forget all about the polyholes and concentrate of the issues actually caused and relevant to slic3r. Namely modeling how the filament gets pushed and dragged inside the tool path. I'm with bubnikv there.

@DrLex0 Obviously you don't see the problem when printing from SD card. An SD card manages 1-10MiB/s, the serial porton the other hand only does 10-20KiB/s. That's 3 magnitudes slower. And a resolution limit of 0.02mm puts a limit there too.

[nophead]

Because that's exactly the correction polyholes does.

No polyholes do two things. The cos(1/n) puts the sides of polygon on the circle instead of the vertices. Since the sides are straight lines they are accurately placed if only one outline is used. Reducing the number of vertices to the minimum puts the corners as far outside the circle as possible. That means that when the corners are rounded by the corner cutting effect they are still outside the circle. That's how it works for me anyway.

On 21 August 2016 at 22:56, Goswin von Brederlow notifications@github.com wrote:

Yes, we are going in circles. Yes, polyholes are not a magic bullet. They only fix the problems on the design side and shortcomings of STL. It's the minimum you have to do. Obviously they are no different from round holes with cos(1/n) correction. Because that's exactly the correction polyholes does.

Now forget all about the polyholes and concentrate of the issues actually caused and relevant to slic3r. Namely modeling how the filament gets pushed and dragged inside the tool path. I'm with bubnikv there.

@DrLex0 https://github.com/DrLex0 Obviously you don't see the problem when printing from SD card. An SD card manages 1-10MiB/s, the serial porton the other hand only does 10-20KiB/s. That's 3 magnitudes slower. And a resolution limit of 0.02mm puts a limit there too.

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

[ioquatix]

@mrvn could you solve the bandwidth problem by increasing buffer space on the device?

[bubnikv]

You would have to change the serial protocol to send and confirm multiple lines at once. The bottleneck currently is the turn around time of the USB2 protocol.

On Aug 22, 2016 4:26 AM, "Samuel Williams" notifications@github.com wrote:

@mrvn https://github.com/mrvn could you solve the bandwidth problem by increasing buffer space on the device?

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

[mrvn]

@ioquatix Want to solder on some extra ram?

@bubnikv The serial protoctol already sends multiple lines and the firmware buffers it. Just a few lines though, like 3, since the problem is the lack of ram on the microcontrollers. It buffers just enough to calculate direction changes ahead of time so it can limit the acceleration and jerk.

[bubnikv]

The serial protoctol already sends multiple lines and the firmware buffers it. Just a few lines though, like 3, since the problem is the lack of ram on the microcontrollers. It buffers just enough to calculate direction changes ahead of time so it can limit the acceleration and jerk.

What firmware? What protocol?

AFAIK Marlin sends the g-code line by line, because there is no hardware line control implemented.

On Mon, Aug 22, 2016 at 9:15 AM, Goswin von Brederlow < notifications@github.com> wrote:

@ioquatix https://github.com/ioquatix Want to solder on some extra ram?

@bubnikv https://github.com/bubnikv The serial protoctol already sends multiple lines and the firmware buffers it. Just a few lines though, like 3, since the problem is the lack of ram on the microcontrollers. It buffers just enough to calculate direction changes ahead of time so it can limit the acceleration and jerk.

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

[mrvn]

Any firmware should handle it. When sending gcode you can include a line number "Nxxxx" and the controler will respond with "OK xxxx" when it has handled that line. You can also include checksums and firmware is supposed to ask for resends of lines with checksum error or when line number are skipped (because they got lost due to lack of hardware flow control).

Any firmware that has acceleration settings has to not only handle it but also has to read ahead. Without buffering and read ahead the tool would have to stop after every segment making a mokery of the whole thing. Marlin does this and things like Octoprint do send multiple lines (iirc 3) before waiting for OK replies.

[bubnikv]

Marlin does this and things like Octoprint do send multiple lines (iirc 3) before waiting for OK replies.

That's exactly the problem. It waits for OK after each line (all right, it may be 3). This turnaround takes 1ms.

On Mon, Aug 22, 2016 at 1:40 PM, Goswin von Brederlow < notifications@github.com> wrote:

Any firmware should handle it. When sending gcode you can include a line number "Nxxxx" and the controler will respond with "OK xxxx" when it has handled that line. You can also include checksums and firmware is supposed to ask for resends of lines with checksum error or when line number are skipped (because they got lost due to lack of hardware flow control).

Any firmware that has acceleration settings has to not only handle it but also has to read ahead. Without buffering and read ahead the tool would have to stop after every segment making a mokery of the whole thing. Marlin does this and things like Octoprint do send multiple lines (iirc 3) before waiting for OK replies.

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

[nophead]

Although the lines are sent one by one the G1 moves go into the planning buffer after the OK is sent, so as long as there are not too many segments per second the protocol does not slow it down. There is a limit though with USB and a much higher one with SD.

So printing too fast can cause the holes to shrink if the planning buffer runs dry. It also causes the filament to drag more, so corner cutting gets worse.

[nicksears]

OK, I've had a beef with this issue for a while now. I've worked on the flow math behind it before, but haven't come up with an elegant formula that could just say "increase internal radius by a factor of X". The idea is that we're extruding a flattened torus, but it is pushing towards the inside more than the outside, so the volumetric midpoint is not the center of the nozzle.

The points on slic3r's manual are valid (http://manual.slic3r.org/troubleshooting/dimension-errors) but I don't think they account for the whole issue. Here's how I propose proving this is more than just a machine calibration issue and we need some kind of compensation algorithm:

1. Use a single perimeter to avoid multiple perimeters pushing inward (this happens for me even with outer perimeter first selected)
2. Use filament with very low variation, (Within 0.02-0.03mm) for very low flow irregularity which can cause layers to squish inward (and out)
3. Polygon approximations (polyholes) may help compensate for low resolution, but we should also just be able to export and slice at high resolution if this is truly the problem. We should use as high as practically feasible (0.005 is about the max for solidworks, and although it will make slicing slow, this may be reasonable for slic3r as well).
4. Finally, we can also avoid possible speed/stutter issues by printing fairly slow (30mm/s)

This should be easy to test without any physical changes to the printer. If you have a well-tuned/high quality printer, those should be the only possible issues, but for most printers there are also two other main considerations: Z-wobble and backlash.

5. Avoid Z-wobble by using a machine with precise, ballscrew z-axis, no perceptible z-wobble
6. Reduce backlash, completely tune out and test with dial guage within .001" (25um)

I'll try these if my first attempt is not successful with steps 1-4. I plan on trying a range of holes 3.0-3.5mm and see where an exact 3mm rod fits, but a 3mm bolt that usually measures ~2.9 would also pass in my book. I usually have to add 0.4-0.5mm for a through-hole fit, but, I've also used 0.25-0.35 for a tight fit. Any thoughts?

[ioquatix]

@nicksears It's a good idea. There must be some mathematical model for this that can be leveraged to do the right thing.

[nicksears]

This issue has been closed, despite being unresolved for some time. If anyone knows of a more active open issue, please let me know.

I have a few new thoughts on this. The majority of this issue when printing circles. I'm not saying it doesn't happen with internal squares, etc, but for the most part people have issues with curves.

The fact that polyholes can compensate for this error is a perfect indication of this. Polyholes proves that undersized holes result from curves, and you can mathematically determine how many external corners you need so that the internal rounding of those corners does not impinge upon the intended diameter. This would not work if internal flat measurements also had this issue.

This may be something many of you have thought of, but I've never thought of it this way. To me, this proves it's almost entirely a curve issue, not mechanical calibration.

[ioquatix]

I ended up using the following code across all my projects which makes the appropriate compensation:

https://github.com/ioquatix/zonestar-p802q-fan-duct/blob/8fde334e706c33159576af5fbea8cdbe1549466a/source/bolts.scad#L1-L13

It's worked well across a wide range of prints and printers (according to others who have printed the same models).

[TomaszSzt]

This issue is still present. I could not however confirm that printing external perimeters first have any measurable positive effect. If I would dare to say, it is even worse but it is up to the limit of my measurement equipment.

Could we get an access to "arc compensation" coefficient to be able to adjust the amount of compensation applied?

What I do observe is that:

1. Linear dimensions are satisfactory accurate.
2. Round holes are getting smaller than designed, roughly by 1/3 of the path width.
3. Round rods are also getting smaller than designed, roughly by the same rule.

Thous, usually when two parts are printed in the same process everything fits. For an example my 3mm rod gets 2,85/2,7/2,93 while 3mm holes are 2,91/2,87/2,96 so in all cases the fit together even tough they are inaccurate.

Neither XY shring/grow or superslicer hole scaling does not touch the core of a problem - a filament drag on the curve. I think adding user an option to artificially compensate this effect would be great.