Actually, while trying to write the blog post, I realised I was taking rubbish in my last two post. The error between intended width and actual width is only the layer height times (1-pi/4) which is 0.043mm for 0.2mm layers. With multiple outlines the error is not cumulative, they just add the intended width and so preserve the original error.

It doesn't explain the big errors tmorris9 has seen, or the ones I have experienced when using anything other than Skeinforge, so it is still a mystery to me. I need to do some experiments I think.

---

[www.hydraraptor.blogspot.com]

Ok, Since I started this thread, I have not gotten any answers..
More questions yes, but answer no...

I have created a couple more files for testing.
I am on my way to warm up printer and try soon.

The files and drawings are created with SolidWorks.

I will take a look at the G-Code that is output and see if I can make heads or tails....

Richard

I was looking at the physical sizes of things and created this image of a 3mm extruding 0.4mm at .5mm wide.
Thought it was interesting....

Quote
Qsilver
Ok, Since I started this thread, I have not gotten any answers..
More questions yes, but answer no...

I think we have some answers.

Q) Does Slic3r place the path in the correct place?
A) Yes for a square extrusion profile the width specified by Slic3r.

Q) Does Slic3r produce the correct E value to produce the extrusion width by height by length required for each path?
A) Yes but for a square extrusion.

Q) Why do holes produced by slic3r turn out too small?
A) It expects a square extrusion but physics dictates the unconstrained path will have a rounded edge which causes an error that they expect you to overcome by reducing the flow rate as per [github.com] but unfortunately that may cause all the paths inside to not be well bonded to each other.

Q) How can we make Slic3r produce parts with correct inner hole dimensions without weakening the part?
A) We can try a few things.

1) Print the outer perimeter first. Kisslicer uses the same method of assuming a square profile but prints from the outer perimeter inwards and people report better accuracy with it.

2) Print lower layers. I said below 0.2mm before but even lower will produce less of an error.

