Error - Homing failed after upgrade to RRF3.2

deckingman

I'm getting an error message when homing my Z axis although the actual process seems to be working. I get M292 then "Error - homing failed". This error is coincidental with the upgrade of firmware to 3.2 from 3.1.1. The firmware upgrade worked flawlessly and I can confirm that the main board and all 3 expansion boards are report the firmware was being 3.2. (All boards being gen 3.)

I don't use a Z probe as such - I have a precision switch connected to the (kinetic) hot end mount nozzle such that when the bed touches the nozzle, it lifts the hot end off it's seat and that breaks the switch.

The switch is configured thus

M574 Z1 P"2.io1.in" ; Expansion board 2, io1.in and inverted

The homing macro is a little complicated. Basically, if the bed is long way down, a separate macro does 100mm fast Z moves until the bed is within less than 100mm of the nozzle. This is sensed by a separate switch on a swinging arm. The error I get happens regardless of whether this "fast jog" macro runs of not.
After this I heat the nozzle to about 140 deg C to soften any plastic, then wipe the nozzle, then move to more or less the centre of the bed, then do the "normal" G1 Z-nn H1 moves. I do a fast pass, then lower the bed 5mm and repeat at a slower speed.

As near as I can tell, the error appears after the second, slow pass, not at the first, faster pass. It should be noted that the axis turns orange to indicate that it is un-homed at the start of the process, then turns blue showing that it is homed at the end of the process (despite the error that says homing failed).

Everything appears to work as it should and I can see the switch trigger (it has an LED attached to it). After the second pass, the bed is dropped by 5mm. The only other thing which looks incorrect is that the Z position never changes. i.e., if it is showing Z=4mm at the start of homing, that is what it shows throughout. I don't see it change to zero when the switch triggers and the bed stops, and after the second pass, Z is moved by plus 5mm but DWC still shows it as being at 4mm.

Here is the entire macro - I've annotated it so it should make sense.

; home z for CoreXYUVAB
; start by warming the hot end so that any oozed filamnt is molten
; ************XYUVAB must be homed first*************

; check if end stop already triggered

if sensors.endstops[2].triggered 
	abort "Z endstop already triggered at the beginning of the homing move - aborting"

; check if X and Y are homed
if !move.axes[0].homed || !move.axes[1].homed 
	abort "X and/or Y not homed - aborting"

TO; select a tool - any one will do
M104 S140; heat to 140 but don't wait
M584 P7 ; use P7 to make all visible 
M98 P"0:/macros/FastJogZ.g" ; home all axes (at high temp)
; reduce motor currents to 50% for Z 
M400 ; wait for any moves to finish (shouldn't be any)
M913 Z50 
G90; set to absolute coordinates 

G1 X50 U50 A50  F12000; move right 50mm  
G1 Y364 V364 B364; now move to rear while nozzle heats so that it gets wiped 
M291 P"Waiting for hot end to heat" R"Homing Macro" S1 T20
M109 S140 ; continue heating hot end to 140 but this time wait

M98 P"0:/macros/Nozzle wipe" ; now wipe the nozzle

G1 X170 U170 A170 Y180 V180 B180 F12000; now move to more or less centre of bed

; FAST home Z 
G1 Z-740 F300 H1
M400;wait for move to finish

;Lower bed again
G91 ;realtive
G1 Z5 F300 ; lower bed
G90 ;absolute

; SLOW home Z
G1 Z-10 F60 H1

; set off set 
;move positive by switch offset amount
;G1 Z0.30; ****Adjust whenever switch is changed or repositioned******** 
;G92 Z0 ; set new zero

; lower bed again
G91 ;relative
G1 Z5 F300
G90 ; back to absolute

M400 ; wait for moves to finish then restore motor currents to 100% for Z
M913 Z100 

M104 S0; set hot end temp back to zero

I repeat that all moves seem to complete as expected. The error message seems to appear in the console after the second, slow pass - not at the first, faster pass). I have in the past applied an offset by doing a small z move then using G92 but these lines are all commented out.

Also, this has been working fine on firmware 3.1.1 - it only started today after upgrading to 3.2.

EDIT. I'm running stand alone - no SBC involved.

EDIT2 - XYUVA and B all home correctly and without errors - only the Z axis is giving me problems.

Phaedrux

Only thing I see a little unusual is the use of G90 absolute moves to seek the endstop. Typically they would be relative moves.

@deckingman said in Error - Homing failed after upgrade to RRF3.2:

