[request] XY Compensation for inner perimeters

[Lord2Vader]

Behavior

Having the Printer calibrated correctly prints come out +/- 0.05mm over whole print space. But still inner holes are too small. XY compensation helps but also compensates for the outer dimentions... All in all i can say that inner perimeters are drawn about 0.2 mm to the inside (not due to shrinkage).

So it would be nice to have a Hole Compensation. This would result in correct print more the less...

[lordofhyphens]

For holes is your model designed with kerf in mind? Just shrinking one set of faces is a much harder problem than what xy comp does (which tweaks wall thickness) On May 10, 2016 9:59 AM, "Lord2Vader" notifications@github.com wrote:

Behavior

Having the Printer calibrated correctly prints come out +/- 0.05mm over whole print space. But still inner holes are too small. XY compensation helps but also compensates for the outer dimentions... All in all i can say that inner perimeters are drawn about 0.2 mm to the inside (not due to shrinkage).

So it would be nice to have a Hole Compensation. This would result in correct print more the less...

— 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/3323

[Lord2Vader]

Mhh cant imagine its done that way. I suggest the perimeters are somehow set in or not? Well the thing is, that your CAD file does not state the real dimensions. For that it would be easier for all to just set a fixed print/slicingvalue once. For instance your prototyping and you do a offset on every inner wall and then want to cnc machine it. Depending on the object thats a lot of additional work instead of tweeking the print parameters once in a while. A slicer is a complicated programm so I think its not the worst work to do on a slicer ;) iam not the only one with that problem and as far as I know some slicers like craftware are going that way too.

[mrvn]

Most likely your model is made wrong: http://hydraraptor.blogspot.de/2011_02_01_archive.html

And imho CAD programs are to blame here. They know what is an inside hole and should correct for facet errors. If you also get the facet count right then slic3r doesn't have to compensate for corner cutting since that will actually help correct the facet error that's left. Only when reducing resolution would slic3r need to do something.

Where is your model? How did you make it?

[Lord2Vader]

Yeah thx....of cource...CAD programs are to blame for 3D Printing specific issues... of course! No they are not! CAD Programs are made for design. So if you say the hole shoud be 8mm its declared as 8mm so the CAD program is absolutely correct!

The printer cant figure out what the gcode is trying to tell it because it just does whats its told to, do that G1 X2 Y3 E3 for example. Its a 3D Printing issue which all people have and I just made a suggestion to make 3D printing more pleasant!

XY Compensation is the same thought but it makes holes larger AND outer dimensions smaller or the other way around.

Iam not shure why everyone is against this...

Its like saying no powersteering is not needed. Its the fault of the universe that turning rubbertires around under a 1500kg car is so freaking hard!

[lordofhyphens]

@Lord2Vader It's not currently a priority, but if you can work out how, algorithmically, how to make this work and describe it accurately (also covering the likely follow-on issues), it'll go a long way towards making this feature actually be a thing.

[mrvn]

The CAD program is to blame and here is why: You design a 8 mm hole by telling the CAD program to remove a cylinder with 8 mm diameter. But what the CAD program does is output a 12 sided polygon with 8 mm between the corners and less between the flat surfaces. The printer prints this and the hole is too small.

On the other hand I cut out a six sided cylinder out of my object to hold a standard M8 nut. I tell the CAD program to use 6 sides and what radius to use as per the specs for an M8 nut. The CAD program then outputs a 6 sided cylinder in the stl file with the right dimensions and then printer will print it as such to perfection.

Now imagine slic3r would do XY compensation. Now the 8 mm hole comes out right but the hole for the M8 nut will be too large. How is slic3r supposed to see that the 8 mm 12 sided cylinder is supposed to be round and needs compensation while the 6 sided hole for the M8 nut does not?

I'm not saying XY compensation is useless but more that slic3r can't know where to apply it, not with stl files. That is something the user has to tell the CAD software.

[JohK]

It is NOT the CAD programms. In my experience with printing from stls generated by Pro/Engineer 4 and Creo 2 the inner diameter of holes is always too small. Originally when the no. of facets was suggested to me as the source of this problem, I started exporting extremely high-res stls. (Like in 200 facets per circle). Which made no difference for the resulting prints...

Sadly this issue makes slic3r impractical for me in prototyping mechanical parts, as I always have to rework the holes.

[bubnikv]

