[4.2] Slicing fails because of zhop speed

[Liger0]

Application version
4.2

Platform
Win10 x64

Printer
Dual extrusion

Reproduction steps
Try to import my profile (done in a previous cura version) into cura 4.2 using a dual extrusion machine.
Any attemp to import the profile into a single extrusion machine will fail because of #6083.

Actual results
The slicing will fail because of a "wrong" zhop speed (which is set to 10mm/s).

Expected results
It should work. I have no idea why the 10mm/s are marked in red.

Additional information

PLA 0.4mm + PVA 0.5mm 0.16LH brass.zip

[nallath]

Because the machine states that 5 is the maximum value it can handle.

[Liger0]

Oh I see. Wouldn't it make sense to add a button to revert to Z maximum value?

[Alaric323]

This isn't the case. I also get this bug, but only when support is enabled. Setting Zhop to 5 makes slicing fail with the same message of "the following settings have errors", but then leave the settings area blank.

Disabling support lets it slice fine, regardless of zhop speed.

[lordpreto]

#6073

[atmora77]

same issue here ..................... FUCK

[AtHeartEngineer]

Same issue, mac OSx Mojave and Ender 3 Pro. Can't seem to get it to slice with support enabled at all.

[smartavionics]

People, a workaround for this issue is to install the printer settings plugin from the marketplace and then increase the max z speed value to 10 (or more). It should then be able to slice without barfing.

[DocYester]

and what about errors with no information , after fixing the z-hop , retraction prime speed and so on ?!

any workaround for them ?!

[smartavionics]

So you have set the z hop speed and the max z speed both to be >= 10 and you still get that message?

[DocYester]

yep, only when support is enabled , at my own and at the standardprofiles

[smartavionics]

And if support is not enabled, it slices and doesn't show the error?

Please save that project file (File -> Save), and zip up the resulting file and attach to this thread so I can take a look. Thanks.

[DocYester]

classic reinstall helped just a sec ago ... made a clean install of cura and reimported my profiles , then ran through the settings for "z hop speed" and "max z speed" -> 50
restarted cura
then it sliced with and without support

[smartavionics]

OK, well, that's at least something.

I haven't a clue why enabling support causes a problem. As I suggested in my original issue #6073, I think there's a problem related to the z-hop speed being settable per-extruder but as I don't really understand how any of the front end configuration stuff works, I have not delved into it further. Leave that to the Cura devs.

[plazmax]

same here ender 3 doesnt solve with giving 5 or 1-5, and with printer settings plugin we need to wait cura devs.

[smartavionics]

same here ender 3 doesnt solve with giving 5 or 1-5

You need to set a value of 10 or more for both the z hop speed and the max z speed.

[plazmax]

same here ender 3 doesnt solve with giving 5 or 1-5

You need to set a value of 10 or more for both the z hop speed and the max z speed.

yep but with z hop and without z hop 0-100 not working both options

[smartavionics]

And do you have support enabled? Some people have said that they can slice without support but not with and @DocYester above says a reinstall followed by setting the max z speed and z hop speed solved the problem.

[plazmax]

i can slice without support and tree support but cant slice with support, ill try remove all clean install

[smartavionics]

I'm leaving this thread. Good luck!

[atmora77]

The devs are not able that test himself the deployment update is just ridiculous
A slicer that not slice LOOOOOOOOL. A car that not drive. A plane that not fly the same

[Liger0]

That's not a dev problem.. I'd say the problem is they rush way too much the release after the beta. There should be a bigger gap between beta and final release to leave devs time to fix those major bugs and people to report them, in my opinion.
To me, the latest working cura has been 3.4.1.
After that, each version fixed some minor bugs on the previous version, but introduced new bugs which each time broke more things than the old ones. So at each version it always became less usable.
They literally release a new version with untested features and the bugs accumulate.
With this 4.2 I am also getting completely random crashes...

[Ghostkeeper]

I guess it's useful to give some insight in our workflow and why this went wrong.

The developers do test each feature. They go through 3 or 4 layers of testing, depending on what you count. First the developers test them, then Cura's QA team tests them. Then a system/integration team tests them. Then it goes out to beta where users can test them.

• The developers test them in their development environment.
• The QA team tests the builds.
• The System/Integration team tests the workflow in general (not aimed at specific features any more).
• Beta users test basically everything. We get very varied bug reports.

