Feature request: set XY before Z for first layer

[agvol]

Version

2.1.0

Operating system type + version

Windows any

example generated GCODE

G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
M900 K45 ; Filament gcode
G1 Z0.200 F6000.000
G1 E-2.00000 F2400.00000
G92 E0
G1 X62.696 Y51.400 F6000.000
G1 E2.00000 F2400.00000
G1 F1800
G1 X63.380 Y50.659 E2.03162
G1 X64.145 Y50.001 E2.06324
G1 X65.043 Y49.398 E2.09718

G1 Z0.200 F6000.000 - set Z to 0.2 ...... G1 X62.696 Y51.400 F6000.000 - set XY

I use pre-bleed plastic and then raise the nozzle, and the code immediately lowers and moves the nozzle directly over the table. It would be great to be able to swap the two commands for the first layer.

[rtyr]

It would be not safe. The nozzle can touch the bed for example. You don't want to move XY in that case. Closing.

[foreachthing]

I use pre-bleed plastic and then raise the nozzle, and the code immediately lowers and moves the nozzle directly over the table. It would be great to be able to swap the two commands for the first layer.

And so I made this: https://github.com/foreachthing/Slic3rPostProcessing This will be more like the Cura-Move: Ooze where you want, then move XYZ (simultaneously) to the first start-point in your gcode.

[foreachthing]

Just added a quick and dirty python version of the "Cura"-move: https://github.com/foreachthing/Slic3rPostProcessing/tree/master/SPP-Python

[qwewer0]

By itself either the Z first then XY or XY then Z is both can be dangerous to an uneven bed surface. (XY than Z if there is no z lift before it)

Maybe a better approach would be to add a setting to include a configurable amount of z lift before moving to the printing position (right after the start gcode), like a z lift for retraction, but without any retraction.

[foreachthing]

You could use this Post Processing Script: https://github.com/foreachthing/Slic3rPostProcessing/tree/master/SPP-Python

Like so, in Print Settings-> Output Options-> Post-Processing Scripts: C:\Users\USERNAME\AppData\Local\Programs\Python\Python39\python.exe c:\Slic3rPostProcessing\Slic3rPostProcessor.py --xy;

The parameter --xy tells the script to go XY first, then drop on Z. Without this parameter, the printer will go straight (XYZ) to the start point.

Before:

;LAYER_CHANGE
;Z:0.2
;HEIGHT:0.2
;layer:0;
M117 Layer 0;
G1 Z0.200 F7200.000 ; move to next layer (0)
G1 E-6.00000 F3000.000 ; retract
G92 E0 ; reset extrusion distance
G1 X106.311 Y96.324 F7200.000 ; move to first skirt point
G1 E6.00000 F3000.000 ; unretract
;TYPE:Skirt
;WIDTH:0.5
G1 F1800.000
G1 X107.362 Y96.129 E6.01532 ; skirt
G1 X117.414 Y96.631 E6.15955 ; skirt

After:

;LAYER_CHANGE
;Z:0.2
;HEIGHT:0.2
;layer:0;
M117 Layer 0;
; G1 Z0.200 F7200.000 ; move to next layer (0) ; REMOVED by PostProcessing Script:
G1 E-6.00000 F3000.000 ; retract
G92 E0 ; reset extrusion distance
G1 X106.311 Y96.324 F7200.000 ; just XY - added by PostProcessing Script
G1 Z2.0 F7200.000 ; Then Z2.0 at normal speed - added by PostProcessing Script
G1 Z0.2 F3600.0 ; Then to firt layer height at half the speed - added by PostProcessing Script
G1 E6.00000 F3000.000 ; unretract
;TYPE:Skirt
;WIDTH:0.5
G1 F1800.000
G1 X107.362 Y96.129 E6.01532 ; skirt
G1 X117.414 Y96.631 E6.15955 ; skirt

[bubnikv]

I cannot make sense of what you are trying to achieve. You want the printer to travel in XY at print head Z=0?

[qwewer0]

@foreachthing Your shared post processed code moves the XY axis before any Z lift, so the nozzle could move at Z=0 and potentially scrape the bed, which was my initial problem on https://github.com/prusa3d/PrusaSlicer/issues/4065. I know that we can do a lot of things with post processing, but the main goal would be to make (vanilla) PS better and safer.

If the changed starting move order isn't acceptable to all, then maybe the best option would be to add a "Z lift before first layer" or "Raise before first layer" check box with a customizable value for the lift height (min. layer_height*2(?), max. max_print_height). By selecting the feature, (in the produced gcode) there would be a Z rise before the initial XY movement, then the Z movement to the first layer.

@bubnikv What do you think about this approach?

As an example: Before:

G1 Z0.200 F9000.000
G1 E-5.00000 F3600.000
G92 E0
G1 X103.943 Y102.354 F9000.000
G1 E5.00000 F2400.000
;TYPE:Skirt

After:

