After my discussion with Nophead in my previous post I realised that my attempt to compensate for hole shrinking was flawed. It seems that the dominant effect wasn’t what I thought but turned out instead to be the number and order of perimeters I was using in my Slic3r settings.
This has already been researched before, but I decided to investigate it further. This time I used RapCAD to generate the test pieces since its multi-material support made creating the Slic3r print modifiers a doddle.
I decided to use square holes since I can then measure them accurately with a digital vernier calliper.
Because of the way Slic3r handles multi materials, and modifiers I had to export the main() part first, then comment it out and export the mods() as a separate multi material part.
I applied the mods such that the first hole had 1 perimeter, the second 2 perimeters, etc. up to 5 perimeters. Unfortunately Slic3r decided to add extra perimeters internally to the part. This is probably a Slic3r bug but not a problem for this test piece.
I printed the parts out and took 4 measurements of each hole, 2 widthways and 2 lengthways. I then took the average of these four measurements and subtracted them from the specified width of 6mm to get the error. I divided this value by two since this error is doubled up, (there are two sides to the hole).
The red line shows the results from a second test piece in which the “Print outer perimeters first” setting was used.
So in summary I don’t think I’ve learned anything new here. Outer perimeters first seems to be the solution as has been suggested before. I was quite surprised to find that the error to perimeters relationship is not linear, but this might be due to errors in measurement, since there is a straight line that goes between all the error bars.