[3.6.0-rc2] Error: G30: Z probe readings not consistent

caviara

Hi team,

I came across a small issue with FW 3.6.0-rc2, as following:
When i try to home Z (using IR probe on CoreXY), after the initial probe, and when the bed is moving down (every time) i have slight movement, about 1mm, of the carriage in X+ direction, which (i believe) leads to the following error in console (and on the PanelDue):

G28 Z
Error: G30: Z probe readings not consistent
Error: Z probe readings not consistent

This movement in X+ is valid on every single probe made with G30, i mean - two probes = two movements.
This problem initially appeared after yesterday i upgraded to 3.6.0-rc2 from the previously installed 3.6.0-beta2.
Today in order to get some parts printed i downgraded to 3.5.4 "(stable one) and problem disappeared.
After this initial print i got back to the 3.6.0-rc2, and behavior is present.

My setup is as follows:
CoreXY on Duet3 6CH (V1.0 as i remember), with IR probe.

Here are the config files:
config.g
config-override.g
homeall.g
homez.g
(sorry for all the mess in those, still have not found time to clean them out )

and here is the result from M122:

4/18/2025, 8:37:07 PM 	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-rc.2 (2025-03-31 12:17:13) running on Duet 3 MB6HC v1.0 or earlier (standalone mode)
Board ID: 08DJM-956L2-G43S4-6JKD2-3SD6R-1U56F
Used output buffers: 1 of 40 (34 max)
=== RTOS ===
Static ram: 137420
Dynamic ram: 127860 of which 448 recycled
Never used RAM 78088, free system stack 140 words
Tasks: NETWORK(1,ready,28.8%,180) ETHERNET(5,nWait 7,0.1%,322) HEAT(3,nWait 6,0.0%,329) Move(4,nWait 6,0.0%,242) TMC(4,nWait 6,3.2%,341) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,338) MAIN(1,running,67.8%,103) IDLE(0,ready,0.0%,29) USBD(3,blocked,0.0%,149), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:13:09 ago, cause: software
Last software reset at 2025-04-18 20:23, reason: User, Gcodes spinning, available RAM 78328, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.9ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 10, maxWait 140309ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 23781.00/23781/0.00 321.00/321/0.00 2070.00/2070/0.00
Next step interrupt due in 247 ticks, disabled
Driver 0: standstill, SG min 0, mspos 952, reads 5946, writes 33 timeouts 0
Driver 1: standstill, SG min 0, mspos 56, reads 5946, writes 33 timeouts 0
Driver 2: standstill, SG min 0, mspos 360, reads 5947, writes 32 timeouts 0
Driver 3: standstill, SG min 0, mspos 72, reads 5947, writes 32 timeouts 0
Driver 4: standstill, SG min n/a, mspos 648, reads 5962, writes 17 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 5968, writes 11 timeouts 0
Phase step loop runtime (us): min=0, max=85, frequency (Hz): min=1016, max=8928
=== DDARing 0 ===
Scheduled moves 106, completed 106, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000007, drives owned 0x00000007
Code queue is empty
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0, axes/extruders owned 0x00000000, drives owned 0x00000000
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1 -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
=== Filament sensors ===
Driver 31: pos 2469.02, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== CAN ===
Messages queued 3742, received 0, lost 0, ignored 0, errs 3711809, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 3742/0/0
Tx timeouts 0,0,3741,0,0,0 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 4.95ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 6 2 2 2 2 2 0 2 0

My apologies if it was discussed earlier - i did try to search for similar with no success.

Edit:
Forgot to mention that the package for 3.6.0-rc2 comes with DWC 3.6.0 RC1, and DWC (ver. 3.6.0-rc2) needs to be uploaded separately to avoid error messages

gloomyandy

@caviara Are you seeing this movement show up in the X/Y position displayed by DWC?

caviara

@gloomyandy said in [3.6.0-rc2] Error: G30: Z probe readings not consistent:

@caviara Are you seeing this movement show up in the X/Y position displayed by DWC?

My apologies for the late response, i had urgent surgery and then some recovery.

To answer this question - yes, there is a change in X readings:
The carriage goes in X+ direction with about millimeter or two, however the reading changes from 150 to 149.08 exactly (every time).

Here is a short video showing this behavior:
https://youtu.be/no36pmUC0-U

PS
Just few minutes ago uploaded RC3 - same behavior is observed

gloomyandy

@caviara I hope the recovery is going well! You may want to try disabling skew correction:

M556 S100 X0.631

I think another user has reported similar issues with changes in X/Y after probing and that seems to be related to the use of M556.

gloomyandy

@caviara See this thread: https://forum.duet3d.com/topic/38033/g30-during-g28-issue It looks like there is a new build of RRF that may have a fix for the problem reported in that thread, so if removing skew correction removes the X offset, you may want to try the builds from that thread.

caviara

Hi @gloomyandy

You were absolutely right:
the scew compensation was the problem - tested it on both RC2 and RC3.
With it on - the behavior was as explained above,
when i commented it - all was good (i.e no movement for the gantry, no register on the screen/DWC in negative and no error about inconsistent reading of Z-probe)

And most importantly:
The firmware published by DC42 (3.6.0 RC3-1), seems to fixed this issue!

Thanks a lot guys!

dc42

@caviara are you sure this is completely solved? The other user having a similar issue reported that the new firmware reduced the movement but didn't entirely eliminate it.

caviara

@dc42 said in [3.6.0-rc2] Error: G30: Z probe readings not consistent:

@caviara are you sure this is completely solved? The other user having a similar issue reported that the new firmware reduced the movement but didn't entirely eliminate it.

Unfortunately you are right - today when i tried to print a long job, got a lot of errors around time, when G32 is finished. (errors like "position outside machine limits"). This does not prevent machine from printing, but i got inconsistent initial layer, which was not really visible on small part (like calibration cube).

I really need to finish today's print fast, so downgraded again to 3.5.4 and will report back with more tests later today or tomorrow.

PS
Did not notice these errors few days ago, because i was just got used to hit print and not monitor the screens (just wait for the part) - you spoiled me
Will try better to Beta-test next time, sorry

caviara

Just got Z probe error again with 3.6.0_RC3-1
The strange thing now is that i do not get this error every time, but like 1 of 3...

no X or Y movement is registered in DWC, so i would like to get advice from you:
Shall i search for dial gauge and way to mount it on the Y axis, to measure small carriage movement (that i cannot see by eye), or you have something else in mind?

dc42

@caviara please try the firmware at https://www.dropbox.com/scl/fo/vg4yfqcuk1u7oofsiogd6/AMDAS-LZ44linkaLjtrkCAY?rlkey=ptopknaa5xr4nhtacr94t6mw3&dl=0. It includes another fix for the position after homing when skew correction is in use.