Closed BillieRuben closed 2 years ago
smartavionics
commented
4 years ago 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
commented
4 years ago The project file is attached above, and I have managed to reproduce it. Will discuss
smartavionics
commented
4 years ago 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
commented
4 years ago I could give you the STL if you like? And export my settings? Or try re exporting the project file from cura 4.5 (the one I included was from 4.6.1).
On Wed, 6 May 2020, 6:03 pm Mark Burton, notifications@github.com wrote:
Devs, in case you're interested, when I try to load that project file I get this...
2020-05-06 08:59:14,272 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: Exception: Could not check file PyQt5.QtCore.QUrl('file:///home/markb/Downloads/3dp/CCR1_Mesh Base.3mf') 2020-05-06 08:59:14,272 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: Traceback (most recent call last): 2020-05-06 08:59:14,273 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: File "/opt/cura/lib/python3/dist-packages/cura/CuraApplication.py", line 1840, in checkIsValidProjectFile 2020-05-06 08:59:14,273 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: result = workspace_reader.preRead(file_path, show_dialog=False) 2020-05-06 08:59:14,273 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: File "/opt/cura/lib/cura/plugins/3MFReader/ThreeMFWorkspaceReader.py", line 445, in preRead 2020-05-06 08:59:14,274 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: root_material_id = reverse_material_id_dict[material_id] 2020-05-06 08:59:14,274 - ERROR - [MainThread] cura.CuraApplication.checkIsValidProjectFile [1843]: KeyError: 'generic_pla_175_creality_cr10s5'
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624501667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7PT3FFZSAUHGHGWWMDRQEKU7ANCNFSM4M2GPGQQ .
smartavionics
commented
4 years ago Hi, yes, please export from 4.5 as my Cura is still using configs from that era...
BillieRuben
commented
4 years ago Here you go! :)
On Wed, May 6, 2020 at 6:16 PM Mark Burton notifications@github.com wrote:
Hi, yes, please export from 4.5 as my Cura is still using configs from that era...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624506961, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7L3YVFCQSVDCBHPKTTRQEMFLANCNFSM4M2GPGQQ .
smartavionics
commented
4 years ago 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
commented
4 years ago That was just the default profile for the cr10s5 with just the nozzle size (and I think maybe a couple of other settings) changed, it's not my normal one.
My normal one is the one you can't get to open. That one has combing off and such.
Did you get it to stop doing the weird doubling back and ironing bits? Can I have a copy of that project file if so?
On Wed, 6 May 2020, 6:41 pm Mark Burton, notifications@github.com wrote:
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.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624517884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7P3H3QMBNKHH55VCRLRQEPCXANCNFSM4M2GPGQQ .
mahtDFR
commented
4 years ago 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
commented
4 years ago You're such a gem, thank you so much!! ♥️♥️
On Wed, 6 May 2020, 7:09 pm maht, notifications@github.com wrote:
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
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624531507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7KZC5DQ2T42KNMIFJTRQESOLANCNFSM4M2GPGQQ .
smartavionics
commented
4 years ago So, why are you using such a wide line width? Is it because you are using a monster nozzle?
smartavionics
commented
4 years ago 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
commented
4 years ago Yep I'm using a monster nozzle. It's the difference between a 6 hour print and a 1 hr one. 😉
I'm sorry I've not really submitted a bug report on GitHub before, so I don't super understand how it works. Did you say you weren't one of the Cura devs?
On Wed, 6 May 2020, 7:14 pm Mark Burton, notifications@github.com wrote:
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.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624533449, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7LGRSHLZYJ27W4EZALRQES6HANCNFSM4M2GPGQQ .
smartavionics
commented
4 years ago No, I'm just a user who makes contributions and tries to help Cura users solve problems.
BillieRuben
commented
4 years ago Gotcha! Thanks!
I got quite a bit of help on that twitter thread, and in DM, and on the discord server too. Jamie/ Nallath asked me to submit this bug report. :)
On Wed, 6 May 2020, 7:25 pm Mark Burton, notifications@github.com wrote:
No, I'm just a user who makes contributions and tries to help Cura users solve problems.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/7687#issuecomment-624538605, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK7WX7IXKGDTAJP565WW6OTRQEUIBANCNFSM4M2GPGQQ .
mahtDFR
commented
4 years ago @BillieRuben Not a solution, but a workaround: resize the model to 100.02%
Ghostkeeper
commented
4 years ago 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:
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:
BillieRuben
commented
4 years ago 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
commented
4 years ago OMG it's working! I'm so happy. Thank you so much all! :,) So so happyyyy :D :D :D Thank youuu
benderprod
commented
4 years ago 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
commented
4 years ago If it's unrelated to the walls, probably best to open as a separate issue.
BillieRuben
commented
4 years ago 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.
BillieRuben
commented
4 years ago wait, it's not always the same.
This is combing off:
and this is it not in skin:
Within infill is different again:
Here's the project file: CFFFP_connector.zip
Ghostkeeper
commented
4 years ago It's the same problem again. The vertices are staggered, so the model is thicker in some places than in others.
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
commented
4 years ago 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 https://github.com/Ultimaker/CuraEngine/pull/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:
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.
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.
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.
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
commented
4 years ago I have no idea what algorithm is being used in https://github.com/Ultimaker/CuraEngine/pull/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
commented
2 years ago This is fixed in https://github.com/Ultimaker/CuraEngine/pull/1210.
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
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