3) Reduce the flow rate of the perimeter only so it makes a path the width requested but with a rounded edge using the formula by Nophead (1 + (3.14159/4 -1) / (width/height)) ...... ( this is currently not possible but should be relatively easy via post processing or changing Slic3r's internal code.)

---

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

Here is some G-Code...
As I understand the second line makes a move X from 100.404 to 101.047 and Y from 93.733 to 93.800.
Also matching linear the extruder from 1.03202 to 1.04310..
G1 X100.404 Y93.733 E1.03202
G1 X101.047 Y93.800 E1.04310
Accordingly this table suggests 0.1295 sq mm in the extrusion...............................................
3.100 mm^3/mm 7.54767635
Delta X Delta Y Length Delta Ext Volume A Extrude
G1 X 100.404 Y 93.733 E 1.03202
G1 X 101.047 Y 93.8 E 1.0431 0.643 0.067 0.646 0.011 0.084 0.12936
G1 X 101.625 Y 93.895 E 1.05316 0.578 0.095 0.586 0.010 0.076 0.12963
G1 X 102.295 Y 94.128 E 1.06531 0.670 0.233 0.709 0.012 0.092 0.12928
G1 X 102.887 Y 94.387 E 1.07639 0.592 0.259 0.646 0.011 0.084 0.12942
G1 X 103.449 Y 94.705 E 1.08747 0.562 0.318 0.646 0.011 0.084 0.12951
G1 X 103.976 Y 95.08 E 1.09855 0.527 0.375 0.647 0.011 0.084 0.12929
G1 X 104.461 Y 95.506 E 1.10963 0.485 0.426 0.646 0.011 0.084 0.12955
G1 X 104.9 Y 95.98 E 1.12072 0.439 0.474 0.646 0.011 0.084 0.12956
G1 X 105.288 Y 96.497 E 1.1318 0.388 0.517 0.646 0.011 0.084 0.12938
G1 X 105.62 Y 97.051 E 1.14288 0.332 0.554 0.646 0.011 0.084 0.12948
G1 X 105.894 Y 97.636 E 1.15396 0.274 0.585 0.646 0.011 0.084 0.12946
G1 X 106.008 Y 97.938 E 1.1595 0.114 0.302 0.323 0.006 0.042 0.12954
G1 X 106.189 Y 98.559 E 1.17058 0.181 0.621 0.647 0.011 0.084 0.12929
G1 X 106.304 Y 99.194 E 1.18166 0.115 0.635 0.645 0.011 0.084 0.12959
G1 X 106.354 Y 99.838 E 1.19274 0.050 0.644 0.646 0.011 0.084 0.12947
=========================
The Layer Height is .25 mm so.. to match this section area you get...
The rectangular width is .518mm (100% fill)


More to come.....

Ok so I wrote an SolidWorks Macro to read so I could overlay the G-Code points.
Here is the result... This is the first layer.
The blue lines represent a .518 wide nominal rectangular extrusion.. See above.
The center opening is 12mm The inner G-Code circle is 12.550 dia...


Edited 4 time(s). Last edit at 12/22/2013 06:00PM by Qsilver.

So I made a thicker part 3mm of the same so I could look at each layer...
STL is attached...

I then went into G code and split layer by layer...
Overall I am impressed with the nice job that the software is doing. Lot's and lot's of math...
Here is layer 3: Plot of print head to actual designed borders of part.. ( I tried to remove most of the rapids..)


Here is the slic3r comments section...
; generated by Slic3r 1.0.0RC1 on 2013-12-22 at 18:13:48

; layer_height = .25
; perimeters = 3
; top_solid_layers = 3
; bottom_solid_layers = 3
; fill_density = 0.3
; perimeter_speed = 30
; infill_speed = 30
; travel_speed = 130
; nozzle_diameter = 0.40
; filament_diameter = 3.10
; extrusion_multiplier = 1
; perimeters extrusion width = 0.40mm
; infill extrusion width = 0.53mm
; solid infill extrusion width = 0.53mm
; top infill extrusion width = 0.53mm
; first layer extrusion width = 0.55mm

Edited 1 time(s). Last edit at 12/23/2013 11:13PM by Qsilver.

Moving on a bit...
I must conclude that Slic3r is placing the print head in the correct location if the first layer is printed with .550mm
And borders with .400 mm... Now my question is why are things not in the right place?


I guess I will have to look at the E parameter on this data set.....

More to come...
Richard

Edited 1 time(s). Last edit at 12/23/2013 11:10PM by Qsilver.

Hello again..
I'm sure you are getting tired of these ramblings...
I used the e values to calculate extrusion area and plotted the 2 layers in this sketch...


Then I used sample values and calculated (spread sheet) the extrusion area for layer 1 and layer 2.


Look at that exactly the correct volume for layer 2..

WTF? The software looks like it should be making a part perfectly.....
For now my answer is .... Happy Holidays...

Edited 1 time(s). Last edit at 12/23/2013 11:24PM by Qsilver.

Not sure why you think it should be making correct parts when you have shown the volume dispensed makes a track 0.4537 wide but only offsets by 0.4/2.

---

[www.hydraraptor.blogspot.com]

Quote
nophead
Not sure why you think it should be making correct parts when you have shown the volume dispensed makes a track 0.4537 wide but only offsets by 0.4/2.

I guess I'm not saying that Slic3r is correct in it's assumptions, just that is not a software logic error.
Slic3r clearly sets the perimeters as .4 wide and extrudes the correct amount of plastic for the .4 x .25 ideal area.
The .4 x .25 area is equal to round edge area at width of .4537.

I know that the rounded profile is likely for at least one side of the unconstrained internal path.
For that I can attribute .02685 (1/2) the difference. So for a hole .053 mm smaller then design.
I believe that you did the calculation for .20mm layer height.

Quote
nophead
Actually... (snip) ..The error between intended width and actual width is only the layer height times (1-pi/4) which is 0.043mm for 0.2mm layers. .....

The errors I'm seeing are much larger then this. On average 0.25 mm.

I have to conclude that:
1. I need to re-verify that my material flow is correctly calibrated.
I will look for a very precise way to do this.
2. Check software settings that may be able to minimize the effects.
3. Beg the developers for separate internal and external perimeter offsets...
( I don't know how they do the math, but they seem to get the print head center on the correct side!)

I will continue to test....

Thanks all.
Happy Holidays...

It would be really nice if the developer would read and respond to this thread but I doubt that will happen.

Merry Christmas to all.

I am wondering if multiple outlines actually gives a bigger error because the plastic doesn't want to flow right into the sharp corner under the rounded edge of the previous line. If it leaves an air gap there then each subsequent outline will give an bigger error, which seems to be what I observe.

---

[www.hydraraptor.blogspot.com]

Quote
nophead
I am wondering if multiple outlines actually gives a bigger error because the plastic doesn't want to flow right into the sharp corner under the rounded edge of the previous line. If it leaves an air gap there then each subsequent outline will give an bigger error, which seems to be what I observe.

I agree with you.. If the order of perimeters is middle outer inner (3 perimeters) then the inner will be .457 wide (maybe wider)
The next volume can't fill the corners + there is already material in the way.
I did this and calculated the areas to be .100 as Slic3r used.

You can see the edge error could be .046 so .092 on a hole...
This is closer to the numbers I record, but it's still not the error I get.
I have to assume I am over-extruding. I'll do another drawing like this one with some over extrude.

Here is the error with a 5% area increase... a miss calibrated extruder length of 10.5mm calibrated as 10mm.
Not out of the realm of possibility.
This would get to .146mm on a hole.....

So here is the error with 5% over extrude, inner to outer perimeter order.
Here is a whopping error of .106 per side .212mm on a hole ID...
I think that this covers most of the possibilities..
I'm sure there could be contributing material issues also.
Mean time I will be re-checking my extruder calibration....

This is also why you get a ridge when the infill is done from two directions and meets in the middle.

---

[www.hydraraptor.blogspot.com]

I have been 3d printing for many years now and have been patiently waiting for a slicing solution that handles the implications of rounded extrusion profiles properly but nothing has ever appeared. Skeinforge seems to be the only slicer with enough settings flexability to make it work (by fudging perimeter widths and flow rates) but it is a pain to work out since the fudge factors needed are different for different layer heights. Because of the way skeinforge treats extrusion width as a ratio of the layer height, changing heights means changing many settings. There is also the fact that skeinforge is horrifyingly slow. Also, development seems to have been abandoned back in early 2012.

I thought CuraEngine looked promising because it is very fast and written in C++, but it is also missing some important features like slic3r's infill every n layers or skieinforge's skin. That makes printing very thin layers difficult (because the infill becomes crumbly and bridges snap). It does have a nice feature of filling small gaps between perimeters on thinnparts that skeinforge doesnt have.

Some people also like Kisslicer, but it isnt open source and it also has dimensional issues.

Is this assessment accurate? Do we really have no slicers that have all of the desirable features for making dimensionally accurate prints?

I see when the new curaengine was released, nophead had a few comments on the release blog:
[blog.reprap.org]

Nophead: did you ever get around to looking at the code changes? Or were you put off by other missing features?

Edited 2 time(s). Last edit at 12/25/2013 04:33PM by Greg Frost.

I think your assessment is fair. Neither Sound or Daid recognize the problem, so I doubt they would even accept patches to fix it. I intend to fork Cura and fix it because I like its simplicity and it is written in C++, albeit with a bizarre form where everything is in .h files. Cura is primarily written for Bowden machines, so some things are not right for non Bowden. For example it likes to miss out retractions whereas I like to always have them as they work properly on non-Bowden machines and are no detriment apart from time but any missed ones produce print defects.

First I need to do some more experiments because the sort of errors I get with all other slicers seem far bigger than I have calculated. For example I printed an M8 nut trap in ABS with 2mm walls in Cura and it was more than 1mm too small! There is also the mystery that Sublime claims to get perfect sizes from Kisslicer but I don't. Not only are holes too small. They don't even come out round with Kisslicer on the few test I have done. It seems to do some crazy things and the gcode is difficult to make sense of. As it is closed source I haven't spend much time playing with it.

In the long term, when I retire from making Mendel90 kits, or people stop buying them, I intend to write my own slicer from the ground up. I don't like having to accept other people's choices of how my machines should build an object.

---

[www.hydraraptor.blogspot.com]

Quote
nophead
There is also the mystery that Sublime claims to get perfect sizes from Kisslicer but I don't.

I have never found any slicer that results in the holes being too small as so many of you find. I have always gotten correct dimensions regardless of the slicing software. It has always been dependent on the settings used. I never print with layers over 0.2 and if I want precise parts I print even lower. The part I printed in this discussion I printed at 0.139mm layers and as the pictures show it is dimensionally accurate. That is why I always claim it is a printing style issue not a slicer issue. Also I truly believe the hysteresis in a Bowden cable is a good thing since it evens out the flow rate to a constant.

Quote
nophead
Cura is primarily written for Bowden machines, so some things are not right for non Bowden. For example it likes to miss out retractions whereas I like to always have them as they work properly on non-Bowden.

This is an interesting comment and I do believe it is why Cura does it. But in my findings it is far more important with a Bowden to retract every single time since the hysterisis will cause extrusion while travelling. What is actually important is to avoid needing to retract and is why Kisslicer is so good, its path planning is such that it travels less often.

@ Greg Frost
I wrote a quick script that lets you reduce the flow rate of the perimeters like you would with skeinforge but works with Cura and Kisslicer if you would like to try it out. [github.com] . It allows you to adjust any extrusion types flow rate using Marlins M221 flow rate modifier and has Nopheads flow rate equation in it for the perimeters so all you have to do is enter the layer height and extrusion width in it before processing the gcode file.

---

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

Quote
nophead
I intend to fork Cura and fix it because I like its simplicity and it is written in C++, albeit with a bizarre form where everything is in .h files.

I believe that CuraEngine has recently been refactored now so that the code is more conventional (only declarations in the header files).

What would be the principal difference in the ground up slicer you would write. What language would you use?

The key things I would like in a slicer:
Infill every n layers/skin.
Control over perimeter inset (with a sensible default based on the rounded extrudate maths)
Independent flow rate/speed settings for bridges (including dealing with the bridge being a different thickness to the rest of the model's layers).
Speed setting for top layers
Filling small gaps.

Some advanced things I think would be good:
Dealing with the fill from different directions to avoid the ridge (reduced volume runs)
Some canonical tuning models built in (e.g. Slice a bridge test model so that it uses a progressive range of speeds or flows so that the optimum settings can be determined relatively easily, another eg: a model that tests dimensional accuracy by printing a press fit joint. Another eg. A model that tests for backlash).

Quote
Sublime
@ Greg Frost
I wrote a quick script that lets you reduce the flow rate of the perimeters like you would with skeinforge but works with Cura and Kisslicer if you would like to try it out. [github.com] . It allows you to adjust any extrusion types flow rate using Marlins M221 flow rate modifier and has Nopheads flow rate equation in it for the perimeters so all you have to do is enter the layer height and extrusion width in it before processing the gcode file.

Reducing the flow is not always what you want. Look at the following two pictures. One was done using a reduced flow such that the part came out "right-sized" and the other was done using an increased inset so that the part was "right-sized".
You can see that the outer perimeter on one of them hasnt always bonded well with the layer below. The one with consistent flow but increased inset has bonded well.

Quote
Greg Frost

Quote
Sublime
@ Greg Frost
I wrote a quick script that lets you reduce the flow rate of the perimeters like you would with skeinforge but works with Cura and Kisslicer if you would like to try it out. [github.com] . It allows you to adjust any extrusion types flow rate using Marlins M221 flow rate modifier and has Nopheads flow rate equation in it for the perimeters so all you have to do is enter the layer height and extrusion width in it before processing the gcode file.

Reducing the flow is not always what you want. Look at the following two pictures. One was done using a reduced flow such that the part came out "right-sized" and the other was done using an increased inset so that the part was "right-sized".
You can see that the outer perimeter on one of them hasnt always bonded well with the layer below. The one with consistent flow but increased inset has bonded well.

Kisslicer already has a built in inset feature that does exactly what you are looking for. The script was to allow for the "fudging" of things like in Skeinforge where you reduce just the perimeter flow and increase the perimeter/infill overlap. I agree that simply reducing the flow rate is a bad idea and is one of the things this thread is trying to avoid. But again if you print with a high w/h ratio like 0.15 layers and 0.52mm extrusion width you could reduce the flow on the perimeter a fair bit without de-lamination becoming an issue. Where as printing with large layers and being just at the 1.5/1 w/h ratio you will easily go below that when reducing the flow.

---

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

So I did some checking on my printer.
My extrusion parameter was off, and I was over extruding about 7%
I have since re-calibrated and now the extrude length is acurate to .05mm per 10mm or 0.5%.

I will be re-printing many tests.
I will let you know where this gets..

Rich

Quote
Greg Frost

Quote
nophead
I intend to fork Cura and fix it because I like its simplicity and it is written in C++, albeit with a bizarre form where everything is in .h files.

I believe that CuraEngine has recently been refactored now so that the code is more conventional (only declarations in the header files).

What would be the principal difference in the ground up slicer you would write. What language would you use?

It would be like a cut down version of Skeinforge but without the horrible GUI and slowness. I intend it to be my first program in D as an exercise to learn the language.

Quote

The key things I would like in a slicer:

The whole point of writing my own is that it does the things I like and isn't complicated by features I don't use.

Quote

Infill every n layers/skin.

I have never understood how that can work properly when the walls are not vertical.

Quote

Control over perimeter inset (with a sensible default based on the rounded extrudate maths)

Yes but you already have that with skienforge if you do the maths yourself. You can set the outline W/T higher than the infill, so that when it is flow rate corrected for the change in width the end result is exactly the same shape extrusion but offset more.

Quote

Independent flow rate/speed settings for bridges (including dealing with the bridge being a different thickness to the rest of the model's layers).

Bridges work well when the area of the extrudate is just a little less than the die swell value and W/T is 1.5. I don't do anything special for them with skeinforge.

Quote

Speed setting for top layers

Perhaps, but I currently do everything at the same speed for best quality. I am not in a hurry.

Quote

Filling small gaps.

I think there is a limit to how small a tench you can fill. I just design my objects bearing in mind the filament width so I don't get any features between 2 and 3 times it.

Quote

Some advanced things I think would be good:
Dealing with the fill from different directions to avoid the ridge (reduced volume runs)

Yes that would be good but I think it gets complicated for irregular shapes where a single run of infill can be both enclosed on one side and on both sides.

Quote

Some canonical tuning models built in (e.g. Slice a bridge test model so that it uses a progressive range of speeds or flows so that the optimum settings can be determined relatively easily, another eg: a model that tests dimensional accuracy by printing a press fit joint. Another eg. A model that tests for backlash).

Not sure that a slicer should contain its own models.

Edited 2 time(s). Last edit at 12/27/2013 09:45AM by nophead.

---

[www.hydraraptor.blogspot.com]

Update on my 10mm hole object

Today a new Slic3r was released 1.0.0 RC2 (from RC1)

I noticed in the release notes this "a regression caused all perimeter holes to be completed doing contours instead of finishing one island at time"

I am not sure what this means but I thought I would try it. My hole got closer to the intended size. Using my standard settings (as mentioned earlier) the hole is now 9.65mm before it was always in the 9.4?? range so something changed for the better.

Just a quick update...
I have been re-checking many things.
Found another interesting calibration error.
My Y axis belt was slightly uphill to the print bed from the end pullys. 5mm or so
Prusa v2... Never thought that having the belt just slightly out of line would cause a measurable error.
It does... .25mm per 100mm travel. Not huge but another source of error.

Hello!
I have been reading this thread and first off I'd like to thank you for this research work. Your comments, diagrams and thoughts are much more valuable than any code patch. I really hope we can all together come to a solution in terms of algorithms, needed config options, calibration procedures. Making everything configurable by adding tons of options is not the ideal solution, unless we provide an easy way for the average user to configure them correctly. Still, I'm open to making things extremely configurable to power users if this would open up more research.

I *do* confirm dimensions are often wrong. I drill holes myself too. Luckily, the error is on the side of smaller holes which easier to fix than larger.
Before talking about math, I need to point out that other factors usually affect dimensional errors so it's not entirely a matter of G-code generation. Here's a recap of the most common issues: [dl.dropboxusercontent.com] Not to mention loose belts and such. While I'm sure experienced users' printers (like nophead's and Sublime's ) are built perfectly, I'm afraid such problems do affect the average user.
Anyway, let's make the hypothesis that none of these issues exists in our case and let's move onto math.

Current Slic3r's model includes an extrusion width value (which may be distinct per perimeters/infill/solid infill/etc.) and a spacing value, which is calculated automatically according to said extrusion width, to layer height and nozzle diameter. When width > nozzle diameter, it is assumed that the extrudate has a shape of a rectangle with rounded sides. When width <= nozzle diameter, a rectangular shape is assumed.

In my experience, once I have calibrated for a given extrusion width, a change to layer height could probably result in a wrong extrusion width. Yes, I agree this suggests that flow math may be wrong, but in this case I really wouldn't know what model would be better than the rectangle with rounded walls. (Note I'm talking about hollow single-wall models, so spacing/overlap is not involved in this.)

I have been refactoring Slic3r's internal API to make it cleaner and modular. I want to document every single internal method and allow people to replace parts easily, because I don't like to constrain people into my own choices (nophead, I do agree with you on that). Slic3r needs to be an open framework rather than a monolithic application. The current Slic3r's flow logic is contained in a separate Flow class. Any other model is applicable by just changing that code. Also note that Slic3r's codebase is currently 50% C++.

I'm very open to experimenting with your ideas. I just ask you to work on complete proposals, and I'll do my best to implement them. Example of proposal:

• a good default extrusion width formula for any combination of [layer height, nozzle diameter]
• a formula for calculating path spacing (i.e. width - some overlap) according to given [extrusion width, layer height, nozzle diameter, any other factor which might affect the calculation]
• whether we should let the user enter the die swell diameter and how we use it in the above formulas (if yes, should we still ask for nominal nozzle diameter? if so, what for?)
• whether we should apply some special treatment (width/spacing/overlap...) to the outer loop vs. the inner loops
• whether we should apply some special treatment to single-wall objects
• whether we should apply distinct math for distinct materials (PLA/ABS/flexible materials etc.)
• a possible calibration procedure for the average user

In my personal opinion, the presence of so many variables in this equation (including the mechanical/physical unmeasurable errors mentioned above) makes a pure-math solution not possible. It looks like many relationships are not linear, so we can't really calbrate on a single set of values and expect the calibration to be valid in any situation (two examples: this one [github.com] and Matt Robert's advance algorithm which works in theory but is almost impossible to calibrate in practice). I would really like to experiment heuristic (non-analytic) approaches, i.e. guide the user through a calibration procedure, acquire data, build tables and interpolate values. A sort of "PID". For example, print a plate of objects with slightly different flow, then have the user measure them and point out the one with the most correct dimensions. Then do the same to have him pick the most smooth solid infill. Monitor calibration works this way, and maybe we should take the same route. But this is just my humble opinion and I really look forward for implementing ideas coming from you.

for taking the challenge Alex and now that KS and SF is probably in a no developing zone all good reasons could be found to really dig deep to solve these complex matters and make them accessible to general or more advanced users in a proper way. it could do no harm also to look into the ways other slicers compensate for some of these things like "inset" compensation and "streching" and similar methods.
Keep up the good work.

Sound, thank you for taking the time to read the thread and for working on a solution. I look forward to the day when parts print extremely close to proper size.