Inset feature for Cura

I have added an inset feature to my branch of Cura. [github.com] . It allows you to calibrate the flow to achieve perfectly solid parts and then use the inset feature to inset the perimeters to get the part exactly the correct size. Again if there is enough positive feedback on it I will initiate a pull request with the main branch of Cura.

You will have to compile it yourself. It will automatically pull in my branch of the Cura engine.

Edited 1 time(s). Last edit at 02/16/2014 07:43PM by Sublime.

---

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

Have you built this on windows? If so can you package it so we can try it out without having to get the build environment setup?

I am a Linux user and do not have access to any Windows PC's. If anyone else compiles it for Windows or Mac I would be happy to host the files on my server to download.

Also by the look of Cura's readme you do not need much in the way of dependencies if any at all for Windows.

 For Windows the package.sh script can be run from bash using git. The "package.sh" script generates a final release package.

Both MacOS and Linux require some extra instructions for development, as you need to prepare an environment. Look below at the proper section to see what is needed.

---

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

@ Greg Frost

I see you merged my changes into your branch of Cura and initiated a pull request. Does this mean you found it useful? Have you been using it? I think the only way you will get Daid to accept it is to have enough people saying it is a good solution to the problem.

---

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

Great feature. Needed since forever [sic]. If this gets accepted and Cura gets bridge settings, I should be able to dump Slic3r entirely.

Edited 1 time(s). Last edit at 04/22/2014 04:27AM by whosawhatsis.

---

[whosawhatsis.com]

We need more testers and confirmation from prominent figures that it does indeed work to get watertight parts with correct dimensions before Diad will look at it seriously.

As for bridging in Cura. I know it does have an algorithm to detect them, but it is unclear to me what it does with that data after detecting them. If I ever figure it out it should be easy enough to make the bridge speed, bridge fan speed and flow rate adjustable. Or at least have it mark bridges in the gcode file to make those things adjustable via a post processor.

---

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

I'll have to see if I can figure out how to build Cura for Mac then. I always have the worst luck when I try to build things from source...

---

[whosawhatsis.com]

Quote
Sublime
I have added an inset feature to my branch of Cura..

Does it affect both dimensions - internal and external as kisslicer does? Or only internal?

Quote
karabas

Quote
Sublime
I have added an inset feature to my branch of Cura..

Does it affect both dimensions - internal and external as kisslicer does? Or only internal?

It affects both internal and external. It just adds the extra inset to the one already calculated to inset the path half the extrusion width. Currently the Cura engine does not differentiate between them. It just insets all the perimeters toward the solid portion of the model and I just added a couple of lines of code to add the extra inset to that.

---

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

Oh, this is another feature that I rely on in Slic3r and that is really needed in Cura: [github.com]

---

[whosawhatsis.com]

Quote
whosawhatsis
I'll have to see if I can figure out how to build Cura for Mac then. I always have the worst luck when I try to build things from source...

I have a second thread concerning my branch of Cura that has some information on compiling it for Windows which may also apply to Mac. [forums.reprap.org]

If you do figure it out please let me know and I will try and update my repo to be in sync with the Official Cura engine and then maybe you could recompile it and I could host it for download to let others try it.

---

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

Quote
whosawhatsis
Oh, this is another feature that I rely on in Slic3r and that is really needed in Cura: [github.com]

Next time I am in there I will have a look and see how hard it would be.

Edited 1 time(s). Last edit at 04/22/2014 03:28PM by Sublime.

---

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

Quote
Sublime

Quote
karabas

Quote
Sublime
I have added an inset feature to my branch of Cura..

Does it affect both dimensions - internal and external as kisslicer does? Or only internal?

It affects both internal and external. It just adds the extra inset to the one already calculated to inset the path half the extrusion width. Currently the Cura engine does not differentiate between them. It just insets all the perimeters toward the solid portion of the model and I just added a couple of lines of code to add the extra inset to that.

So, xy-scale compensation is required. But how it can be calculated? Inset is non linear operation...

Quote
karabas

Quote
Sublime

Quote
karabas

Quote
Sublime
I have added an inset feature to my branch of Cura..

Does it affect both dimensions - internal and external as kisslicer does? Or only internal?

It affects both internal and external. It just adds the extra inset to the one already calculated to inset the path half the extrusion width. Currently the Cura engine does not differentiate between them. It just insets all the perimeters toward the solid portion of the model and I just added a couple of lines of code to add the extra inset to that.

So, xy-scale compensation is required. But how it can be calculated? Inset is non linear operation...

