<p>According to the RepRap.org <a href="http://reprap.org/wiki/G-code" rel="nofollow noreferrer">list of G-Code commands</a>, see <strong><a href="http://reprap.org/wiki/G-code#G0_.26_G1:_Move" rel="nofollow noreferrer">G0 &amp; G1: Move</a></strong>:</p>

<blockquote>
  <p>The <code>Ennn</code> command is <em>The amount to extrude between the starting point and ending point</em>. </p>
</blockquote>

<p>However, according to <strike><a href="https://github.com/daid/Cura/issues/385" rel="nofollow noreferrer">this</a></strike> a discussion, that is now deleted from GitHub, about the Cura slicing engine:</p>

<p>The <strong>E</strong> values are in <em>absolute mode</em>, so perhaps the firmware is attempting to move the stepper motor to the absolute position (which is almost 50% through your print). This may lead to clogging or skipping depending on how hot your extruder is at that point.</p>

<p>As a last resort, you can perform a Boolean subtract on your model of the section that's already printed and re-slice the model to print the remaining bit. Then glue, or ABS weld, the remaining piece to the main print. I've done this in the past, it's not super glamorous, but it gets the job done if the part doesn't require a lot of structural integrity.</p>

<p><strong>I was incorrect with the following statements with regard to the Cura slicing engine:</strong> </p>

<p><s>It's been a while since I've looked at 3D printer G-Code, but from what I remember, <strong>E</strong> values can be the bane of any manually written G-Code. Usually the slicing engine generates the <strong>E</strong> value as an incremental step value throughout the G-Code (at least this was true for Skeinforge and early MakerWare, please verify this). So, if the value is incremental and depending on the controller, this value could be lost or corrupt if a new print is initialized.</p>

<p>I would hope, that if you're using a slicing engine's <em>custom G-Code</em> input, that the software would be able to compensate situations like this and reformat your provided G-Code to match the value of <strong>E</strong> or any similar command.</s></p>

