33
what causes this?
(lemmy.nz)
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
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).