Duet2+Duex5 3.4beta5: exploding leadscrews.

H2B

Hey all,

Oddest occurrence today: after completing a print successfully on my Jubilee toolchanger, I removed the print as usual, and then clicked the "Print Again" option on DWC. Lo and behold, my G28 ran the Y and then X homing sequence, and then started the Z homing sequence.

The carriage failed to move to the center of the bed, as defined in my homez.g, and as such, the bed kept raising and seeking the endstop (conveniently located nowhere near where its supposed to be) until the anti-backlash nuts popped right off. I did get a single message stating "Error: G1/G2/G3: intermediate position outside machine limits" but I'm unsure when in the cycle this appeared.

Picture for posterity's sake:

Machine had no tools loaded (I had just completed a print), and here's the relevant sections of my gcode file in the start and end portions that would be relevant to what the machine was trying to operate.

Only thing that I think could have happened is somehow my homeu.g failed to complete, but in that case, why didn't the machine move in X or Y, but continued to move in Z?

I can easily add some conditional gcode to handle checking if axes are homed, but I really think this might be some overlooked area of the codebase that triggered this odd (and potentially machine-destroying) condition..

Start of gcode file:

M104 S235 T2 ; set temperature
;TYPE:Custom
; babystepping (PLA 0.11; PETG -0.03)
M290 S-0.01 R0
M190 S55 R55
T0 P0
T1 P0
T2 P0
T-1 P0
; BEGIN: start custom g-code
G91 G1 Z5 ; drop bed slightly
G90 ; absolute positioning
G28 ; home all axes    <---- this is where it failed.
M558 F400 S0.01
G32 ; tram bed
G32
G32
M558 F400 S0.01
G29

End of gcode file:

G1 X148.409 Y155.848 E-0.01371
;WIPE_END
G1 E-0.03 F3600
; stop printing object cable_clinger_v0.stl id:0 copy 0
M107
;TYPE:Custom
; Filament-specific end gcode 
;END gcode for filament
M104 S0 ; turn off temperature for tool
T-1 ; unload tool
;G91 G1 Z10 G90
M0 ; call stop routine
M84     ; disable motors

stop.g simply calls cancel.g, which is here:

; cancel.g
; called when a print is cancelled after a pause.

T-1                     ; park any active tool
M400
G91 G1 Z5 G90
G0 X-20 Y-20 F42000      ; return all motions to home
M140 S0                 ; turn off the bed heater.
M84 S600                ; disable motors after 10 mins of inactivity

homeall.g:

; homeall.g
; called to home all axes X Y Z and Toolchanger lock
;

G91 G1 Z5 F800 H2           ; Lift z so we don't crash
M98 P"homey.g"
M98 P"homex.g"
M98 P"homeu.g"
M98 P"homez.g"

homey.g:

; homey.g
; called to home the Y axis

; make sure everything has stopped before we make changes
M400

; Set relative mode
G91
G1 Y-400 F6000 H1       ; Big negative move to search for endstop
G1 Y4 F600              ; Back off the endstop
G1 Y-10 F600 H1         ; Find endstop again slowly

; set absolute mode
G90

homex.g:

; homex.g
; called to home the X axis
;
M400                  	; make sure everything has stopped before we make changes

G91                     ; Set relative mode
G1 X-400 F6000 H1       ; Big negative move to search for endstop
G1 X4 F600              ; Back off the endstop
G1 X-10 F600 H1         ; Find endstop again slowly
G90                     ; Set absolute mode

homeu.g (toolchanger lock axis):

; Home U Axis

G91                     ; Set relative mode
G1 U-100 F6000 H1       ; Big negative move to search for endstop
G1 U6 F600              ; Back off the endstop
G1 U-10 F600 H1         ; Find endstop again slowly
G90                     ; Set absolute mode

and finally, homez.g:

; Home Z Axis
; Set acceleration for travel moves
M204 T10000

; Lift z so we don't crash
G91 G1 Z10 F800 H2 G90 

; Move to the center of the bed
G1 X155 Y155 F42000

 ; Set the probing speed
M558 F500
; run probe 1
G30
; Set a slower probing speed
M558 F100
; run probe 2
G30

relevent entry from log file:

2021-11-02 20:20:31 [warn] Started printing file 0:/gcodes/cable_clinger_v0.gcode
2021-11-02 20:21:10 [warn] Leadscrew adjustments made: -0.072 -0.063 -0.030, points used 4, (mean, deviation) before (-0.056, 0.112) after (0.000, 0.111)
2021-11-02 20:21:29 [warn] Leadscrew adjustments made: -0.055 -0.051 -0.052, points used 4, (mean, deviation) before (-0.053, 0.114) after (0.000, 0.114)
2021-11-02 20:21:49 [warn] Leadscrew adjustments made: -0.052 -0.058 -0.056, points used 4, (mean, deviation) before (-0.056, 0.110) after (0.000, 0.110)
2021-11-02 20:23:12 [warn] 25 points probed, min error -0.155, max error 0.081, mean -0.017, deviation 0.060
Height map saved to file 0:/sys/heightmap.csv
2021-11-02 20:36:20 [warn] Finished printing file 0:/gcodes/cable_clinger_v0.gcode, print time was 0h 15m
2021-11-02 20:41:28 [warn] Started printing file 0:/gcodes/cable_clinger_v0.gcode
2021-11-02 20:41:50 [warn] Error: G1/G2/G3: intermediate position outside machine limits
2021-11-02 20:42:10 [warn] Cancelled printing file 0:/gcodes/cable_clinger_v0.gcode, print time was 0h 0m
2021-11-02 20:42:10 [info] Event logging stopped

config file attached for reference: config.g

o_lampe

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

; Lift z so we don't crash
G91 G1 Z10 F800 H2 G90

There are many invalid z-lifts in your files (without H2). I'm sure they are ignored by RRF.
This quoted one looks better, but I'd put the G90 in a separate line and add M400 afterwards. Just to make sure, the printer is in absolute mode when you move X,Y.
That's how I interpret the error message "Error: G1/G2/G3: intermediate position outside machine limits"

H2B

@o_lampe this config has been working for over 6 months without a hitch. Its just yesterday with the failed U axis home that I had the error, and the Z homing failed.

Also, why would I need H2 on Z-lifts? I'm using a 3xZ configuration and I'm moving the bed normally. What's your thinking behind this suggestion?

T3P3Tony

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

The carriage failed to move to the center of the bed, as defined in my homez.g

so the question is why this did not happen this time. has anything changed in config/firmware etc recently?

dc42

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

Also, why would I need H2 on Z-lifts?

H2 is needed when doing a Z lift in a situation in which Z may not have been homed yet, for example in the scripts to home X and Y.

H2B

@t3p3tony yes, that's the question. nothing for the firmware, config, etc. had changed.

The only thing that I can be sure happened during this whole event was that my U axis (for my tool lock) failed to home, and that threw off the Z homing macro's first couple of steps to move the carriage to the middle of the build plate.

That's about as far as I can tell. So the question would now be: Why was the error thrown and why did the macro fail to move the print head (I'm assuming the error is from line 9 of the homez.g: G1 X155 Y155 F42000

T3P3Tony

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

U axis (for my tool lock) failed to home

any idea why?

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

that threw off the Z homing macro's first couple of steps to move the carriage to the middle of the build plate

If you U is un homed, do X and Y move normally with your config? They should do as far as I can see but worth a test to understand if that could be the cause.

I assume its too late to check if X and Y say there moved to the middle (and did not) or they report that they never moved (i.e. the position is still where they were before homez was called.

H2B

@t3p3tony

U Axis failed to home due to a physical problem with the physical state of the U stepper (to skip over the details: it completely failed to home).

I have non-homed axes movement allowed in my config, so it shouldn't have impacted the movement of X and Y in the homez.g macro. I feel like it may have something to do with how macros are called when an error is triggered. For example, G1 error thrown in homeu.g, sent to console for display, but in the background the next macro is called and the first G1 command is skipped due to the error from the previous step. This may have been the case, but I'm not certain.

Also X and Y were at their endstops, so they definitely didn't move at all. You're right, its too late to check (and I'm not ready to try and recreate this event!) if DWC reported different coordinates for those axes..

T3P3Tony

@h2b said in Duet2+Duex5 3.4beta5: exploding leadscrews.:

You're right, its too late to check (and I'm not ready to try and recreate this event!)

Obviously we don't want any more dramatic leadscrew disassembly events, but it might be worth seeing if you can recreate this under controlled conditions:

Cause the U axis to not home in the same manner
see if the homeZ still fails to move X and Y.
be ready to hit the trigger manually to stop Z before any issues happen.

While this may have been a very fluky one off it would be nice to understand what happened, if we can.

H2B

@t3p3tony I've tried recreating it by removing the endstop connection, stalling the stepper during homing, etc. etc. but I can't seem to recreate the same error message I've had, and the printer still runs the Z home macro flawlessly. I'm honestly quite perplexed and chalking this one up to RRF beta gremlins

Thanks for the help in all cases!