No scaling should ever be required. The entire point of this is that when you slice an object it assumes the extrusion is a square profile but in reality the profile is rounded on the sides which makes the extrusion wider than calculated (slic3r has you reduce all the flow to get the rounded profile to come out the width of the calculated square one which leaves holes everywhere else). So if you properly calibrate your extruder using the distance of filament being requested all sides of the part should now come out a fraction larger due to this rounded edge. This inset allows you to move all the paths in further to allow that rounded edge to end exactly on the models edge.

I personally do not even find any changes are needed on Tantillus as all dimensions come out correct for me using lower layer heights [forums.reprap.org] . But I do know that a lot of machines have issues printing the correct dimensions and that larger layers have a large rounded edge that requires this inset.

---

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

In addition to the rounded edges of extrusion, any Z wobble/ribbing due to Z axis issues will exacerbate these fit issues. These problems should be fixed mechanically of course, but for some users working with poorly-designed printers, that is not an option.

---

[whosawhatsis.com]

I find myself using Cura more and more. I really like the results I get from it, and it is very fast. It's also accurate - I've had files that baffled both slic3r and skeinforge that cura slices without an issue.

The only issue I am having with it is in saving profiles. If I select an already existing file from the file browser, say profile.ini, and save it, I get a file named profile.ini.ini. If I just type the work "profile" infor the file name, I just get a file named "profile" - no extension. Profiles don't change that often, and I've gotten used to going over to that directory to rename a few files.

Now back to the subject of this thread - has the pull request been accepted? If not, and if it would help the effort, I'll gladly download your git and start playing around with it.

Quote
jbernardis
I find myself using Cura more and more. I really like the results I get from it, and it is very fast. It's also accurate - I've had files that baffled both slic3r and skeinforge that cura slices without an issue.

Its also nice that you can turn the repairing on an off.

Quote

The only issue I am having with it is in saving profiles. If I select an already existing file from the file browser, say profile.ini, and save it, I get a file named profile.ini.ini. If I just type the work "profile" infor the file name, I just get a file named "profile" - no extension. Profiles don't change that often, and I've gotten used to going over to that directory to rename a few files.

I just tried in my Branch on Linux that is 2 months behind and it does not have that issue.

Quote

Now back to the subject of this thread - has the pull request been accepted? If not, and if it would help the effort, I'll gladly download your git and start playing around with it.

It has not been accepted and more testing would be appreciated. If you know of any reason why I should get my branch inline with the current Cura head please let me know and I will try and get it updated.

---

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

I am having trouble building your git. It looks like it clones your CuraEngine, and then compilation fails on file gcodeExport.cpp. It's complaining about line 149, and when I look there I see the following:

<<<<<<< HEAD

This is definitely not C++ - it looks like some kind of git artifact. In any event, I don't know how to proceed.

I am running Ubuntu 12.04 LTS. My machine is an older 32 bit machine, so my build command was "sudo ./package.sh debian_i386"

Quote
jbernardis
I am having trouble building your git. It looks like it clones your CuraEngine, and then compilation fails on file gcodeExport.cpp. It's complaining about line 149, and when I look there I see the following:

<<<<<<< HEAD

This is definitely not C++ - it looks like some kind of git artifact. In any event, I don't know how to proceed.

I am running Ubuntu 12.04 LTS. My machine is an older 32 bit machine, so my build command was "sudo ./package.sh debian_i386"

Ok that was from me trying to merge the upstream master and not being very good at git. I have reverted that merge so it should work.

---

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

OK here are .deb files for Ubuntu:

32bit [www.Tantillus.org]
64bit [www.Tantillus.org]

They were compiled on Ubuntu 13.04 since that is what I am running.

---

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

Ok I finally figured out how to build this in windows 7 32bit in virtual box.

Here is the win32 build [www.Tantillus.org]

---

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

So with your correction, I was able to build my clone of your git without issue. Everything seems ok.

When I run the program, the only real difference I see is that you have a perimeter inset field on the advanced settings page and, of course, a corresponding value in the profile files. There is no guidance for determining values, but I gather that I should slice and print a few objects and compare their actual dimensions with the model dimensions. The difference gets entered here and I iterate until I get good values. A couple of questions:

1) I assume that whatever I measure as the difference I should halve because I need to achieve half of the correction on each side of the object, and
2) I think of inset as a value taken away. So based on this, I assume a positive number REDUCES the size of the object, and if I want to make the object bigger, I should reduce the inset value?

Quote
jbernardis
1) I assume that whatever I measure as the difference I should halve because I need to achieve half of the correction on each side of the object, and
2) I think of inset as a value taken away. So based on this, I assume a positive number REDUCES the size of the object, and if I want to make the object bigger, I should reduce the inset value?