G1 Z5.000 F9000.000
G1 E-5.00000 F3600.000
G92 E0
G1 X103.943 Y102.354 F9000.000
G1 Z0.200 F9000.000
G1 E5.00000 F2400.000
;TYPE:Skirt

(Maybe the retraction should be before the z movement, not sure...)

[foreachthing]

Well, the code above is not complete!

I got an Ultimaker 2. So, my start gcode is as following: First, home axis, then move the nozzle to X=1, Y=6, Z=35. Then finish heating and ooze a bit of filament. Then, move in XY to the first startpoint (at Z=35), then drop to Z={first_layer_height}. I even "improved" my python script a bit, where the nozzle drops to Z=+2 mm at normal speed, then to first layer height at half that speed.

Compare the files attached: pps_before.gcode.txt pps_after.gcode.txt

Left: before post processing script. Right: after post processing script

I don't know if you know the UM2 .. there are clips on the glass plate to secure it. So, with the standard start sequence of PS, it can, will and has happend that the nozzle will crash into the first clip. Because of that, I need to make sure my nozzle is as far away from that clip as possible (and for other reasons, like unlevel bed, etc.). But, to ooze, I want to be right above the clip. That way the oozed material can catch on that clip and doesn't get dragged across the plate.

[agvol]

I cannot make sense of what you are trying to achieve. You want the printer to travel in XY at print head Z=0?

No, I want to insert some code(with intro line, etc) into start section. This code contain G-CODE commands for moving along the Z axis. As a result, my part of the code ends up lifting the print head, but the code from the slicer returns the print head to the bed and makes the move very low to the start position.

[bubnikv]

@agvol If you have Z-lift enabled for layer change, then the Z-hop is performed when the slicer moves the print head to the 1st layer. For our MK2 profiles the first move is Z up to 0.4mm.

@foreachthing ok I understand your thinking. But then there is a risk that the print head may crash into the clips any time after the 1st move during normal printing if you place your object between the clips, right? It may not be the case with "avoid crossing perimeters" disabled, but with "avoid crossing perimeters" enabled, the print head may try to avoid the objects thus bumping into the clips. Thus the only safe option for you is to shrink the working space rectangle.

@foreachthing I understand your request now, however the problem is that the initial Z height would have to be delivered to the PrusaSlicer slicing engine someho, for example PrusaSlicer would have to parse and understand the custom start block to understand the Z height. That is doable, but it would basically require to process the G-code glued together from custom G-code blocks with the firmware simulator. We have the simulator for calculating print time estimates, so it is technically doable, but it is not an one liner.

[foreachthing]

@bubnikv, no. No I'd never crash into the clips (if the arrange would work better with custom bed shape), because then I could do this:

Right now I have to do this and keep out of the red areas (manually):

So, to avoid those clips, I made that post processing script and it works great. And after a few layers (maybe 5 mm) I technically could print over the clips.

View on print bed: Image from https://www.youmagine.com/uploads/image/file/157197/span4_SuperNeoTkoE3d-pic-002.jpg.

But it would make sense (from my point of view) to integrate that "cura-move" into PS. There is no drawback if you ask me.

I don't think you need to know the start block, since I only change these few lines after the start block (well after '# # # end header').

[bubnikv]

But it would make sense (from my point of view) to integrate that "cura-move" into PS. There is no drawback if you ask me.

It may make sense to do the "cura" move, I have to think about it. It would mean to adapt all the start G-code blocks for a Z up move, otherwise somebody's print bed could get scarred with the straight line movement from Z=0 to Z=first layer height while traveling to the start of the skirt. For us (PrusaResearch) we know that such change would not break anything and we can force users to update their profiles after PrusaSlicer update, but we may break some other user's expectation. We can always add a new configuration value to enable the "cura move", but if we can do without that, I would be happier.

pá 26. 2. 2021 v 10:21 odesílatel Gilbert notifications@github.com napsal:

@bubnikv https://github.com/bubnikv, no. No I'd never crash into the clips (if the arrange would work better with custom bed shape), because then I could do this: [image: image] https://user-images.githubusercontent.com/10420187/109279851-8b827e80-781a-11eb-9ad3-cf62f9dcf385.png

Right now I have to do this and keep out of the red areas (manually): [image: image] https://user-images.githubusercontent.com/10420187/109279879-94735000-781a-11eb-82b1-1dc7b6df7072.png

So, to avoid those clips, I made that post processing script and it works great. And after a few layers (maybe 5 mm) I technically could print over the clips.

View on print bed: [image: image] https://user-images.githubusercontent.com/10420187/109281216-524b0e00-781c-11eb-816f-83fcbda889b3.png Image from https://www.youmagine.com/uploads/image/file/157197/span4_SuperNeoTkoE3d-pic-002.jpg .

But it would make sense (from my point of view) to integrate that "cura-move" into PS. There is no drawback if you ask me.

I don't think you need to know the start block, since I only change these few lines after the start block (well after '# # # end header').

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2931#issuecomment-786520302, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI3I4UOS35LGLKKJO5TTA5RZXANCNFSM4IXGDI5A .