When I studied the xy compensation code I was quite surprised. The FFF is notorious in rounding external sharp corners and shrinking internal holes due to the die swell effects (the extruded material wants to shrink to the original shape). So a simple counter measure would be to enlarge holes with small diameter. But the current xy compensation influences the outer perimeters as well, which makes the feature unusable for hole size compensation. I suppose we need a hole only xy compensation. Please note, we implicitly discuss vertical holes only: those, which are perpendicular to the layers. The discussion would be more interesting, if horizontal and slanted holes were considered. On Jul 11, 2016 9:40 PM, "Johannes Kneer" notifications@github.com wrote:

It is NOT the CAD programms. In my experience with printing from stls generated by Pro/Engineer 4 and Creo 2 the inner diameter of holes is always too small. Originally when the no. of facets was suggested to me as the source of this problem, I started exporting extremely high-res stls. (Like in 200 facets per circle). Which made no difference for the resulting prints...

Sadly this issue makes slic3r impractical for me in prototyping mechanical parts, as I always have to rework the holes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3323#issuecomment-231841724, or mute the thread https://github.com/notifications/unsubscribe/AFj5I4n3V2FeeYQ0cgWsqOSoOzHxPEy2ks5qUpwngaJpZM4IbL4I .

[lordofhyphens]

@bubnikv the reason inner and outer perimeters are changed is because I am fairly certain that slic3r can't figure out which faces of the STL constitute holes, as it's not an easy problem. @alexrj can probably shed more light on this, but I'm not aware of any FOSS 3d slicing SW that solves this problem. What Slic3r looks like it does is put the perimeter one half-width from where the edge of the model is, which is what you'd expect.

I found this conference paper while looking around for algorithms to detect solid holes in 3d models; I need to dig around and see if it showed up in a journal somewhere (where hopefully it's explored better). http://www.eurasip.org/Proceedings/Eusipco/Eusipco2012/Conference/papers/1569581583.pdf

Some of this is also failure to design with tolerances in mind, IMHO, since Slic3r does its level best to give you the model you asked for. If you specify a hole to be exactly 8mm, that "8mm" bolt isn't going to fit because it's not perfect either.

Horizontal (that is holes that are parallel to the layers) are generally already taken care of (this is part of designing for tolerance) and I think holes at arbitrary angles w/r/t the layer orientation should be covered if we work out internal faces (on a layer-by-layer basis).

@JohK @nophead did a lot of looking into polyholes (that is, low polygon counts for holes affecting accuracy) at http://hydraraptor.blogspot.com/2011/02/polyholes.html and may be able to weigh in on this.

[JohK]

In mechanical engineering the CAD stage of development is still kind of agnostic of the actual production method. Also in professional CAD systems the 3d model and the derived 2d drawings are linked. You design using nominal values that will carry though to the drawings. While for a hobbyist project it might be an acceptable workaround to just adjust the hole diameter of a single part. In bigger projects this is certainly considered malpractice and will cause havoc down the road.

The problem should arise for all concave and convex shells, right? So the solution might be as simple as correcting for the local curvature?

[lordofhyphens]

AFAIK you'd still design for tolerances, regardless of the production method. If tab A fits into slot B and both are defined at exactly the same dimensions it isn't going to fit.

[JohK]

Classically, you would have the same nominal diameter and define the fit by setting appropriate tolerances for the hole and the axle. The CAM tool preparing the data for the machines (or the worker reading the drawings) would then respect the tolerances.

As you wrote: tolerances are there to define the fit, and thus functionality! The production method has then to be chosen accordingly, not the other way round. Unfortunately the tolerance information is lost when the data is exported to STLs. But this is another problem altogether.

At the moment prints from slic3r don't even have the correct nominal inner diameter of holes. IMHO this is the first problem to address. As I wrote above, I suspect this could be done based on the local curvature of the current shell section.

[bubnikv]

I think the proposal on local curvatures is going in the right direction. If my hypothesis on the hole shrinkage due to the die swell is correct, then you would get insufficient bonding of infill to the hole perimeters. Making the hole bigger in the CAD would not correct for the insufficient bond. The cure is to modify the extruder path to stretch the extrudate to correct for the die swell. This path correction may be described as a local decrease of curvature - the extruder would draw a longer arc, thus stretching the extrudate. This algorithm would then work on holes as well as on outer sharp corners. I suppose the correction would be curvature dependent. Correction of high curvatures would be strong, correction of low curvatures weak or none at all. On Jul 11, 2016 11:10 PM, "Johannes Kneer" notifications@github.com wrote:

In mechanical engineering the CAD stage of development is still kind of agnostic of the actual production method. Also in professional CAD systems the 3d model and the derived 2d drawings are linked. You design using nominal values that will carry though to the drawings. While for a hobbyist project it might be an acceptable workaround to just adjust the hole diameter of a single part. In bigger projects this is certainly considered malpractice and will cause havoc down the road.

The problem should arise for all concave and convex shells, right? So the solution might be as simple as correcting for the local curvature?

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

[lordofhyphens]

@JohK As far as I can tell, Slic3r is producing toolpaths with the correct interior diameter for holes. Example: inner hole is 7mm radius, centered about the origin with a 0.5mm extrusion width. I set 0% infill, no top/bottom infill as well to just get perimeters. See lines 40-56 to see what I mean; Slic3r has the correct coordinates for a 0.5mm trace. test.zip

@bubnikv Interesting theory; if you do any code work on it please please give it its own branch in your repo :) You should be able to even start from your playground branch and it should be able to be rebased to master when you're done.