CC BY-SA 3.0
2016-03-22T15:26:15.283Z
I have not edited any codes, except removing layers 0-108
user1104
CC BY-SA 3.0
2016-03-22T15:31:40.317Z
In removing those lines of code, you would have needed to stop the errant print, remove lines 0-108, re-upload the GCode file, and re-initialize the printer for the new GCode file. In doing so, the value for **E** is lost after stopping the print. I believe that **E** sets the position of the stepper motor. I think, in "losing" this value, you won't be able to pick up where you left off. There might be a function in some slicing engines to pick up at a specific line.
tbm0115
CC BY-SA 3.0
2016-03-22T15:36:04.757Z
it does follow the correct path, it just won't extrude filament
user1104
CC BY-SA 3.0
2016-03-22T15:38:46.053Z
Yes, the machine will follow the correct Cartesian coordinates (XYZ) because they are written in Absolute coordinates. The **E** value (for the stepper motor and/or distance between nozzles depending on the machine), I believe is written in Incremental coordinates. This would explain why the machine moves to the correct location, but may hang up on extruding. I'll try finding some more information for you to hopefully explain better.
tbm0115
CC BY-SA 3.0
2016-03-22T15:43:26.313Z
Please regard [this](http://reprap.org/wiki/G-code#G-commands) where it refers to the **E** command as *The amount to extrude between the starting point and ending point* meaning that it refers to the previous **E** value to determine how much filament is extruded.
tbm0115
CC BY-SA 3.0
2017-05-31T05:45:15.853Z
Unfortunately, the link to the discussion has died... I wonder if it has been retained elsewhere on the web, in an archive?
Greenonline
CC BY-SA 3.0
2017-05-31T17:29:14.797Z
@Greenonline Thanks, the issue that I linked seems to have been deleted completely. I check the issue log on the repository, but it's empty.
tbm0115
CC BY-SA 3.0
2016-03-22T15:22:37.283Z
2017-05-31T17:28:24.917Z
2017-05-31T17:28:24.917Z
tbm0115
<p>I know this is an old thread but I have been running into similar issues with my delta machine with Marlin firmware.  </p>

<p>Not all printers running Marlin ignore large <code>E</code> (extruder) moves.  G-code has always (even in CNC machines) run commands from were the motors are now, to the value in the G-code line.  For example, <code>G0 X10</code> will move the X motor 10 units.  The units are set through <code>G20</code> or <code>G21</code>. </p>

<p>When your machine has lost power, you need to re-home all axes in order for the machine to know where it is.  If you don't, it will likely think that it currently is at 0, 0, 0, 0.  Then when you have the line, </p>

<pre><code>G1 F3600 X210.390 Y105.771 E4104.65185 
</code></pre>

<p>it will try to go from 0,0,0,0 to 210.390, 105.771, 0, 4104.65185 at the feed rate of 3600. Therefore it is always good to home after power loss and add a <code>G92 E4104.4</code> (last line ran before power loss) even if your machine may not need it.  </p>

<p>Good habits make for less mistakes. </p>

CC BY-SA 3.0
2016-05-19T01:42:13.897Z
2017-05-31T05:48:40.680Z
2017-05-31T05:48:40.680Z
skidoo
<p>Is the hotend temperature set correctly? If you only preheat the hotend but then turn it off, it will behave exactly as you described (while you're above <code>EXTRUDE_MINTEMP</code> it will behave normally, but once the temperature drops too low it will continue doing the XYZ-moves, but stop extruding). Perhaps you need to add a <code>M109</code> command to set the temperature properly.</p>

<p><a href="https://3dprinting.stackexchange.com/questions/850/no-extrusion-when-trying-to-resume-failed-print-with-manually-edited-gcode/851#851">In his answer</a>, tbm0115 mentions absolute and relative coordinates. Whether absolute or relative coordinates are used is set using the <code>G90</code>/<code>G91</code> commands and will always be the same for all axes (XYZ and E). He also mentions that:</p>

<blockquote>
  <p>so perhaps the firmware is attempting to move the stepper motor to the absolute position (which is almost 50% thru your print). This may lead to clogging or skipping depending on how hot your extruder is at that point.</p>
</blockquote>

<p>This shouldn't happen, as extremely long extrude moves are ignored by Marlin. When the printer encounters</p>

<pre><code>G1 F3600 X210.390 Y105.771 E4104.65185
</code></pre>

<p>it performs only the XYZ-part of the move, but doesn't move the extruder (assuming the printer was reset and the current extruder position is 0). However, it does update the internal value for the extruder position, so the next move happens normally. Perhaps missing the initial extrude segment isn't a big deal, but if you want the print to resume perfectly where you left off, you should add a <code>G92</code> command to the beginning to initialize the extruder position correctly, for example:</p>

<pre><code>G92 E4104.4
</code></pre>

<p>(but the exact value depends on the last extruder position in the previous layer).</p>

CC BY-SA 3.0
2016-03-25T10:42:27.823Z
2017-05-31T06:23:55.527Z
2017-05-31T06:23:55.527Z
Tom van der Zanden
<p>I was in the process of printing a 16 hour print, but I must have failed to copy the G-code correctly, because the print stopped after 107 of 223 layers. Looking at the G-code, It also stops there. </p>

<p>However, I had the full G-code on my computer, and decided to try and resume the print from layer 108. It seemed to work, with the exception of a little excess extrusion at a single point in the beginning, but after three layers, i noticed that it wasn't extruding anymore. I am not completely positive that it isn't due to nozzle jamming, but I have a strong feeling that the problem is the G-code itself, as it does extrude some plastic just before printing starts.</p>

<p>Here are the first lines of my manually edited G-code. Can anyone see why I get the blob in the beginning, or why I don't get anything at all later on? Or does it look good, and my problem is probably the nozzle? </p>

<pre><code>;FLAVOR:UltiGCode
;TIME:60308
;MATERIAL:119047
;MATERIAL2:0
;NOZZLE_DIAMETER:0.400000
;NOZZLE_DIAMETER2:0.400000
;MTYPE:PLA

;Layer count: 222
;LAYER:109
G0 F9000 X208.213 Y107.948 Z16.610
;TYPE:FILL
G1 F3600 X210.390 Y105.771 E4104.65185
G0 F9000 X210.390 Y103.170
G1 F3600 X168.331 Y61.111 E4107.77457
G0 F9000 X167.074 Y61.111
G1 F3600 X120.237 Y107.949 E4111.25208
G0 F9000 X121.695 Y107.949
G1 F3600 X74.857 Y61.111 E4114.72962
G0 F9000 X73.600 Y61.111
G1 F3600 X26.763 Y107.948 E4118.20709
</code></pre>

<g-code>
No extrusion when trying to resume failed print with manually edited gcode
user1104
# No extrusion when trying to resume failed print with manually edited gcode

(Asked by: username_0 on 2016-03-22)

I was in the process of printing a 16 hour print, but I must have failed to copy the G-code correctly, because the print stopped after 107 of 223 layers. Looking at the G-code, It also stops there. 
However, I had the full G-code on my computer, and decided to try and resume the print from layer 108. It seemed to work, with the exception of a little excess extrusion at a single point in the beginning, but after three layers, i noticed that it wasn't extruding anymore. I am not completely positive that it isn't due to nozzle jamming, but I have a strong feeling that the problem is the G-code itself, as it does extrude some plastic just before printing starts.
Here are the first lines of my manually edited G-code. Can anyone see why I get the blob in the beginning, or why I don't get anything at all later on? Or does it look good, and my problem is probably the nozzle? 
;FLAVOR:UltiGCode
;TIME:60308
;MATERIAL:119047
;MATERIAL2:0
;NOZZLE_DIAMETER:0.400000
;NOZZLE_DIAMETER2:0.400000
;MTYPE:PLA

;Layer count: 222
;LAYER:109
G0 F9000 X208.213 Y107.948 Z16.610
;TYPE:FILL
G1 F3600 X210.390 Y105.771 E4104.65185
G0 F9000 X210.390 Y103.170
G1 F3600 X168.331 Y61.111 E4107.77457
G0 F9000 X167.074 Y61.111
G1 F3600 X120.237 Y107.949 E4111.25208
G0 F9000 X121.695 Y107.949
G1 F3600 X74.857 Y61.111 E4114.72962
G0 F9000 X73.600 Y61.111
G1 F3600 X26.763 Y107.948 E4118.20709

**Tags:** g-code

---

## 3 answers

### Answer by username_1 on 2016-03-22. Score: 3

According to the RepRap.org [list of G-Code commands](http://reprap.org/wiki/G-code), see **[G0 & G1: Move](http://reprap.org/wiki/G-code#G0_.26_G1:_Move)**:

> The `Ennn` command is *The amount to extrude between the starting point and ending point*.

However, according to [this](https://github.com/daid/Cura/issues/385) a discussion, that is now deleted from GitHub, about the Cura slicing engine:

The **E** values are in *absolute mode*, so perhaps the firmware is attempting to move the stepper motor to the absolute position (which is almost 50% through your print). This may lead to clogging or skipping depending on how hot your extruder is at that point.

As a last resort, you can perform a Boolean subtract on your model of the section that's already printed and re-slice the model to print the remaining bit. Then glue, or ABS weld, the remaining piece to the main print. I've done this in the past, it's not super glamorous, but it gets the job done if the part doesn't require a lot of structural integrity.

**I was incorrect with the following statements with regard to the Cura slicing engine:**

~~It's been a while since I've looked at 3D printer G-Code, but from what I remember, **E** values can be the bane of any manually written G-Code. Usually the slicing engine generates the **E** value as an incremental step value throughout the G-Code (at least this was true for Skeinforge and early MakerWare, please verify this). So, if the value is incremental and depending on the controller, this value could be lost or corrupt if a new print is initialized.~~

I would hope, that if you're using a slicing engine's *custom G-Code* input, that the software would be able to compensate situations like this and reformat your provided G-Code to match the value of **E** or any similar command.

> **Comments:**
> **username_0**: I have not edited any codes, except removing layers 0-108  
> **username_1**: In removing those lines of code, you would have needed to stop the errant print, remove lines 0-108, re-upload the GCode file, and re-initialize the printer for the new GCode file. In doing so, the value for **E** is lost after stopping the print. I believe that **E** sets the position of the stepper motor. I think, in "losing" this value, you won't be able to pick up where you left off. There might be a function in some slicing engines to pick up at a specific line.  
> **username_0**: it does follow the correct path, it just won't extrude filament  
> **username_1**: Yes, the machine will follow the correct Cartesian coordinates (XYZ) because they are written in Absolute coordinates. The **E** value (for the stepper motor and/or distance between nozzles depending on the machine), I believe is written in Incremental coordinates. This would explain why the machine moves to the correct location, but may hang up on extruding. I'll try finding some more information for you to hopefully explain better.  
> **username_1**: Please regard [this](http://reprap.org/wiki/G-code#G-commands) where it refers to the **E** command as *The amount to extrude between the starting point and ending point* meaning that it refers to the previous **E** value to determine how much filament is extruded.  
> **username_2**: Unfortunately, the link to the discussion has died... I wonder if it has been retained elsewhere on the web, in an archive?  
> **username_1**: @Greenonline Thanks, the issue that I linked seems to have been deleted completely. I check the issue log on the repository, but it's empty.  

---

### Answer by username_3 on 2016-05-19. Score: 2

I know this is an old thread but I have been running into similar issues with my delta machine with Marlin firmware.  
Not all printers running Marlin ignore large E (extruder) moves.  G-code has always (even in CNC machines) run commands from were the motors are now, to the value in the G-code line.  For example, G0 X10 will move the X motor 10 units.  The units are set through G20 or G21. 
When your machine has lost power, you need to re-home all axes in order for the machine to know where it is.  If you don't, it will likely think that it currently is at 0, 0, 0, 0.  Then when you have the line, 
G1 F3600 X210.390 Y105.771 E4104.65185 

it will try to go from 0,0,0,0 to 210.390, 105.771, 0, 4104.65185 at the feed rate of 3600. Therefore it is always good to home after power loss and add a G92 E4104.4 (last line ran before power loss) even if your machine may not need it.  
Good habits make for less mistakes.


---

### Answer by username_4 on 2016-03-25. Score: 1

Is the hotend temperature set correctly? If you only preheat the hotend but then turn it off, it will behave exactly as you described (while you're above EXTRUDE_MINTEMP it will behave normally, but once the temperature drops too low it will continue doing the XYZ-moves, but stop extruding). Perhaps you need to add a M109 command to set the temperature properly.
In his answer, tbm0115 mentions absolute and relative coordinates. Whether absolute or relative coordinates are used is set using the G90/G91 commands and will always be the same for all axes (XYZ and E). He also mentions that:

so perhaps the firmware is attempting to move the stepper motor to the absolute position (which is almost 50% thru your print). This may lead to clogging or skipping depending on how hot your extruder is at that point.

This shouldn't happen, as extremely long extrude moves are ignored by Marlin. When the printer encounters
G1 F3600 X210.390 Y105.771 E4104.65185

it performs only the XYZ-part of the move, but doesn't move the extruder (assuming the printer was reset and the current extruder position is 0). However, it does update the internal value for the extruder position, so the next move happens normally. Perhaps missing the initial extrude segment isn't a big deal, but if you want the print to resume perfectly where you left off, you should add a G92 command to the beginning to initialize the extruder position correctly, for example:
G92 E4104.4

(but the exact value depends on the last extruder position in the previous layer).


---