The problem here is not with features though. It's a profile for a printer. One setting says that the Z hop speed must be 10. Another says that the maximum speed for Z movements is 5. Our workflow is like this:

• We accept these profiles from the community because they say that they work well. In this case the CreawsomeMod was immensely popular, as we saw by crash reports from 4.1 because the mod overwrote some of the QML files in Cura's actual installation.
• We run through the profile changes (the text files) to see if they make sense. Individually, the two profile changes make sense fine. Though a maximum Z speed of 5mm/s is admittedly a bit low, but okay for cheaper printers that may well be the case.
• We make a basic slice with these settings. This didn't catch the error because we didn't enable support for that slice, purely default settings.
• We release the beta. Apparently the 6.000 users that downloaded the beta this time didn't find it. Though actually one of them did but it was closed when it was deemed to not be an issue after all (and reopened due to bug reports after the stable release).
• When the beta is released we gave an assignment to volunteer testers to specifically test 3 calibration prints on whether anything broke. One of those volunteers has an Ender 3. One of those calibration prints contains supports so that should've found it too. We got a very detailed report from that tester about how printing time was slowed down by 23% or so, but final part quality was improved, so we thought that was okay. I still don't know why the bug wasn't found there, so we'll need to find that out. Human error, perhaps?

To me it seems like a perfect storm of circumstances here 😭 There have been so many points in this process at which it should've been discovered but wasn't. That's very frustrating.

We've had 2 week beta periods at basically every release since 2.5. Before that we had a slower release cycle. The only exception was at Cura 4.0, which was delayed a while due to the release of a new firmware version for Ultimaker printers that enabled support for Cloud printing. I've tried to argue that it should be 3 because that's easier for the translators as well, but mostly because of the System/Integration testing layer that wasn't feasible; we'd need to go into feature freeze like 4 weeks after every release and that's not enough time to develop some of these features. Having a slower release cycle is not desirable either for a multitude of reasons, one of which is that we've had great response from the community about our current release cycle before.

[Ghostkeeper]

Fixed here: 1d7f2e6

We're probably going to release a 4.2.1 today because of this issue and the related #6091.

[Liger0]

With all these critical issues caused by the creawsome mod implementation, I don't think releasing a 4.2.1 would be a good idea, unless you revert back to previous cura profiles which at least had a good base profile.
#6082
#6083
#6100

[nallath]

#6083 Is actually a feature request
#6082 Is probably intended behavior (it was overridden in your profile)
#6100 Is intentional; It basically means that there are no pre-defined profiles for those materials. That makes total sense since those are materials that are customly added by you (and thus don't have a pre-defined quality available)

[shawe]

I guess it's useful to give some insight in our workflow and why this went wrong.

The developers do test each feature. They go through 3 or 4 layers of testing, depending on what you count. First the developers test them, then Cura's QA team tests them. Then a system/integration team tests them. Then it goes out to beta where users can test them.

• The developers test them in their development environment.
• The QA team tests the builds.
• The System/Integration team tests the workflow in general (not aimed at specific features any more).
• Beta users test basically everything. We get very varied bug reports.

The problem here is not with features though. It's a profile for a printer. One setting says that the Z hop speed must be 10. Another says that the maximum speed for Z movements is 5. Our workflow is like this:

• We accept these profiles from the community because they say that they work well. In this case the CreawsomeMod was immensely popular, as we saw by crash reports from 4.1 because the mod overwrote some of the QML files in Cura's actual installation.
• We run through the profile changes (the text files) to see if they make sense. Individually, the two profile changes make sense fine. Though a maximum Z speed of 5mm/s is admittedly a bit low, but okay for cheaper printers that may well be the case.
• We make a basic slice with these settings. This didn't catch the error because we didn't enable support for that slice, purely default settings.
• We release the beta. Apparently the 6.000 users that downloaded the beta this time didn't find it. Though actually one of them did but it was closed when it was deemed to not be an issue after all (and reopened due to bug reports after the stable release).
• When the beta is released we gave an assignment to volunteer testers to specifically test 3 calibration prints on whether anything broke. One of those volunteers has an Ender 3. One of those calibration prints contains supports so that should've found it too. We got a very detailed report from that tester about how printing time was slowed down by 23% or so, but final part quality was improved, so we thought that was okay. I still don't know why the bug wasn't found there, so we'll need to find that out. Human error, perhaps?

