Cura: [4.1 - current master branch] Z feed rates

[paukstelis]

Application Version
4.1, master branch

Platform
Linux
Printer
Any

I notice that I am getting extremely high feed rates for Z movements using a custom printer profile. Not sure where this number is coming from, but you can see here:

G1 X72.995 Y123.541 E6.714
G1 X73.207 Y123.395 E6.71884
G1 F1500 E5.91884
G1 F17987547480000 Z0.7
;MESH:3DBenchy.stl
G0 F3600 X92.737 Y133.777 Z0.7
;TYPE:WALL-INNER
G1 F17987547480000 Z0.3
G1 F1500 E6.71884
G1 F1800 X92.721 Y133.778 E6.71914

This causes the printer to reset.

[smartavionics]

I expect it was 86336591652d82ac53d1044080145c6ddc36f732 that has caused this.

[smartavionics]

As a workaround, install the printer settings plugin and then you can set sensible values for the max x/y/z feedrates.

[paukstelis]

I've found setting Max Z Speed under Travel also fixes this.

[Ghostkeeper]

Yes, that feedrate of 17987547480000mm/min is exactly light speed. The setting is used as default for the Z hop speed. I'd expect the jerk and acceleration to limit it though. Maybe the firmware is just not able to store such high numbers? Maybe we should fix it by introducing a Z hop speed setting?

[alfrix]

i just encountered this, i suspect the atmega dislikes this unusual high value and probably is the reason why it stops and then resumes after a couple of seconds

[chiefcw]

I found that if the maximum z-axis speed is left at zero Cura sends G1 F17987547480000 to Marlin on z-moves which resulted in the z-axis moving extremely slow. When changed to 5 in Cura it then sent G1 F300 in the gcode. It prints normally now.

[kevquinn]

This issue caused me a fair bit of worry until finally figuring out the nasty grinding noise on my Z motor (Marlin 1.1.9 on an Ender 3) after upgrading to 4.1 was due to a ridiculous number being used for the feed rate on Z hops, and then finding this ticket.

FWIW I have this in my Marlin configuration:

define DEFAULT_MAX_FEEDRATE { 2500, 2500, 100, 25 }

so I don't know why the printer firmware didn't override.

I've set a max z speed now in my Cura settings which is fine as far as it goes - however if the internal Cura default is now ridiculous-speed and the maximum z speed is zero, I think Cura should throw a warning to the unsuspecting user.

(maybe profiles delivered with 4.1 already have a max z speed set, but I imagine I'm not alone in bringing forward configurations that didn't)

[kevquinn]

I think Cura should throw a warning to the unsuspecting user.

A little more thought - a better approach could be to simply skip setting the feed rate when user hasn't provided a value (i.e. when the value has been defaulted by Cura).

And/or add an explicit field for setting the Z-hop speed.

[lorak41]

So what is the best fix for that? Search and replace script?

[alfrix]

in the meantime set "Maximum z speed" to something reasonable like 5 mm/s

until the devs decide upon reverting 8633659 or something else

[drdeimos]

This "bug" also still in release 4.1 version of cura.

[jensravesloot]

I can confirm that this bug is indeed still in the newest Cura 4.1. Today I installed this new Cura and my printer started to act very strange. After some troubleshooting I found that the Z feed rate was F17987547480000 which caused my printer to 'crash' when any G1 Z command was given. When setting a maximum z speed of 5 mm/s all issues were fixed.

[shadowkrazee]

I am seeing this same issue with my tevo tornado on win10 64 bit, switched back to 4.0 today, sliced the same file with the same profile, and the issue is gone.

[alfrix]

4.1 also does this insanity!!!

an m203 ? why? this is insane

[mjf55]

While looking in the fdmprinter.def.json file for the feed rates, I found that the default value for x,y,z is set to 299792458000, so it is probably a good idea to set you own max rate in your profile.

[smartavionics]

an m203 ? why? this is insane

At the end of the print, Cura tries to restore various printer parameters to what it believes is their previous values. To stop this happening I think you need to set machine_max_feedrate_z to a sensible value. You can do that by either editing the machine definition and reloading the machine or by installing the printer settings plugin and editing the value in the GUI.

[dont4u]

While looking in the fdmprinter.def.json file for the feed rates, I found that the default value for x,y,z is set to 299792458000, so it is probably a good idea to set you own max rate in your profile.

RIGHT..!

[Asho777]

I see this problem in almost every 3D Printing FB group I'm in. Notified Ultimaker about it, said that there is no support for 3rd party printers....fair enough. So they suggested to come here, and bring up the issue! Well it appears that it is a well know issue here, so has any of the Ultimaker developers here to see and address the issue? I myself does not have the issue as I normally do not use Z hop. I have suggested to users of the groups to ensure you make your setting for the Maximum Z Speed 15mm/sec. This seems to fix the problem with most Creality printers!

[Ghostkeeper]

Yeah I see this issue as a blocker (imo) for the next release. There is no chance that there will be a 4.1.1 release for this issue though. But we'll fix it for the next release.

[zaventh]

