Comment - FBXL Lotide

ExcessShiv@lemmy.dbzer0.com ⁨1⁩ ⁨week⁩ ago

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.

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.

Are we looking at layer 2 partially complete or layer 3 partially complete?

Partially complete layer 2

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)

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.

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 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)

Has it always done this?

I honestly can’t remember…maybe?

Did you get the printer new?

Yes

How long have you had it?

8 months or so

What temperature was the bed when you took the bed mesh?

55°C, heat soaked. It uses KAMP so it’s a new mesh every print.

original

Sort:hotnew top

natecox@programming.dev ⁨1⁩ ⁨week⁩ ago

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.

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.

original
Crozekiel@lemmy.zip ⁨1⁩ ⁨week⁩ ago

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.

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).

original