Homing X or Y will cause Z to considered homed
-
I have a bed that moves up and down, with two leadscrews, there's a really long travel limit switch at the bottom
The activation point of the switch is NOT my Z's zero. There are beefy locking shaft collars on all my Z shafts (all corners of the printer) and leadscrews that set the true zero, this is done to make sure that the two Z shafts are always in sync after homing (which stalls both motors on purpose), and it makes sure the bed doesn't flex when I use a putty knife to remove the print.
(the limit switch is there to ensure that the long 300mm down travel doesn't cause me 30 seconds of loud motor stalling noises CLICK CLICK CLICK CLICK CLICK CLICK CLICK CLICK CLICK when the bed was actually only 100mm off the ground, the switch is simply there to tell the bed motors to slow down, "hey you only have 5 more millimeters left, not 200mm, slow down", not stop)
X and Y axis uses stall detection for homing, don't worry about this, irrelevant, except I'm stating this so you know when I say "switch", it can only ever refer to the Z bottom limit switch.
My homex and homey scripts have a bit that moves the bed down 10mm if the switch is not pressed, and then at the end, moves the bed up the same 10mm, only if the switch is not pressed. (in case I use homex to recover from power-outage or layer shift)
At the end of my homex and homey, there's a G92 to set X or Y to 0, I don't set Z coordinates in these scripts
When I click Home X while the switch is depressed, at the end of the script, both X and Z are considered homed
This is wrong! Z is not homed until I ram it against my shaft collars, just because the switch is down, doesn't mean it's homed.
If I do it while the bed is elevated (but not considered homed), the bug doesn't happen, Z remains not homed.
If I power off my printer with the bed against the switch, spin one Z leadscrew by hand to throw it out of level, start the printer, and press Home X, it will think Z is homed, if a print starts, it will fail because the Z platform is not leveled.
This I've tried to work around this problem: deconfiguring the limit switch near the end of homex.g doesn't seem to make this problem go away, Z is still considered homed if it was down, probably because of the optional 10mm Z dive
removing the limit switch config from config.g and moving it into homex and homez doesn't help either
the only thing that helps is removing the Z dive from homex altogether, regardless of where I configure/deconfigure my limit switch
this means that I need to move the Z dive into the failure-resume script instead, which is an acceptable workaround
but I do suggest you re-think how your homing logic works, the key point here is: just because the switch is depressed, doesn't mean it is homed. switches can have a lot of over-travel.
(and the detection is only occurring while a move command happens? that's also weird)
-
@frank26080115 Suggest you post the actual homing files that you are using, and also any other macros that you are using. Your configuration files might be useful too. Without that information, it is impossible to make any kind of informed opinion or suggestion.
-
The homing file that exhibits the bad behaviour: https://github.com/frank26080115/HephaestusConfig/blob/16ae781d3dfe3e088e128c1d193fb98bccd60dc4/duet/sd_card/sys/homex.g
The homing file that does not exhibit the bad behaviour: https://github.com/frank26080115/HephaestusConfig/blob/master/duet/sd_card/sys/homey.g
(which is the work around)
(I show the homex and homey differently just to illustrate to you what works and what doesn't work, the master branch will be updated with both that works, so don't look at master branch)
For the rest of the files you might be interested in: https://github.com/frank26080115/HephaestusConfig/tree/master/duet/sd_card/sys
-
Hi,
When issuing a G1 command with a H1 (used to be S) parameter for a given axis, if there is a endstop switch configured for that axis, when the switch is triggered that axis is considered to be homed regardless of the axis position or direction of the move.
In your "home x" file you are issuing such commands for the Z axis. If the switch triggers during those moves, Z will be considered to be homed.
That's just the way endstops are treated when the H1 parameter is used during a move.
And just FYI when using the H1 parameter you don't need the H564 commands.
You might be able to use the M581 command to setup a trigger or perhaps the M577 command. I haven't tried either of those but it should be simple to devise a test to determine if one of them would work.
Frederick
-
Thanks, you've confirmed the behaviour I've suspected through my experiments
I don't think that's a good thing for the firmware to do. Like I explained, just because the switch is pressed, doesn't mean it's in the right position to be considered homed, due to the possibility of switch over-travel. This could cause problems, especially with dual Z motors that might be out of sync.
But since you know about it, fixing it would probably break some of other people's gcode files... I guess a new parameter to the G0/G1 moves might help keep compatibility and prevent the system to flag the axis as homed
-
@frank26080115 said in Homing X or Y will cause Z to considered homed:
Thanks, you've confirmed the behaviour I've suspected through my experiments
Like I explained, just because the switch is pressed, doesn't mean it's in the right position to be considered homed, due to the possibility of switch over-travel.
While a switch may have "over-travel", electrically it is either closed or open. All the Duet can do is respond to the state of the switch being opened or closed. It cannot determine if a switch is "mostly closed".
Frederick
-
If the repeatability is the problem then move the axis to close the switches, back off a few mm and home again at a much lower feedrate? if that still isn't accurate enough, then you'll have to look at other types of limit switches (ir/inductive/capacitive)
-
As I understand it, you want to move Z until it reaches a switch. Once that switch is triggered, you then want to continue to move Z but use stall detection to complete homing. Is that correct? If so I think this is easy.
When you home X and Y, keep the Z axis well away from it's homing position so that no Z switch will ever trigger. Z homing state should only change if you use G1 Znn with an S1 parameter but if you move both X and Z with an S1 parameter, then for sure Z will be considered homed if it's switch triggers.
In your home Z, you start with M574 set to use S0 or S1 depending on whether your switch is active high or active low. Then home Z and back off a few mm. Next, (still in homez) you reconfigure the end stop using the S3 parameter for stall detection. Then home Z again. This time, it should ignore the switch and rely on stall detection. To be safe after that homing, reset M574 to use the switch again so that next time you homez, it will do the same thing.
I think that would work if I understand correctly what it is you are trying to do.
-
Here's another way that might work. If you use H3 or S3 instead of H1 or S1 in the G1 command, then it will still stop if the endstop switch is hit, but instead of setting the current Z height it will adjust the M208 limit to match the recorded height. You don't want it to do that of course, so you would need to reset the M208 Z limit afterwards.
-
I have encountered a scenario in which this behaviour may seem problematic and a potential solution.
My endstop switches have only 1.5 mm of total travel, and they advise NOT to bottom them out. (I'm sure doing it lightly couldn't hurt but with any force behind it, it could damage the switch -- a contact switch from metrol).
In order to avoid bottoming out the switch, homing must be performed with the deceleration phase in mind, and speed limited so as to prevent the deceleration phase from becoming 1.5 mm or greater.
In my homex, y, z, u files I too want to move Z up (bed down) to allow X/U and Y to home without interference. I want the axis to stop if it happens to hit an endstop. If this move is not performed delicately, as Z homing must be, the switch could be bottomed out and/or the recorded home position for Z might not be accurate.
To resolve this, I will simply move my Z axis in my homeXYU files delicately as if I was homing it, in case it does get homed incidentally.
