Relative Extrusion CuraEngine

I created a branch of the Cura slicing engine that produces relative E values instead of Absolute E. To use it just download the development version of Cura and change line 29 of the package.sh file to

	CURA_ENGINE_REPO="https://github.com/Intrinsically-Sublime/CuraEngine"

which will pull in my version of the engine with Relative E enabled when you compile it. I have not made any changes to Cura's front end so there is no switch. It also does not insert the M83 to set the firmware to relative E.

The default Cura start code has a couple of G92 E0 that are not needed with Relative E that can be deleted.

If it works well for you I will look into adding the switch to Cura's front end and then do a pull request and hope that it gets added to the main branch of Cura.

---

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

I have updated the engine to have access to the relative switch from the engines settings. It still defaults to Relative E so it will not change the usage from Cura's front end. It will however make it easier to integrate into Cura's front end. It also allows access to the setting from the command line or the engines config file.

---

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

It now automatically inserts M83 for Relative E and M82 for Absolute E.

I have also added the switch to the Cura front end in the machine settings as well as the wizard. [github.com]

---

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 pointed out that there was a missing underscore in the config name for Relative extrusion which caused it to not save the check box when set during the initial Config wizard. It is now fixed.

---

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

are you going to pull request these changes? I have been trying unsuccessfully so far to build it on windows and would love to give the inset change a try.

Quote
Greg Frost
are you going to pull request these changes? I have been trying unsuccessfully so far to build it on windows and would love to give the inset change a try.

I was hoping for more response so I could point them to these threads and say "look other people want them too" but as it stands I do not have a lot of backing for them so I have my doubts on their reception.

If you would just like to try the inset on something you could create a Cura profile with your settings and I could slice a model with your profile and what ever inset(s) you would like. Cura is really fast so I do not mind slicing the model with a bunch of different insets for you. At least that way I could get some feedback on its usefulness.

---

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

Well it looks like I can compile Windows binaries in Linux using Mingw but as it stands I am having issues which look to be common when trying to cross compile. But during my reading I think I may have found out how to do it on Windows natively.

1) Install git [msysgit.github.io]
2) Run sh.exe (part of git) from the command line
3) You should now be in a a git bash terminal
4) change to the cura directory
5) Run "package.sh win32" (I enter the entire path in Ubuntu)

If that does not work you may need to install mingw (it is a minimal gnu compiler for Windows) and repeat the above.
If that does not work either you could try [www.cygwin.com] which will allow you to run the "package.sh win32" command in windows

Edited 2 time(s). Last edit at 02/25/2014 01:37AM 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

Why would one use Relative E values instead of Absolute? Just ask because I dont know about it. :-)

Quote
Kenzu
Why would one use Relative E values instead of Absolute? Just ask because I dont know about it. :-)

It is easier to post process the gcode. (like splice multiple gcode files together or change the retraction values, etc)
It is easier to manually write or change the gcode.
The start and end gcode is much easier without any G92 E0 's
The firmware does not have to track really high values that can cause an over flow in the firmware.
It is easier to find bugs in the gcode because things like the retractions really stand out.
It is an option in every other slicer as well as all firmwares (just not Cura).
Easier to change filament mid print (no worrying about the current E value).
No chance of the extruder running in reverse for a few cm because the extruder had not been reset.

---

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
Kenzu
Why would one use Relative E values instead of Absolute? Just ask because I dont know about it. :-)

It is easier to post process the gcode. (like splice multiple gcode files together or change the retraction values, etc)
It is easier to manually write or change the gcode.
The start and end gcode is much easier without any G92 E0 's
The firmware does not have to track really high values that can cause an over flow in the firmware.
It is easier to find bugs in the gcode because things like the retractions really stand out.
It is an option in every other slicer as well as all firmwares (just not Cura).
Easier to change filament mid print (no worrying about the current E value).
No chance of the extruder running in reverse for a few cm because the extruder had not been reset.

wow, what a list :-)

Can I use it with volumetric e? Just made the switch. [reprap.org]

