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.

Sign up for GitHub

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

Jump to bottom

[4.6.1] [4.5] nozzle going over random line segments after printing them, 'ironing' them despite ironing disabled and it being midway up a print (not an upper layer) #7687

Closed
BillieRuben opened this issue May 6, 2020 · 27 comments
Closed

[4.6.1] [4.5] nozzle going over random line segments after printing them, 'ironing' them despite ironing disabled and it being midway up a print (not an upper layer) #7687

BillieRuben opened this issue May 6, 2020 · 27 comments
Labels
Type: Bug The code does not produce the intended behavior.
Milestone
5.0.0

Comments

@BillieRuben
Copy link

Application version
(The version of the application this issue occurs with.)
happened first on 4.6.1 later tried 4.5 and same issue, also tried a totally fresh install of 4.5 (removing all existing profiles and other installs of cura etc) and same issue (using the CR10s5 profile as a base). Also happens on other people's installs as they were trying to help me.

Platform
(Information about the operating system the issue occurs on. Include at least the operating system and maybe GPU.)
Windows 10 Pro 64-bit
Nividia GTX 1080

Printer
(Which printer was selected in Cura?)
creality CR10s5

Reproduction steps

  1. (Something you did.)
  2. (Something you did next.)

Screenshot(s)
(Image showing the problem, perhaps before/after images.)
lots of pics/gifs in this thread: https://twitter.com/BillieRubenMake/status/1257912124736561152

Actual results
(What happens after the above steps have been followed.)
it makes these goopy marks because the nozzle is coming back and dwelling on line segments that it's already printed. https://twitter.com/BillieRubenMake/status/1257912709456080896

Expected results
(What should happen after the above steps have been followed.)
it should just lay the lines down and leave them, not revisit them and 'iron' segments of them.

Project file
(For slicing bugs, provide a project which clearly shows the bug, by going to File->Save. For big files you may need to use WeTransfer or similar file sharing sites.)
CCR1_Mesh Base.zip

Log file
(See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)
Not crashing, just an odd bug in the toolpathing.

Additional information
(Extra information relevant to the issue.)
Combing is off, filling gaps between walls is off, it's not always happening at Z seams, just at these curves. toggling anything with optimize in the title has no effect on it. Coasting is off, gap fill is off, fiddling with the line width seems to change where it happens but doesn't eliminate it. I've gone through and toggled/edited every setting to do with walls and infill one by one and seen no solution. I put the model into 3d builder to see if it needed repair, but it didn't. rotating the model has no effect, nor does editing the model and re importing it,

I hope that's all the info! :)
Thanks team! <3
@BillieRuben BillieRuben added the Type: Bug The code does not produce the intended behavior. label May 6, 2020
@smartavionics
Copy link
Contributor

Hi, thanks for the model, it would be good if you could provide a project file instead as that includes both the model and the settings. Please do File -> Save and then zip/rename the .3mf and attach to this issue, thanks.

@mahtDFR
Copy link
Contributor

mahtDFR commented May 6, 2020

The project file is attached above, and I have managed to reproduce it. Will discuss

@smartavionics
Copy link
Contributor

Ah, yes, sorry, it is a project file, the problem is at my end because Cura can't load the settings from it due to some inscrutable error. Please ignore me.

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@smartavionics
Copy link
Contributor

Hi, yes, please export from 4.5 as my Cura is still using configs from that era...

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@smartavionics
Copy link
Contributor

OK, I can load it now. Immediate thoughts are:

1 - don't use no-skin combing as it forces the travels to move up and down those thin walls. Either turn off combing or use mode all.

2 - enable the overlap compensation for outer walls and set a min wall flow of something like 50 (or even more).

Hope this helps.

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@mahtDFR
Copy link
Contributor

mahtDFR commented May 6, 2020

Thanks for the detailed report - GIFs really help!
After a discussion we will look into this with some priority, I've added this to our current sprint.
Internal ticket: CURA-7424

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@smartavionics
Copy link
Contributor

So, why are you using such a wide line width? Is it because you are using a monster nozzle?