Setting a max z speed of 5 mm/s in Cura wasn't enough for my Prusa clone. The z-axis movements were still very fast and erratic. Slices on Cura 3.x do not exhibit this issue.

[nallath]

This has been fixed in master, so it will be in the 4.2 release.

[Ghostkeeper]

Setting a max z speed of 5 mm/s in Cura wasn't enough for my Prusa clone. The z-axis movements were still very fast and erratic. Slices on Cura 3.x do not exhibit this issue.

In that case your bug probably wasn't fixed. Do you have a project file that you can share?

[commo81]

I found that if the maximum z-axis speed is left at zero Cura sends G1 F17987547480000 to Marlin on z-moves which resulted in the z-axis moving extremely slow. When changed to 5 in Cura it then sent G1 F300 in the gcode. It prints normally now.

Forgive me for being a total noob to this, but where do I change this Z setting? My Ender 3 Pro is doing the same thing it prints a little then pauses then prints then pauses.
http://www.mediafire.com/file/8gof17uptdsf5p7/Ender3Pro_Pause_issue.mp4/file
There's a video on it. I've only been using this for about 2 months, but it started doing this after the last cura update. my 14 hour print turned into 16 hours because of it.

[chiefcw]

I found that if the maximum z-axis speed is left at zero Cura sends G1 F17987547480000 to Marlin on z-moves which resulted in the z-axis moving extremely slow. When changed to 5 in Cura it then sent G1 F300 in the gcode. It prints normally now.

Forgive me for being a total noob to this, but where do I change this Z setting? My Ender 3 Pro is doing the same thing it prints a little then pauses then prints then pauses.
http://www.mediafire.com/file/8gof17uptdsf5p7/Ender3Pro_Pause_issue.mp4/file
There's a video on it. I've only been using this for about 2 months, but it started doing this after the last cura update. my 14 hour print turned into 16 hours because of it.

Just put a "z" in the search settings box, under the "Speed" heading you will find the "Maximum Z Speed" setting.

[commo81]

I found that if the maximum z-axis speed is left at zero Cura sends G1 F17987547480000 to Marlin on z-moves which resulted in the z-axis moving extremely slow. When changed to 5 in Cura it then sent G1 F300 in the gcode. It prints normally now.

Forgive me for being a total noob to this, but where do I change this Z setting? My Ender 3 Pro is doing the same thing it prints a little then pauses then prints then pauses.
http://www.mediafire.com/file/8gof17uptdsf5p7/Ender3Pro_Pause_issue.mp4/file
There's a video on it. I've only been using this for about 2 months, but it started doing this after the last cura update. my 14 hour print turned into 16 hours because of it.

Just put a "z" in the search settings box, under the "Speed" heading you will find the "Maximum Z Speed" setting.

Thanks. I set it to 15 for now, will retest later with a print and if it still acts up, I'll try 5. I appreciate the help!

[commo81]

Setting it to 15 worked for me and resolved the issue. thank you for the help.

[reloxx13]

I see this problem in almost every 3D Printing FB group I'm in. Notified Ultimaker about it, said that there is no support for 3rd party printers....fair enough. So they suggested to come here, and bring up the issue! Well it appears that it is a well know issue here, so has any of the Ultimaker developers here to see and address the issue? I myself does not have the issue as I normally do not use Z hop. I have suggested to users of the groups to ensure you make your setting for the Maximum Z Speed 15mm/sec. This seems to fix the problem with most Creality printers!

yeah, with the community... i loled

so we got a bunch of community users with 4.1 posting on gh and fb that their printers wont work for the next 1-2 month till 4.2.

[kevquinn]

yeah, with the community... i loled

And then you noticed they had indeed already merged a fix. Your snark is misplaced, as I suspect you know, and would be better directed at the manufacturers who ship old forks of Cura for nothing without contributing to its maintenance here.

[smartavionics]

And then you noticed they had indeed already merged a fix.

The fix that has arrived on the master branch may not be sufficient to stop the bug reports. Let's see what happens with 4.2.

[Ghostkeeper]

Yeah we're still discussing what to do with resetting the maximum Z speed after the print is done. It gets reset to whatever Cura thinks that the default maximum Z speed is in the firmware, but we just don't have information about that, for some printers. I'm doing my best to get it done for 4.2.

[commo81]

How come 4.0 worked perfectly fine with my ender 3 pro and 4.1 sets the Z speed to 0 by default? What had changed? I was reading that others had no issue with 4.0 and reverted back to 4.0, so something in the last update had to affect it. Just saying maybe if 4.0 was looked at and compared to 4.1 a solution could be found to this issue. I manually set Z speed to 15 and I'm fine but I have to admit its pretty annoying doing it every time. Just wanted to point out that maybe if both versions were compared, the problem could be located and found. If I can help provide info, please let me know but I am also running TH3D unified firmware on my E3 pro since I have the ezabl. Even with their firmware I was affected by the issue. Where does one look in the firmware for the Max Z speed set in the firmware?

[Ghostkeeper]

How come 4.0 worked perfectly fine with my ender 3 pro and 4.1 sets the Z speed to 0 by default? What had changed?

The reason is that we try to introduce at least 3 bugs with every release in order to keep the Github page a bit active.