Edit:
Just had a look at gcodes on reprap wiki.
Do you use "G91: Set to Relative Positioning" too? or only "M83: set extruder to relative mode"?

Edited 1 time(s). Last edit at 02/25/2014 04:21AM by Kenzu.

Quote
Kenzu

Quote
Sublime

Quote
Kenzu
Why would one use Relative E values instead of Absolute? Just ask because I dont know about it. :-)

It is easier to post process the gcode. (like splice multiple gcode files together or change the retraction values, etc)
It is easier to manually write or change the gcode.
The start and end gcode is much easier without any G92 E0 's
The firmware does not have to track really high values that can cause an over flow in the firmware.
It is easier to find bugs in the gcode because things like the retractions really stand out.
It is an option in every other slicer as well as all firmwares (just not Cura).
Easier to change filament mid print (no worrying about the current E value).
No chance of the extruder running in reverse for a few cm because the extruder had not been reset.

wow, what a list :-)

Can I use it with volumetric e? Just made the switch. [reprap.org]

Edit:
Just had a look at gcodes on reprap wiki.
Do you use "G91: Set to Relative Positioning" too? or only "M83: set extruder to relative mode"?

No G91. We only use Relative for the E axis.

Yes you can still use Triffid_hunters volumetric E calibration.

The only difference with Relative E is each E value is for the line segment being printed instead of the total E from the previous lines plus the current line segment. A lot of the experienced users that get great results use relative E (Nophead, Richgain, Myself, to name a few) and it looks like the only reason most people use Absolute is because it is the default set in most firmware with the exception of Teacup (Teacup is written by Triffid_hunter).

---

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

Sublime: If you are going to submit a pull request, you might want to fix a few things up.:

I got a compiler warning as a result of one of your changes:

gcodeExport.cpp: In member function 'void GCodeExport::writeMove(Point, int, int)':
gcodeExport.cpp:228:8: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]

You need to put braces around your new if clause.

Looking at your code you have not followed the indenting scheme in the rest of the file either which is the sort of thing people hate when accepting pull requests. You might also want to check fffProcessor.h:307,309 inset.cpp:17

Another thing I noticed was (and this is unrelated to your changes) in Cura package.sh on line 37, because there are no double quotes around the `which $1` you get a syntax error if the path to $1 contains a space (which im my case it did because i had 7zip installed under "Program Files" as is the default on windows).

--- ../Cura/package.sh  Wed Feb 26 10:22:39 2014
+++ ./package.sh        Tue Feb 18 01:27:48 2014
@@ -34,7 +34,7 @@
 #############################
 function checkTool
 {
-       if [ -z `which $1` ]; then
+       if [ -z "`which $1`" ]; then
                echo "The $1 command must be somewhere in your \$PATH."
                echo "Fix your \$PATH or install $2"
                exit 1

Thanks for the build tip. I was just running package.sh without the win32 argument and I think the problems I was having were building for other platforms.

Now I just need to work out how to run the version that appeared to build successfully.

Edited 3 time(s). Last edit at 02/25/2014 08:10PM by Greg Frost.

hmmm. I got it to run, but then had some problems.

The first run wizard went through ok and I entered a custom machine profile with 0.5mm nozzle and selected relative E.
Then when it got to the cura interface, Shell thickness was highlighted red. When I click in the field, it says "incorrect nozzle size". I went into the machine settings again and there no longer seems to be a place to enter the nozzle size. Something seems screwed up with the settings.

Quote
Greg Frost
Sublime: If you are going to submit a pull request, you might want to fix a few things up.:

I got a compiler warning as a result of one of your changes:

gcodeExport.cpp: In member function 'void GCodeExport::writeMove(Point, int, int)':
gcodeExport.cpp:228:8: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]

You need to put braces around your new if clause.

This one is actually not mine. It is like that in the main branch of Cura and I avoid fixing compile errors on things that actually work as I have found that by getting rid of warning sometimes it breaks things as the compilers decision may not be the same as my fix.

