Slic3r 0.8.2 inner holes much larger

Slice3r 0.8.2 appears to include changes in the algorithm to correct shrinkage of inner holes, but I am finding that this now means that previously perfectly calibrated parts aren't printing correct.

So the main question is this. Do I have to recalibrate my printer to match what Slic3r now does (if this is possible)? Or do I modify all the parts?

Outer dimensions seem to be unaffected so I can't see how I can change my printer calibration to suit.

Also, we shouldn't be modifying parts to suit the slicing tools.

I have been looking for documentation which explains the changes, but don't seem to be able to find any. I'm probably not looking in the right place, so more than happy if someone points it out to me, but if pointed at the source code I will quite disappointed. As one of my previous managers said "Source code is not documentation". (I'm a software developer myself).

I have attached two screen shots of the GCode paths of the same object sliced with 0.8.2 and 0.7.2 this morning, it can be readily seen that there is quite a difference in the inner dimensions that are created.

0.7.2:
0.8.2:
STL: CKSpool_v1_Hub.stl (In case it will help). This is for a new printable spool I am making. Not loaded to Thingiverse yet as I wanted to get it right first.


There might be hidden advanced options that I can tweak, if there are, I'd love to know about them.

Thanks,
Craig

A lot of people are having issues with this and there is a bug report filed on Github to have an option to disable it.

For most people the problems are when slicing stuff people have modelled with shrinkage in mind when designing and Slic3r is now compensating again. Are your holes being modelled exactly the size you want them or larger like has been the norm until now?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

How big is this? Surely at the scale of a spool any hole shrinkage would not be visible. Also the rectangular slots look bigger and they should not need any correction.

---

[www.hydraraptor.blogspot.com]

Sublime Wrote:
-------------------------------------------------------
> A lot of people are having issues with this and
> there is a bug report filed on Github to have an
> option to disable it.
>
> For most people the problems are when slicing
> stuff people have modelled with shrinkage in mind
> when designing and Slic3r is now compensating
> again. Are your holes being modelled exactly the
> size you want them or larger like has been the
> norm until now?

It's a bt of catch 22. They are modelled with the the shrinkage I was having in mind, however the are coming out larger than actually specified. i.e. overcompensated. The rectangular slots are defined as 8.2 x 3.2 and are printing out at about 8.8 x 3.8 That's quite a bit larger than specified.

I'll admit that there could be printer calibration issues, etc, but with Slic3r 0.7.2 they were coming out around 7.9 x 2.9 with no other changes and the same filament. So that is quite a large shrinkage compensation change.

I know I can fix my source files, my comment is more about the fact that the compensation (which I think is an excellent idea) seems to overcompensate with this particular model.

nophead Wrote:
-------------------------------------------------------
> How big is this? Surely at the scale of a spool
> any hole shrinkage would not be visible. Also the
> rectangular slots look bigger and they should not
> need any correction.


Nophead,

Thanks for replying. These changes don't really affect the object I am making, but as I mentioned when replying to Sublime, they just threw up the realisation that the compensation appears to be incorrect.

The object I have uploaded is around 80mm outer diameter. The inner hole is for an 8mm axle (I have some old threaded bar that I am using to hang my spools off.).

This item is the hub section of a modular spool which you assemble completely out of printed parts (no vitamins - well some little bits of plastic offcuts from cable ties, but even these could be printed), with the aim to minimise printing time and plastic compared to the others that are on Thingiverse. with the rectangualr sections having come out larger it means I don't have as much positive location of the locking tabs, but that is easily solved by making larger tabs, so not the end of the world.

As said before to Sublime, the issue isn't so much a problem with my object which I can easily correct as I have a fully parametric (I think) Openscad file, but rather that the compensation factors appear to need to be able to be tweaked.

I've been having M3 nut traps (5.5mm wall to wall) coming out at over 6mm even when sized exactly in the model - big enough for the nuts to easily spin in the traps. I've had to drop them to just 5mm in the model to get them the right size, however then vertical traps (where the bolt goes through horizontally) are far too small so I have to use different nut trap sizes in my model depending on orientation!

when this is fixed, I can have exactly the same size in my model in any orientation and they'll come out as the same size.

tl;dr: definitely massively overcompensated by at least an order of magnitude!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I have exactly the opposite problem, inner holes come out smaller than modeled, as explained in this thread.

It looks like some means of user control over shrinkage compensation could make things easier.