@smartavionics
Copy link
Contributor

If you use a line width of, say, 0.5mm it takes longer to print but doesn't appear to do all that back and forth weirdness.

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@smartavionics
Copy link
Contributor

No, I'm just a user who makes contributions and tries to help Cura users solve problems.

@BillieRuben
Copy link
Author

BillieRuben commented May 6, 2020 via email

@mahtDFR
Copy link
Contributor

mahtDFR commented May 7, 2020

@BillieRuben Not a solution, but a workaround: resize the model to 100.02%

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented May 7, 2020 •
edited
Loading

Hey, I recognise your name from Reddit. Loved your idea with the staggered bridges.

Okay, I figured out what the problem is here.

Here is how your model looks when imported in Blender, seen from the bottom. The problematic part is the middle of these three walls:
image

The width of the straight wall is 1.01mm (Blender assumes the units are metre, but Cura assumes millimetre). I'm assuming this is intended to match the line width of 0.99mm.

However when it goes into this curve the width becomes slightly less or slightly more, depending on where the vertices are placed. This is because the vertices are staggered. When it's around a vertex on the inner curve, the wall is less than 0.99mm wide. When it's around a vertex on the outer curve, the wall is more than 0.99mm wide. You can see the measurements I put there in Blender.

Cura manages to fit a line in when it's wider than 1 line width. Cura doesn't fit in a line when it's smaller than 1 line width. So as a result, you get tiny triangular loops where the wall fits, and voids where it doesn't fit. Cura prints these loops one by one with tiny travel moves in between. This is why it goes back and forth along the wall here.

Essentially the problem is that you're JUST on the border where Cura decides "I can fit a line here" or "I can't fit a line here". So it puts lines where it can and then doesn't where it can't.

There are several workarounds/solutions I can think of:

  • Easiest workaround: Apply a Horizontal Expansion of 0.01mm. This works around the problem because your part is then no longer on the threshold of fitting a line.
  • Best workaround: Modify the model so that the vertices in curves are no longer staggered. This means though that you'd have to render the inner curves at a higher resolution than the outer curves, which may be complex to do depending on which CAD software you used to create this 3D model. Make sure that each segment of the curve gets the same line width all over.
  • Second-best workaround: Since you have 20 micrometre of play here, it may also help to simply increase the resolution of the curve in the model.
  • Easiest solution: Cura should try a range of line widths and slightly vary the line width to minimise the number of parts while maximising the covered area. This could incur some significant extra computational costs though.
  • Best solution: Merge in libArachne: Use Arachne to vary line width CuraEngine#1210 . It's amazing how often I can respond with this PR.

@BillieRuben
Copy link
Author

BillieRuben commented May 8, 2020 •
edited
Loading

oh hey thank you! :) Not my original idea I don't think, I just made a fancy gif showing it. :)

I've now exported the model with much higher accuracy (from fusion360) and it's looking way healthier! :D :D Thank youu!! I'll try printing now.
CCR1_Mesh Base.zip

@BillieRuben
Copy link
Author

OMG it's working! I'm so happy. Thank you so much all! :,) So so happyyyy :D :D :D Thank youuu

@Ghostkeeper Ghostkeeper mentioned this issue May 11, 2020
Closed
@benderprod
Copy link

benderprod commented May 11, 2020 •
edited by mahtDFR
Loading

My issue #7697 was closed. I followed the suggestions here and was able to get Cura to slice the .8 walls as walls, but in the preview mode, it shows double printing the layer. Do add on to this issue, my original issue or open a new ticket?

@mahtDFR
Copy link
Contributor

mahtDFR commented May 12, 2020

If it's unrelated to the walls, probably best to open as a separate issue.

@Ghostkeeper Ghostkeeper mentioned this issue Jul 16, 2020
Closed
@BillieRuben
Copy link
Author

I'm still seeing this issue in all my parts. :(

