Error - Homing failed after upgrade to RRF3.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.............

deckingman

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

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.

Correct. I got bored of waiting for something to happen which would give some benefit to using an RPi - especially given the downsides related to the longer start up time etc. So I've removed the RPi and installed home assistant on it. At least it's doing something mildly useful - even if that's simply turning a few lights and things on and off around the house ..........

deckingman

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

...................Then i think that Most Bugs that effect your Special use Case would be fixed in the stable ...........

Homing Z with a simple switch instead of a probe - just like X and Y, is a "special use case" ? This is how all machines were homed before BL touch and IR probes came into being. Something as basic as homing Z which worked in 3.1.1. and now fails using 3.2 is because of my special use case?

This is why I can never get anything fixed - whatever the issue I come across, it's always because of my "special use case".

deckingman

Is this going to get fixed or looked at?

To recap, since upgrading to 3.2, I get a "Homing failed" message after homing my Z axis. I've spent hours tracking the cause of the problem which I've narrowed down to one M109 command, although another user has reported the same problem with a different command in his homing file.

I do have a work around which is to replace that M109 with M116 P0.

BUT. Because of the way I configure my machine, and the fact that I use the nozzle as a probe, and that I have 3 different hot ends, I have a number of homing files. I have home Z, home all, but also use different home all "pre-print" compared to just doing a home all (because things happen in a different order). And because I heat the nozzle to soften any blobs of plastic prior to homing, I have different pre-print home all macros depending on the filament I use. So around 5 homing files which include the Z axis - for each hot end - and I have 3 configuration folders making around 15 files. Then I have backup copies on both a local NAS and cloud storage.

So to implement this work around, potentially I'll need to edit in the order of 45 files. It would be a lot less work for me if the firmware issue got fixed - but I suspect I know what I'll end up having to do ............

dc42

The problem here is that the M109 command was created in the early days of RepRap, when 3D printers had only one tool and there was no concept of a tool being active or not. RRF already has to jump through hoops to handle the case of M109 being commanded when no tool is selected, which is unfortunately what many slicers generate.

The recommendation of RRF (since before I got involved with it) is to use G10, followed by M116. It's also possible to use M104 followed by M116, provided that a tool is selected when M104 is issued.

Why do you want to heat the tool during homing? Surely homing and tool heating are two completely separate operations? Or is is that heating the tool affects the homing accuracy?

I can look at supporting M109 during homing, but it will need to abort if no tool is selected (instead of selecting the lowest-numbered tool), requiring extra code complexity.

deckingman

@dc42 Christ, I wish you would read what I post!

I've explained the usage case and the reason why I have to heat the nozzle multiple times - I'm not going to waste my time repeating it all again if you can't be bothered to even read it.

And another user has posted the same "Homing failed" message in this very same thread - and he doesn't heat the nozzle or use M109!!!

My last word on this.

.....oh, what's the point in even typing anything more. You clearly don't want to even read what I've already written, so you won't read this................