But no, this issue is a side effect of the fix for https://github.com/Ultimaker/Cura/issues/5640. The machine setting is used as a limit for a dozen or so settings that shouldn't be limited if Cura has no knowledge about the printer's limits. What we didn't think of was that the setting was also used for Z hops. It's not in the setting name or description so it was a bit illogical that way.

Just saying maybe if 4.0 was looked at and compared to 4.1 a solution could be found to this issue.

Yeah we did that and have a solution. As you can see, this issue is closed now.

Where does one look in the firmware for the Max Z speed set in the firmware?

The Marlin configuration has a macro for DEFAULT_MAX_FEEDRATE which is a 4D (XYZE) vector that indicates maximum feedrate for every axis. The 3rd entry is the Z speed. I don't know how TH3D firmware relates to that.

[baxi69]

And then you noticed they had indeed already merged a fix.

The fix that has arrived on the master branch may not be sufficient to stop the bug reports. Let's see what happens with 4.2.

Can you pls give a link to the master AppImage?

[smartavionics]

I can give you a link to my builds which are based on the master branch + my own mods. Please take a look at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0
There's a README.md file in there that provides some info as to what the differences are.

[Ghostkeeper]

Here is a daily bleeding-edge build of what will eventually become 4.2. Keep in mind it's unstable:
http://dulek.net/work/Cura-4.2.99-master.20190620014544.AppImage

[sk8nfool]

The tool tip for the max z speed says that if it's set to zero the printer's firmware default is used. This implies either an M503 (report settings) is sent or the information is extracted from the initial report sent when the printer is initially connected. This isn't the case. The max z speed is internally set to light speed regardless.

Cura the takes the max Z value and wraps this up with an M203 command directly. This effectively multiplies the value specified my 60! Either the label in the max Z box needs to be changed or the value given must be divided by 60 when it's wrapped into the M203 command.

Also Cura 4.1 tries to reset the printer to what it thinks is the firmware setting but since it didn't do that right it sets the speed "back" to light speed.
This doesn't deal with the fact that Marlin is a bit confused about units. The M203 command (used to set the default speeds) in in units/minute but the per-command speed values are in units/second.

[Ghostkeeper]

Stuff like M503 will not work if you're printing via any other method than a serial cable. Cura works with pre-generated g-code so the g-code will not adjust based on what the printer outputs through a serial port.

[sk8nfool]

In either case the tooltip and reality don't match. The tooltip claims entering 0 causes Cura to use the firmware setting. It doesn't. It uses light speed.
And since the slicer is generating G-code why can't it use M503? What other protocols are supported?

[Ghostkeeper]

In either case the tooltip and reality don't match. The tooltip claims entering 0 causes Cura to use the firmware setting. It doesn't. It uses light speed.

Please note that this issue has been fixed for the next version.

And since the slicer is generating G-code why can't it use M503?

Because most users of Cura store the g-code on disk or on a USB stick and put it in their printer later, even while Cura is not running. People don't have their printer connected via USB cable. Cura can put M503 in the g-code but there is nobody to listen when then printer outputs its settings, so it makes no difference.

[sk8nfool]

Ok - That presents a real problem. The G-code is tailored to a specific
printer that may not be available to query at slicing time. This still
doesn't make the tooltip correct. If the printer isn't present the Cura
should NOT specify the max speed but leave that to the printer when the
G-code is sent. You can't tell the future without a crystal ball so setting
the max speed in the G-code to light speed doesn't make sense and makes the
tooltip very misleading.

And yes - I know you have said this is fixed in the next release (4.2.x?)
but you haven't said how it's been fixed.

On Wed, Jun 26, 2019 at 2:16 AM Ghostkeeper [e-mail]
wrote:

In either case the tooltip and reality don't match. The tooltip claims
entering 0 causes Cura to use the firmware setting. It doesn't. It uses
light speed.

Please note that this issue has been fixed for the next version.

And since the slicer is generating G-code why can't it use M503?

Because most users of Cura store the g-code on disk or on a USB stick and
put it in their printer later, even while Cura is not running. People don't
have their printer connected via USB cable. Cura can put M503 in the g-code
but there is nobody to listen when then printer outputs its settings, so it
makes no difference.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/5753?email_source=notifications&email_token=AC3TLCT34ZHXZNXCWVHCH7DP4MCVRA5CNFSM4HN3J432YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYSORUQ#issuecomment-505735378,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC3TLCQU5U6RQG3GBTMIRDLP4MCVRANCNFSM4HN3J43Q
.

[smartavionics]

As mentioned earlier in this thread, the current fix still leaves the possibility of upset printers as at the end of the print it could output this:

M203 Z299792458000

[AbeFM]

Lies. :-P

I thought that was funny.
It looks like everyone's good and aware of it, but the tooltip adds credence to the earlier comment about just letting the printer's hardware make that decision. :-)

I heard about the work-around (could you put THAT in the tooltip?) and am merrily back in business. Thanks folks!

[Ghostkeeper]

We can't put that in the tooltip any more since the setting is gone in 4.2.

[AbeFM]

Ah! Guess I should get on the 4.2 train. Thanks again for the attentive feedback!