Error - Homing failed after upgrade to RRF3.2

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.