Error - Homing failed after upgrade to RRF3.2

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.

deckingman

@dc42 To be clear, after changing M109 to M116 I do NOT get the homing failed message using the first "stand alone" homing macros that I posted. That did indeed fix the issue with those particular files.

BUT, I DO still get the homing failed error message when I run my pre-print homing macro which I posted on 23rd Jan above. This file already has the change from M109 to M116 so something else in that file triggers the error message.

Both files do indeed have the TO instead of T0 error. But they have always worked up until RRF 3.2 - probably because I have T0 in my config.g file. In any case, I only have one heater so whichever tool is selected is irrelevant as far as heating the nozzle is concerned.

If you want to download the offending homing file, it's still available from the link I posted above on 24th Jan.

dc42

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

BUT, I DO still get the homing failed error message when I run my pre-print homing macro which I posted on 23rd Jan above. This file already has the change from M109 to M116 so something else in that file triggers the error message.

I will try that file. Can you confirm that the lines that read {1} in that code box are additional lines that the forum software inserted, rather than replacing lines that were originally in the file? If in doubt, please attach the file to a post.

Both files do indeed have the TO instead of T0 error. But they have always worked up until RRF 3.2 - probably because I have T0 in my config.g file.

Thanks, I looked but I didn't spot that before because I was expecting the T0 command if present to be at or near the end of config.g.

dc42

[deleted, see my later post]

JayJay

@deckingman

YouTube is an amazing invention, your video's are very informative

dc42

Progress! I wasn't using exactly your version of FastJogZ. When I changed to use exactly your version I got these messages:

01/02/2021, 21:53:29 	Error: in file macro line 4 column 21: meta command: control character in string
Error: in file macro line 4 column 21: meta command: control character in string
Error: Homing failed

Sure enough, there is a problem with line 4 of the FastJogZ macro:

echo "Switch Closed

The closing quote mark is missing. This is causing the macro file and the containing homeall.g file to be aborted, leaving Z showing as not homed.

In summary, the two "Homing failed" messages had completely different causes:

The original one was triggered by using M109 in a homing file. M109 and homing use the same state machine, so I am not surprised that it causes problems - it is more surprising to me that it worked sufficiently well for you in firmware 3.1. I intend to change the behaviour to produce an error message if M109 is used in a homing or tool change file.
The second one was caused by a missing trailing double quote in your called macro file, which was picked up and correctly reported by the improved error handling in 3.2. However, if you were running the command from your PanelDue, then I guess you didn't see the error message before it was overwritten by the "Homing failed" message, and you didn't check the console page for additional error messages. I ran the G28 command from DWC, so the additional messages were obvious to me.

deckingman

@dc42 Thanks for looking into this - but something doesn't stack up, for two reasons.

Firstly, everything worked fine with 3.1.1. and no changes have been made to any of the homing macros for at least 6 months.

Secondly, all macros which home the Z axis (homez.g, homeall.g and pre-print homeall .g) use the same "fastjog" macro. So the problem with the missing parenthesis should have affected all 3 of those macros - not just the "pre-print" homing macro.

Having slept on it, I think I may know why this is.

I have always kept a "master" of any printer related files on my PC here in my study. So if I make any changes or write any new macros, I do so on this PC. These file folders are synchronised with my NAS and also backed up to cloud storage.

Since I moved the printer down into my garage about a year ago, I now have an old laptop connected to it. So I transfer files from my PC over Ethernet to the laptop and upload them to the Duet board from there.

What I think has happened is that I may have come across the genuine homing failed error caused by the missing parenthesis and corrected this "locally" on the laptop but not made those changes to the "master" copy on the PC. The files I posted here are from the PC so would not have contained the changes I made "locally". So the missing parenthesis may in fact not be missing on the file that the Duet board is actually using. Similarly, if TO rather then T0 caused a real error message, then I may have already corrected that "locally". I need to check......

There are two things I could do. I could upload the "genuine" files from the Duet and copy them to my google drive. But what would probably be better is if I do what I did with the homez file. That is, comment out most commands, then re-introduce them one at a time (or in batches) so that I can isolate the particular command which is triggering the "Homing failed" error message.

The latter is more work for me and less for you but it's probably the better approach because I have the machine which generates the homing failed message but you do not.

Finally, if I do get a "Homing failed" error message, but DWC shows that the axes have in fact all been homed, is it safe to assume that the error is not "real" in terms of actual homing, and that it is safe to print.?

dc42

@deckingman, have you checked whether the trailing double-quote character is present in the macro file on your machine?

If it is, and you are still getting the Homing Failed message, then please check the PanelDue console for additional error messages. Also please double-check that you really have removed the M109 command(s) from the homeall.g file on your printer.

If the above don't reveal anything, then commenting out lines in batches sounds like a good approach to tracking down the problem commands.

Regarding everything working in 3.1, the handling of some types of error has been improved in 3.2. So it's possible that an error of some sort was occurring, but it didn't give rise to a message and didn't affect the operation of your printer sufficiently for you to notice.

deckingman

@dc42 I found some time to play around with this - not much but a bit.

The trailing double quote character was missing on the "fastjog" macro file that is on the machine. However, this in itself does not cause the "Homing failed" error message to appear (it may well generate other error messages but not the "Homing Failed error message).
The tool command in the homing files on the machine was indeed TO rather than T0 (the letter "O" rather than zero). But this on on it's own does not cause the "Homing Failed" error message.
There is indeed a T0 (zero) in the config.g file (it's at the end of the "Tools" section) and I can confirm that on power up, DWC shows Tool zero as highlighted.
So the sequence of heater commands when homing, was as follows.
T0 (zero from config.g)
TO (letter "O") at start of homing macro
M104 S140
M109 S140
The above commands did not cause the heater to behave in any way other than expected. That is to say, the hot end would start to heat, XYUVAB would be homed, then the system would wait for the hot end to reach 140, then the rest of the homing macro would complete.
The "Homing failed" message appeared right at the end of the homing sequence - i.e. after the second, slow homing of the Z axis. (But the axis itself shows as being homed on DWC)
Correcting the TO (letter O) and replacing it with the correct T0 (zero), and correcting the missing trailing quotes from the "fastjog" macro but using M109 instead of M116, still causes the "Homing Failed" error message to appear.
Using M116 instead of M109 does stop the "Homing Failed" message from appearing.
Both 109 and M116 perform exactly as expected with any heater errors

So this is very specific in being the use of M109 instead of M116 will cause a "Homing Failed" message to appear, but it does NOT have any impact on the operation of the heater, and the message itself appears right at the end of the homing macro (not during the heating process itself). Might it be the very last M104 S0 after that prior M109??? I'll comment that out to see if it makes any difference......

So I'm still baffled as to why the use of M109 causes a "Homing Failed" message to appear, when the heating process itself happens correctly and without any error. I double checked, having corrected the TO and the missing trailing quotes and it's definitely just the use of M109 which causes a homing failed message to appear later.

Finally, I quickly ran the pre-print home all macro "stand alone" and it ran without errors. What normally happens is that this homing macro gets called by another pre-print macro which takes care of other things like heating the bed and I've temporarily disabled the call to that pre-print homing macro. When I get chance, I'll re-enable it to try and pin down what's causing those Homing Failed" errors.

EDIT. The errors appear on DWC - I don't have a PanelDue. Oh, and in case you've forgotten, I'm running stand alone - I don't have an RPI either.