Yes exactly. If a 20mm cube comes out 20.2 you would enter an inset of 0.1

If it were to come out less like 19.8 then you could enter -0.1. But I would think if it comes out too small you should recheck the flow and/or X/Y steps per mm again.

It does nothing with the Z axis at all. Those surfaces will not get any inset.

Edit: The only other difference with my branch is you have the option to use relative E.

Edited 1 time(s). Last edit at 04/27/2014 12:32AM by Sublime.

---

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

OK - I sliced a calibration cube with a hole through the center both with and without inset overrides, and there was an observable difference. I've got a bit more tweaking to do, though, because the inner dimension of the hole was still a bit small. I'll work with it some more though.

I've also sliced up several more complex objects just to see is everything still holds together and everything looked fine. I am really happy with the results here. I just wish it had a better profile system. I give Slic3r top marks for the way profiles are organized.

Glad to hear it is working for you. For the inner holes I would suggest you play with the layer height and the width. I would suggest 0.2mm layers and then use my calculator to determine the extrusion width. Then you will have to enter a "shell thickness" that is exactly divisible by that width because of how Cura will print strange widths if you are not careful with the shell thickness. (Cura divides the shell thickness by the nozzle diameter, rounds the result and then divides the shell thickness by it to determine the extrusion width. It allows the result to be anywhere from 80%-150% of the nozzle diameter.)

I actually have an experimental branch on my machine that has the start of a Material profile system. It currently uses my calculators math to determine the width automatically based on the nozzle diameter , steps per mm and layer height. Once complete it will do everything my Calculator does so all you will ever have to change will be the layer height and select a material. Then it will determine the width, speed and temps for you automatically.

---

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

You also need to check that the hole is actually the size you think it is in the model. For instance, if you use OpenSCAD and try to cut a circular hole, it will always come out smaller because of the difference between radius and apothem of a polygon. The way curves will be converted to polygons in other CAD programs may differ, but you're still likely to end up with circles smaller than what you specified, especially if you try to approximate a smooth curve too closely by using small facets. More info here: [hydraraptor.blogspot.com]

---

[whosawhatsis.com]

Sublime

I already have exactly that. My layer height is 0.2 and I have my extrusion width set to 0.56 - independently calculated, but verified with your calculator. Based on that, I set the skin thickness to 1.12 (BTW - I like the feature of specifying skin thickness in mm instead of number of perimeters).



whosawhatsis

I am familiar with nophead's polyhole idea. I haven't tried it yet, but I will do so over the next few days.


I have MANY settings that still need to be fine-tuned. That's why I'm not too worried about it yet.

Quote
whosawhatsis
but you're still likely to end up with circles smaller than what you specified, especially if you try to approximate a smooth curve too closely by using small facets.

This has never made any sense to me unless OpenScad measures circles flat to flat and this technique relies on the vertices being placed further out than the diameter being printed (actually what skeinforge stretch plug in does). I model in Blender and the vertices are placed on the edge of the circle being drawn. This means if you use less vertices the flats will intersect the circles diameter and surely make the holes too small. I usually model small holes with at least 32 vertices and large holes I model with 96 or more. I have provided many examples and prints to show that the holes do not come out too small using this technique. So this seems more like an issue with OpenScad rather than an issue with using too many sides. Or as I have speculated many times before it is an issue with extrusion size being used.

EDIT: I just re-read the poly hole page and he is actually making the holes larger and then using the low polys so the edge lines up with the original circles diameter. So it still is printing undersized but he is using that to his advantage and it is not solving the issue, rather just hiding it.

Edited 1 time(s). Last edit at 04/30/2014 07:41PM by Sublime.

---

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

Quote
jbernardis
Sublime

I already have exactly that. My layer height is 0.2 and I have my extrusion width set to 0.56 - independently calculated, but verified with your calculator. Based on that, I set the skin thickness to 1.12 (BTW - I like the feature of specifying skin thickness in mm instead of number of perimeters).

Good to hear. How did you come to that extrusion width? My calculator is a result of many years of printing and making different profiles and then using that data to figure out the relations between them.

My experimental version still uses a skin thickness and divides it by the calculated extrusion width to come to a perimeter count rather than entering the perimeter count separately.

---

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

You know, I can't really remember how I calculated that. I think it was an earlier version of Josef Prusa's reprap calculator. I was playing around with that and it started giving me messages about how the extrusion width to layer height ratio should be greater than 200% in order to have good layer to layer adhesion, and then with continued experimentation, I zeroed in on 280% as my "golden" ratio. I still play around with this number from time to time, but it's always >200%.