To me it seems like a perfect storm of circumstances here There have been so many points in this process at which it should've been discovered but wasn't. That's very frustrating.

We've had 2 week beta periods at basically every release since 2.5. Before that we had a slower release cycle. The only exception was at Cura 4.0, which was delayed a while due to the release of a new firmware version for Ultimaker printers that enabled support for Cloud printing. I've tried to argue that it should be 3 because that's easier for the translators as well, but mostly because of the System/Integration testing layer that wasn't feasible; we'd need to go into feature freeze like 4 weeks after every release and that's not enough time to develop some of these features. Having a slower release cycle is not desirable either for a multitude of reasons, one of which is that we've had great response from the community about our current release cycle before.

I started last week 3D printing without issues, but now I have the same problem described here, any suggestion to try to solve it? In my case the value for z hoop to 5 or 10 is causing the same problem because is not auto-generating supports. Only two piece were rendered with supports, are only one printed with supports. An never again works this.

If any devs need it, I can give you access to my PC to try to get some useful details about this.

EDIT 1: I try deleting the config files on Linux: https://github.com/Ultimaker/Cura/wiki/Cura-Preferences-and-Settings-Locations#linux but problem still persists and seems to store some config in another place because start/end gcode are filled with some custom values that I add.

EDIT 2: For me this file is causing the problem, maybe anyone else can reproduce it with it, before some tries I was able to generate a preview but using "Tree support" in Experimental section and with "Generate support" disabled. For me is the only way to continue at this time, but wasting a lot more material.
FilamentGuide_top_V5_for_CR-10_Ender3.zip

[Ghostkeeper]

I started last week 3D printing without issues, but now I have the same problem described here, any suggestion to try to solve it? In my case the value for z hoop to 5 or 10 is causing the same problem because is not auto-generating supports. Only two piece were rendered with supports, are only one printed with supports. An never again works this.

I have a couple of questions for you then:

• Which version of Cura are you using? This issue was fixed in version 4.2.1.
• Could you try saving a project file for us and uploading that here? You can save a project file by going to File -> Save... The resulting file needs to be zipped in order for Github to accept it. With this project file we can reproduce the exact settings and model. Your .zip file only contains the STL model and doesn't influence whether or not a slice can start.
• Did you close Cura before deleting the config files? If Cura is open, there is indeed some config in another place: In memory of Cura, and it'll restore it when closing Cura.

[shawe]

I started last week 3D printing without issues, but now I have the same problem described here, any suggestion to try to solve it? In my case the value for z hoop to 5 or 10 is causing the same problem because is not auto-generating supports. Only two piece were rendered with supports, are only one printed with supports. An never again works this.

I have a couple of questions for you then:

• Which version of Cura are you using? This issue was fixed in version 4.2.1.
• Could you try saving a project file for us and uploading that here? You can save a project file by going to File -> Save... The resulting file needs to be zipped in order for Github to accept it. With this project file we can reproduce the exact settings and model. Your .zip file only contains the STL model and doesn't influence whether or not a slice can start.
• Did you close Cura before deleting the config files? If Cura is open, there is indeed some config in another place: In memory of Cura, and it'll restore it when closing Cura.

Thanks for your interest.

• Versión is 4.2.0-PPA, I must try it with latest version after this message.
• This is the problematic file on this old version
  CE3_FilamentGuide_top_V5_for_CR-10_Ender3-Z-Hoop-Speed.zip, I'm downloading new version to try it again with 4.3.0.
• Yes, Cura was closed, and for this reason I was advicing about this. Maybe was an instance of cura freezed/hanged in memory because on weekend I was watching some big STLs at same time and system has some blocks to not have enough resources. I think this is no so important, because I only found start/end gcode that I was trying to fill when I detected that is yet filled it.

EDIT: Yes, I can confirm that this version solves this issue and also generates the slider preview more faster than before. And without tree supports waste less material than with previous print.

Thanks for your help @Ghostkeeper and sorry to not ensure before if I was using the latest version.

@thopiekar can you update your Ubuntu PPA repo with the latest version, please? Maybe more users can arrive here re-opening this thread like me for using and older version.