; FAST home Z G1 Z-740 F300 H1 M400;wait for move to finish ;Lower bed again G91 ;realtive G1 Z5 F300 ; lower bed G90 ;absolute ; SLOW home Z G1 Z-10 F60 H1

deckingman

@Phaedrux said in Error - Homing failed after upgrade to RRF3.2:

Only thing I see a little unusual is the use of G90 absolute moves to seek the endstop. Typically they would be relative moves.

@deckingman said in Error - Homing failed after upgrade to RRF3.2:

; FAST home Z G1 Z-740 F300 H1 M400;wait for move to finish ;Lower bed again G91 ;realtive G1 Z5 F300 ; lower bed G90 ;absolute ; SLOW home Z G1 Z-10 F60 H1

Agreed that looks a little odd ............... but it's how I've always done it and it's worked for years up until now.

Still it's easy enough to change and test - I'll do that tomorrow (it's getting a little late here in the UK).

deckingman

Update.

Despite the lateness of the hour, I changed that absolute to relative - still get the error.

Also, I then commented out the second pass, so after the print head moves to the centre of the bed, all I do is change to relative, then G1 Z-740 F300 H1. As soon as the switch triggers, I then get the error message M292 Homing failed.

Where does that M292 come from? According the wiki, it says quote ....

"This command is sent by the user interface when the user acknowledges a message that was displayed because of a M291 command with parameter S=2 or S=3. The P parameter is ignored unless M291 was called with S=3."

But I don't use any M291 in my homing macro - very weird.

But as I said before, at the start of the macro the axis is immediately flagged as not homed, then after the homing move, it turns blue in DWC and shows as being homed (even though I get the error message saying it that homing failed). And the reported Z position after homing is 4mm but there is a G1 Z5 which should leave it at 5mm.

Phaedrux

@deckingman said in Error - Homing failed after upgrade to RRF3.2:

M291 P"Waiting for hot end to heat" R"Homing Macro" S1 T20

What's all this then?

deckingman

@Phaedrux Ahh missed that. So I do have an M291 but without an S2 or S3 so I still should not be getting an M292 (and I've never seen it before with earlier firmware).
I don't really care about it. I only mention it because because it might give @dc42 a clue about the real problem of homing failure since upgrading to 3.2.

deckingman

OK. So 2 things.

Number 1. By a process of elimination, I've narrowed the cause of the homing failed message down to this line in my homing macro...........

M109 S140 ; continue heating hot end to 140 but this time wait

If I comment out that line, homing completes without the error message. If I remove the comment so that the command becomes active again, then I get the error message "Homing failed". It's repeatable and consistent. But as I've said repeatedly, homing does not actually fail.

Number 2. When my homing switch triggers, Z is reported as being at -1 rather than zero. That explains why, after dropping the bed 5mm, Z is reported as being at 4mm. I'm dammed if I can find where that offset is coming from. I noticed that my M574 Z1 did not have an "S1" so I added that in (although I think S1 should be the default) but that has made no difference. Maybe there is something that I just can't see in my config.g. Here it is.........

config.g

Edit. I guess I could work around #2 by doing G92 Z0 before dropping the bed again, but I'd rather find the real reason for the -1 offset.

Edit 2. Semi-random thought......I've never got around to tuning the heater on this particular hot end variant. So the temperature isn't very stable. Might that be a clue? Might the "Homing failed" error message actually be an erroneous message that ought to be something along the lines of "hot end temperature not stable".

gloomyandy

@deckingman The lower limit for Z is defined as -1 in your config.g file. According to https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move G1 H1 will set the position to the axis limit. So perhaps that is the cause of your -1 position? I'm surprised that has changed since 3.1.1 though.

deckingman

@gloomyandy said in Error - Homing failed after upgrade to RRF3.2:

@deckingman The lower limit for Z is defined as -1 in your config.g file. According to https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move G1 H1 will set the position to the axis limit. So perhaps that is the cause of your -1 position? I'm surprised that has changed since 3.1.1 though.

Of course !!! How could I have been so stupid to miss that !. Many thanks - a second pair of eyes is often a great help.

(BTW, setting Z min to be -1 was a very recent (temporary) change but I haven't used the machine for few weeks and had completely forgotten about it - so it would also have been an issue in 3.1.1. as well).

That's one mystery solved - just the homing error message which I guess @DC42 will need to comment on.

dc42

Has that M109 command in your homing file ever worked? If so then I am surprised, because if no tool is selected then that M109 command will cause a tool change to your lowest numbered tool. The state machine that handles homing and tool changes isn't designed to handle both simultaneously.

A Former User

Hi,
@deckingman
I hope you do not mind deckingman that I join here but it is related:

just updated to RRF3.2 (Hardware duet-ethernet-1.4):

On the company-printer I used to have inside "homeall.g" a double-check for whoever uses it

M291 R"Homing all axis?" P"make sure nothing is in the way" S3 ;T5

With RRF3.2 that throws the following error(s):

If I comment that line within homeall.g out, everything is fine and no error(s) appear

I can confirm that with or without M291 all axes turn within DWC from yellow/orange (unhomed) to blue (homed) - so I might ignore it for now

Regards

Edit: Tryed without M291 but with a M292 within homeall.g (clear message(s)) - M292 does NOT seem to have any effect, no error(s) here

Edit2: Tryd with M291 followed by M292 within homeall.g (clear message(s)) - errors posted earlier in this post are present

deckingman

@dc42 said in Error - Homing failed after upgrade to RRF3.2:

Has that M109 command in your homing file ever worked? If so then I am surprised, because if no tool is selected then that M109 command will cause a tool change to your lowest numbered tool. The state machine that handles homing and tool changes isn't designed to handle both simultaneously.

Yes of course it works and always has done. If you look at the full macro posted above you'll see that it starts with a "T0", followed by "M104 S140" to start heating the tool but without waiting. The M109 S140 follows on after.

This is partly because when running home all, I start by heating the hot end but without waiting, then home XYUVA and B, then wait for the hot end to finish heating, then do the nozzle wipe before homing Z. To create the home Z file, I merely copied and pasted the relevant bits. I could remove the initial M104 but I need to retain the M109.

dc42

@deckingman, does the problem go away if you comment out the M291 line?

deckingman

@dc42 said in Error - Homing failed after upgrade to RRF3.2:

@deckingman, does the problem go away if you comment out the M291 line?

No. Not on it's own.

dc42

You could try using M116 P0 instead of the M109 command.

deckingman

@dc42 said in Error - Homing failed after upgrade to RRF3.2:

You could try using M116 P0 instead of the M109 command.

OK. As a work around (at least for my case), replacing the M109 with M116 P0 seems to fix the issue. As does commenting out that single M109 (but leaving every other command intact).

BUT. This needs fixing. I have numerous different home all and home Z files for my various machine configurations which all do slightly different things. I could go through and change all those files but I'm not at all happy about the prospect of having to do so, nor do I see why I should have to.

I've suffered too many problems in the past with issues caused by running beta versions or release candidates, which is why I have waited for a stable release before upgrading. I'm very disappointed to find that this "stable" release appears to have issues, and once again, I'm now wondering what other problems might exist which might not be so obvious to spot.

hackinistrator

@deckingman
maybe try pid tuning the heater , if you wish to leave m109 command .

JayJay

@hackinistrator said in Error - Homing failed after upgrade to RRF3.2:

@deckingman
maybe try pid tuning the heater , if you wish to leave m109 command .

That might be a little bit difficult to do Firmware Limitations

PCR

@deckingman said in Error - Homing failed after upgrade to RRF3.2:

I've suffered too many problems in the past with issues caused by running beta versions or release candidates, which is why I have waited for a stable release before upgrading. I'm very disappointed to find that this "stable" release appears to have issues, and once again, I'm now wondering what other problems might exist which might not be so obvious to spot.

But you have to admit that you have a pretty specific edge case! Even stable software from big companys need bugfixes although they are releasing stable versions. IMO i think that 3.2 is stable enough for most use cases.

But for 3.3 a Idea would be to use a second Pi only for Beta Testing. Then i think that Most Bugs that effect your Special use Case would be fixed in the stable Most of the stuff reported in the 3.2 cycle was fixed.

JayJay

@PCR said in Error - Homing failed after upgrade to RRF3.2:

@deckingman said in Error - Homing failed after upgrade to RRF3.2:

I've suffered too many problems in the past with issues caused by running beta versions or release candidates, which is why I have waited for a stable release before upgrading. I'm very disappointed to find that this "stable" release appears to have issues, and once again, I'm now wondering what other problems might exist which might not be so obvious to spot.

But you have to admit that you have a pretty specific edge case! Even stable software from big companys need bugfixes although they are releasing stable versions. IMO i think that 3.2 is stable enough for most use cases.

But for 3.3 a Idea would be to use a second Pi only for Beta Testing. Then i think that Most Bugs that effect your Special use Case would be fixed in the stable Most of the stuff reported in the 3.2 cycle was fixed.

I might be wrong, but i think @deckingman is running in standalone mode so i dont think he would he run a single board computer at all.