Super slow travel speed

[mruiferreira]

I've updated from cura 4.2 to 4.4 and now when i start printing and the nozzle is travelling from the starting corner to the center of the build plate to start printing, the travel speed is extremely slow you can barely notice the hotend moving at all... downgrading to 4.2.

I am using the same settings i was using on 4.2, checked all speed settings and they are correct. travel speed at 100mm/s but on reality it's less than 1mm/s, i can't even see it moving.

[fieldOfView]

Please fill out the issue template. We are missing vital information to do anything about this, like what printer you use. Also what is your start gcode?

[mruiferreira]

Application version 4.4

Platform Windows 10

Printer Anycubic i3 Mega

Reproduction steps

1. Something you did. Installed cura 4.4 (was using 4.2)

2. Something you did next. Sliced a model without changing any settings

Actual results The travel speed was extremely slow the print head wouldn't even visibly move.

Additional information Downgraded back to 4.2 without changing any settings and the speed is correct in this version.

[smartavionics]

Please save the project file from 4.4 (File -> Save) and zip or rename the .3mf file and attach to this issue, thanks.

[fieldOfView]

Also what is your start gcode?

[Pugnator]

The same issue here, Anycubic i3Mega, the nozzle and the bed move very slow at the very beginning, when hotend and bed are calibrating.Below are the first 70 lines of Gcode I used

;TIME:985
;Filament used: 1.18923m
;Layer height: 0.3
;MINX:65.758
;MINY:20.871
;MINZ:0.2
;MAXX:144.241
;MAXY:189.128
;MAXZ:0.275
;Generated with Cura_SteamEngine 4.4.0
M140 S60
M105
M190 S60
M104 S220
M105
M109 S220
M82 ;absolute extrusion mode
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F100 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F100
G0 Y20 F100
M117 Printing...
G5
G92 E0
G92 E0
G1 F2400 E-6
;LAYER_COUNT:1
;LAYER:0
M107
M204 S3000
M205 X10 Y10
G1 F600 Z0.275
G0 F3000 X66.114 Y24.278 Z0.275
M204 S1800
M205 X8 Y8
;TYPE:SKIRT
G1 F600 Z0.2
G1 F2400 E0
G1 X66.385 Y23.685 E0.04554
G1 X66.727 Y23.13 E0.09107
G1 X67.134 Y22.62 E0.13665
G1 X67.601 Y22.165 E0.18219
G1 X68.119 Y21.77 E0.22769
G1 X68.683 Y21.441 E0.27329
G1 X69.282 Y21.183 E0.31885
G1 X69.908 Y21.001 E0.36438
G1 X70.552 Y20.897 E0.40994
G1 X71.078 Y20.871 E0.44673
G1 X138.921 Y20.871 E5.18531
G1 X139.572 Y20.911 E5.23087
G1 X140.213 Y21.03 E5.2764
G1 X140.835 Y21.227 E5.32197
G1 X141.427 Y21.498 E5.36745
G1 X141.983 Y21.84 E5.41304
G1 X142.492 Y22.248 E5.4586
G1 X142.948 Y22.714 E5.50414
G1 X143.343 Y23.233 E5.5497
G1 X143.671 Y23.796 E5.59521
G1 X143.929 Y24.395 E5.64076
G1 X144.111 Y25.021 E5.6863
G1 X144.215 Y25.665 E5.73186```

[fieldOfView]

Also what is your start gcode?

In other words, what is the text entered in the Start GCode box in Preferences -> Printers -> Machine Settings? This contains some replacement patterns (text between {} curly brackets) which are not visible now. If you show us that Start GCode snippet, we can probably make suggestions how to improve your snippet.

Without having seen the actual Start GCode snippet, I can only guess it is using {speed_print} or {speed_travel} replacement patterns. In Cura, these settings are specified in mm/s, but Marlin needs mm/minute (for reasons, I am sure). So the value that gets put in the gcode may be 60 times lower than what you would expect. If this is the case, hardcoding a saner value may be your only option.

[Pugnator]

G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F{speed_travel} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{speed_travel}
G0 Y20 F{speed_travel}
M117 Printing...
G5```

[fieldOfView]

Looks like this is indeed the mm/s vs mm/min thing. Change all 3 occurrences of F{speed_travel} with F6000.

[Pugnator]

Looks like this is indeed the mm/s vs mm/min thing. Change all 3 occurrences of F{speed_travel} with F6000.

that did the trick, thanks

[Ghostkeeper]

Not sure how we should deal with this bug. Cura is sort of doing what it's expected to do: fill in the value of the setting there. But the user is expecting it to be multiplied by 60 in order to get a correct result.

[Ghostkeeper]

We've decided to defer this. We could make an option to perform mathematics in those replacement keys, like dividing by 60, or we could automatically do the mathematics for the user if we detect it's in an F parameter. But none of it is too important. Hard-coding those speeds in the start g-code works fine enough for now.

[kevquinn]

Tripped over this, having just found that the default start/end g-code for an old printer I pulled out of retirement has "F{speed_travel}" coded into it, which (for Marlin firmware at least) doesn't achieve what the author of that start/end g-code wanted.

38 of the printer definitions have that specific case (as of 4.6.1). I guess it's up to whoever contributed those definitions to sort them out :)

[alxvasilev]

Note that there is inconsistency with the printing speed, which is properly multiplied by 60 (the F parameters of all G1 commands are the value of "Print speed", multiplied by 60). So, it seems somehow Cura is already doing the correction, and I wonder if it would be easily applied to travel speed as well?

[fieldOfView]

it seems somehow Cura is already doing the correction, and I wonder if it would be easily applied to travel speed as well?

Cura does the replacement of {} patterns in start gcode, before handing things over to CuraEngine. CuraEngine knows about G-Code and that all gcode interpreter known to man need feedrates specified in mm/min. CuraEngine is a separate, self-contained part of the application. Cura itself does not try to interpret what you tell it to do, it just does literally what you tell it to do: put the value you configured for the travel speed anywhere you say {speed_travel} in your start gcode.

[Ghostkeeper]

Some people add settings to their g-code header or footer in comments so that they can trace back what settings an experiment was using. In those cases you don't want it to use mm/min:

;Infill density: {infill_sparse_density}%
;Travel speed: {speed_travel}mm/s
;Outer wall speed: {speed_wall_0}mm/s

Cura currently has no idea of whether a speed setting should get multiplied by 60 or not. I think an appropriate way to fix this would be to allow some form of calculations to happen in these tokens.

[github-actions[bot]]

Hi 👋, We are cleaning our list of issues to improve our focus. This bug seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still a problem for you in the current version of Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.

If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale. If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.