[JohK]

@lordofhyphens What matters is the printed part having the correct dimensions. Slic3r is the piece of software in the toolchain that translates CAD data to machine code. If "nominal" toolpaths result in in an off-nominal print, slic3r should implement a correction.

The current situation is annoying, because you can't get dimensionally accurate prints from correctly designed CAD-parts with slic3r.

[mrvn]

@JohK The CAD program translates the design into STL file. At that point it has to incorporate tolerances and counteract shrinkage due to triangulation. As said above slic3r can not know weather you have a circular hole that is approximated as octagon and has shrunk due to triangulation or weather you actually want an octagonal hole in the dimension specified in the stl file. Once you have the stl file that information is lost. So the CAD program has to compensate and output the stl file accordingly.

For me there are only 2 questions:

1) does the toolpath + extrusion width follow the surface specified in the stl file? Accoring to @lordofhyphens tests it does.

2) does the printed hole have the dimensions set by the tool path?

@bubnikv seems to suggest this is not the case because the filament does not cooperate. This effect would not be related to holes though but as mentioned to any sharp corner. Holes just being the extrem case where you notice it. It would be interesting to see a model for this and how to counteract it.

Personally I've been printing holes with slic3r compensating in openscad for both the triangulation (enlarge radius to generate an outcircle instead of incircle) and adding tollerance and the holes come out ok. I can print the hole for an M8 nut and it fits in tightly.

[JohK]

@mrvn I completely agree with your questions; and to my experience the answer to the second one is: no, the holes are smaller.

Let me sum it up: There are several steps in the toolchain that could theoretically cause a shrinkage of holes:

1. CAD: Exporting to STLs (Low resolution reduces inner diameters if no compensation takes place) This is known to be an issue, nophead has put quite some time into investigating it. If this is your problem, you can simply fix it by exporting the model with a higher angular resolution.
2. Slic3r: Wrong toolpath As @lordofhyphens wrote slic3r currently assumes the correct toolpath is right along the edge of the model. And based on this assumption the output is correct.
3. Printing: Shrinkage due to the way the plastic is deposited

IMHO If the assumption for the correct toolpath (2) is any good, then printing a high resolution STL file should result in a dimensionally accurate object. To my experience this is NOT the case. Therefore I would challenge the current assumption for the creation of the toolpath. (AFAIK this toolpath simply traces the outlines of the 3d model?)

Solutions:

1. "Change the CAD Model": It is often suggested to change the model, i.e. the inner diameters of holes, to compensate the shrinkage. This is a workaround, which might be ok for very simple CAD models, for more complex projects it becomes a nightmare. From the professional mechanical engineering viewpoint this is just wrong. In the CAD stage you define functionality: can a part rotate around another, how much resistance is there to the rotation, etc. You chose nominal sizes and tolerances so they result in the correct fit for the application: Is the bolt in the hole a snug fit, can it be slid in and out, or is it a loose fit with some play. The CAD-Model reflects the functionality though the chosen dimension and the tolerances of paired parts. Manufacturing has then to respect those.

The printed object should have the exact dimensions of the CAD model/STL file. To my and others experience this is currently not the case for vertical holes.

