I have this annoying issue where solid infill on the bottom layers doesn’t print properly. It also affects walls on those layers. It looks like under extrusion to me, but it doesn’t make sense.
- It only affects solid infill bottom layers (I.e. layer 2 and 3 for my regular slicer settings)
- it does not happen on first layer.
- it’s not a clog issue, rinsing and cold-pulling doesn’t fix it. Brand new nozzle + hotend didn’t fix it either
- it’s not a flow capacity issue, it happens even with flow as low as 2mm3/s. I’ve used both Stefan’s weighing method and orcaslicers built-in flow calibration and they agree it tops out around 25mm3/s and slicer is conservatively set to 20mm3/max
- it’s not speed related, it happens regardless of speed, from 10mm/s to the regular 200mm/s
- internal solid infill line width is set to 105%, same as top layer.
Is there a slicer setting I messed up? Prints turn out ok, slight indent only on layer 2 and 3 because of this. But this just bugs the hell out of me because it shouldn’t be happening.
Edit: it’s a Qidi xmax-3 printer
Bed is within 0.18mm from lowest to highest point (according to the bed mesh), with all four corners within 0.07mm. It’s the best I could achieve. But again, this is only happening on layer 2 and 3, the bottom solid infill layers, but not first layer. If it was a general structural issue it should be prevalent throughout the model? but it isn’t. Its doesn’t fade in/out either, it starts adruptly when layers 2 begins, persists without change through entire layer 2 and 3, and is completely gone when it starts layer 4.
If the layers aren’t being properly squished down by the nozzle at the base sometimes the height will “catch up” and fix itself later. Is the left side of the image the first layer? I’m making that assumption.
The picture you posted just looks an awful lot like the offset is too high at the center of the bed; the gaps between the infill and the walls is a classic symptom of that. Having the other side of the model (the back of the picture) appear to be properly squished down is what makes me think that the bed or the gantry is the culprit, but that’s obviously just a guess from limited info.
Its not, that’s my shaky-cam photo skills and the angle. And it’s not like it “catches up” as the print continues, smoothing it out. It’s consistent all through entire layer 2 and 3, and as soon as layer 4 starts, it’s completely gone on layer 4 and onwards.
I think what they meant by “catching up” would happen at later layers, not later in the same layer. Basically, those layers are bad themselves but putting down enough material in the right places that a future layer will go down correct and smooth. So layer 4 being fine basically agrees with above commenter.
Are we looking at layer 2 partially complete or layer 3 partially complete? Because while I see the obvious problem on the partially complete layer, I also see problems on the layer that is complete. The back right area has tell-tell signs of too low z-offset (the very thin pinch lines coming up) but as it moves to the front of the image it looks like the z-offset is too high (not closing the gaps at the ends of lines and defined gaps between lines). Even the layer that is in progress looks like the lines are coming apart as the print head moves from back to front, like the gap is bigger in the front than back.
This all shouts levelling problem or motion system problem.
Has it always done this?
Did you get the printer new?
How long have you had it?
Can you post a picture of the bed mesh?
What temperature was the bed when you took the bed mesh?
No I’m saying the gap between lines on layer 2 and 3 is the same throughout the entirety of both layers without change (also on walls), but not present at all on layer 4 and onwards.
Partially complete layer 2
This seems to be unrelated to Z-offset, as it’s happens regardless of print placement and orientation but follows infill direction with the more squished part being towards the end of the layer and the slightly less squished part being the beginning.
The entire bed is within 0.18mm from lowest to highest point, with 0.07mm between highest and lowest corners. According to the probed mesh at least when I probe the entire bed.
This is also following infill direction actually, now that I think of it. It starts out almost ok, but gaps occur to a greater extent as solid infill progresses (regardless of print orientation and infill direction)
I honestly can’t remember…maybe?
Yes
8 months or so
55°C, heat soaked. It uses KAMP so it’s a new mesh every print.
Yeah this is what I was describing. If the nozzle is too far from the bed the line will not be properly squished down, meaning that the line will be too narrow (gaps seen on print) and too tall across the whole layer, which means the next layer gets put down higher than it should and is also too tall but slightly closer to the nozzle. Rinse and repeat, eventually a future layer is at the correct height to get squished and every layer past that is correct.
Still really feeling like this is a z-offset issue, which could be calibration, or an unlevel or uneven bed, or tramming.
This should not be the case. You shouldn’t have too much material at the end of a layer and too little at the start (or vise versa). Does the result look the exact same no matter where on the bed you put it? Like it looks the same centered vs put in corners but keeping the same orientation and print order.
If it happens anywhere on the bed in the exact same way then I don’t think it is a bed mesh problem and wondering if there is some sort of e-step problem that is compounding over the course of the layer, but resets on a layer change. Maybe try relative positions vs absolute positions in the gcode settings to see if it changes anything?
However, if moving the print to a different part of the bed moved the “problem areas” then there is either a motion system issue or bed mesh issue. Something could be out of square, or a z-axis lead screw is out of shape, or even I’ve seen printer firmware just tossing out the bed meshes - they will still scan them, but then just tosses it out at the beginning of a print (could be problematic “beginning gcode” in the slicer doing that too).