Heightmap is completely ignored

kevincorinth

thank you for your beautiful idea!
I modified your idea slightly. Instead of changing only one (of 81) point(s). I changed a complete line.

But hooray. This method worked for me. I was able to see the rise and fall of the nozzle in the middle of the bed, where the fakeheightmap.csv was active!

At least I know now that there is some heightmap usage in the Background.
but sadly I still don't know what is wrong with my heightmap.
Could it be a bad offset of my BLTouch?
Or any other guesses?

Thank you very much in Advance!

martin7404

@kevincorinth i am not near my printers now. I will do folowing:
Home, tram and g29
I have 50 mm height gauge with dial indicator an will check mesh points with it

oliof

So one thing I note is that you save filament specific height maps, but you just load the generic heightmap.csv in the startup gcode @kevincorinth. Does the generic heightmap.csv even exist?

Since you can have filament profile specific gcode in PrusaSlicer which you seem to be using, maybe move the G29 from the startcode there, and reference the filament specific one.

oliof

also considering your height map image -- that already looks pretty flat. I would print on that without compensation (ignoring the front right corner unless I really have a full plate, which I tend to avoid).

Maybe you can show us a bit more about your setup: Print plate, printer gantry, hotend/nozzle, etc. I am at this point assuming your problem is not one of the heightmap, but another mechanical issue.

kevincorinth

@oliof

My first Layer is my USP. And my duet printer is my most expensive one. So achieving a perfect first layer would be great.

yes, there is always a heightmap.csv generated.

I have included in the start gcode of my prusa Slicer following lines:
"
G29 S2 ;clear all stored mesh
G29 S1 P"fakeheightmap.csv ; use the "Faked" heightmap
"
The result has been as expected. In the middle I still have a + 1mm offset in my fakeheightmap.csv. My first Layer looks exactly as usual. But you can see that in the middle the contour line has way less contact to the printsheet as to the right and left.

As a result my heightmap.csv is not ignored. My heightmap.csv ist simply too "weak"?

I will try what @martin7404 suggested. I will use a gauge and measure myself to compare the measured values with the BLTouch ones. I hope that helps me to get a clue of what is going wrong here.

Are there any known issues?

Thank you for your help!

mikeabuilder

I had a similar issue with a printer I'm building and the root cause was that when the print head moved from one side of the bed to the other, there was a slight force on it from the wiring and filament. This force caused the printhead to tilt one way on side 1 of the bed and tile the other way on side 2. That tilting lifted the nozzle enough to cause the first layer to not adhere, or shoved the nozzle into the bed. The offset of the z-probe from the nozzle can amplify any wobbliness in the printhead.

kevincorinth

@mikeabuilder

Thank you very much for your answer.
In deed my extruder was a little bit loose (compared to my einsy prusa extruders). I have completely diassembled my extruder on my caribou duet and retightened all the screws an cables.

Now my extuder is mounted rocksolid. But I still have a poor first layer.

kevincorinth

@oliof

my setup:

I have assembled the printer myself. The parts are printed by myself.

I have just disassembled and reassembled my bondtech extruder with Mosquito hotend.
I have also loosend the rod screws for the gantry. I have heard there can be some mechanical issues.

Still no change.

Thank you for your help in advance.

mikeabuilder

OK, the quick answer did not solve the problem. Putting on my mad scientist thinking cap...

Your original post said you had a bad first layer, so let's keep that as the problem to solve. Several posts and experiments here have shown that the mesh compensation matrix does make the z motors move as the print head moves, so we conclude mesh compensation is "on", but does not seem to be working well.

Theories of what might be wrong:

The z-offset between the probe and the nozzle may be different at different points on the bed.
Z offset might be set wrong everywhere on the bed.
Something else (mad scientist's last excuse).

Now we need to experiments to test our theories.

Some missing data - you didn't explain or show a picture of the bad first layer - is it everywhere, or good in some places and bad in others?

Experiment 1 - Turn off mesh compensation. move the nozzle to the middle of the bed and home Z (G30) there. Now we ignore the rest of the bed and print a 25mm square that is one layer thick. If this layer is not good, adjust the z-offset until it is good. This is now your Z-offset for the next experiments.

Experiment 2 - Move the nozzle near one corner of the bed (where the worst layer 1 is happening). Use G30 to home in that location. Print a single layer 25mm square in this location. If the offset between the nozzle and the probe is consistent in this location, the layer should be as good as in the center of the bed, adding weight to theory 1. If not, this adds weight to Theory 2 above. If the first layer looks bad, note whether it's too thin (nozzle too low) or too thick (nozzle too high).

Experiment 3 - If experiment 2 gave a bad first layer, let's see if the error is consistent on the other corners of the bed. If you got a good print in experiment 2, I'd skip this experiment. Repeat experiment 2 on those corners (move nozzle to a corner, home (G30) there, print small square. Look for changes in the quality at each corner. Does it change? How? I looked at the pictures on the caribou web page and they don't show the location of the tough probe, but the Superpinda looks to be to the right of the nozzle, but close to the nozzle front/rear. If the badness of the first layer on the left sides are the same but opposite of the badness on the right side, I'd add more weight to theory 2. If the front corners are the same badness but opposite to the rear corners, I'd give less weight to theory 2. If diagonal corners are equal badness, but opposite to the badness of the other diagonals, I'd just to theory 3 - something else and that something would be that the 4 leveling screws are curving the bed. The height map you posted shows this, but the amount of height offset seems low enough that mesh compensation should remove it.

Experiment 4 - do this if Experiment 2 made a good first layer. We are pursuing theory 1 now, and we think that we have a good Z-offset. Run bed leveling and compensation, then print a 25mm square near each corner of the bed. Are they all good now? If not, what is the quality of the first layers? Note that this experiment is different from experiment 2 because Z is not re-homed near each corner.

Hopefully these experiments will give you some insight to what is happening, and hopefully a simple z offset adjustment will solve it. If you are still on the path of theory 2, I'd sit in front of the machine with your experiment 3 results and ask "what could be causing the probe offset to change in a way that would give these results?". When I had a similar problem, here's where I ended up at this step. It's not your printer, but the pictures might give you some ideas of what to think about if you are staring at your printer and asking "how are you doing this to me?" https://forum.duet3d.com/topic/26397/mesh-compensation-effect-on-g30-command

In a worst case scenario, you could do an experiment 5 where you readjust the zoffset at each corner (maybe 5 x 5 mesh points) and capture the offset differences. Then compare to the heightmap.csv at those points. The difference would be a "machine adjustment for whatever is happening we can't figure out". Then you could write a macro that added those adjustments to the heightmap and applied it. This would be a brute force method and might need to be repeated occasionally.

kevincorinth

@mikeabuilder

I finally found time to do your very helpful scientific experiment.
Was to complicated for me.

But for anyone else having this problem:

My z axis minimum was set to z0

Changing M208 for Z0 to Z-2 in config.g was finally solving the problem.

@atall thank you all for your great and quick help, tips and tricks.

After 10 months of guessing and time consumable troubleshooting I am finally able to use my most expensive printer!

hooray!