G38.2 much less precise than G30 and moving wrong axes (Bug?)

NeoDue

I still need to doublecheck that, but for some reason the values a G38.2 Z probe move prints out seem to be quite a bit less precise than the ones a G30 z probe moves create - so far, testing created variances in hundreths of a millimeter for G30, compared with tenths of a millimeter for G38.2. Is that intentional or a bug in firmware 3.5.0 rc1?

The only reason I use G38.2 is that G30 moves keep creating messages on the PanelDue which disturb the ones I create.

NeoDue

Update: I tested this now with the following macro:

; Variables
global Druckplattendicke = 5        ; defined in my config.g, just added here for clarity
var Startmesshoehe = 2
var Wartezeit = 500			; Millisekunden zusätzlich zur Dauer der Messung geändert


G28 							; Homing
T1 P0 						;activate right print head

; remove glass plate to get access to sensor contacts on bed
G1 H2 Z180 F6000
M400
M291 S2 P"remove the glass plate!" R"bed leveling"   

; heat up heads and bed
; G1 H2 Z{move.axes[2].max} F6000
M140 S60 						; bed: 60°Cn
M568 P1 S220				; Hotend 2:  220°C
M116							; wait

; clean print head
G1 H2 U{move.axes[3].max-50} F3000 
M400
M291 S2 P"thoroughly clean the print head and the bed contacts" R"bed leveling"
G1 H2 U{move.axes[3].max} F3000 	; back to parking pos.

G1 H2 Z0 F6000						; move bed up - contact height is -5mm (glass thickness)


; measure distance with G30
G1 H2 U115 Y-94 F3200					; move to contact
M400								; wait
G1 H2 Z{-global.Druckplattendicke + var.Startmesshoehe} F6000	; move bed closer to nozzle
M400
while iterations <=6
	G4 P{var.Wartezeit}			; wait
	G30 S-1 K1					; measure Z with the right hotend
	G1 H2 Z{move.axes[2].machinePosition + var.Startmesshoehe} F3000	; lift nozzle

; measure distance with G38.2
while iterations <=6
	G4 P{var.Wartezeit}			; wait
	G38.2 Z-7 K1				; measure Z with the right hotend
	echo {move.axes[2].machinePosition}
	G1 H2 Z{move.axes[2].machinePosition + var.Startmesshoehe} F3000	; lift nozzle
	T0 P0
	G1 X-175 F3000				; why the hell does the G38.2 command above move the X 
axis?? Move the head out of the way where it belongs for now <-- does not work either. Why?
	T1 P0
; finish
G1 H2 Z5 F100						; move bed back to safe distance for XY moves

Result:

The G30 probes vary +/- 0,003 mm, with an offset around 0,02 mm between measurement cycles which is most likely caused by the XY gantry.
The G38.2 results vary up to +/- 0,1 mm around what was measured by G3 before (the variance itself varies greatly between measurement cycles), and the G38.2 command moves the X axis together with the Z axis, which I do not understand at all. (By the way, the printer is a typical cartesian IDEX printer running RRF 3.5.0rc1 on a Duet 3 6HC - one motor for X, one for Y, one for Z and one for U. Thus, just a simple M669 K0 in the config.g, nothing fancy...)

Edit: I also tested if that precision issue might be caused by the other hotend moving (I unplugged the motor for that since I could not get it to stop moving). Result: no, the quality of G38.2 does not get better...
2nd Edit: even if I disable the X stepper with M18, G38.2 moves it when it should move Z only - and that happens without updating its position

NeoDue

And another question about this topic: with G38.2 being too unprecise (and moving axes it should not) and G30 creating messages on the PanelDue I do not want - is there any other way to do a z probe without getting a popup on the PanelDue? (in case someone asks about the reason, look here - I want to recreate the "guided leveling" the Snapmaker J1 has)
Conditional Gcode with "while sensors.probes[1].value[0] == ..." does not work because of the channel logic @dc42 noted here.

Edit: in case it is needed, here is the axes / tools definition part of my config.g:

