Mesh Issue

JayJay

It may be a good idea to delete your heightmap.csv and create a new one after running G32.

I do that as a matter of course when i run a G29

Try using just G29 S1 in your start code, removing the P"heightmap.csv" part

Done i will test and report.

M122 reports "bed compensation in use: mesh"
On a 4 point height map ( with the latest DWC) it showed both front points a dead nuts, both rear points to be Z (Left) -0.025 and Z (Right) -0.033 which is about right, a 6x6 height map look correct, even though it says mesh in use i can see no compensation occurring.

Kolbi

Not sure if it was discussed or pertinent, but could this be warping? I have found it best to heat the bed to the operating temp and let it solidify for ~5 minutes before any critical probing.

JayJay

@kolbi said in Mesh Issue:

Not sure if it was discussed or pertinent, but could this be warping? I have found it best to heat the bed to the operating temp and let it solidify for ~5 minutes before any critical probing.

The issue Is that during tests you can physically see the first layer is "squished" more on one side (right) of the test print than the left and that although the system lists mesh as occurring the motors do not appear to be following a height map.

Mechanical issues with lead screws/couplers were the first thing ruled out.

I allow my three printers to sit and heatsoak in my man cave, in fact they are hardly turned off.

Its not warping, I thought about the possibility and started testing with Form Futura CF-PETG which doesn't actually need a heated bed because warp is not a thing it does.

Im also going to test klipper on the board to see if that makes any difference.

Phaedrux

You must use the M671 command to define the X and Y coordinates of the leadscrews. The M671 command must come after the M584 command and must specify the same number of X and Y coordinates as the number of motors assigned to the Z axis in the M584 command; and these coordinates must be in the same order as the driver numbers of the associated motors in the M584 command. The M671 command must also come after any M667 or M669 command.

https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

Check your config. I think you need to move your M671 below your M584 command.

M671 X-25:255 Y0:0 S10                      ; The Z axis pivot point locations to allow levelling to be undertaken
M569 P0 S1                                             ; Drive 0 (X Motor) goes forwards
M569 P1 S1                                             ; Drive 1 (Y Motor) goes forwards
M569 P2 S1                                             ; Drive 2 (Z1 Left Motor) goes forwards
M569 P3 S1                                             ; Drive 3 (Extruder Motor) goes forwards
M569 P4 S1                                             ; Drive 4 (Z2 Right Motor) goes forwards
M584 X0 Y1 Z2:4 E0.3                           ; Drive mapping

Kolbi

@jayjay Ok, I do think that klipper is interesting and could make a difference if the configuration is spot on, but the same could be said for RRF.
FWIW I use 3.11 and independent Z motors in my setup and have had zero issues for the longest time, you can browse my files here if it helps: https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s/

JayJay

@kolbi said in Mesh Issue:

@jayjay Ok, I do think that klipper is interesting and could make a difference if the configuration is spot on, but the same could be said for RRF.
FWIW I use 3.11 and independent Z motors in my setup and have had zero issues for the longest time, you can browse my files here if it helps: https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s/

This machine just recently started to exhibit this behavior, or at least i just noticed it after i couldn't get a decent first layer on a new material i was testing. before that it has been running perfectly fine in this configuration for years.

One of my other machines is exactly the same as this one and isn't presenting these symptoms

@Phaedrux

This machine (and the other one) has ran fine with that configuration for years, the only changes being firmware updates, but I did move the M671 command to be the final entry in the drives section.

That along with removing the "heightmap.csv" part from my G29 S1 in the start g code of my slicer(s) has made no difference, I tried it with ideamaker, prusa slicer and simplify3d.

Kolbi

@jayjay Ok, that adds a bit of a milestone to the troubleshooting process. Since you have another machine that is exactly the same, have you swapped sd cards between them to see if the problem shifts?

Phaedrux

At this point could you try switching to fw 3.2 then to see if the problem is related to 3.3 beta2?

https://github.com/Duet3D/RepRapFirmware/releases/download/3.2.2/Duet2and3Firmware-3.2.2.zip

Upload this zip file to the system tab.

JayJay

@kolbi

I have tried multiple new Scandisk industrial i procured through work. formatted in slow mode with the SD association SD card formatting tool.

posting on the forum is a last resort.

@Phaedrux

I was on 3.2.2 when i noticed the issue , i updated to the beta to see if that would cure it, sadly it didn't, and i just never rolled back

Kolbi

@jayjay I was suggesting that since both printers are exactly the same, to power them both off and swap the cards between the two of them. Taking the card from a known-good and putting it in a deranged unit would half-step the issue, or at least prove if it is software/configuration or something else.

Phaedrux

Can you show what the mesh display looks like now in dwc 3.3?

Can you also share heightmap.csv?

JayJay

@phaedrux

I cured the issue, I went back to RRF 2.0.5.1 all my problems went away, so I'm spending time printing instead of diagnosing issues.

And its happy to use DWC 1 again.

So although unorthodox the problem has been "solved"

dc42

@jayjay said in Mesh Issue:

@phaedrux

I cured the issue, I went back to RRF 2.0.5.1 all my problems went away, so I'm spending time printing instead of diagnosing issues.

And its happy to use DWC 1 again.

So although unorthodox the problem has been "solved"

@JayJay, that doesn't sound like a solution to me. Are you definitely using bed compensation with RRF 2.05.1, and is it definitely working?

JayJay

@dc42

Yes & Yes

I want to use the printer to print things not waste time and filament chasing an issue, taking a retrograde step has allowed me to get back to printing.