Error - Homing failed after upgrade to RRF3.2

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.

deckingman

@PCR You are of course entitled to you opinion. But you have no idea of the history of my relationship with the Duet team which goes back to their very first 06 board. If you did, you might think otherwise. There was a time when they welcomed my efforts to explore new concepts and ideas and we could work together to "push the boundaries".

Sure my machine is an "edge case" as you put it. It is unique but all of the concepts have been individually copied and used by others. It isn't the only machine that uses a mixing hot end, but it was me who requested (and got) the ability to retract all filaments concurrently using Duet firmware. The machine is the world's first CoreXYUV with extruders mounted on a separate gantry. Others have since built their own variants but I designed and built that first one and the Duet guys wrote the kinematics for the axes to be individually homed. Then I added a dynamic load balancing gantry and the Duet guys (eventually) added the kinematics to support these additional AB axes. This concept was copied and won an award at a RepRap festival in Scandinavia somewhere. I could go on but you get the idea. I like to think that my efforts have benefited others - including the Duet team who ultimately get to sell more boards.

But when Gen 3 products came out, I got thrown under a bus and even now, after more than 18 months, my machine lacks some of the functionality it had with gen 2 due to firmware limitations.

You aren't the first to intimate that Duet products are only for mainstream users. Sadly, that was not always the case.............