Relative Extrusion CuraEngine

Re: Relative Extrusion CuraEngine

pandionx — Wed, 21 Jan 2015 15:00:16 -0500

Thanks for the info DC, I didn't know that! Will check it out!

Having said that, relative IS useful if you're going to be editing the gcode manually, so the plugin may still have some benefit for me in the future.

Re: Relative Extrusion CuraEngine

dc42 — Tue, 20 Jan 2015 18:41:31 -0500

btw using my fork of RepRapFirmware, you don't have to use the relative extruder plugin for Cura, because I fixed the bug with absolute extruder moves in the original firmware many months ago. Also, you can get round the T1/T0 numbering using the an extension to the M563 in your start gcode - see the note towards the end of [reprap.org].

Re: Relative Extrusion CuraEngine

pandionx — Tue, 20 Jan 2015 14:22:32 -0500

After being frustrated by the print quality of Slicer over the weekend, I eventually tried Cura by using a relative extrusion plugin created by Cash from this forum. Had to make an additional change since Cura seems to use T0 as the extruder, and on my DC42 firmware it's T1, but in any event.
I was astounded at the quality difference. The quality of Cura is superb, where Slicer, frankly, was horrendous on a small object I was trying to print.

I tried numerous settings to avoid z-scars on Slicer, none of which worked. With Cura, the print was perfect. I still need to do one final test where I set the Slicer setting exactly to what my Cura settings are, but I am not expecting a difference.

I am not sure what the argument about accumulating error refers to, was it used an an excuse not to pull your change? Irrespective, the argument is completely irrelevant - the fact is that some printers (like my Ormerod) uses relative extrusion. It is not up to the developer of a slicer to decide for me that I must switch to absolute - it's built into my firmware.

Secondly, the number of decimal places after the comma in g-code does not mean one needs to use the same number of decimal places in the C code to calculate the overall lengths. Frankly, if it was such an issue, they should use a Decimal (lossless) class in C, instead of a lossy float or double C type anyway.

In any event, I have not tried your branch of Cura yet Sublime, I will try do so in the next week or so, and if it works, I will be happy to also motivate for a pull request.

PS. I'm planning to start printing your mini-Lathe soon :)

Re: Relative Extrusion CuraEngine

Sublime — Tue, 08 Jul 2014 14:18:15 -0400

Quote
hercek
It is a pity you did not get this merged. The argument about accumulating error due to use of relative coordinates is silly. There are 4 decimal places after the dot in the *.gcode files. This may lead to volume error of about 2.4e-4 mm³ per one E movement. But filament diameter typically varies at least in the range like 1.74 to 1.76 mm. This leads to error of about 5.5e-2 mm³ per one 1 mm of E movement. That is about 200 times more. We should always use only relative coordinates for E movement (and absolute only for X/Y/Z movement). No need for an option in GUI.

I would have to agree 100%.

Re: Relative Extrusion CuraEngine

hercek — Tue, 08 Jul 2014 12:42:11 -0400

It is a pity you did not get this merged. The argument about accumulating error due tu use of relative coordinates is silly. There are 4 decimal places after the dot in the *.gcode files. This may lead to volume error of about 2.4e-4 mm³ per one E movement. But filament diameter typically varies at least in the range like 1.74 to 1.76 mm. This leads to error of about 5.5e-2 mm³ per one 1 mm of E movement. That is about 200 times more. We should always use only relative coordinates for E movement (and absolute only for X/Y/Z movement). No need for an option in GUI.

Re: Relative Extrusion CuraEngine

Sublime — Thu, 26 Jun 2014 19:30:11 -0400

My intent has never been to make an alternative Cura but rather just a branch to test things that will hopefully get in to the main version. So in the end getting Daid to make the changes would be better then me doing it. But in the event he is not interested I will do my best to maintain at least some version with my options.

Re: Relative Extrusion CuraEngine

jbernardis — Thu, 26 Jun 2014 15:01:20 -0400

