Closed martinbudden closed 3 years ago
Do you think it has any consequences on a print profile? Isn't it more useful on the printer machine limits tab?
@supermerill Hi! I'm not the TS but we just had a discussion about this issue and I'm willing to let you know what I've found. Here's a fragment of code generated by slic3r++, actually prusa does exactly the same:
;LAYER_CHANGE
;Z:0.2
;HEIGHT:0.2
; custom gcode: before_layer_gcode
;LAYER:0
M117 INDICATOR-Layer0
; custom gcode end: before_layer_gcode
G1 Z0.200000 F7200.000 ; move to next layer (0)
(see the last line)
Perhaps G1 Z0.200000 F7200.000
is really not very beautiful. Although I'm perfectly fine with the superslicer's gcode, my printer's firmware ignores velocities greater than upper limit of my printer.
Maybe instead of using travel_speed
for Z velocity you could use machine_max_feedrate_z
?
Maybe instead of using travel_speed for Z velocity you could use
machine_max_feedrate_z
?
Maybe, or i can create a machine_z_travel_speed
next to it.
I'll have to see if it's useful to create an other one. I have some 3D-path that may want to use a slow machine_max_feedrate_z
, and travel that want to use a fast machine_z_travel_speed
I'm using klipper (and it ignores 120mm/s on z movements), but probably some firmwares may not ignore it.
Sorry the delay in replying.
Maybe instead of using travel_speed for Z velocity you could use
machine_max_feedrate_z
?
That was my initial idea, however, from the (limited) discussion on the PrusaSlicer fork, there seemed a reluctance to use machine_max_feedrate_z
for this purpose.
Also, machine_max_feedrate_z
is not directly accessible by GCodeWriter
, so it would certainly be a more complicated PR to do it this way.
My feeling is that an additional option of travel_speed_z
is more likely to get accepted as a PR for the PrusaSlicer.
Note that Marlin (unlike Klipper, it seems) definitely does not honour the value of machine_max_feedrate_z
, so the z feedrate does need to be limited by the slicer.
I'm ok for a pr to add travel_speed_z
OK, I'll get my PR from PrucaSlicer moved over here.
Shouldn't this be closed now?
This is the same bug as https://github.com/prusa3d/PrusaSlicer/issues/2945 for which I have submitted a PR in PrusaSlicer , but not had a reply.
Describe the bug The z travel speed is the same as the xy travel speed, so when the xy travel speed is high, you get z-banding or even z-axis skipping.
I have a fix for this and so this bug report is just to see if you are interested in the fix - if so I will submit the PR. I'm also happy to submit it for review without any expectation that it will be accepted.
For reference, the PrusaSlicer PR is here https://github.com/prusa3d/PrusaSlicer/pull/6369