; general
;
M451								; FDM printer
M669 K0 							; cartesian printer
M111 S0 							; Debugging off
G21 								; units: millimeters
G90 								; absolute coordinates...
M83 								; ... except for the extruder
M555 P1 							; firmware compatibility RepRapFirmware
M200 D1.75 							; filament diameter 1,75mm for all extruders

; global variables
;
global Druckplattendicke = 5.00 	; print plate thickness
global Filament_X_retract = false   ; used for tool switch macros
global Filament_U_retract = false   ; used for tool switch macros

; PanelDue
;
M575 P1 S1 B115200					

; drivers
M569 P0.0 S0 F4 Y1:2 D3 H94 V94 ; DRIVER_0 (X) 
M915 P0.0 T94     
M569 P0.1 S1 F4 Y1:2 D3 H94 V94 ; DRIVER_1 (U)
M915 P0.1 T94  
M569 P0.2 S1 D3 H310 V310		; DRIVER_2 (Z)
M915 P0.5 T310              
M569 P0.3 S0 F4 Y1:2 D3 H94 V94 ; DRIVER_3 (Y) 
M915 P0.3 T94                
M569 P0.4 S0 D3 H310 V310		; DRIVER_2 (E1)
M915 P0.5 T310                
M569 P0.5 S1 D3 H310 V310		; DRIVER_3 (E2) 
M915 P0.5 T310    

; axes and extruders
;
M584 X0.0 U0.1 Y0.3 Z0.2 E0.5:0.4			; map drivers to axes
M350 E64:64 Z16 I0 						
M350 X16 U16 Y16 I1 					
M92 X80 U80 Y80 Z1600 E138.58:138.58 S16 
M566 X240 U240 Y240 Z100 E100:100		
M203 X21000 U21000 Y21000 Z600 E4800:4800	
M201 X8000 U8000 Y8000 Z500 E5000:5000
M906 X1000 U1000 Y1400 Z1000 E800:800 I95
M84 S30 	
M915 X U Y S20 F1 R2                        ; Stallguard 

; coordinates
;
M208 X-175 Y-101 Z0 U-151 S1 		; min
M208 X151 Y101 Z209 U175 S0 		; max

; Tools
M563 S"Hotend 1" P0 D0 H1 F0		
G10 P0 X0 Y0 Z0 		
M568 P0 R0 S0 			
M563 S"Hotend 2" P1 D1 H2 F1 X3			
G10 P1 X0 Y0 Z0

fcwilt

Hi,

My reading of the documentation on G30 and G38.2 suggests they are intended for very different purposes.

Is the issue with the PanelDue critical?

Frederick

NeoDue

@fcwilt you are right, but I admit I expected a probe move have a similar accuracy in all cases. And there is no remark at G38.2 that limits it to CNC use.

The PanelDue issue is critical in that way that it breaks the display of motion messages I wrote to recreate the graphic leveling tools of the Snapmaker J1.

Sadly, neither @Phaedrux nor @dc42 had this obstacle in mind when I posted my initial question if such a recreation with the corresponding display is possible... everything else works (even if it is a bit fincky to tune the display timing vs. the measurement times since you cannot update a message in the PanelDue instead of creating a new one), it is just that one command.

fcwilt

@NeoDue said in G38.2 much less precise than G30 and moving wrong axes (Bug?):

The PanelDue issue is critical in that way that it breaks the display of motion messages I wrote to recreate the graphic leveling tools of the Snapmaker J1.

Do you have any programming skills?

The Duets are able to send Telnet messages to a remote device, like a computer.

Perhaps that feature could be used to send the needed information to an application running on a computer to obtain the desired display.

Frederick

NeoDue

@fcwilt No, sorry... Some basic things such as batch programs or conditional gcode is okay, but everything else is over my head - otherwise I would have already tried to compile my own version or add a parameter to G30 in Github...

Thus, I think that would require much more than I can do. Apart from that, I have to admit I don't really like having to switch between two displays.