2. "Toolpath Compensation" For concave toolpaths the extruded plastic seems to be squished more towards the inner radius. The effect becomes obvious in vertical holes where the diameter shrinks. As this is a phenomenon specific to the FDM method, the solution should be implemented in the tool that creates the specific machine code (Slic3r). Maybe the effect could be compensated by moving the toolpath depending on local curvature and extrusion width.

[mrvn]

The "shrinkage" effect seems to also be larger (or less offset by other errors) the more segments you use.

When the CAD program generates a polygon that lies outside the intended circle then the fewer segments you have the larger the hole. And for some lucky reason that actually seems to compensate more or less for the shrinkage effect.

So if you have too small holes try LESS segments, not more. More segments only applies to when the CAD program (or you) does not correct for the triangulation causing shrinkage.

[alranel]

The manual lists several causes affecting size of holes, have you seen it?: http://manual.slic3r.org/troubleshooting/dimension-errors

[bubnikv]

©Alexei mentioned a hole compensation, which has been implemented and later removed from slic3r. I suppose it was the original idea from the RepRap project. Such pure geometric compensation produces a very weak compensation. Andreas Bowyer mentions, that the molten plastic acts as a non-newtonian fluid and he applies a 8x multiplier to the geometric compensation. I suppose this heuristic is what has been implemented in slic3r and it did not quite work. So a better model is needed.

[bubnikv]

I think the first step to really solve the issue of hole shrinkage is to quantify the effect for various hole diameters, materials, layer and nozzle sizes etc. Then we may fit the data with some model and implement a reliable correction. Any volunteer to do the measurements?

[lordofhyphens]

@bubnikv I think that information would be more generally interesting (beyond us) and would be best kept on the reprap wiki.

I also don't think this is something Slic3r should try to account for automagically. Finding and classifying problem areas, yes, but not correcting them. If we can devise (or borrow from the literature) a method to find these holes on a layer-by-layer basis we can provide advanced tuning procedures similar to the current XY compensation but only affects interior holes. Users can then work out what is best for them.

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Wed, Jul 13, 2016 at 1:26 PM, bubnikv notifications@github.com wrote:

I think the first step to really solve the issue of hole shrinkage is to quantify the effect for various hole diameters, materials, layer and nozzle sizes etc. Then we may fit the data with some model and implement a reliable correction. Any volunteer to do the measurements?

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

[nophead]

The simple way to get round holes the right size is to use polyholes http://hydraraptor.blogspot.co.uk/2011/02/polyholes.html in the design so they don't shrink and so don't need material / layer height / speed / temperature dependent slicer correction.

On 13 July 2016 at 19:49, Joseph Lenox notifications@github.com wrote:

@bubnikv I think that information would be more generally interesting (beyond us) and would be best kept on the reprap wiki.

I also don't think this is something Slic3r should try to account for automagically. Finding and classifying problem areas, yes, but not correcting them. If we can devise (or borrow from the literature) a method to find these holes on a layer-by-layer basis we can provide advanced tuning procedures similar to the current XY compensation but only affects interior holes. Users can then work out what is best for them.

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Wed, Jul 13, 2016 at 1:26 PM, bubnikv notifications@github.com wrote:

I think the first step to really solve the issue of hole shrinkage is to quantify the effect for various hole diameters, materials, layer and nozzle sizes etc. Then we may fit the data with some model and implement a reliable correction. Any volunteer to do the measurements?

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

.

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

[mrvn]

@nophead No, it's not. We already mentioned correcting the triangulation in the CAD program. Please read the thread from the start carefully. Polyholes is doing exactly that correction by creating a polygon that lies outside the circle instead of the default of inside. It doesn't compensate for shrinkage of the filament we are discussing now.

[bubnikv]

Just fixing the xy compensation to influence holes only will not help much as the correction needed is not constant. I would myself rather continue to use the adjusted diameters in openscad. In my opinion the slicer really shall be aware of the material properties and compensate for them automatically. Otherwise the 3d printing will never become mainstream.

@nophead Your workaround is interesting, but in my opinion it will create gaps between the innermost perimeter and infill, where the stretched filament cuts the corners, and the holes will not be tight at the corners of the polygons. The polygonal holes may be convenient for metal screws though, as the corners may reserve space for the plastic cut away by the metal screw threads.

[nophead]