Also in a lot of programming languages you can have a single statement after an "if" without brackets which is what it is complaining about.

Quote

Looking at your code you have not followed the indenting scheme in the rest of the file either which is the sort of thing people hate when accepting pull requests. You might also want to check fffProcessor.h:307,309 inset.cpp:17

Maybe I am not seeing what you are but it does look to be following the correct indentation. It could be a result of my editor not using the same font as yours because they used spaces not tabs which cause it to show differently with different fonts. Github's diff tool shows them all being the same except one in inset.cpp (not the one you mentioned) that is off by one space on github but correct in my editor using a mono space font. Also the python front end has to be the correct indentation because python relies on it and they used tabs in it. I am not a programmer so I may be missing something and having to switch back and forth between the languages is a little confusing at times.

For fffProcessor.h:307,309 my "if" is indented the same amount as the "if" above it (My if is not inside of the above if so it is not indented more.

For inset.cpp:17 I only added a comma and one variable name.

-void generateInsets(SliceLayerPart* part, int offset, int insetCount) <- original

+void generateInsets(SliceLayerPart* part, int offset, int insetCount, int perimInset) <- my version

If you look at the diff [github.com] you will see I only added one variable to a couple of files in the Cura engine and as far as the diff looks it is all exactly as it should.

Quote

Another thing I noticed was (and this is unrelated to your changes) in Cura package.sh on line 37, because there are no double quotes around the `which $1` you get a syntax error if the path to $1 contains a space (which im my case it did because i had 7zip installed under "Program Files" as is the default on windows).

--- ../Cura/package.sh  Wed Feb 26 10:22:39 2014
+++ ./package.sh        Tue Feb 18 01:27:48 2014
@@ -34,7 +34,7 @@
 #############################
 function checkTool
 {
-       if [ -z `which $1` ]; then
+       if [ -z "`which $1`" ]; then
                echo "The $1 command must be somewhere in your \$PATH."
                echo "Fix your \$PATH or install $2"
                exit 1

Thanks for the build tip. I was just running package.sh without the win32 argument and I think the problems I was having were building for other platforms.

Now I just need to work out how to run the version that appeared to build successfully.

There should be an installer in the scripts folder.

My build in win7 32 in virtualbox still will not work.

---

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

Quote
Greg Frost
hmmm. I got it to run, but then had some problems.

The first run wizard went through ok and I entered a custom machine profile with 0.5mm nozzle and selected relative E.
Then when it got to the cura interface, Shell thickness was highlighted red. When I click in the field, it says "incorrect nozzle size". I went into the machine settings again and there no longer seems to be a place to enter the nozzle size. Something seems screwed up with the settings.

Its in the advanced tab for some reason.

---

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

I ran up an old version to check and youre right, it is under the Advanced tab (which is crazy because really there should be one size per extruder, and it should be associated with the Machine, but on your version I got this:

I'm gonna try building Daid's version to see if I can get that working.

Edited 1 time(s). Last edit at 02/26/2014 01:11AM by Greg Frost.

Yup that was me. I have fixed it if you want to download and try again or you can simply open the compiled version Cura/Cura/Util/Profile.py and change line 182.
- setting('nozzle_size', 0.4, float, 'machine', _('Machine'))...................
+ setting('nozzle_size', 0.4, float, 'advanced', _('Machine'))...................

I am not even sure how that happened. It is not like that in my local development branch. I do remember thinking it needed to be moved into the machine settings and I must have started and then got side tracked.

---

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
Kenzu

Quote
Sublime

Quote
Kenzu
Why would one use Relative E values instead of Absolute? Just ask because I dont know about it. :-)

It is easier to post process the gcode. (like splice multiple gcode files together or change the retraction values, etc)
It is easier to manually write or change the gcode.
The start and end gcode is much easier without any G92 E0 's
The firmware does not have to track really high values that can cause an over flow in the firmware.
It is easier to find bugs in the gcode because things like the retractions really stand out.
It is an option in every other slicer as well as all firmwares (just not Cura).
Easier to change filament mid print (no worrying about the current E value).
No chance of the extruder running in reverse for a few cm because the extruder had not been reset.

wow, what a list :-)

Can I use it with volumetric e? Just made the switch. [reprap.org]

Edit:
Just had a look at gcodes on reprap wiki.
Do you use "G91: Set to Relative Positioning" too? or only "M83: set extruder to relative mode"?

No G91. We only use Relative for the E axis.

Yes you can still use Triffid_hunters volumetric E calibration.

The only difference with Relative E is each E value is for the line segment being printed instead of the total E from the previous lines plus the current line segment. A lot of the experienced users that get great results use relative E (Nophead, Richgain, Myself, to name a few) and it looks like the only reason most people use Absolute is because it is the default set in most firmware with the exception of Teacup (Teacup is written by Triffid_hunter).

Okay i have made the switch to Relative E with my volumetric e setup and it's working well. :-)
As I use Simplify3D as slicer I have not tested your Cura branch yet. But I follow Cura now and then as I want a free slicer to. You have my vote now for Relative E support in Cura.

Is there someone who can compile this for W7?
Im to silly to do this or it doenst work for me.
Thanks in advance

Quote
Hux Flux
Is there someone who can compile this for W7?
Im to silly to do this or it doenst work for me.
Thanks in advance

You can PM greg frost to see if he has his copy available. I personally am not a Windows user and I never could figure out how to compile it in Windows in virtual box.

---

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

Hi Sublime, don't now if you are still working on this, but i tried to build with checkout i did 5/29. But its not building. I am getting this Error:

c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: utils/sock
et.o: bad reloc address 0x20 in section `.eh_frame'
collect2.exe: error: ld returned 1 exit status
Makefile:39: recipe for target 'CuraEngine' failed
mingw32-make: *** [CuraEngine] Error 1
mingw32-make: Leaving directory 'c:/Users/gdwinslow/Cura/CuraEngine'
Failed to build CuraEngine

The Ultimaker version worked ok. I am a Big fan of Cura as it dos a Supper-ear Job at 0.1mm layer height on my RepRapPro Tricolor Mendel. I have replaced my controller with the Ormarod controller and it will only work with Relative Extrusion. If you have any suggestions, its much appresheated

I am not sure why you are having trouble compiling it but i think it may be an issue with mingw. I did figure out how to compile it for windows in virtual box and have binaries available for it Win32 [www.tantillus.org] Debian (ubuntu) 32bit [www.tantillus.org] 64bit [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

Thanks I will give it a try tonight when I get home

I can't get cura to do any retraction. I am using Sublime's 14.02-RC5, and have the following retraction settings: retraction_enable=true, retraction_speed = 30; retraction_amount = 2; retraction_min_travel 2; retraction_combing = True; retraction_min_extrusiobn = 0.05; retraction_hop = 0.

Every time the print head does a non-extrusion move, it just continues smoothly at the same speed to the new location. The extruder gear stops turning, but it never reverses. Many of these moves are greater than the 2mm minimum travel, so I don't know why it's not retracting.

Any ideas?

Quote
jbernardis
I can't get cura to do any retraction. I am using Sublime's 14.02-RC5, and have the following retraction settings: retraction_enable=true, retraction_speed = 30; retraction_amount = 2; retraction_min_travel 2; retraction_combing = True; retraction_min_extrusiobn = 0.05; retraction_hop = 0.

Every time the print head does a non-extrusion move, it just continues smoothly at the same speed to the new location. The extruder gear stops turning, but it never reverses. Many of these moves are greater than the 2mm minimum travel, so I don't know why it's not retracting.

Any ideas?

Cura is a little strange with its retractions. Can you try printing two cubes at the same time and see if it retracts between them? If that works can you try the original file again with absolute extrusion? With the answers to those two questions it should be easy to track down if it is a bug.

---

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

A little late here on the east coast US - besides I'm in the middle of a 4 hour print. I'll give it a shot tomorrow evening.

BTW - I'm already using absolute extrusion. I know the title of this thread has to do with relative extrusion, and I should have probably started a new thread, but it seemed to flow with the conversation here

So I created a plate with 2 cubes about 25mm apart. Still with absolute extrusion. There most definitely is retraction when it moves from one object to another, but none within a single object. The cubes were each 15mm in X and Y and there were layers where it started down the middle, so there was movement from one corner to an adjacent corner - a distance of 15mm - larger that the minimum retraction travel distance - and there was no retraction.

I'm wondering if is does not retract if it does not cross a perimeter. Obviously a cube is a bad test object for that, but if I try an arc shape I could reasonable expect that there'd be occasional movement from one end to the other across the open space in between. Let me try that test and see what happens.

Do you think it worthwhile to try relative extrusion? There is no firmware change for that - just difference slicing parameters, so it would be easy enough to try. I just don't know what we'd be trying to illustrate with that test.

EDIT - I tried a more complex shape to see if I could get it to cross a perimeter, and it actually seemed to go out of its way to stay INSIDE the perimeter. So I did a more careful reading of the pop-up help, and what I think I want to do is to disable retraction combing. Again, the printer is busy right now, but I will try this later. I think I've got it this time.

Edited 1 time(s). Last edit at 06/12/2014 11:42PM by jbernardis.

Yeah it does sound like comb is the issue.

---

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

What is it going to take to get your inset feature merged into the main cura branch? I can attest to the accuracy of the models sliced with Cura. I just printed the same piece sliced with both Cura and Slic3r. The piece has pockets for 20x20 aluminum extrusions, a 608 bearing, two holes for 8mm smooth bars, and several bolt holes. I used actual dimensions in my openscad source.

The Cura printed object was absolutely perfect. Everything fit perfectly and snugly. With the slic3r printed object, not only did I have to ream holes a bit larger, but I had to use my mallet as a persuader.

Any time I need absolute dimensional accuracy, Cura is the slicer of choice.

My only complaints with Cura are:

1. I solved the retraction issue discussed above by turning off the "retraction combing" feature. The only time I have an issue in this regard is when it moves from the skirt to the object first layer. It does not retract, and since we are in the first layer, I sometimes get a smear of filament over to the starting point. If it happens to be on an interior perimeter (which it usually is) the smear appears on the exterior bottom of the final object, and
2. I just wish it was better at bridging.

Quote
jbernardis
What is it going to take to get your inset feature merged into the main cura branch? I can attest to the accuracy of the models sliced with Cura. I just printed the same piece sliced with both Cura and Slic3r. The piece has pockets for 20x20 aluminum extrusions, a 608 bearing, two holes for 8mm smooth bars, and several bolt holes. I used actual dimensions in my openscad source.

The Cura printed object was absolutely perfect. Everything fit perfectly and snugly. With the slic3r printed object, not only did I have to ream holes a bit larger, but I had to use my mallet as a persuader.

Any time I need absolute dimensional accuracy, Cura is the slicer of choice.

I think we need to get a few more people to try it and get the same results as you have gotten. Once that is achieved we can point Daid to those testimonies and then maybe he will at least test it and then possibly merge it.

Quote

My only complaints with Cura are:

1. I solved the retraction issue discussed above by turning off the "retraction combing" feature. The only time I have an issue in this regard is when it moves from the skirt to the object first layer. It does not retract, and since we are in the first layer, I sometimes get a smear of filament over to the starting point. If it happens to be on an interior perimeter (which it usually is) the smear appears on the exterior bottom of the final object, and
2. I just wish it was better at bridging.

The retraction on combed travel moves is actually something I want to figure out how to enable without disabling combing.

The retraction on the first layer has never been an issue for me but I can see why you would want it and if I get a chance to play with the other retraction issue I will see if I can figure out where it makes that decision and add a check box.

CuraEngine does have files called Bridge.ccp and bridge.h that I don't fully understand just yet. It may be possible it already has the ability to detect and deal with bridges but no settings or the file is inactive at this time, I am not really sure (it may even be possible it's functional in a later release that I have not tested).

---

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