When I said it fixed it last time I think it might just have been that model. I'm still getting it with everything I print and it's making little surface zits wherever it does this meaning all my prints are looking really ugly. :(

I've tried re-installing the latest stable release and making totally new profiles and using different models and it's still doing it, just running the nozzle over random bits in random layers kinda like it's ironing.

It seems the same whether I have combing on or off.

image

@BillieRuben
Copy link
Author

wait, it's not always the same.

This is combing off:
image

and this is it not in skin:
image

Within infill is different again:
image

Here's the project file:
CFFFP_connector.zip

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Jul 28, 2020 •
edited
Loading

It's the same problem again. The vertices are staggered, so the model is thicker in some places than in others.

image

Since your outer wall line width is 0.4mm, it won't fit an outer wall in the space where it measured 0.3925mm. It will create a loop in the space where it measured 0.425mm.

Since the walls are too thin to fit the line, the part is essentially broken up in multiple pieces. Those pieces will be printed in an order that minimises travel moves. This is why the combing mode can change the order in which the pieces are printed: Different pieces may be the closest option. Changing the order will change the travel moves.

My previous comment lists some workarounds for you, as well as some fixes that the developers can implement. We're taking the direction of the "best solution" listed there, through this pull request.

@Sophist-UK
Copy link
Contributor

Sophist-UK commented Aug 31, 2020 •
edited
Loading

Variable line widths should be a HUGE improvement as and when they get finished and merged. If you are using a line width which is 150% of the nozzle size so that filament is squished out under the flat sides of the nozzle hole, then Cura can pretty much vary the line width down by up to 33% without having much impact on strength or quality.

I have no idea what algorithm is being used in Ultimaker/CuraEngine#1210, and I would be very interested to see a write up. But in theory, if you can vary both the number of walls and the width of those walls, you pretty much should be able to print any wall width you want. For example, with a nozzle size of 0.4mm and a maximum-line-width of 150%:

Wall width, Number of Walls, Line-Width
0.3 - thin wall -  cannot be printed accurately - best option would be 1, 0,4mm which would be variable and better than 1, 0.6 as at present
0.4, 1, 0.4
0.5, 1, 0.5
0.6, 1, 0.6
0.7 - cannot be printed by full lines between nozzle-width and maximum-line-width, but can be printed using overlapping wall functionality as now to reduce the line-width below the nozzle size using the previously printed overlapping wall to block part of the nozzle and narrow it. Currently this would be printed with the first wall at 0.6mm and the second at 0.1mm, but with variable line-width it could be printed with the first wall at 0.4mm and the second at 0.3mm which I would image would be better quality.
0.8, 2, 0.4
0.9, 2, 0.45
1.0, 2, 0.5
1.1, 2, 0.55
1.2, 2, 0.6 or 1.2, 3, 0.4
1.3, 3, 0.433
1.4, 3, 0.466
1.5, 3, 0.5
1.6, 3, 0.533 or 1.6, 4, 0.4
1.7, 3, 0.566 or 1.6, 4, 0.425
etc.

The size and number of wall widths where you cannot print the exact width are going to be more frequent, the smaller the maximum-line-width % - if it were 125% instead of 150%, then you would have issues between 0.5mm and 0,8mm and again between 1.0mm and 1.2mm.

Other algorithm complexities:

  1. You would need to decide how to vary the line widths when wall widths vary. For example, if the wall width varies from 4mm to 6mm you could print this continuously with 10 lines which each vary from 0.4mm to 0.6mm, or you could print 5 lines at a fixed width of 0.6mm and print the rest with a varying number of lines - between 2 and 5 lines - and these would have travel moves where lines stop and start. The different choices might have different visual or strength qualities, and take different times to print - so you might need to have a setting to allow the user to decide what their priority is - and then the algorithm would need to optimise accordingly. It might be necessary to undertake formal experimental analysis of the various strengths and timings in order to decide what optimisations and options should be provided.

  2. Since printers can only print a fixed line-width in any one G1 gcode command, you will not only need to issue frequent G1s for curves as at present, but you may also need to break these straight line segments into smaller multiple G1 commands in order to vary the line-width. The existing mesh-optimisation settings don't apply to variable line-widths, so you will probably need a setting to influence how frequently the line-width is changed or the maximum size of the tiny gaps that will result from stepped changes in line-width.

  3. To preserve surface quality you may want a different setting for the variability of outer-wall widths, and to give priority to having variable line-widths happening on inner-walls in order to preserve the quality of the outer walls.

  4. Whatever algorithm is chosen, actual printing with real extruders and bowden tubes / direct extrusion etc. might not match the predicted theoretical flow - and there might be a need for tweaks to compensate for these real-life differences between theory and practice.

But if these can be overcome, the print quality improvements and time savings from having more continuous extrusion and fewer travel moves with variable line-widths should be substantial, not to mention making it far easier to get a high quality print without having to check the preview and manually tweak the line widths until you get the best optimised solution.

@Ghostkeeper Ghostkeeper mentioned this issue Sep 1, 2020
Closed
@Ghostkeeper
Copy link
Collaborator

I have no idea what algorithm is being used in Ultimaker/CuraEngine#1210, and I would be very interested to see a write up.

Actually, this was part of the PhD of BagelOrb, who invented the algorithm. He's written a paper about it which got published: https://research.tudelft.nl/en/publications/a-framework-for-adaptive-width-control-of-dense-contour-parallel-
It can indeed vary both the line width and the number of walls, opting to print with fewer walls if that allows the line width to be closer to the nominal line width.

You would need to decide how to vary the line widths when wall widths vary.

There are several "beading strategies" available in the current implementation (considering to rename those to "variable line width strategies" or something). These decide how to vary the line width and the number of lines. For instance there is a strategy that keeps the line width completely fixed, similar to the old behaviour. There is a beading strategy that keeps the outer wall line width fixed but varies the line width more towards the inside, so you'd get a more consistent surface. There are a number of things you could do with this. So I think this is implemented more or less as you describe here.

It does only make local decisions though. I already did see a case similar to this issue where it kept alternating between 4 and 5 lines.

Since printers can only print a fixed line-width in any one G1 gcode command, you will not only need to issue frequent G1s for curves as at present, but you may also need to break these straight line segments into smaller multiple G1 commands in order to vary the line-width.

That's exactly what the PR does at the moment. The resolution of this is not a setting though, but hard-coded to a reasonable value I think. It's a bit hard to visualise for a user.

To preserve surface quality you may want a different setting for the variability of outer-wall widths, and to give priority to having variable line-widths happening on inner-walls in order to preserve the quality of the outer walls.

It's not a completely separate setting right now, but part of the options you can choose for the beading strategies. There's an option to keep the outer wall line width fixed and spread the rest of the variability within all of the inner walls, and an option to have all of the variability in the innermost wall.

Whatever algorithm is chosen, actual printing with real extruders and bowden tubes / direct extrusion etc. might not match the predicted theoretical flow - and there might be a need for tweaks to compensate for these real-life differences between theory and practice.

We've done some test prints and found that the dimensional accuracy improved regardless. However we do expect that we'd need to vary the speed to achieve the correct line width, to get better accuracy if the line width varies quickly in a short space. Ultimaker printers use Bowden tubes so this is important to us.

@Ghostkeeper Ghostkeeper mentioned this issue Dec 23, 2020
Closed
@Ghostkeeper Ghostkeeper mentioned this issue Jul 14, 2021
Closed
2 tasks
@Ghostkeeper Ghostkeeper mentioned this issue Sep 22, 2021
Closed
2 tasks
@Ghostkeeper
Copy link
Collaborator

This is fixed in Ultimaker/CuraEngine#1210.

@Ghostkeeper Ghostkeeper added this to the 5.0.0 milestone Dec 14, 2021
@Ghostkeeper Ghostkeeper mentioned this issue Dec 20, 2021
Closed
2 tasks
@Ghostkeeper Ghostkeeper mentioned this issue Mar 14, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Bug The code does not produce the intended behavior.
Projects
None yet
Milestone
5.0.0
Development

No branches or pull requests
6 participants
@smartavionics @Ghostkeeper @Sophist-UK @mahtDFR @BillieRuben @benderprod