@mrvn, Yes it is. I have used it for 5 years with Skienforge and all my holes come out the right size. I compensate for plastic shrinkage due to thermal contraction with XY scaling, but that is only about 0.5%. The main problem with round holes is the plastic cutting corners. That is avoided with polyholes by reducing the number of sides. The flat sides of the polygon end up where they should be. The vertices get rounded off but they are outside the circle so can be rounded off without reducing it. The trick is to have just as many as are needed.

[7eggert]

• Adjusting each screw hole in each model for each print does not work. This does especially not work if the model is downloaded without the CAD files.

E.g. I downloaded LEGO gears, hole diameter 4.8 mm, printed hole diameter 4.5 mm. Size of counterpart 4.78 mm (i guess).

The interesting holes are "+"-shaped, and for the round holes, I'd need a 4.8 mm drill - not easily available.

• The problem is - at least in my case - not the polygons. I re-imported the model and verified it by designing the counterpart and zooming. The round part did fit into the polygonized part. (Also a slight amount of friction is desired.)

• Adjusting for overextrusion should be easy - just virtually print a half-sized (configurable) filament at the wall.

• I hope these drawings do help.

[7eggert]

Also the option is hidden under "print settings" -> "advanced" in the current version 1.2.9.

[nicksears]

This problem has plagued slicers for the longest time. @alexrj attributes it to mechanical issues rather than software (this is a grossly oversimplification on my part, and many of the issues are legitimate).

@nophead holds that polyholes is the solution, but I think it's the proof of the problem. If an algorithm can describe the geometry necessary to avoid hole shrinkage, then that's something that we should be able to compensate for in software (and evidence that it's not a mechanical issue).

Commercial systems (even the cheap mojo in our shop) can do +/-0.1 or better and I don't think it's unreasonable to expect this kind of resolution. Sure, I don't expect to fit a 3.0 mm rod in a 3.0mm (printed) hole, but a m3 bolt (~2.9mm) should work, even if I do have to change all of my previous models...

[yodor]

Having the same issues as all above, I was testing @supermerill patch for hole compensation the past few days. It works very nice for me. Patch is very small - and IMHO should be included by default in slic3r. https://github.com/supermerill/Slic3r/commit/dd20123d0f94e7dcd8eaa05527cbd3a682dc5f06

[KostinPavel]

Having the same issues as all above, I was testing @supermerill patch for hole compensation the past few days. It works very nice for me. Patch is very small - and IMHO should be included by default in slic3r. supermerill/Slic3r@dd20123

It should be included in the release so that the public can experience and test this in practice.

[OrangePartisan]

I had the luminous idea to use geometry data from a DXF file instead of an STL file, and then code my own slicer around it. DXF is a much more precise representation of the geometry of an object then the triangular shapes used by STL.

But, after burning the midnight oil once again, I have to conclude this is not an option when using Autodesk AutoCAD software. The latest release of DXF file formats that actually shows geometry data of an object is Release12 (kinda old) and there is little to no backwards compatability in writing an R12 DXF file with the latest release of AutoCAD.

I'll keep looking at other CAD software and report back once in a while, if only to contribute to where the origin of those faulty dimensions in printed objects ly. I think it's still a mayor issue going forward, and it's still an enormous peeve from an engineering standpoint.

[SphaeroX]

The topic is a bit older but I have the same problem.

When I work with the XY compensation, the holes get bigger but the polygons get too big, you should be able to set it up so that you only have the compensation on holes.

The problem is natural because holes are many small straight lines (linear movements), while polygons and the other geometries consist of large lines.

Here I have made a test file, and you will notice that you can never make the holes and polygons both measure at the same time.

https://www.thingiverse.com/thing:4841423

[lordofhyphens]

Something something philosophers stone.

On Tue, Apr 27, 2021, 7:36 AM SphaeroX @.***> wrote:

The topic is a bit older but I have the same problem.

When I work with the XY compensation, the holes get bigger but the polygons get too big, you should be able to set it up so that you only have the compensation on holes.

The problem is natural because holes are many small straight lines (linear movements), while polygons and the other geometries consist of large lines.

Here I have made a test file, and you will notice that you can never make the holes and polygons both measure at the same time.

https://www.thingiverse.com/thing:4841423

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/slic3r/Slic3r/issues/3323#issuecomment-827572700, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHYCXCFHSYFYVEOZMTI5DTK2VV7ANCNFSM4CDMXYEA .

[SphaeroX]

Something something philosophers stone.

Sorry didnt know what u mean, but i mean the hole compensation from SuperSlic3r should be a Part of Slic3r