Ultimaker / CuraEngine

Powerful, fast and robust engine for converting 3D models into g-code instructions for 3D printers. It is part of the larger open source project Cura.
https://ultimaker.com/en/products/cura-software
GNU Affero General Public License v3.0
1.69k stars 886 forks source link

Engine and GUI 2.3.1 - Top/Bottom Line Width? #420

Closed ghost closed 7 months ago

ghost commented 7 years ago

Curious, does Cura do something with the flow rate on Top Layers? It's almost like it under extrudes on purpose. I'm having a hard time getting the top to fill in and not leave gaps.

I'm using a .40 nozzle width 1.75 mm PLA, measures really consistently at 1.75 so that's what's in Cura Flow rate is 100%

.67 line width for everything 1.34 wall thickness (2 passes)

.20 layer height .40 top/bottom thickness (2 layers)

Infill is 30%

First layer is printed at 15 mm/sec with moves at 30 mm/sec

All other layers: Speed for outer shell is 15 mm/sec Speed for inner shell and infill are 30 mm/sec

Everything else prints perfect, bottom layers, vertical shells, infill, everything except the top layers.

The machine is well calibrated The axis move the exact amount they're supposed to, and it's repeatable without error I tell it to move exactly 100 mm it does exactly that, and returns 100mm to the same position Stepper drivers are adjusted properly Definitely not a movement issue

It's definitely not a filament feed issue either The extruder grips the filament perfectly, doesn't miss steps, and flows freely If I tell it to extrude 100 mm, it does exactly that.

It doesn't appear to be an under extrusion issue either I have also broken down the nozzle just to make sure and it's clean inside. The actual orifice is clear as well

I'm really at a loss

Take a look at the gcode First 2 layers are solid

Layers 23, 24, 48.49 and the last 2 should all be solid, but are not.

Ghostkeeper commented 7 years ago

Really sounds like you've taken a lot of effort to get to the bottom of this!

I'd really suggest using a line width that is slightly smaller than your nozzle width. But that should not affect only the top layer. And of course that's heavily dependent on the structure of your nozzle, so don't mind me talking.

Take a look at the gcode

Did you mean to upload the g-code somewhere? It would also help to have a model where this happens, unless it happens on all models. We can then try to reproduce it and see why it produces the wrong g-code. I haven't seen this issue yet.

ghost commented 7 years ago

Aw man, I mean't take a look at the attached gcode file, but I didn't attach it. I'm attaching a truncated one here that includes the layers I'm working with.

frame_trunc_2.gcode.txt

Thus far I've only printed cubes and similar items. But it's on everything I've printed.

I did also measure the lines with a digital caliper. Everywhere I'd expect it to be .67 it is (inner/outer shell, infill). Except those top solid layers, they seem to measure .40 Which is a little odd, that's what I have set for the nozzle.

IF it's doing some thing like that, of course placing .40 mm lines where they should be .67 would leave us gaps.

Edit: Truncated that file even more to just the affected layers. Gcode analyzer shows that it's designing the exact same infill paths between those layers. And I know it's at the same speed. Just have to determine if it's changing the flow rate.

BagelOrb commented 7 years ago

Some Times the line width settings for the top/bottom are overridden specifically; likewise for the speed settings. The global speeds not always set the top/bottom speed as well.

2 top/bottom layers is a bit tight. Try something like 5. Perhaps you are simply experiencing some kind of pillowing effect.

ghost commented 7 years ago

I suppose it could be pillowing to an extent. Not the kind where it erupts and makes a fissure, but maybe similar effects.

With other slicers, I've successfully printed a lower amount of top layers, I don't recall if it was 2 or 3 top layers. I've been printing more oozy filament for a while here and the ooze/flow could account for it being filled in in fewer layers. I'll try more.

Prior to this part, I specifically turned off all speed modifiers, it did everything at F1800 (30mm sec) and it still printed the same.

I know the speed can be/are constant as well as the nozzle diameter. The only thing I can't tell for sure is if the flow rate is lessened for a reason.

I'd want to inspect the gcode, though I wouldn't know what to pick out to compare

Ghostkeeper commented 7 years ago

To inspect flow rate per line, I usually load the g-code into RepetierHost. It shows by the thickness of the line how much is actually extruded according to the g-code.

ghost commented 7 years ago

I've loaded it to Repetier

It looks to me like it only gives representation of the paths in 3d, it doesn't seem to give a representation of the line width.

The top is Layer 2 which fills fully The bottom is Layer 23 which doesn't fill fully

comparison

ghost commented 7 years ago

I thought Repetier was not representing the line width But it was, and it was telling me there were gaps in between those lines

Here's the same object with all the same settings, except:

All line width are set to .40 mm (my nozzle size) Wall thickness is 1.20 mm (line width x 3 shells)

cura_success

Result was a perfect print.

It's like Cura does some distance between line calculation, and anything over the nozzle size it has a problem with.

Ghostkeeper commented 7 years ago

Perhaps the culprit is here somewhere: https://github.com/Ultimaker/CuraEngine/blob/master/src/MergeInfillLines.cpp#L104

It seems to use the nozzle size there for merging lines together. But they should only get merged if they have the same direction and meet on one end, iirc.

ghost commented 7 years ago

I can work around that. Looks like there's a software limit of nozzle * 3 /2. Which would make the max I can put in that field to .60 mm. I just switched the line width to .40 mm and everything looks and prints out perfect.

Except, on my most recent print, I saw a layer with a lot of wierd retracts.

This is layer 49 of the attached gcode file

retracts

It's set for 3 top layers And for some reason it did the 1st solid infill correctly, the 2nd one it didn't make complete zig zag, and is doing retracts. You can see it in the picture here. For the final layer, it did proper infill.

Odd thing is that there's another feature just like this on the other side of the part, and it didn't do this, it did proper solid infill all the way through.

Here is the STL. box.stl.txt

Here's the gcode box.gcode.txt

Ghostkeeper commented 7 years ago

Except, on my most recent print, I saw a layer with a lot of wierd retracts.

Well, we've had a couple of issues like that during development for 2.4 (though possibly not the exact same case). Might be that you're striking on those same issues and we've already fixed them for you. If that's the case, the 2.4 beta should be out shortly, so we can test again.

ghost commented 7 years ago

Is 2.4 beta out?

Ghostkeeper commented 7 years ago

Not yet.

The people that you see using it either built it themselves, or used Thopiekar's PPA to get a Linux build: https://launchpad.net/~thopiekar/+archive/ubuntu/cura-master

BagelOrb commented 7 years ago

The problem you are experiencing is a bug in planning zig zag lines. This bug is sadly not solved in 2.4. As far as I know the only way to work around the issue is to set the fill pattern to Lines.

wawanbreton commented 7 months ago

Not reproducing this kind of issue in Cura 5.7.0, closing. Please open a new issue if something is still wrong.