Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cura 5.8.0 Infill problem #19478

Closed
Schatta123 opened this issue Aug 4, 2024 · 13 comments
Closed

Cura 5.8.0 Infill problem #19478

Schatta123 opened this issue Aug 4, 2024 · 13 comments
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.

Comments

@Schatta123
Copy link

Cura Version

5.8.0

Operating System

Windows 11

Printer

Biqu B1

Reproduction steps

  1. I created an object that has a thickness of 3mm
  2. I slice the model with a 30% cubic infill

Actual results

Cura wasn't able to put infill. It just left it completely hollow.
image

Expected results

While in cura 5.7.0 it is able to put infill there like I expected. I even use the same profile and object.
image

Add your .zip and screenshots here ⬇️

3mm Problem.zip

@Schatta123 Schatta123 added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Aug 4, 2024
@GregValiant GregValiant added Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Aug 4, 2024
@GregValiant
Copy link
Collaborator

GregValiant commented Aug 4, 2024

Thanks for the report.
I can duplicate this. With 3 walls at 0.40 line width, the walls take up 2.4mm of the model. That leaves just a 0.60mm gap in the interior. Since that is less than 2 line widths wide there is no infill. That might be something that has changed over the last few versions.
If you decrease the Wall Count to 2 you will see that infill is generated.
If you decrease the Wall Line Width to 0.37 then you will also get infill.
Another alternative is to make the Wall Count 4 and make the piece solid. It's so small that infill won't have any effect anyway.
This is 3 walls at a line width of 0.37.
image

The Cura team will take a look.

@HellAholic
Copy link
Contributor

This seems (at first glance without investigating the code) to be connected to the fix implemented in 5.7.1 (rather than 5.8.0) for #18924 issue. The infill lines in this case appear to fall within the filter range and get removed as a result.

Added a ticket for investigation.
Internal Cura reference: CURA-12068

@mzhu1113
Copy link

mzhu1113 commented Oct 22, 2024

Since I can't see the status of the internal ticket, is there movement on this? This is a rather frustrating issue as an ODM having to work around this for designs that are not in our control so we're left with the option of giving the customer a substandard part (not ok) or expending much more material/time (not ideal). This is provided that a slicer tech actually catches that a design would have this issue.

I do agree the idea of there being a filter but I'd much rather have preferred this was a value the user is able to modify and what to do if it's under that value though I'd imagine there's a conflict with Minimum Infill Area?

Thanks.

@HellAholic
Copy link
Contributor

HellAholic commented Oct 23, 2024

Hey mzhu1113, We tried couple of approaches, but they were not promising, meaning they introduced additional issues. I'll bump the ticket again to see if we can get to a solution from a different angle.

Just as a curiosity point and maybe some additional bump up points for this, how is the final part quality affected if you go with 2 wall line count instead of 3?
I'm using the initial model shared as an example here, so it might not work in all scenarios (if you can provide additional cases that also helps).
image

@mzhu1113
Copy link

mzhu1113 commented Oct 23, 2024

@HellAholic
Thanks for the reply and also thanks for the work put into the 5.9.0 beta. Had a couple parts printed and the seams are pretty mint. 😄

Just as a curiosity point and maybe some additional bump up points for this, how is the final part quality affected if you go with 2 wall line count instead of 3? I'm using the initial model you shared as an example here, so it might not work in all scenarios (if you can provide additional cases that also helps)

I didn't submit this bug haha. But I am tracking it because we're affected by this and it's a painful one for us at that which I'll explain more below.

I don't know of why or what was the reason the filter was introduced (I assume it was a overall speed increase for the job or other problem) but I'd much rather the part is not lacking internal infill like this for an arbitrary amount like "2 wall perimeters" and simultaneously sacrifice part strength. If something like this has to be made, I'd rather it be not hardcoded and something user configurable.

With 2 wall lines and a gap present, the part loses too much shear resistence and the resolved part is able to have it's walls compressed from just simply pinching the affected features. However, all bumping the wall line count from 2 to 3 does is just change the thickness range that a feature will be affected. With 0.4mm nozzles, a 2.0mm thick panel will have this issue. Great 3 wall perimeters will fix it but now I'll have a problem with a 2.8mm thick panel and so on and some models are fairly complex and at some point simply increasing the wall line count is not going to help one or the other on the same part or even build.

