Error - Homing failed after upgrade to RRF3.2

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

[deckingman]

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

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

Config.g is unchanged. All tool change macros (tpre and tpost etc) are non-existent unless firmware upgrades install them. In which case they will be empty (or contain whatever defaults the firmware chooses to add). To be clear, I've never used them so I've never put any commands inside those macros if the have been created by firmware.

This is the pre-print homing macro which exhibits the behaviour since "upgrading" to 3.2 and which is unchanged since it worked on 3.1.1, with the exception that the M109 command has bee replaced with M116.

;Pre-print homeall.g
; For 7 axis (3 gantry homing)


; start by warming the hot end so that any oozed filamnt is molten

TO; select a tool - any one will do
M104 S175; heat to 175 but don't wait

M584 P7 ; use P7 to make all visible 

M584 X3.2 Y3.1; temporarily map X3.2 and Y to 3.1 only

;*****Home XYUV (lower 2 gantries)


; reduce motor currents to 25% for XYUVAB 
M400 ; wait for any moves to finish (shouldn't be any)
M913 X25 U25 Y25 V25 A25 B25 

G91 ; set to use relative coordinates

G1 Z5 F600 ; move bed down 5 mm

;G1 X-380 U-380 Y-380 V-380 F4800 H1; move all 4 axes fairly quickly until one or other triggers a switch

G1 Y-380 V-380 F4800 H1; now move Y and V fairly quickly forward until one or other triggers a switch

G1 Y-380 F1200 H1; course home Y
G1 V-380 F1200 H1; course home V

G1 Y10 V10 F600; Go back a few mm

G1 Y-380 V-380 F360 H1; Move slowly to Y and V axis endstops once more and stop when one triggers

G1 Y-380 F360 H1 ; fine home Y 
G1 V-380 F360 H1 ; fine home V

G1 X-380 U-380 F4800 H1; now move just X and U fairly quickly left until one or other triggers a switch

G1 X-380 F1200 H1; course home X
G1 U-380 F1200 H1; course home U

G1 X10 U10 F600 ; Go back a few mm

G1 X-380 U-380 F360 H1; Move slowly to X and U axis endstops once more and stop when one triggers

G1 X-380 F360 H1 ; fine home X 
G1 U-380 F360 H1 ; fine home U

;****Now home upper Gantry

G91 ; set to use relative coordinates

G1 A-380 B-380 F4800 H1; move A and B fairly quickly until one or other switches triggers
G1 A-380 F4800 H1 ; course home A
G1 B-380 F4800 H1 ; course home B

G1 A10 B10 F600 ; back off a few mm

G1 A-380 F360 H1 ; fine home A
G1 B-380 F360 H1 ; fine home B

M400 ; wait for moves to finish then restore motor currents to 100% for XYUVAB but leave Z at 70%
M913 X100 U100 Y100 V100 A100 B100 


;***Now home Z****

G4 P500; wait 500 ms
M104 S165; heat to 165 but don't wait

M98 P"0:/macros/FastJogZ.g" ;

; 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
M116 P0 ; continue heating hot end to 175 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
G92 Z0 ; set to zero
G4 P1000; 1 sec delay

;Lower bed again
G91 ;relative
G1 Z5 F600 ; lower bed
G90 ;absolute
M400

; SLOW home Z
G1 Z-10 F60 H1
G4 P1000; 1 sec delay

G91 ; relative
G1 Z0.15 ;slightly lower
G4 P1000; 1 sec delay

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 

As you will have observed, it's complicated routine and I really can't be ars*d to spend hours agian tracking down and isoltaing which particular command in all that lot is responsible.

For the sake of completeness, here are the other two macros which get called from that homing macro.

; Fast Jog Z
M400; wait for any moves to finish
G91; Set relative
echo "Switch Closed
while sensors.gpIn[2].value=0
	G1 Z-1 F900; move
	M400; wait for move to finish
	
echo "Switch open" 
echo "Fast moves completed" 

; Nozzle wipe
; ****Printer must be homed and nozzle heated

G90; set to absolute coordinates 

G1 X50 U50 A50 Y364 V364 B364 F12000; move quckly to rear left
G1 X60 U60 A60 Y344 V344 B344 F900; slowly right 30, forward 20
G1 X70 U70 A70 Y364 V364 B364; slowly right another 30 and back 20
G1 X80 U80 A80 Y344 V344 B344; slowly right anither 30 and forward 20
G1 X90 U90 A90 Y364 V364 B364; back and right 

Edit. Those lines which contain {1} are just blank lines in notepad++. I have no idea why they show up as {1} when I copy and paste into this forum. Could that be clue?

[Phaedrux]

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

Edit. Those lines which contain {1} are just blank lines in notepad++. I have no idea why they show up as {1} when I copy and paste into this forum. Could that be clue?

The forum software seems to insert them sometimes. Not sure what kind of blank space character it's picking up, but sometimes it happens and others not.

[deckingman]

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

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

Edit. Those lines which contain {1} are just blank lines in notepad++. I have no idea why they show up as {1} when I copy and paste into this forum. Could that be clue?

The forum software seems to insert them sometimes. Not sure what kind of blank space character it's picking up, but sometimes it happens and others not.

I was wondering if either the firmware or DWC was also picking them up and that is somehow triggering the homing failed message? Just clutching at straws..........

[matt3o]

@deckingman mh this is interesting, are you saving the files in UTF-8 and linux line ending? can you put the file somewhere and link it here (not copy/paste)

[deckingman]

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

@deckingman mh this is interesting, are you saving the files in UTF-8 and linux line ending? can you put the file somewhere and link it here (not copy/paste)

This link should work. I've no idea about formats - I've always used notepad++ so line endings are whatever that defaults to. It worked fine up until I upgraded to 3.2.

https://drive.google.com/file/d/1L7uu5uevBgMd6zrezFtjNgbVUQlpREFI/view?usp=sharing

[matt3o]

@deckingman yes, you are using windows line endings (CRLF), just to rule that out, can you try to save the file in linux format (LF)?

PS: of course you need to reupload it to the duet. I know it's a long shot....

[dc42]

I am looking at this issue now, because it is one of four outstanding issues I had scheduled for investigation before the 3.2beta1 release.

I have replicated your configuration on the bench, with minor changes. So far I have found the following:

• If I run the homez.g file that you posted in your first post in this thread, I always see the "Homing failed" message. However, the Z axis has been homed and it is safe to print.
• If I replace the M109 command by either M116 or M116 P0, then I never see the "Homing failed" message. I have tried repeatedly, freshly from power up, after homing already, and after homing but subsequently sending M18 Z to flag the Z axis as not homed.

The M109 command invokes an implicit tool change as I pointed out before, and I had not previously considered the effect of using M109 within a homing file. But as you appeared to have a tool selection command near the start of the file, earlier than the M109 command, it puzzled me that it should cause a problem, because if a tool is already selected when M190 without a T parameter is commanded, there will be no tool change.

Then I noticed that the command at the start of your homez.g file is TO (uppercase "o") not T0 (digit "0") as I presume you intended. So the T command is being interpreted as requesting the current tool number to be echoed (if you send TO from the command prompt, it reports "No tool is selected"). Therefore, when you run the file, unless you have previously selected a tool, there will be no tool selected when the M104 and M109 commands are run. In that case, they will both default to the lowest-numbered tool configured, which is tool 0. The M104 command will therefore set the active and standby temperatures of tool 0 to the requested 140C. The M190 command will also be applied to tool 0, and will implicitly cause tool 0 to be activated.

This isn't the whole story because:

• If I replace TO by T0 then I still see the "Homing failed" message if I use M109;
• You reported that you still get the message when you replace the M109 command by M116; but I haven't been able to reproduce that.

I will carry on investigating why the message is produced when M109 is used in the homing file.