[3.3 release] strange homing issue

markz

I'd like to believe this is me but I'm really confused by my HomeZ not working. Twice now it has failed and forced an emergency stop/reboot (after which it worked). I never saw this with 3.2 but it's a fairly new installation.

File:

G91 ; relative mode
; speed of 400 is set to avoid thunking into the switch
G1 H1 Z180 F400 ; move up +Z direction, stopping if the homing switch is triggered
G1 Z-4 F100 ; move slowly 4mm in the -Z direction
G1 H1 Z10 ; move slowly 10mm in the +Z direction, stopping at the homing switch
G1 Z-5 F400 ; move down 5mm zero...
G90 ; back to absolute mode
G92 Z0 ; and set Zmax to 0 here
G1 Z-20 F800

The thing is that it seems to register the homing switch just fine. It does the up and slight back and slower up and slight down and then it just starts to move all the way down into the table (at which point I hit the EStop). It's like the G92 is completely ignored.

Is it possible that I need to wait for the move to finish?

By default my system runs in coord space 2 (G55).

Mark

peter247

@markz I've had a similar problem once , but I wasn't watching what happened.
It looked like the X and Y homed then drove the Z nozzle into the bed.
I didn't think that the bltouch was deployed and was waiting for a end stop ?.

dc42

@markz said in [3.3 release] strange homing issue:

By default my system runs in coord space 2 (G55).

Have you set up any offsets in that coordinate space?

Phaedrux

Your homing files is confusing to me. You're homing to Zmax, and then set G92 Z0, and then tell it to move into the negative.

Can you post your config.g as well, and tell us where the endstop is physically located?

markz

@dc42 I'm not sure what offsets are. I do usually zero X,Y,Z to fixture locations and it may be those values are cached here. I didn't check but will next time. If so, the Z zero spot is at top or bottom of stock.

@phaedrux Yes, it's kind of strange. I set the physical Z zero to top of travel (where the homing switch is) and all other Zs are negative. That way a script can go to physical Z zero and it's always way up out of the way. Settings:

; axis limits
M208 X0 Y0 Z-130 S1               ; set axis minima
M208 X265 Y98 Z0 S0               ; set axis maxima

Some of the physical movement is just so I know it homed correctly (like this). The Z homing switch on the mill is poorly placed and sometimes gets knocked off by the air nozzle - I need to remount it. Here it's engaging ok and when I reboot the board it homes just fine with no physical changes.

Thanks, Mark

markz

@Phaedrux Well, it happened to me again just now. It seems to be rather consistent.

I haven't used my mill in a day.
Steps:
a) turn on the ATX power
b) note that Z is showing as 80mm in dashboard (so offset)
c) home Z goes up, down a little, up, then heads down into the stock
d) hit EStop
e) console M80
f) run home Z again - it works fine

I'm including my entire config.g config.g file.

System is a Duet3 (very recent) with no pi. The supply seems rather RF noisy but the milling operations to date have all been perfect.

Thank you.

Postscript: I got to thinking about the @dc42 offset comment and now have more info. I tried setting Z zero to top of stock and then home Z fails consistently with a G0/G1 move outside of physical limits (on the last move operation in the script). If I just switch to G54 the home works fine... but only once. So, I'm probably not doing the homing right or the physical boundaries right. The point to the at-startup home Z is to be able set physical limits - after which I switch to G55 and Z sensing for all logical coordinates.

I think the physical limit is set to 5mm below the homing switch. I'm in a bit of a catch22 - after turning on ATX power I have to rehome Z.

Phaedrux

The way you have your Z axis limits set, you can only ever move to a negative absolute z value. Normally you'd want to have Z0 be the lowest point of travel since all moves are likely to be in positive Z space.

Do you understand better why I find your setup so confusing and unusual?

; Configuration file for Duet 3 Mill (firmware version 3)
; executed by the firmware on start-up
;
; General preferences ---------------------------
G90                                          ; send absolute coordinates...
M550 P"DuetMill"                             ; set printer name
M552 P0.0.0.0 S1							 ; enable networking w/dhcp

M453 							; put into CNC mode
M950 R0 C"io7.out" L1000		; use the fan2 port for spindle, 
M563 P1 S"Spindle 1" R0         ; create spindle 1

