User avatar
dkightley
Posts: 2405
Joined: Tue Mar 10, 2015 4:09 pm

Re: Incorrect hole sizes

Again...as I've said before on this thread, I totally concur with everything Carl has said. Holes are generated by the slicer correctly, and designers need to ensure they compensate for any "undersize" the .stl resolution causes, and for any "undersize" caused by over-extrusion.

I have conducted a test print to see how holes print on my printer.....and a 1.5mm drill fits comfortable in a hole designed to be 1.8mm diameter and a little less comfortably in a hole 1.7mm. So, I have to compensate by 0.3mm caused by over-extrusion. Not too much of an issue at all! And for info, the horizontal compensation would do this. And where I have horizontal holes, I always oval out the top half of the hole to compensate for any un-supported droop.


corry wrote:Your "test" is a graphical depiction?! That's not a test. Are you an engineer? Wow.
I could respond negatively to this comment....but throwing insults is not a grown-up way of holding a discussion.
Doug Kightley
Volunteer at the National Tramway Museum http://www.tramway.co.uk
Railway modeller and webmaster at http://www.talkingtgauge.net
Cameron
Posts: 3
Joined: Wed Mar 04, 2015 9:55 pm

Re: Incorrect hole sizes

OK so if I use the Horizontal size compensation, that will adjust the inner diameter a bit, what else will it do to the rest of the model?
That might be my solution?
corry
Posts: 15
Joined: Sun Sep 13, 2015 3:40 pm

Re: Incorrect hole sizes

I see myself and one other with g code priovong the model *ISNT* being sliced correctly. That's why I asked why your verification was *GRAPHICAL* and not *MATHEMATICAL*. It's a matter of precise definition. Not insult. Yes, now there's frustration in my tone. The g code is flat wrong. The the slicing behavior is wrong. I can verify it 1000x over on any model I wish to as long as I use basic arithmetic and geometry.

I'm not sure what emotional hold you have on there not being a bug, is it because you think money manors bug free software? I wish! I'm paid to write code and I still write bugs. So why not break out the g code, and a calculator, and verify. My 3 mm hole was set to print from the center at 2.5mm. The stl said 3. The GCode said 2.5. Reality would have been about 2.1-2.2. It'll take you 5 minutes to verify.
corry
Posts: 15
Joined: Sun Sep 13, 2015 3:40 pm

Re: Incorrect hole sizes

And one other thing, if we're going to tak about the adult things to do, we should mention normally abandoning cognitive dissonance, assuming the other person isn't just telling lies because he's "out to get us" or "seeking a higher status than us" or more nobly, but equally flawed, "trying to tarnish the reputation of the product". The adult thing to do is to assume he wants the product he paid for to work correctly. He gave specific, precise examples, none of which have been countered, one of which confirmed by someone else, so either something is corrupt in their installs, some setting can create this bad behavior, or there is a bug. The adult conversation would be to figure out why the GCode is being generated incorrectly, not apply cognitive dissonance. So, now if you'd like to try again, I'm willing, but don't break out the adult thing to do when you yourself deviated from that path.

That said, just to prove beyond a shadow of a doubt I'm not making this up, I'll download microsofts screen record utility. Maybe then we can move from the "that can't happen" phase...
CompoundCarl
Posts: 2005
Joined: Wed Aug 05, 2015 7:23 am

Re: Incorrect hole sizes

I've checked the gcode as well. It is correct. I have yet to find any situation where the slicer is behaving incorrectly. There's several people who have posted their evidence in this thread proving it is working correctly. So if you feel differently, post your files instead of just "claiming" it's wrong. That doesn't help anyone.
Vertex
Posts: 2
Joined: Mon May 09, 2016 1:55 pm

Re: Incorrect hole sizes

Alright, i'm experiencing the same issue.

For simplicity, i use a square hole instead of a round one. printed in PLA.

I've made a square 20x20x10 (X Y Z) it contains a square hole/pocket in the middle, and the walls is designed to be 5mm thick.
Untitled.jpg
Here is my problem:
The outer wall is measure to be 19,75mm (supposed to be 20mm)
The inner wall is measured to be 9,75mm (supposed to be 10mm)
and the walls between is exactly 5.00mm, as it should be.
the height is also precisely 10.00mm high.

