Z Hop speed being used for layer change speed even when hop off

[hayden-t]

Application Version

4.8-4.13.1

Platform

Win 7

Printer

Ender 3 S1 Pro

Reproduction steps

Slice a project with Z hop off, noting current Z hop speed setting

Actual results

Z hop speed is still being applied to the layer change height, in this case 10mm/s (F600)

G0 F600 X55.845 Y138.749 Z0.96

G0 F15000 X55.763 Y138.831
G1 F3000 X55.845 Y138.749 E456.87983
G1 F2400 E456.07983
;MESH:NONMESH
G0 F600 X55.845 Y138.749 Z0.96
G0 F15000 X55.41 Y81.578
;TIME_ELAPSED:403.859418
;LAYER:2
;TYPE:WALL-INNER

Expected results

I would expect with Z hop off there would be no speed component to the layer change, as this should be limited by the firmware ? If not Z speed should be visible and labelled as such, i believe from googling there used to be a max z speed but it was taken out.

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

2_size_bottle_opener.zip

[GregValiant]

The Z Hop Speed is the Z travel speed.
In the Creality_base.def.json file in line 135 the Max Z Speed is defined at 50mm/sec. That carries over to your printer as there are no over-rides on the setting in the creality_ender3pro.def.json file (or the Ender 3 for that matter).
In the MarketPlace is the plugin "Printer Settings". Load that plugin and re-start Cura. There are a lot of the normally hidden settings in there including Max Feedrates, Max Accels, and more.
In this case I'm not seeing a bug. It is "expected behavior" but perhaps it could be better explained in the tooltip or by changing the setting name to "Z Travel and Z-Hop Speed".
I'm inclined to change this to an "Improvement" request rather than a bug report. Let me know if you have any thoughts on that.

[hayden-t]

The bug at least is that in 4.8.2 "creality slicer" branded cura (the one i just got with my new 2022 model printer) if z hop is off , z hop travel speed is hidden, which by name makes sense until you work out via investigating other problems that the zhop speed is being used as a z layer speed.
At least with 4.13.1 "cura" cura, z hop speed is visible regardless of z hop setting. But in the tooltip it still only mentions that its just the speed for the z hops.

[GregValiant]

I believe Creality maintains their branch.
It appears that part of the situation has been resolved in Ultimaker Cura by leaving the setting visible. In regards to the ToolTip and Setting Label, sometimes these things happen when English isn't a first language of the people who make up the wording.

I'm going to change this to an "Improvement" as I don't see a bug here. At the default Z Accel of 100mm/sec² the max speed that will be reached in a 0.2mm layer move is 10mm/sec. That would be true even if the Z-hop speed was set to 100mm/sec. There just isn't time to go any faster.

[hayden-t]

So the reason I found this problem is that im using a plugin for octoprint that can cancel objects when doing say 6 at once and one develops a problem so the rest can complete. And the problem is that you have a x y component of your z layer change, which because it is defaulting to F300 or F600, once you have some cancelled object near the layer change the head still has to travel to the layer change spot each cycle, and its doing this at F300 in my case which is very slow and causes major stringing.

paukstelis/Octoprint-Cancelobject#62

Cura should not be using a value assigned for z hop speed as the z travel speed.

[GregValiant]

I understand. When you change the Z-Hop speed in Cura you should see the result in those "Z" travel moves. If you change the Z-Hop speed to 50 then lines like this:
G1 F4500 X95.199 Y172.415 E205.85978
;MESH:NONMESH
G0 F600 X95.199 Y172.415 Z0.2 --->Z-Hop Speed at 10mm/sec
would turn into this:
G1 F4500 X95.199 Y172.415 E205.85978
;MESH:NONMESH
G0 F3000 X95.199 Y172.415 Z0.2 --->Z-Hop Speed at 50mm/sec

A caveat would be that whatever ZMax Feedrate the printer has stored in it's M203 register could be a limiting factor. If your M203 has the Z Max Feedrate at 10mm/sec then that "F3000" would be limited to "F600" by the printer speed limit. In that case the Gcode would be correct but if you were watching the printer to see what happened it would still be going slow.

[hayden-t]

Yes if you read my comments further to bottom of the github issue i posted, i got around the issue by setting zhop speed to 0 which gives me F0 in gcode which luckily my printer ignores and defaults to normal travel speed, alternatively you could set the z hop to desired travel speed as you suggest.