Duet Firmware Upgrade Homeall.g or G28 doesn't work
-
I get a G0/G1: insufficient axes homed. I just saw another post that says to go to the FAQ on Wiki so I am gonna look there.
-
Ok, I may have solved my own problem. I am posting what the FAQ says so someone doesn't have to go look. This may just fix it.
FAQ States
"Recent firmware versions do not allow axes to be moved before they have been homed. The only movements allows are homing moves (G1 moves with S1 or H1 parameter) and individual motor moves (G1 moves with S2 or H2 parameter). So any Z movements that your homing files make before Z is homed should use the S2 parameter. Alternatively, add M564 H0 to config.g to allow axis movement before homing."
Not sure how I missed the post with this in it.
-
@cesther said in Duet Firmware Upgrade Homeall.g or G28 doesn't work:
M669 K1
This may only apply to 2.03 which is currently in beta and has generalized kinematics for corexy style motion. So if you're using 2.02 I think you should still be using the M667 S1 for CoreXY.
https://duet3d.dozuki.com/Wiki/Gcode#Section_M667_Select_CoreXY_or_related_mode
-
I actually tried the M667 S1. This is what I started out with. I read the post where it said to look at the update notes, so I did and that is where I got the M669 K1. I thought this was done on a much earlier update. Any way when using the M667 S1 I did the home x, y, and z work as they should individually, however the homeall.g does not function and the G28 in the gcode file still won't work. I am running a print right now that has the g28 command deleted. It is about a 4 hour print. I am going to try the M564 H0 command in the config.g file when I am done with this print.
-
Yes, as you found in the FAQ that should resolve the insufficiently homed axis error you got. You can also add S2 to the moves of unhommed axis in the homing files. Usually this is from raising the Z axis before homing X and Y.
-
I'll try that after the print is done. What I don't understand is that my home routine starts with the z axis, then y, then x. This is the order that individual home routines work. I would have thought that if the homeall.g routing contained that same code it would work.
Thanks for your help. I'll post my results.
-
It would help if you posted your homing files so we could see exactly what's going on.
-
Ok, first off. The M564 H0 WORKED!!!!!! However here are the homing files for review.
Here is homeall.g
M561
G91
G1 Z0.5 F400
; home Z first
G1 Z400 F500 S1
G1 Z-4 F200
G1 Z10 S1; then home Y
G1 Y-500 F3000 S1
G1 Y4 F600
G1 Y-10 S1; then home X
G1 X-500 F3000 S1
G1 X4 F600
G1 X-10 S1
G90 -
homez.g
;
G91
G1 Z400 F500 S1
G1 Z-4 F200
G1 Z10 S1
G90 -
homey.g
;
G91
G1 Z0.5 F400
G1 Y-500 F3000 S1
G1 Y4 F600
G1 Y-10 S1
G1 Z-0.5 F400
G90homex.g
;
G91
G1 Z0.5 F400
G1 X-500 F3000 S1
G1 X4 F600
G1 X-10 S1
G1 Z-0.5 F400
G90 -
@cesther You usually have to home X and Y before you can home Z - at least that's how it used to be unless something has changed.
The reason being that most people use a probe to home Z and usually, that means moving the probe to the centre of the bed first. Hence it is necessary to home X and Y before the probe can find the centre in order to be able to home Z.
Edit - Yes I just checked on my machine and it is the same as it always used to be. i.e. the firmware won't let me home Z unless X and Y have been homed first.
-
So now my question is......Should I have used an S2 in all of these files instead of the M564 H0? Should I do both? Or don't worry about it since it works? In trouble shooting I have learned to make only one change at a time. It takes a while longer, but at least I know and understand the effects of each action.
-
Originally this machine homed x and y first, however, it was always my opinion that Z should be homed first as we have a home switch. Thus it drops the bed down out of the way. With the new firmware, I was excited to see that I could not home anything until Z was homed.
-
@cesther I use the G1 S2 instead of the M564 in all of my homing files. It doesn't make a difference on which method used.
-
I am printing a part right now, it will be done by lunch. After that I may try the S2 command without the M564. I'll try to post my results. Again, right now all is working great. Would still like to learn what does what and so forth.
Thanks everyone for your help.
-
@cesther It always used to be the case that one could move any axis before it had been homed. This meant that there was nothing to stop a gantry being moved outside it's normal limits by accidentally entering a wrong value. This was deemed as being potentially dangerous by some users - especially OEM manufactures and CNC users. So the firmware was changed to prohibit any moves until an axis has been homed.
This is a safety feature but it can be overridden either by using an S2 parameter in a specific move command or by putting M564 H0 at the end of config.g as a more "global" setting.
Once an axis has been homed, then any movement command will stop at the minimum and maximum values that have been defined for that axis. So for example if your gantry was sitting at 10mm away from zero and sent a command to move it 100mm towards zero, it would only move 10mm and stop. But if you use M564 H0 then whenever you turn on the machine, there is nothing to stop it acting on a command that could send the print head trying to go beyond the axis limits and crashing into the frame or worse.
Personally, I do use M564 H0 but I am experienced enough to understand the risks which I accept.