I even tried a bigger model which was 60x60x20 in size, and the problem persists
the difference is that this model got 10mm thick walls,

The outer wall is measure to be 59,75mm (supposed to be 60mm)
The inner wall is measured to be 39,75mm (supposed to be 40mm)
and the walls between is exactly 10.00mm, as it should be.
the height is also precisely 20.00mm high.

I seriously don' get why?
I have calibrated my nozzle, the extruded width is set to 0,42 and is calibrated and measured to be 0,42 so this is all fine.
and it cant be the steppers that is calculated wrong, as i've tried with different sizes, and its not by a percentage, but a constant value.

But how on earth is the walls between the inner and outer wall always perfect, but in dimensions inside and outside keeps being 0,25 undersized?
I've tried printing with many different temperatures to see if that makes a difference, but no luck, and i'm currently printing at 168c

And no, i cant use use horizontal compensation as it would make the walls in the middle thicker, and they are currently perfect.

Anyone got any clue how to fix this, without making the CAD model bigger, as this is only some places it does this?
CompoundCarl
Posts: 2005
Joined: Wed Aug 05, 2015 7:23 am

Re: Incorrect hole sizes

You should really start a new thread to discuss your issue. Include your gcode file and mention the exact lines in the file where you think the software is moving to the wrong position. As has been stated in this thread, the software was always moving to the correct position, so any issues where likely just due to plastic shrinkage or under/over-extrusion.

Start a new thread if you want help on your specific print
citrik
Posts: 6
Joined: Sun Jul 19, 2015 2:14 am

Re: Incorrect hole sizes

I'm also hitting this issue, Kind of frustrating to get all the basic tuning done then hit this. So I'm printing on an i-Delta (Kossel Style on Repetier/RAMPS). I've tried running Simplify3d from both my Mac and PC and get the same result. I've posted a simple, low plastic test print on thingiverse, link below. With the TestRing1520 file, It's supposed to be 20mm on the outside, 15mm on the inside, 5mm tall. When I slice with Simplify3d and then print I'm getting 20 on the outside and 13.7 on the inside, 5mm High +/- 0.1mm on the two diameters. Any other slicer is spot on for the dimensions. Also included the factory file, if it shows I have something wrong with my settings.

Sent a request to support but never heard back. Do you guys usually get an autoreply? Wondering if my form submission failed.

If you do or don't have this issue, what type of printer do you have? I'm wondering if it is limited to Deltas or something, since not everyone is encountering the issue.

Thanks!

http://www.thingiverse.com/thing:1668381
lasersharkdesign
Posts: 8
Joined: Sat Apr 30, 2016 9:54 am

Re: Incorrect hole sizes

Just adding to this issue. Been doing some tests with my TAZ5 using a .6mm Volcano Nozzle, ABS.

I made a test cube, 20mm x 20mm x 5mm high.

Inside this cube I made a 5mm square hole, and next to it a 5mm diameter hole.

I purposely set the extruder to over-extrude a bit, and also started a print a little too high off the bed. Why? So that the holes would be cone shaped - not in G code, but because of the nozzle. A slight over extrude, and a starting the print a hair too high off the bed would make the holes wider at the bottom (not flattening out against the bed as much) and narrower at the top (over extruding on the top few layers will cause some "smushing")

Printed, the 20mm x 20mm square, external dimensions:
Very bottom layer: 19.84mm
Top layer: 20.6mm

The over extrusion caused the outside to be .76mm wider at the top than at the bottom.

Square hole, bottom: 4.88mm
Square hole, top: 4.2mm

