Error - Homing failed after upgrade to RRF3.2
-
@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.
-
[deleted, see my later post]
-
YouTube is an amazing invention, your video's are very informative
-
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.
-
-
@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.?
-
@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.
-
@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.
-