<p>As Oscar commented, check the tail end of your gcode files.  Most slicing software includes commands to move the head to x=0,y=0 at the very least.  I am a bit surprised that your files don't appear to have this, since Cura does apply said code. </p>

<p>Possiblly there's something lacking in your printer's firmware and it doesn't recognize some of the gcode commands.</p>

CC BY-SA 4.0
2018-09-07T14:37:36.003Z
The software that came with the printer was proprietary and did not work with my Mac, that is why I used Cura instead.  It seems to only have this problem with taller prints.  I sliced it with the recommended settings.
theMouse
CC BY-SA 4.0
2018-09-07T14:19:44.827Z
2018-09-07T14:19:44.827Z
Carl Witthoft
<p>As can be seen from the G-code file, the head is instructed to travel to x=0, y=0 (<code>G28 X0 Y0</code> is actually a homing instruction to home the head and label the position with zero X and zero Y). After that it powers off the motors (<code>M84</code>). </p>

<p>From your picture, it looks like the head digs in the print without moving to the home position, so <code>G28 X0 Y0</code>  is <strong>not working</strong> (although you mention it tries to move while digging in?!?). That is strange as there is no instruction to lower the head. Please alter <code>G28</code> to <code>G0</code> so that it reads:</p>

<pre><code>G0 X0 Y0
</code></pre>

<p>(or <code>G1 X0 Y0</code> which does work and will instruct the head to move). </p>

<p>The digging into the print could be explained by the weight of the head/carriage that cannot be held when the steppers are not powered anymore (as instructed by <code>M84</code>). When the nozzle is hot, the nozzle will then dig into your print.</p>

<hr>

<p><strong>Edit</strong>:</p>

<p>Now that I see your comment on another answer, your proprietary software may produce different G-code than Cura does, this could imply that your printer does not use a "standard" G-code interpreter or does not implement all G-codes.</p>

CC BY-SA 4.0
2018-09-07T18:23:33.707Z
Or maybe move the G28 homing command up 5 or 6 lines
Carl Witthoft
CC BY-SA 4.0
2018-09-10T18:09:55.393Z
Maybe worth mentioning that `G28` is not a move, it is a home instruction, so the '0' should be ignored.Where you say 'alter ... in ...', it would be better as 'alter ... _to_ ...'
Sean Houlihane
CC BY-SA 4.0
2018-09-07T15:49:45.030Z
2018-09-13T21:06:06.827Z
2018-09-13T21:06:06.827Z
0scar
<p>From the provided G-code:</p>

<pre><code>G28 X0 Y0
</code></pre>

<p>The meaning of the <code>G28</code> code is <a href="https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29" rel="nofollow noreferrer">move printhead to home</a>.  In theory, the presence or absence of <code>X</code>, <code>Y</code>, and <code>Z</code> values are used to indicate which axes the printhead should move on, but as the RepRap wiki notes, some printers ignore this, typically interpreting any <code>G28</code> code as "move to 0,0,0".  In particular:</p>

<blockquote>
  <p>Because the behavior of G28 is unspecified, it is recommended not to automatically include G28 in your ending GCode. On a Cartesian this will result in damaging the printed object. If you need to move the carriage at the completion of a print, use G0 or G1.</p>
</blockquote>

<p>You should probably replace the code with <code>G1 X0 Y0 Z[value near the top of your printer]</code>.  You could simply replace <code>G28 X0 Y0</code> with <code>G1 X0 Y0</code>, but that risks dragging the tip of the nozzle across the upper surface of the finished print.</p>