Other points I want to make

  1. You have a user base that most likely would not know that this is an issue. Not everyone just looks through a github repo and navigate/search (much less know what they're looking for). So this filter is creating parts that they are going to perceive is weaker in Cura than other slicers.

  2. Even if we know of the workaround, we would also have to know that a specific model would be impacted in order to actually change that setting. This requires human checks and with our daily throughput some part is going to be missed during the prep stage which leads to us having to deal with that fallout if it makes it to a client. I'd rather this be a systemic fix so I don't have to burden 3 stages of a job to specifically check for this.

  3. Some models prevent us from using that workaround and the workaround to that workaround such as infinite bottom/top layers actually cause undesired toolpath movements, oddly applied speed logic with bridge settings, and just plain limitations from the client.
    We have a client that uses us to print full leg prothetics that has a base with holes for bolts to go thru. We have access to a Lumafield and found that we cannot go above some amount of wall line count otherwise the walls around the holes and the base itself will introduce cavities at the junctions that they have to meet. I also have infill set to 100% concentric. The problem is that some prothetics have to be thicker and the part has to be 100% solid and the base top/bottom pattern has to be rectlinear. So because we're aware of the bug/quirk we have to sink a lot of time looking for this issue if it's present in a part and it's frustrating when one makes it through after expending rather expensive material just to have to scrap and reprint when we find a small internal cavity in the CT scan where it is thicker than the 9-10 wall count and the infill won't kick in because their modeler targets a certain range of thickness.

Hope this helps. I can't really provide example models cause of some NDA or HIPPA so I'll try to describe as much as possible. I can CAD some example pieces if you need but it'd take time.

In the end, the desired outcome for now is that I'd rather the filter be configurable and the bonus to be that the old behavior to be brought back.

Thanks again!

@GregValiant
Copy link
Collaborator

GregValiant commented Oct 23, 2024

This is a wedge shape. I think it shows the problem regardless of wall count. Scaling it in the "Y" will allow a higher wall count.
Infill Test.zip
2 walls
image

1 wall. With one wall the problem area simply moves closer to the pointed end.
image

@smartavionics
Copy link
Contributor

Hi @GregValiant , for amusement, I sliced your test project with no alterations using 4.20.24 and this is what you get...
Screenshot_2024-10-23_22-21-38
Screenshot_2024-10-23_22-21-19

Pretty well filled with either infill or gap-fill.

So folks, if you don't need Cura 5 features, there is a solution at https://github.com/smartavionics/Cura/releases

@HellAholic
Copy link
Contributor

HellAholic commented Oct 24, 2024

I bumped up the ticket, might be able to get it into stable but no promises. Will try my best 🤞

@mzhu1113
Update: Bump successful, fix (after testing and validation) will be included in 5.9 Stable release.

@rburema
Copy link
Member

rburema commented Oct 24, 2024

For those who might want to follow along, the fix is implemented here; Ultimaker/CuraEngine#2156 and indeed slated for 5.9.0-final once merged (not in the 5.9-beta, it's still broken there).

@mzhu1113
Copy link

Perfect! Thank you everyone for pushing this through to the stable release! I'm really looking forward to this one.

@HellAholic
Copy link
Contributor

image

@rburema
Copy link
Member

rburema commented Nov 7, 2024

FYI: Due to unrelated circumstances, we're decided to have a 2nd beta this time around. The upshot is that this already should include the fix: https://github.com/Ultimaker/Cura/releases/tag/5.9.0-beta.2 (and of course it'll still be in stable later on).

@MariMakes
Copy link
Contributor

👋 Quick update on our side.
This is resolved in the 5.9 release 🎉 , you can download the Cura version with the fix here: https://github.com/Ultimaker/Cura/releases/tag/5.9.0

I'll close this issue since it's resolved.
Thanks again, and please let us know if you run into any other issues 💪

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

7 participants