Slicing "stalls" in Cura 5.5

[dokcal 0]

I noticed that my slicing takes MUCH longer in Cura 5.5 than Cura 5.4--and in some cases doesn't complete at all!
 

I'm not sure what's behind this--even the same Project file will take longer to slice, with absolutely no changes.

Is 5.5 doing something extra behind the scenes that takes up loads of computing cycles?

[Slashee_the_Cow 275]

No changes that I'm aware of. Seems about as quick as 5.4 to me. Could depend on your system and printer (like I'm guessing it takes more time for an Ultimaker S series since they figured out how to make it print faster).

 

I have experienced a couple of times when it stalls and never finishes, for those I had to switch from tree supports to regular and then it sliced fine.

Edited November 9, 2023 by Slashee_the_Cow

[nubman83 1]

I noticed this too dokcal.  I tried to slice this item:  https://www.printables.com/model/554709-nasa-fabric/files.  It was the 12x16 size and it took about two hours to slice.  I've done bigger and more complex prints and I've never had it take more 5-10 mins.  This was also when I was using version 5.4.  There has to be some new issue with this new software version.  I'm going to try some things on 5.4 tonight and tomorrow to see if I get the same delay/stall again.

[Slashee_the_Cow 275]

@nubman83 the link you provided leads to multiple files - I'm assuming you mean the biggest and most complex one? I downloaded that and shrank it to fit my bed, then sliced:

Cura 5.4 - 4:48.39

Cura 5.5 - Gave up after 5 minutes

 