Actually a bit more on the retraction on the first layer issue. If I have a simple object with no interior perimeters, then it retracts from the end of the skirt to the beginning of the object perimeter. If, however, I have an interior perimeter that is large enough, Cura will actually produce a skirt within that. This is when it doesn't retract - when it is moving from one skirt section to another.

Regarding the bridging issue, I was printing a piece that had 3 downward-facing nut traps. When I have this, I always add a 0.25mm high cylinder where the the holes meet. This creates a membrane that later needs to be drilled out, but it allows for a smaller hole to be printed above a larger hole. Cura recognized this, but it just gave me a solid fill there, parallel with the rest of the infill. But you know the way Cura does solid infill in the midst of sparse infill: sometimes it leaves gaps in the printing and comes back and fills them in later. It is not treated any differently than any other infill on the layer. I don't think Cura "considered" it to be a bridging situation. The net result here was that there was almost no material that needed to be drilled out. The final "bridge" if you want to call it that was just a few sagging threads. (the good news was that the print was fine) Both Skeinforge and Slic3r currently handle this better and result in good strong bridges..

Perhaps I should be posting these issues over on Daid's repo. I certainly would like these two branches to merge together at some point.

Re: Relative Extrusion CuraEngine

Sublime — Thu, 26 Jun 2014 11:43:40 -0400

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:

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
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).

Re: Relative Extrusion CuraEngine

jbernardis — Thu, 26 Jun 2014 11:17:50 -0400

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:

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
I just wish it was better at bridging.

Re: Relative Extrusion CuraEngine

Sublime — Fri, 13 Jun 2014 00:25:06 -0400

Yeah it does sound like comb is the issue.

Re: Relative Extrusion CuraEngine

jbernardis — Thu, 12 Jun 2014 22:30:05 -0400

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.

Re: Relative Extrusion CuraEngine

jbernardis — Wed, 11 Jun 2014 23:51:49 -0400

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

Re: Relative Extrusion CuraEngine

Sublime — Wed, 11 Jun 2014 23:30:44 -0400

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.

Re: Relative Extrusion CuraEngine

jbernardis — Wed, 11 Jun 2014 21:34:05 -0400

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?

Re: Relative Extrusion CuraEngine

gdwinslow — Fri, 30 May 2014 18:59:49 -0400

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

Re: Relative Extrusion CuraEngine

Sublime — Thu, 29 May 2014 23:53:53 -0400

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]

Re: Relative Extrusion CuraEngine

gdwinslow — Thu, 29 May 2014 23:37:19 -0400

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

Re: Relative Extrusion CuraEngine

Sublime — Wed, 16 Apr 2014 12:07:45 -0400

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.

Re: Relative Extrusion CuraEngine

Hux Flux — Tue, 15 Apr 2014 12:14:02 -0400

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

Re: Relative Extrusion CuraEngine

Kenzu — Wed, 26 Feb 2014 03:02:35 -0500

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.

Re: Relative Extrusion CuraEngine

Sublime — Wed, 26 Feb 2014 01:17:31 -0500

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.

Re: Relative Extrusion CuraEngine

Greg Frost — Wed, 26 Feb 2014 00:55:16 -0500

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:

2vbo215.jpg

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

Re: Relative Extrusion CuraEngine

Sublime — Tue, 25 Feb 2014 22:14:55 -0500

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.

Re: Relative Extrusion CuraEngine

Sublime — Tue, 25 Feb 2014 22:14:15 -0500

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.

Re: Relative Extrusion CuraEngine

Greg Frost — Tue, 25 Feb 2014 20:36:34 -0500

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.

Re: Relative Extrusion CuraEngine

Greg Frost — Tue, 25 Feb 2014 20:05:46 -0500

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.

Re: Relative Extrusion CuraEngine

Sublime — Tue, 25 Feb 2014 11:55:26 -0500

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).

Re: Relative Extrusion CuraEngine

Kenzu — Tue, 25 Feb 2014 04:17:31 -0500

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"?

Re: Relative Extrusion CuraEngine

Sublime — Tue, 25 Feb 2014 03:35:10 -0500

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.

Re: Relative Extrusion CuraEngine

Kenzu — Tue, 25 Feb 2014 03:02:46 -0500

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