IR surface mesh issues between firmware 3.2.2 an 3.4.6

[Yao]

Our printer is running perfect with 3.2.2 but i maybe an update (its 2024 now) would be good.
After upgrading to 3.4.6 all works fine except the bed adhesion of the first layer.
The further away from XY 0,0 i print the worse the surface adhesion is

I am using a IR surface scan prior to every print as we swap the printsurface between prints.
These printsurfaces are never regular (plaster) and need to be scanned for good first layer adhesion.

For testing the observed issue i just used a piece of PMMA covered with paper. It is not flat, corners are curved up little: ( the plaster the PMMA is resting on is a bit wet and the paper cover on that side absorbed the water expanding that side of the PMMA) bat that should not matter for the scan.

I just apgraded a printer to 3.4.6 firmware and noticed a diviation in the YZ direction while printing
after trying a lot of calibration i started measuring the actual values from the mesh and they are off.

When changing the firmware back to 3.2.2 this is the mesh result is what is should be
I did not alter anything else, only the firmware. The printer behaves as it should.

scan in 3.2.2:

3min later exact same scan in 3.4.6:

deviation is only in the Y direction. The relative point differences along X are somewhat similar between firmwares.

I have been trying to figure out what to do to compensate this mesh results but sofar i can't seem to find a logical reason. Do I need to change any values in any config files for the 3.4.6 firmware to work as the 3.2.2 in relation to Bed mesh or IR config?

in config.g:

M574 Z1 S2
M558 P1 C"zprobe.in+zprobe.mod"h5 F1000 T6000 
G31 P515
M557 X5:170 Y5:210 S40
M376 H20

I also notice that dive speeds andgeneral sensing behaviour are different between firmware.
Homing Z with 3.4.6 is also faster, it just keeps going full speed down and abrubtly stops at about 5mm above the surface.
In 3.2.2 the homing is fast untill the IR senses the surface about 15mm above it, then it slows down untill it hits the P515 value at about 5mm above the surface.

Is this a setting I now need to adjust somewhere?

1 hour later: tried 3.4.5 but that one is even worse:

3.3 is different again:

[droftarts]

@Yao When doing a jump in firmware, it is always wise to acquaint yourself with changes between the firmwares. See the firmware update notes here, and look specifically at the 'Upgrade' and 'New features' sections of each firmware release: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x

Specifically for your mesh bed probing speed issue, it's this change in 3.3:

• M558 now accepts either one or two F values, e.g. F1000:300. If two values are provided, then when executing a G30 command with no P parameter an additional probe using the first speed will first be done to establish the approximate Z=0 position, followed by one or more probes (controlled by the A parameter) to establish Z=0 more precisely.
• When using an analog Z probe, the probing speed is no longer reduced when the probe is close to triggering. Use the new M558 facility to do fast-then-slow probing instead, if necessary.

For more details of this change, see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m558-set-z-probe-type

You haven't provided details of your machine (does moving the Y axis move the bed, or move the X axis gantry?), Duet hardware (Maestro?) or the config.g, so I can't guess why movement in the Y axis would cause the bed mesh to change in that direction.

Ian

[droftarts]

@Yao Actually, my best guess is that the Z axis speed is too high as you lift the Z axis, and you are loosing steps as the mesh progresses. Reduce Z axis speed/acceleration/jerk.

Ian

[Yao]

@droftarts Hi Ian,

thanks! for the response, I used a LUTUM for the above tests. Stationary bed.
duet wifi 2.
max speed change for Z = 50 mm/min
max speed for Z = 1300 mm/min
accelerations for Z = 20 mm/s^2

i dont think these are the issue, printing itself is fine with or without using the mesh data.
its just that the mesh data itself does not represent the actual surface.

i went over the differences between 3.2 and the following firmwares.
"Use the new M558 facility to do fast-then-slow probing instead" unfortunately this is a much slower process.

i also found this:
"The object model for the height map (move.compensation.probeGrid) has changed"
"The height map file format has been extended. Height maps generated by earlier versions of RRF can still be loaded by this version, but height maps generated by this version of RRF cannot be loaded by earlier versions."

anyways, I ran a super slow probe sequence with 3.4.6

M574 Z1 S2
M558 P1 C"zprobe.in+zprobe.mod"h5 F50 T6000 
G31 P515
M557 X5:170 Y5:210 S40
M376 H20

and now its somewhat ok.

its unfortunate it needs to run this slow to work properly
ill try and find the upper speed limit.

[Yao]

@Yao I think this was solved by reducing the probing speed to a maximum of F400