Error - Homing failed after upgrade to RRF3.2

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................

JayJay

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

@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................

I sympathize with your frustration, i feel the same about trying to get my banana pi to talk to the duet-3, think you need to be an OEM to be considered worthy.

dc42

@deckingman, I'm sorry, I don't have time to re-read every post of every thread I reply to. I try to follow multiple threads and I can't keep all the info they contain in my head. I didn't remember that you had already described the use case. Now that you have pointed out that you have already described it, I will go back and look for it.

deckingman

@dc42 I don't suppose you'll read this but I'll waste more of my time in writing it in case it helps others.
I have a feeling (nothing more than that), that this "Homing failed" error message which has started with firmware 3.2., might be something to do with hidden characters, line endings, or spaces between lines.
All the commands within the homing macro perform as they should and as they always have done. TO followed by M104 followed by M109 works as it always has done in terms of heating the hot end. There are no errors related to tool heating - just this "Homing failed" error message.
I have a nagging feeling that the process of editing the file and substituting one command for another (or commenting out lines) is what fixes the problem.
That would explain why it worked for the other user who has seen the same problem but who does not use M109 (or even heat his nozzle).

deckingman

Similarly to my previous post 10 days ago, I don't suppose anyone will read this either. But just in case .....

I dusted off my printer because I wanted to print something - just a simply box with lid. Having implemented my "work around" for the firmware bug that has crept in with RRF 3.2 in all my many homing files (the work around being to replace M190 with M116) when I tried to print an object, I got exactly the same homing failed error message. The "pre-print" homeall macro that gets called from the slicer start code does things a bit differently to the "stand alone" homeall macro so it contains some different commands.

To be clear, I have changed the M109 that was in this file to M116 so it's some other command in this particular macro that causes the "homing failed" message - just like it was a different command that caused the problem for another user.

It's pointless me spending any more time in isolating the exact command that triggers the message because nothing will get done about it. So I've put the dust cover back over the printer and ordered small box from Ebay to use instead of one that I could have printed if I had working firmware.

Stephen6309

@deckingman With the 3.2 betas, don't rememeber if the RCs did it. I would randomly get the homing failed error when the G30 would be executed. the printer would heat up the bed, home X and Y, goto the z homing postion and fail. Duet 3 6HC with 1LC and PI4.

dc42

@deckingman, please provide the homing file that is reporting "Homing failed" as it is now. I presume your config.g is unchanged from when you posted it earlier. Also your tpre1.g and tpost1.g files, as I see you were selecting a tool in your original homing file.