When I go to 'Gcode Viewer' and start scanning through the layers, I see a normal Layer 1 as the bottom layer of my print. Going to Layer 2 shows a blank grid and the following in the information area:
The actual gcode file shows the expected transition from layer 1 to 2, so it appears Octoprint is creating its own 'Layer 2' for some reason. This doesn't affect my prints, as far as I can see, but it creates a bit of an issue when using the 'Multi Colors' plugin. For instance, when I scan the sliced file in Simplify3D, I need a pause after layer 17 to change color. In Octoprint, it shows the transition as layer 18. I've been able to do what I want, but it seems weird that Octoprint inserts a 'do-nothing' layer.
That layer isn't inserted by OctoPrint, it is part of your GCODE file. OctoPrint doesn't invent layers. If you share a GCODE file, this can be verified.
I got a detailed response to this when I posted in another forum that led me to do additional tests.
Further testing on my part yields the following: The layer is inserted by Octoprint as a mis-interpretation, basically. In Simplify3D, the layer thickness is defined as 0.2mm, with the first layer being a thickness of 90% of that value. When Octoprint parses the gcode file, it runs the commands in order; i.e., it performs the lines that moves the gantry and primes the extruder, forming a line near the edge of the bed. But, in the process of parsing, it sees the line that defines a level Z0.2. It is that information that causes Octoprint to think there is another layer prior to the actual commands that start layer 2, so the real layer 2 becomes layer 3 and all subsequent layers are incrememted by 1. My 100 layer calibration cube becomes 101 layers as a result. In most cases, one sees no issue because all the work gets done. It's confusing only when inserting a pause at a certain layer to change colors or perform another operation.
To clarify in a more graphical way:
Layer 1 is Z0.18 (90% of 0.2mm)
BUT, Octoprint also sees the line for priming defined as Z0.2 and tries to do something with it; ergo, it inserts a new layer 2.
Original layer 2(now 3) is Z0.38 (0.18+0.20)
With PRIME in Gcode:
G90
M82
M106 S0
M140 S50
M190 S50
M104 S205 T0
M109 S205 T0
G28 ; home all axes
G29 ; auto level
G1 X0 Y20 Z0.2 F3000 ; get ready to prime <<<This line created the issue in Octoprint
G92 E0 ; reset extrusion distance
G1 X200 E20 F600 ; prime nozzle
; process Process1
; layer 1, Z = 0.180
T0
; feature skirt
; tool H0.180 W0.480
G1 Z0.180 F1000
G1 X65.680 Y67.273 F4800
G92 E0.0000
G1 X67.273 Y65.680 E0.0809 F1800
Without PRIME in Gcode:
G90
M82
M106 S0
M140 S50
M190 S50
M104 S205 T0
M109 S205 T0
G28 ; home all axes
G29 ; auto level
; process Process1
; layer 1, Z = 0.180
T0
; feature skirt
; tool H0.180 W0.480
G1 Z0.180 F1000
G1 X86.480 Y88.073 F4800
G92 E0.0000
G1 X88.073 Y86.480 E0.0809 F1800
G1 X106.880 Y86.480 E0.7565
My conclusion is that I will eliminate the priming function and assume the skirt will take care of preparing the extruder.
No. OctoPrint doesn't care about your layers, makes any assumptions about them or incremends Z values. There isn't any code that would even be capable of misfunctioning in that way.
However, the GCODE viewer (and only that, frontend and client-side only, no file modification at all) usually sort the layers by z-height and that can lead to things looking wonky with extensive cleaning routines at the start of a print. Disabling this sorting via
shows you layers in the order they are contained in the file. Empty layers are nozzle moves to a z height on which neither a move in X/Y nor an extrusion happens.
