Z-offset issues with Slic3r and Da Vinci Nano

Question

I was attempting to use Slic3r 1.3.0 to print to my Da Vinci Nano, using MiniMover (a replacement for xyzprint) to load the G-code.

The print seemed to be a couple of millimeters off of the bed, but adding neither 2 or -2 offset in Slic3r worked.

Neither did adding the following to the g-code.

G92 Z2
G0 Z0

Anyone have a solution?

The start of my G-code is:

; generated by Slic3r 1.3.0-dev on 2020-06-28 at 10:37:50

; external perimeters extrusion width = 0.55mm (3.04mm^3/s)
; perimeters extrusion width = 0.70mm (7.88mm^3/s)
; infill extrusion width = 0.62mm (9.31mm^3/s)
; solid infill extrusion width = 0.70mm (2.63mm^3/s)
; top infill extrusion width = 0.70mm (1.97mm^3/s)

M107 ; disable fan
M104 S220 ; set temperature
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle

; Filament gcode

M109 S220 ; set temperature and wait for it to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0 ; reset extrusion distance
G1 Z0.300 F7800.000 ; move to next layer (0)
G1 E-2.00000 F2400.00000 ; retract extruder 0
G92 E0 ; reset extrusion distance
G1 X40.004 Y40.786 Z0.300 F7800.000 ; move to first skirt point
G1 E2.00000 F2400.00000 ; unretract extruder 0
G1 F1800
G1 X41.753 Y39.328 Z0.300 E2.46602 ; skirt
G1 X45.000 Y38.464 Z0.300 E3.15334 ; skirt
G1 X75.000 Y38.464 Z0.300 E9.29109 ; skirt
G1 X77.243 Y38.861 Z0.300 E9.75711 ; skirt

Answer 1

Behavioral analysis

To find out what is actually wrong, let's do a simple series of test commands first: a G-code that homes the printhead, moves it up 100 mm (10 cm), then zeroes there, moves up 20 more and back to the new 0 at 100 mm above the bed. Make sure not a single offset is active anywhere when sending/loading the G-code as this is to test for the actual movement.

G28 
G1 Z100 
G92 Z0 
G90 
G1 Z20 
G1 Z0

Measuring the distance to the bed should give us something hopefully close to 100 mm. If it is longer or shorter, we have a problem with the bed position to the endstop, even if the bed itself is level to the machine. A releveling is advised unless there is a reason to home to a position widely outside of the printing height or if leveling proves to be impossible.

Why is the error experienced?!

The culprit seems to be that the Z-offset parameter in slic3r is not updated properly when altering it. I just tested this with a ludicrous offset and it took several saving and slicing attempts to register that Z0 was supposed to be 200 mm over the endstop via the offset setting. Compare these two blocks:

G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G1 Z0.350 F7800.000

And this one:

G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G1 Z-199.650 F7800.000

The offset only appears factored in starting with the actual print's G1 commands. But how did I eventually manage to make it update?

Forcing the update

To force an update of all the settings, I did create a secondary printer profile (just saved the same one and in the new one set the offset back to 0) and then swapped between the two back and forth twice and then the correct offset one. This seems to be a very reliable way to force an update of this setting, as it did register every swap after the first one.

Workarounds

manual Offsetting via Filament parameter

But there is a way around that is always taken into account: we can add a custom Filament Start Code, which contains the needed offset under Filament Settings tab > Custom G-Code:

G1 Z<offset we need to be exactly at layer 0 height>
G92 Z0.3

But this is a rather clumsy way and should only be made if nothing else helps and not in conjunction with any offset in the machine setting!

Tackle the problem by the root

The problem isn't usually the offset but a bed leveled to the wrong height. To level the bed the printer should be brought to Z0 via G28 and then leveled again. If this proves futile, setting the offset and forcing an update in slic3r is needed.