CC BY-SA 4.0
2018-09-11T23:09:11.647Z
Basically exactly the same as [this](https://3dprinting.stackexchange.com/a/6868/5740) answer, only with a very useful quote.
0scar
CC BY-SA 4.0
2018-09-11T21:22:17.057Z
2018-09-11T21:22:17.057Z
Mark
<p>For some reason the <code>G28</code> command to home X and Y is not having an effect. I wonder if there is something 'special' in the firmware that affects how it homes.</p>

<p>You can try to replace the G28 with a move (and maybe a different location would be better to place the extruder in the best position for removing your print).</p>

<pre><code>G1 X0 Y0 ;Move to home position
</code></pre>

<p>Best would be to look at one of the included 'pre sliced' models that are usually included with a printer to check the manufacturer's default end sequence.</p>

<p>You might also be able to configure Cura to move up at the end of the print (so long as the print is not at maximum height).</p>

CC BY-SA 4.0
2018-09-10T16:36:39.647Z
What is the difference between 0scar's `G0` and your `G1`? Aren't they pretty similar? Don't they both just move the hotend? `G1` in a straight line, and `G0` maybe not so straight?
Greenonline
CC BY-SA 4.0
2018-09-10T16:45:59.193Z
Ah, the typo in 0scar's answer caused me to fail to parse it properly... He doesn't mention homing either (but that doesn't make this a good answer)
Sean Houlihane
CC BY-SA 4.0
2018-09-13T19:41:11.140Z
@Greenonline, `G1` is "move in a straight line".  `G0` is "move as fast as possible, trajectory not specified".  In practice, a `G0` move will often follow a dogleg path, as one axis finishes its motion before the others.
Mark
CC BY-SA 4.0
2018-09-10T11:04:37.790Z
2018-09-10T11:04:37.790Z
Sean Houlihane
<p>I am using cura with M3D entry level printer.</p>

<p>When I print things more than 6-7cm/2.5-3inches, at the end of the print, the hot end sink back into the print then gets stuck as it tries to return to idle position.</p>

<p>Please see the attached photo.  Has anyone had this problem?  Thank you<a href="https://i.sstatic.net/2xpD4.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2xpD4.jpg" alt="enter image description here"></a></p>

<p>The last 20 lines of gcode is:</p>

<pre><code>G0 X50.83 Y49.982
G1 F600 X50.541 Y49.975 E4399.62304
G1 X50.268 Y49.985 E4399.62637
G1 X49.999 Y49.999 E4399.63024
G1 X49.73 Y50.012 E4399.6341
G1 X49.457 Y50.023 E4399.63742
G1 X49.168 Y50.016 E4399.63941
G0 F7200 X49.28 Y49.87
;TIME_ELAPSED:6301.614981
G1 F1500 E4393.13941
M107
M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
G28 X0 Y0
M84
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
</code></pre>

CC BY-SA 4.0
2018-09-07T11:50:04.253Z
Hi theMouse and welcome to SE.3D Printing! Please add the last e.g. 20 lines of the G-code file, than people can see if it is instructed to do that, otherwise there may be an other problem (e.g. steppers loosing power leading to sinking of the head).
0scar
<print-quality>
3D printer ends print by sinking in to it and getting stuck
theMouse
# 3D printer ends print by sinking in to it and getting stuck

(Asked by: username_0 on 2018-09-07)

I am using cura with M3D entry level printer.
When I print things more than 6-7cm/2.5-3inches, at the end of the print, the hot end sink back into the print then gets stuck as it tries to return to idle position.
Please see the attached photo.  Has anyone had this problem?  Thank you
The last 20 lines of gcode is:
G0 X50.83 Y49.982
G1 F600 X50.541 Y49.975 E4399.62304
G1 X50.268 Y49.985 E4399.62637
G1 X49.999 Y49.999 E4399.63024
G1 X49.73 Y50.012 E4399.6341
G1 X49.457 Y50.023 E4399.63742
G1 X49.168 Y50.016 E4399.63941
G0 F7200 X49.28 Y49.87
;TIME_ELAPSED:6301.614981
G1 F1500 E4393.13941
M107
M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
G28 X0 Y0
M84
M82 ;absolute extrusion mode
M104 S0
;End of Gcode

**Tags:** print-quality
> **Comments:**
> **username_1**: Hi theMouse and welcome to SE.3D Printing! Please add the last e.g. 20 lines of the G-code file, than people can see if it is instructed to do that, otherwise there may be an other problem (e.g. steppers loosing power leading to sinking of the head).  

---

## 4 answers

### Answer by username_2 on 2018-09-07. Score: 1 | Accepted answer

As Oscar commented, check the tail end of your gcode files. Most slicing software includes commands to move the head to x=0,y=0 at the very least. I am a bit surprised that your files don't appear to have this, since Cura does apply said code.

Possiblly there's something lacking in your printer's firmware and it doesn't recognize some of the gcode commands.

> **Comments:**
> **username_0**: The software that came with the printer was proprietary and did not work with my Mac, that is why I used Cura instead.  It seems to only have this problem with taller prints.  I sliced it with the recommended settings.  

---

### Answer by username_1 on 2018-09-07. Score: 4

As can be seen from the G-code file, the head is instructed to travel to x=0, y=0 (G28 X0 Y0 is actually a homing instruction to home the head and label the position with zero X and zero Y). After that it powers off the motors (M84). 
From your picture, it looks like the head digs in the print without moving to the home position, so G28 X0 Y0  is not working (although you mention it tries to move while digging in?!?). That is strange as there is no instruction to lower the head. Please alter G28 to G0 so that it reads:
G0 X0 Y0

(or G1 X0 Y0 which does work and will instruct the head to move). 
The digging into the print could be explained by the weight of the head/carriage that cannot be held when the steppers are not powered anymore (as instructed by M84). When the nozzle is hot, the nozzle will then dig into your print.

Edit:
Now that I see your comment on another answer, your proprietary software may produce different G-code than Cura does, this could imply that your printer does not use a "standard" G-code interpreter or does not implement all G-codes.

> **Comments:**
> **username_2**: Or maybe move the G28 homing command up 5 or 6 lines  
> **username_3**: Maybe worth mentioning that `G28` is not a move, it is a home instruction, so the '0' should be ignored.Where you say 'alter ... in ...', it would be better as 'alter ... _to_ ...'  

---

### Answer by username_4 on 2018-09-11. Score: 2

From the provided G-code:
G28 X0 Y0

The meaning of the G28 code is move printhead to home.  In theory, the presence or absence of X, Y, and Z values are used to indicate which axes the printhead should move on, but as the RepRap wiki notes, some printers ignore this, typically interpreting any G28 code as "move to 0,0,0".  In particular:

Because the behavior of G28 is unspecified, it is recommended not to automatically include G28 in your ending GCode. On a Cartesian this will result in damaging the printed object. If you need to move the carriage at the completion of a print, use G0 or G1.

You should probably replace the code with G1 X0 Y0 Z[value near the top of your printer].  You could simply replace G28 X0 Y0 with G1 X0 Y0, but that risks dragging the tip of the nozzle across the upper surface of the finished print.

> **Comments:**
> **username_1**: Basically exactly the same as [this](https://3dprinting.stackexchange.com/a/6868/5740) answer, only with a very useful quote.  

---

### Answer by username_3 on 2018-09-10. Score: 2

For some reason the G28 command to home X and Y is not having an effect. I wonder if there is something 'special' in the firmware that affects how it homes.
You can try to replace the G28 with a move (and maybe a different location would be better to place the extruder in the best position for removing your print).
G1 X0 Y0 ;Move to home position

Best would be to look at one of the included 'pre sliced' models that are usually included with a printer to check the manufacturer's default end sequence.
You might also be able to configure Cura to move up at the end of the print (so long as the print is not at maximum height).

> **Comments:**
> **username_5**: What is the difference between 0scar's `G0` and your `G1`? Aren't they pretty similar? Don't they both just move the hotend? `G1` in a straight line, and `G0` maybe not so straight?  
> **username_3**: Ah, the typo in 0scar's answer caused me to fail to parse it properly... He doesn't mention homing either (but that doesn't make this a good answer)  
> **username_4**: @Greenonline, `G1` is "move in a straight line".  `G0` is "move as fast as possible, trajectory not specified".  In practice, a `G0` move will often follow a dogleg path, as one axis finishes its motion before the others.  

---

