Cura: Ironing misses some areas Cura 3.5.0 and 3.5.1
Application Version
3.5.0 and 3.5.1
Platform
Win7 (likely all)
Printer
Wanhao Di3 (likely all)
Steps to Reproduce
See attached project, I have seen this issue on several models but some simple models does not have the issue with the same settings.
Actual Results
Some areas are ignored by the Ironing function
Expected results
It worked with the same settings in all earlier versions of Cura3.
Additional Information
printingotb
All 30 comments
Forgot the project file:
ironing issue.zip
printingotb
on 9 Oct 2018
I encountered the same problem. Using Cura 3.4.1 or earlier, everything was fine. Now many tighter spaces get missed by ironing.
Attaching a screeshot from gcode viewer (3.5 up, 3.4.1 down) where the missing ironing moves are clearly visible as lighter areas without the extra tight ironing lines. Some areas just get skimmed through with a single ironing line, others are omitted completely.
The two gcodes were produced using exactly the same project file and settings.
Tomaskom-cz
on 15 Oct 2018
3.5.1 still suffers from this issue.
Also, I think you can change platform to All (I'm on Linux) and printer to All as well. This problem is very likely in the slicing engine.
Tomaskom-cz
on 18 Oct 2018
I think I reported this only one day before the release of 3.5.1
printingotb
on 18 Oct 2018
Yes, it also looks incorrect to me :-)
diegopradogesto
on 24 Oct 2018
Just an observation than might help identify the issue:
It seems the ironing malfunctiones exactly only in areas, where the individual ironing pattern moves (I'm using the default - ZigZag) would be shorter than a certain distance. That distance is consistently something around 6-7mm in my sliced models.
Tomaskom-cz
on 24 Oct 2018
Devs: CURA-5855
rburema
on 25 Oct 2018
Still an issue in 3.6, Didnt have this issue until i updated to 3.5.1. but still had it even after going back to 3.5.0. Using the same model in the past that i never had ironing issues on, I am still getting the above issue. It can be seen in Cura.
zaxhalmon
on 16 Nov 2018
@zaxhalmon We couldn't get this fix in before 3.6, the ticket is still open. We hope to adress this in the current sprint and/or near future.
rburema
on 16 Nov 2018
I've noticed that setting the infill in giroyd the bug disappears and I can use ironing with zig zag pattern without issues
theuncle
on 8 Dec 2018
Hello @theuncle. You are correct because the bit of Cura that is faulty breaks not only the ironing but also the gyroid infill (and zig-zag infill, sometimes). So I cunningly disabled the naughty code when the gyroid infill is used.
smartavionics
on 8 Dec 2018
This is fixed in version 4.0. Thanks for the report!
Ghostkeeper
on 21 Dec 2018
Thanks a lot! :)
printingotb
on 21 Dec 2018
@Ghostkeeper Was this fixed in the Beta or after the beta? I still have the issue with Ironing in 4.0 beta (downloaded today).
I also found the following related issue when helping a guy out:
If I choose zigzag for bottom pattern initial layer, the bottom pattern does not fill the entire area.
Zig zag for the top/bottom layers also fails to fill in all areas (see for example layer 20 in the included project file).
Lines and concentric works as intended (I never use zig zag, that's why I hadn't noticed before).
Zig zag in combination with gyroid infill works as a fix, as it did with the ironing issue.
ZigzagIssue.zip
Cheers!
printingotb
on 1 Jan 2019
Printed nine of these squares today, 4 in cura 3.6 and after seeing this post I downloaded Cura 4.0 BETA today and did 5 more. This is NOT FIXED.
Edit: Side note this cura UI clearly had good intent and I like some of it, but some parts of it are a huge "WHY". Like actions taking more clicks in 4.0 than 3.6
kris2340k
on 2 Jan 2019
Kris...
Read the rest of the thread... it is fixed in the beta for 4.0, you are still using 3.6. Try the beta or wait for it to come out.
Sent from my Sprint Samsung Galaxy S9+.
-------- Original message --------
From: kris2340k notifications@github.com
Date: 1/1/19 7:34 PM (GMT-06:00)
To: Ultimaker/Cura Cura@noreply.github.com
Cc: zaxhalmon alwysgm@hotmail.com, Mention mention@noreply.github.com
Subject: Re: [Ultimaker/Cura] Ironing misses some areas Cura 3.5.0 and 3.5.1 (#4524)
Printed nine of these squares today, 4 in cura 3.6 and after seeing this post 5 more. This is NOT FIXED.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FUltimaker%2FCura%2Fissues%2F4524%23issuecomment-450771826&data=02%7C01%7C%7C670cf76d2aa64a2abab108d6705271fc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636819896725124866&sdata=LgyZBtUYvl7i3KWS3kw%2Fz6QV%2BeZvUl5SsC1X2KmK4f0%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAq_7xIGRpomlTmjVlmyz373u4tn74YLfks5u_AyngaJpZM4XS3Mo&data=02%7C01%7C%7C670cf76d2aa64a2abab108d6705271fc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636819896725124866&sdata=B83LwijYoZwhw1cZUULjgI9%2F%2BgJznUev%2B0M7K1aQzms%3D&reserved=0.
zaxhalmon
on 2 Jan 2019
@printingotb This was not fixed in the beta yet. It was fixed by this merge, about a week after releasing the beta.
We're planning to release a second beta for 4.0 soon, so you can still test it. Due to the UI change we allowed for a longer beta period this time.
Ghostkeeper
on 2 Jan 2019
Nice!
Just wasn't sure if you where aware that the bug affected the top/bottom lines as well.
printingotb
on 2 Jan 2019
A thing to keep in mind: We'll be releasing a second beta before the 'final' (because of the big UI changes), so please keep an eye out for this issue. Like people noticed, this bug and it's fixes have it's tendrils in a lot of places.
rburema
on 9 Jan 2019
Chuck is advertising this broken feature on youtube: https://youtu.be/gh5wC4Ti95s
@Ghostkeeper are you guys going to release a new 4.0beta at last? You promised a new build in January man, and it's March already.
betavr
on 2 Mar 2019
There was a new beta released this week
https://community.ultimaker.com/topic/26773-ultimaker-cura-40-beta-2/
smartavionics
on 2 Mar 2019
@smartavionics But there is no binary. It's certainly not here: https://ultimaker.com/en/products/ultimaker-cura-software/list
betavr
on 2 Mar 2019
Hmm, you're right. Well, I don't know what happened there. I don't actually use those releases myself as I make my own. Sorry to confuse things.
smartavionics
on 2 Mar 2019
The .../cura-software/list page incorrectly shows the release date of the first beta, but links to the second beta. Beta 1 is no longer available, beta 2 is.
fieldOfView
on 2 Mar 2019
Thanks Aldo.
smartavionics
on 2 Mar 2019
@fieldOfView Good to know, thanks.
The fact that the binary isn't listed on the releases page (https://github.com/Ultimaker/Cura/releases) doesn't help either.
betavr
on 2 Mar 2019
Thank you, I think the release of the second beta should be better advertised. I was waiting for it and if I didn't comment on this issue which got me subscribed, I would never know it's actually out.
I can confirm the download page entry gets me a file named "Cura-4.0.0-BETA-2.AppImage" :)
Tomaskom-cz
on 5 Mar 2019
We've never had a 'second beta' before, so there's definitely some things we can improve in that regard if we ever decide to do it again.
rburema
on 5 Mar 2019
Let's hope having a second beta is the start of a good habit.
fieldOfView
on 5 Mar 2019
The second beta was intended to be "just this once" because of the UI change and the cloud connectivity thing. The latter was also the reason for the second beta taking so long to be released by the way. They were having some trouble implementing the firmware update that we depended on. But I agree that it's a good habit to do for big releases like a major version increment.
Ghostkeeper
on 5 Mar 2019
Related issues
StanislavJochman
·
3Comments
ferociousdiablo
·
3Comments
wi1k1n
·
3Comments
muhammadelmogy
·
3Comments
jellewie
·
3Comments
Most helpful comment
Hello @theuncle. You are correct because the bit of Cura that is faulty breaks not only the ironing but also the gyroid infill (and zig-zag infill, sometimes). So I cunningly disabled the naughty code when the gyroid infill is used.