A difference of .67mm, same as the outer edge (. That looks perfectly correct.

Now, the circle:

Circle, bottom: 4.65mm
Circle, top: 3.8mm

A difference of .85mm between the top and bottom.

What does this show? Two things:

First, I believe if you are having a hole size issue with squares, you're over extruding. My outer size was .16mm smaller than it should have been at the bottom, and .6mm larger at the top. My inner square was .12mm smaller at the bottom, and .8mm smaller at the top. Which is almost exactly the same dimensions off as the outside measurements. Getting starting height and extrusion correct should fix that.

Now the circle on the other hand - the circle suffers from the fact that when going in an arc, more filament is extruded on the inside half of the circle than the outside half. It's explained here: http://reprap.org/wiki/ArcCompensation

At the bottom of the square the circle is 4.65mm wide, off by .35mm. The outside of the square was slightly undersized (.08%). The inner square hole was nearly perfectly sized, and offset by almost the same exact size as the outside of the square. But the circle is off by about 3x the undersize of the entire thing (.12 x 3 = .36). This is due to more material 'bunching up' on the inside of the arc.

Imagine your filament is like a balloon used for balloon animals. On a straight line it looks like this:
Image

The balloon is evenly colored/stretched out across it's length.

But when you bend it in an arc, it looks like this (it's not the best example but the best I could find on a quick google search):
Image

Look at the blue side loops. The inside of the loop is darker, and it even buckles in one spot because it's 'bunched up'. Since it's rubber it just bends, and the outer edge stretches. With extruded filament, all that 'extra' on the inside just piles up on itself, and spreads out. Causing the hole to be smaller.

It's even worse at the top of the hole where we're really over extruding. The inner diameter is 3.8mm, an entire 1.2mm too small, and no surprise, it's about 3.5x the undersize of the bottom diameter. The problem is clearly visible when not over extruding too much (bottom later starting high, not 'smushed' against the bed), but when really over extruding the problem is massive.

So yes, over extrusion is an issue. But an even bigger issue is any inner arc, be it a circle, the corners of a triangle, etc. The extra plastic piles up and spreads out where there is the least amount of resistance: The inside of the hole.

There is math out there that helps with the arc compensation. Would be awesome if simplify3d could make use of it. I REALLY don't want to try and program that in the firmware :)
lasersharkdesign
Posts: 8
Joined: Sat Apr 30, 2016 9:54 am

Re: Incorrect hole sizes

Realizing it's impossible to do in the firmware (you need to be able to read ahead and see if arcs are hollow or not), I gave up and wrote an external script to do arc compensation that will modify the size of inner holes to compensate for extra material on the inside of an arc. So far it's working well, but I'm still debugging it (making sure it correctly identifies inner holes).

There are other issues I'm working out at the moment, such as when using dual walls - if you only increase the arc on the inner wall, it will still get pushed some as it overlaps the outer wall. Need to make some options on the script attempting to identify those walls and either compensate them accordingly, or remove them if necessary. If the outer wall is compensated as well, then the outer wall overlaps either infill or solid layers.

But as it stands, it works. I made a box with a 2mm hole in it, and the hole printed at 1.96mm. I made another with a 9.8mm hole, and the hole printed at 9.92mm. Obviously needs a little tweaking, but it's also dependent on your over/under extrusion. Over-extruding will amplify the problem.

As it stands now, the script runs on a web server. Using the 'Additional post-processing commands' feature, Simplify3D uploads the gcode to the script, which modifies it, then sends it back. I wrote it in PHP as thats the language I'm most familiar with. Ideally, I can make the script local and written in Python, both so I'm not slamming my webserver with requests, and so that people can modify it as they like locally (and not have to install curl to send the file to the server).

Once I get it debugged properly, and then harden it against idiots trying to break it, I'll post a link and instructions on how to use it. Except for a few minor issues I'm working on now (just fixed a major one - the script compensating for a thin walled section where the wall is the outer wall, thus making bulges in the object) it's pretty good and almost ready to go.

A few other features I'm adding:
* Compensating for arcs on the outer walls if the arc is not a hole. For example, a filament clip where the "C" clips onto the filament. That is not a 'hole' and is made up of the outer wall. But the radius will still be too small. Right now the script only checks closed loops, and looks to see if they are hollow.
* A more accurate build time calculator. Taking more factors into account like the delay-per-gcode-command. I believe I read each gcode command takes about 10ms (.001 seconds) to process. In a file with 70,000 gcode commands, thats an extra 70 seconds. I read somewhere about someone who made a script that more accurately calculates print time and that was a method they used.
* Might create a different script for this, since it's unrelated to hole size, but something that drives me nuts about S3D is the skirts. The skirt is only made around the bottommost layer. If there is an overhang, S3D will actually do a skirt, and then print supports for the overhang on top of the skirt. Plus, Cura has a great option where you can set the minimum distance for the skirt, so if you're printing a small part you can ensure the nozzle is primed. So I may add that, or make it a separate script.

Anything else I should consider adding?

Return to “Troubleshooting and Bug Reports”