<p>Formally, G0 is a rapid move and G1 is a coordinated move. A G1 will cause the printhead to move in a straight line from the begin to the end position, whereas a G0 allows the printhead to move in any curve, so long as it ends up in the target position. Because of acceleration and deceleration constraints, it can sometimes be faster to move in a curve rather than a straight line.</p>

<p>However, I don't think any actually firmware implements this, and a G0 behaves in the exact same way as a G1.</p>

<p>What the piece of G-code you posted is doing is creating a solid infill, which consists of a bunch of parallel lines, each slightly offset from the next:</p>

<p><a href="https://i.sstatic.net/AoKAc.png" rel="noreferrer"><img src="https://i.sstatic.net/AoKAc.png" alt="Section of G-code render, showing parallel lines of solid inflil."></a></p>

<p>It makes sense that no material is extruded when it moves from one line to the other, as otherwise too much material would get deposited at the edge.</p>

CC BY-SA 3.0
2017-07-30T10:02:25.793Z
If you set the pattern to Zig Zag then Cura will shorten the long infill lines a bit and connect them with a printed line in such a way that you don't deposit too much material.
Tim Kuipers
CC BY-SA 3.0
2017-01-04T12:32:53.440Z
2017-01-04T12:32:53.440Z
Tom van der Zanden
<p>While looking into G-code I was wondering why Cura inserts G0 commands in between G1 commands every other line like this:</p>

<pre><code>G1 F2400 X144.612 Y130.187 E1652.56358
G0 F6000 X144.612 Y129.621
G1 F2400 X72.905 Y57.914 E1654.16570
G0 F6000 X73.471 Y57.914
G1 F2400 X144.612 Y129.056 E1655.75518
G0 F6000 X144.612 Y128.490
G1 F2400 X74.036 Y57.914 E1657.33203
G0 F6000 X74.602 Y57.914
G1 F2400 X144.612 Y127.924 E1658.89623
G0 F6000 X144.612 Y127.359
</code></pre>

<p>It seems like it wants to move to a slightly offset starting position for the next extrusion. I dont understand why, though. It wants to have touching lines as a result, doesn't it?</p>

<p>I do see this making sense in a fill situation, - this section is called 'type: skin'. How does slic3r get away doing infill without this?</p>

<p>Am I correct to read slic3r gcode correctly to use G1 instead of G0 commands for this?</p>

CC BY-SA 3.0
2017-01-05T01:34:41.430Z
It might be a *smoothing*-type option set in your slicing engine. Smoothing essentially performs an action similar to this.
tbm0115
<slicing><ultimaker-cura><slic3r>
Why does Cura insert G0 commands between G1 commands while Slic3r doesn't?
kamuro
# Why does Cura insert G0 commands between G1 commands while Slic3r doesn't?

(Asked by: username_0 on 2017-01-04)

While looking into G-code I was wondering why Cura inserts G0 commands in between G1 commands every other line like this:

```
G1 F2400 X144.612 Y130.187 E1652.56358
G0 F6000 X144.612 Y129.621
G1 F2400 X72.905 Y57.914 E1654.16570
G0 F6000 X73.471 Y57.914
G1 F2400 X144.612 Y129.056 E1655.75518
G0 F6000 X144.612 Y128.490
G1 F2400 X74.036 Y57.914 E1657.33203
G0 F6000 X74.602 Y57.914
G1 F2400 X144.612 Y127.924 E1658.89623
G0 F6000 X144.612 Y127.359

```

It seems like it wants to move to a slightly offset starting position for the next extrusion. I dont understand why, though. It wants to have touching lines as a result, doesn't it?

I do see this making sense in a fill situation, - this section is called 'type: skin'. How does slic3r get away doing infill without this?

Am I correct to read slic3r gcode correctly to use G1 instead of G0 commands for this?

**Tags:** slicing, ultimaker-cura, slic3r

> **Comments:**
> **username_1**: It might be a *smoothing*-type option set in your slicing engine. Smoothing essentially performs an action similar to this.  

---

## 1 answers

### Answer by username_2 on 2017-01-04. Score: 6

Formally, G0 is a rapid move and G1 is a coordinated move. A G1 will cause the printhead to move in a straight line from the begin to the end position, whereas a G0 allows the printhead to move in any curve, so long as it ends up in the target position. Because of acceleration and deceleration constraints, it can sometimes be faster to move in a curve rather than a straight line.

However, I don't think any actually firmware implements this, and a G0 behaves in the exact same way as a G1.

What the piece of G-code you posted is doing is creating a solid infill, which consists of a bunch of parallel lines, each slightly offset from the next:

[![Section of G-code render, showing parallel lines of solid inflil.](https://i.sstatic.net/AoKAc.png)](https://i.sstatic.net/AoKAc.png)

It makes sense that no material is extruded when it moves from one line to the other, as otherwise too much material would get deposited at the edge.

> **Comments:**
> **username_3**: If you set the pattern to Zig Zag then Cura will shorten the long infill lines a bit and connect them with a printed line in such a way that you don't deposit too much material.  

---