; Motors ----------------------------------------
; motor definition
M569 P0.0 S0                                 ; physical drive 0.0 goes forwards
M569 P0.1 S0                                 ; physical drive 0.1 goes forwards
M569 P0.2 S0                                 ; physical drive 0.2 goes forwards
M584 X0.2 Y0.1 Z0.0       ; set drive mapping X to 0, Y to 1 and Z to 2
M350 X16 Y16 Z16  I1       ; configure microstepping with interpolation
M92 X1280.00 Y1280.00 Z1280.00      ; set steps per mm
M566 X500 Y500 Z500		 ; set maximum instantaneous speed changes (mm/min)

; Tested: X@2400 is fine.
M203 X1800 Y1400 Z800   ; set maximum speeds (mm/min)
M201 X75 Y75 Z75    	 ; set accelerations (mm/s^2)
; use about 80% of power rating for heat
M906 X2000 Y2000 Z2000 I30   ; set motor currents (mA) and motor idle factor in per cent

; axis limits
M208 X0 Y0 Z-130 S1               ; set axis minima
M208 X265 Y98 Z0 S0               ; set axis maxima Y could be 140
; set Y home position to 87 so the table boundary won't hit the screw at end of Y travel

; Endstops ----------------------------------------
M574 X2 S1 P"io1.in"            ; x active low max X
M574 Y2 S1 p"io3.in"            ; y
M574 Z2 S1 P"io5.in"           ; z   

; Z probe definition
M558 P8 C"!io4.in" H50 F200 T800 A1 S0.1  ; define Z probe and set dive height, probe speed and travel speed
; P8=switch, A1=probe once, S=0.1mm tolerance, 
G31 X0 Y0 Z0                            	; set probe offsets

; io2 is the endstop
M950 J1 C"io2.in"	; define pin1 as io2.in
M581 P1 T0  ; map pin1 to trigger 0 (estop)

; Fans ------------------------------------------
; set up two temperature sensors
; so mcu varies fans
M308 S2 Y"drivers" A"DRIVERS"                  ; configure sensor 2 as temperature warning and overheat flags on the TMC2660 on Duet
M308 S3 Y"mcu-temp" A"MCU"                     ; configure sensor 3 as mcu temp
; Fans 0 and 1 have explicit 3d printer uses so...
M950 F2 C"!out5" Q2500                         ; create fan 2 on pin out5 and set its frequency
M106 P2 H2:3 L0.35 X1.0 B0.3 T28:50              ; set fan 2: use sensors 2 & 3, 1/3V at min, 1V at max, 300ms turn-on blip, thermostatic value
M950 F3 C"!out6" Q2500                         ; create fan 3 on pin out6 and set its frequency
M106 P3 H2:3 L0.35 X1.0 B0.3 T28:50              ; set fan 3 as fan 2 

; set up the air pump - change this with RRF 3.3
M950 P6 C"out1"  ; map out1 to Output 6 (default for MPCNC post)
M42 P6 S0	; turn off out4

; use second coordinate system
G55

I'll have to take a closer look at your config.g a bit later.

markz

@phaedrux @dc42 Thanks, I'm a dummy. I ran it line by line (with existing offsets) and the last move is absolute but the G55 offset is still in effect. All three of my homes were wrong but because I always home Z first it was the only one I saw failing. I just did the move relative and all good.

Thanks so much for the help. (@dc42 too).

why: My CNC router came from the factory with this setup (Z0 at top) which I thought was dumb but upon reflection kind of liked it (and the existing macros all assumed it) so I kept it with both the mill and when I upgraded the router to a Duet2. The local (G55) Z zero is always at top or bottom of stock, I just use the physical limits to avoid wracking the ballscrews at ends.

dc42

@markz, workplace coordinate offsets are not normally applied when running system macros, including homing files. So I am wondering if there has been a regression between 3.2 and 3.3. Are you running the Duet in standalone or in SBC mode?

markz

@dc42 That might explain why it seemed to start failing with 3.3. Still, it was bad code (imho) since it relied on a side-effect and using relative means I should work either way - so I'm good for now.

I'm running in standalone mode.