(Although one which just stalls and I've never waited to see if it finishes in 5.5 finished in 4:04.10 in 5.4)

 

So it's definitely not just you and @dokcal. I couldn't help but notice that neither was hammering my CPU, a few spikes for both but mostly barely anything (no need to look at task manager or anything, I can just hear the fan on my cooler go faster).

 

So the best thing to do is play any developer's favourite game - what do these things have in common? In this case, that's probably system specs, I'll go first.

Windows 10 Pro x64 22H2

Intel i7-7700K processor (4 cores, 8 threads), running at stock clocks (don't judge me for buying the unlocked version and not actually OCing it)

32GB DDR4 RAM

Printer: Creality Ender-3 V3 SE (slightly customised profile)

 

Not sure how much more is relevant. @Dustin or @MariMakes, please let me know if there's any more relevant specs I can provide.

[Slashee_the_Cow 275]

Huh, I thought I saw it slicing faster on my Linux install (openSUSE Tumbleweed 20231108). Then I copied the settings straight over from my 5.5 install on Windows (in 5.4 on Windows, was using similar settings but not the exact same profile.

Anyway, that NASA thing, 5.4: 5:39.09

That NASA thing, 5.5: Gave up after 10 minutes

Also, what the heck, I'm here, why not throw in one more datum in case it's different.

That NASA thing, 5.5 beta 1: Gave up after 10 minutes 

 

That one of mine that just stalls on Windows, 5.5: 4:08.06. It slices fine on Windows if I'm using regular supports, but not trees (and trees, in this case, save a lot of filament, and through personal experience, would be a hell of a lot easier to clean up - I ❤️ trees).

 

It's a lot easier to wait in Linux - how the hell is there not a free equivalent to Palapeli on Windows?

[Dustin 131]

Thanks for reporting.
UltiMaker Cura Dev's are aware of the issue and looking into the cause/fix for it.

[dokcal 0]

Looking forward to a fix!

Just to increase the database, I'm running Win 11 on an AMD Ryzen 9 5950X (also not overclocked) with 64 GB of DDR4, slicing for a heavily modded Ender-3 Pro.

 

I can't legally include the file I was slicing, but it's a plate of nine "dungeon tiles" for tabletop gaming (squares of stone flooring with attached walls). In 5.4, it takes 1 min. 5 sec., but in 5.5 it takes 5 min. 47 sec.!

[Cuq 198]

I hadn't done the test yet, because on classical mechanical parts it wasn't very significant, but for the same project: I tested the NASA Fabric 12x16.stl model with 0.2 layer and Nozzle Size 0.4 without support on Windows 10.

 

Cura 5.4.0 : 27s

Cura 5.5.0 with Fluid option Off : 17mn 06s

Cura 5.5.0 with Fluid option On : 17mn 26s

 

EDIT 

I've also tested with version 5.6 Beta 1; same as in 5.5.0 : 17mn

 

Given the difference in calculation time and the limited number of users who have been screaming since the release of version 5.5, this may be a problem linked to parts with a lot of slicing areas, like this model ?

 

 

 

Edited November 13, 2023 by Cuq

[Cuq 198]

A few tests later ... The explosion in calculation time seems to be linked more to the number of cutting area than to the  STL size. With a "simple" example Cura 5.4 : 7s   Cura 5.5 : 2min 13s on my PC

 

 

CarpetSpikesFinal.zip

[Dadkitess 19]

Dude, we're still stuck with slicing not being able to complete ?... Every 5.X version got crippled with this "bug", and it's real pain in the a$$... I'm using it for work and most of the slicing I ask are either taking 5 minutes or more, or won't ever be done, with either no message, just a full stall without taxing any calculation, or a "can't slice" error which will require many tries with weird modif like just a little offset of the part on the plate, or just 25% of infill rather than 30%, etc.

 

It's a bit annoying / irritating. It's really 80% of my print, that are rather complex / big but nothing crazy at all. Like the tubes shown in this 5.5 thumbnail for instance !

 

Can we have a 5.X milestone that would be Pro-compliant, even if not getting all the new fancy stuff ?

[Slashee_the_Cow 275]

4 hours ago, Dadkitess said:

Dude, we're still stuck with slicing not being able to complete ?... Every 5.X version got crippled with this "bug", and it's real pain in the a$$... I'm using it for work and most of the slicing I ask are either taking 5 minutes or more, or won't ever be done, with either no message, just a full stall without taxing any calculation, or a "can't slice" error which will require many tries with weird modif like just a little offset of the part on the plate, or just 25% of infill rather than 30%, etc.

 

It's a bit annoying / irritating. It's really 80% of my print, that are rather complex / big but nothing crazy at all. Like the tubes shown in this 5.5 thumbnail for instance !

 

Can we have a 5.X milestone that would be Pro-compliant, even if not getting all the new fancy stuff ?

 

If you think you can fix it, then Cura is open source, so go for it. If you don't think you can fix it, then please leave it to the human beings who have lives and families and don't want this bug to exist either.

[Dadkitess 19]

CURA is "sold" with UM machines. And it's actually the only way to get proper UFP files. Simplify3D as well but I don't know if it is still the nor if it's okay-ish or not.

 

Since UM machines are using a specific file format, yeah, i'm sorry but I do expect a working software along it, be it free / open source. It's totally fine to get new features needing some polish and all but Cura IS needed to get UM machine working, that's it. Especially when UM S5 machines are sold are easy to use, semi-pro very reliable printers.

 

I would not have the discourse for another printer, of course.

[Slashee_the_Cow 275]

10 minutes ago, Dadkitess said:

Since UM machines are using a specific file format, yeah, i'm sorry but I do expect a working software along it, be it free / open source. It's totally fine to get new features needing some polish and all but Cura IS needed to get UM machine working, that's it. Especially when UM S5 machines are sold are easy to use, semi-pro very reliable printers.

You seem to have missed my point entirely. This is one I usually only have to use when it comes to games.

 

Developers are only human. They don't spend all day hunched behind a desk in a dark room typing code like every bit of "hacker" stock footage shows. They need to eat. They need to sleep. Some contributors work a full time job and help with this in their spare time.

They want this bug fixed at least as much as you do. It's one thing to be annoyed at a bug. It's another to know that a bug in the code your team built is causing (potentially serious) problems for people. We call this feeling "guilt".

Humans are not perfect. Or else there would be no bugs in the first place, and everybody would live happy, peaceful lives.

There isn't a magic "fix bug" potion UltiMaker was too cheap to buy. It's possible to have a problem where you could double the number of developers working on it and it would still take just as long. This isn't labour, you can't just throw more man hours at it and finish quicker.

Bugs can take a surprisingly long amount of time to track down, and even longer to fix without introducing more. There's actually a saying that for every bug you fix, it adds ten more. It's sadly closer to reality than you might think.

People feel an inflated sense of entitlement. Are you entitled to bug-free software for your Ultimaker printer? Yes. Are they doing all they can to provide it? Also yes. Just because it's causing you specifically a problem doesn't mean they'll work any harder to fix it, because they're already working as hard as they can.

 

That last one is actually a lot more relevant when it comes to game developers. If an update to a game adds a bug, they can literally get death threats. If they don't fix that bug quickly enough, they sometimes get more. If it launches with bugs, same thing. If they delay the launch to fix bugs, same thing, because people think they're entitled to that game on that specific day. Even if it's not a bug; if they make a specific character weaker, then they can and do receive threats from people who believe they are entitled to kick everyone else's arse with an overpowered character.

 

My overall point being:

They know this is a problem. They are doing all they can to fix it. Receiving vitriol from the community just makes things worse, because then you feel like you're punished for doing your job.

[Dadkitess 19]

Then I was not clear either : I totally get that. I don't say the devs are newbies, that they should work better, that they should trade personal life for a CURA working, like, at all. That's obvious but it's even better when stated, apparently.

 

I just want the team to know that it's not working and it's not "normal" : again should I nuance saying that I obviously don't support the idea to fire the CURA team of make them crunch ? Or can I simply state that it's not okay so far to have 5000+ machines advertised as streamlined and reliable workflow ? It includes Hardware as well as Software, one without the other won't do anything.

 

If CURA was a preferred open-source homemade software among the actual plural software solution, being compatible, well, I would not have these words. But it's not, and we need to use it and the past year has been quite clunky, making it difficult to use. Not "not perfect", but clunky / not usable sometimes.

 

It's a well known problem ? I don't doubt about it, but it does not appear in any way in the communication. Let the consumer know that yep, there is some long-living issues so far, that they are focused on it : it will help.

 

It's funny coz I'm having about the exact same "debate" about a game right now, with exactly the same aspects, the same topics : no communication, not usable, etc, while defenders come to say that it's okay, don't insult the devs, don't harass them, while... Well, you guessed it, there is not insult, to harassments, only people willing to "complain" so that it's well known by the team that it's a major trouble.

 

Anyway, since this is only the first and last words that counts on internet, I'll say and insist : it's not again the dev team, it's not against the Community Managers, etc, it's only to complain to Ultimaker society, to say that it's not right to be stucked with a clunky CURA that is required to get the best of our over-expensive machines, specifically when advertised to be pro-compliant.

 

I'll then excuse if my words were a bit rude, because they were and it lead to your legitimate message : it sounds way too personal and familiar, and lacked of nuance. It was a hot-reaction to the thread while I actually connect to the forum to check the 5.5 official thread and it seemed to me it was particularly okay and then I saw that about slicing issues and was very disappointed. Not a valuable excuse for my message, but rather an explanation of its tone.

Edited November 14, 2023 by Dadkitess

[Dustin 131]

Lets stop with the personal attacks please, its not welcomed here.

Best place to report bugs is on our github, this brings the bug front and center to the entire dev team to see so they are actively aware of it.. 
Here: https://github.com/Ultimaker/Cura/issues

With that said the current bug has been identified and being worked on.

It appears there is a workaround for it as well.
Try disabling "Optimize wall printing order" it should in most cases significantly reduce slicing time (feedback on this is indeed welcomed!)

[Cuq 198]

Unfortunately, there's no difference in my case. With the example : CarpetSpikesFinal

 

Cura 5.4 :  Optimize wall printing order ON  : 7 s

Cura 5.4 :  Optimize wall printing order OFF : 7 s

 

Cura 5.5  :  Optimize wall printing order ON : 2 min 20 s 

Cura 5.5  :  Optimize wall printing order OFF: 2 min 19 s

CarpetSpikesFinal.zip

Edited November 14, 2023 by Cuq
Add 3mf Project

[Dustin 131]

Cuq, thanks for the feedback.. will share this with the team!

[SandmanLG 0]

I just came here to say that this issue still exists in 5.6.0. Can someone confirm if the issue as been found and if it will be fixed on the next release?

Edited March 7 by SandmanLG

[Dadkitess 19]

Yep, still exist. Try to just move / rotate a place slightly and it might do the job, as weird as it sounds. It fix 50% of my issues, even if it requires to try multiple time with loooong slicing operation before showing a fail, so not very convenient.

 

It seems to me that playing with the horizontal expansion makes things worst. But it might be a bias, since I use this parameters on quite complex geometry to "weld" and reinforce tiny fragile connection.

[Slashee_the_Cow 275]

9 hours ago, SandmanLG said:

I just came here to say that this issue still exists in 5.6.0. Can someone confirm if the issue as been found and if it will be fixed on the next release?

The list of current issues and their status can be seen on the Cura GitHub repo.

 

There is a pre-alpha build of Cura 5.7 available for testing slicing problems, but only use it if you're comfortable with the idea of using software that's not ready for release and contains bugs of its own.

[Stapels 0]

Hello all, appreciate the thread. Was going to fall down a rabbit hole troubleshooting. The attached image is a terrain piece  from Terrain4Print. Tried to slice with brim, 10% infill and no support. It would also hang - for me halfway through the slicing progress bar - with v5.6.0. This is on an Elegoo Neptune 4 Max. Downloaded and installed 5.4.0, and now I have profile conflicts, as the EN4M is still a custom profile. Ignoring this for now -  it slices in 10  seconds, vs the 20 mins I gave up on.

[Slashee_the_Cow 275]

3 hours ago, Stapels said:

Downloaded and installed 5.4.0, and now I have profile conflicts, as the EN4M is still a custom profile. Ignoring this for now

Profile conflicts? Each version of Cura uses its own configuration folder. If Cura can't find a configuration folder for its own version it checks to see if a configuration folder from a previous version exists and imports it (or if it can't find any, creates a new one). But AFAIK an older version will never look for newer folders so unless you delete the configuration folder from 5.6 the two will exist completely independently, although in most cases there's nothing stopping you copying things like quality profiles between the two. (I have about 5 different versions of Cura installed so I can try and use the same version people are having trouble with.)

[Stapels 0]

11 hours ago, Slashee_the_Cow said:

Profile conflicts? Each version of Cura uses its own configuration folder. If Cura can't find a configuration folder for its own version it checks to see if a configuration folder from a previous version exists and imports it (or if it can't find any, creates a new one). But AFAIK an older version will never look for newer folders so unless you delete the configuration folder from 5.6 the two will exist completely independently, although in most cases there's nothing stopping you copying things like quality profiles between the two. (I have about 5 different versions of Cura installed so I can try and use the same version people are having trouble with.)

Hello Slashee,

 

Thank you for the response. So I had Cura 5.6.0 installed first, on a new laptop I just moved my printing workflow to. At same time I added an Elegoo Neptune 4 Max to the mix. I set it up by copying the printer profile from the Elegoo Cura software (it reports as v4.8.0 in the about - didn't use the software to slice) that came with the printer on flash disk. I then set it up in Cura 5.6.0 as a custom printer and copied the parameters and gcode over. v5.6.0 worked OK for smaller test slices. Then I ran into the big slice issue  with the real terrain pieces. This led me to this forum post, and that prompted v5.4.0 install. I also set up the custom printer in v5.4.0 by copying and pasting the parameters and gcode into a new custom printer.

 

I have attached the Configuration error prompt I get when I open Cura 5.4.0. I can close the box, and still successfully slice using this EN4M 5.6.0 printer profile. I don't get this opening error prompt with loading v5.6.0. Then I have also added the screenshots of the profile (with the same settings) for the EN4M in v5.4.0 and v5.6.0

 

I am happy to  remove Elegoo Cura, and also do the reset and just readd the EN4M profile after reset, but I'll wait to see if you wanted to suggest something else first?

 

I don't think the gcode matters,  but I included to be complete.

 

Start  gcode:

;ELEGOO NEPTUNE 4 MAX

M220 S100 ;Set the feed speed to 100%

M221 S100 ;Set the flow rate to 100%

M104 S140

M190 S{material_bed_temperature_layer_0}

G90

G28 ;home

G1 Z10 F300

G1 X165 Y0.5 F6000

G1 Z0 F300

M109 S{material_print_temperature_layer_0}

G92 E0 ;Reset Extruder

G1 X165 Y0.5 Z0.4 F300 ;Move to start position

G1 X265 E30 F400 ;Draw the first line

G1 Z0.6 F120.0 ;Move to side a little

G1 X260 F3000

G92 E0 ;Reset Extruder

 

End gcode:

M104 S0

M140 S0G91 ;Relative positionning

G1 E-2 F2700 ;Retract a bit

G1 E-8 X5 Y5 Z3 F3000 ;Retract

G90 ;Absolute positionning

G1 X10 Y400 F6000;Finish print

M106 S0 ;Turn-off fan

M104 S0 ;Turn-off hotend

M140 S0 ;Turn-off bed

M84 X Y E ;Disable all steppers but Z

;Retract the filament

G92 E1

G1 E-1 F300

G28 X0 Y0

M84

 

Regards,

 

Dieter

[Slashee_the_Cow 275]

Elegoo Cura uses the same configuration folders as proper Cura but the two aren't always compatible. If you stop using Elegoo Cura and just set your printer up in regular Cura you shouldn't have any conflicts.

[DivingDuck 105]

It is maybe worth to check your log file.

Usually you should not get this kind of errors. Last time I remember those errors, it was in combination with a material definition file where the definition chain that was somehow broken in a Cura config file set. It took me a while to identify and solve the problem. The log file in the end pointed me to the right place to look at.

 

Regarding different versions of config files. You should always go in versions upwards as this will (mostly) take care that your profiles will update correctly when you install and run a newer Cura version. The other way around asks for problems as here is no "downgrading" procedure in Cura. Copy the lastest working configuration set (or all versions, if you want to install older Cura versions later) to the new computer and rename/delete the actual 5.6 set. Cura should then transform the latest version found in the config folder to the actual version when you start a newer Cura version.