home triggered when Z axis starts moving, limit not plugged in
-
I'm having an issue with Z home. Will try to paint the best picture I can. If you need more info please let me know.
I've run this machine successfully for about 6 months. I'm running the 3.3 firmware on a 6HC.
When I press the home button in the web interface, the Z axis moves for a split second and homes (button turns blue). The machine thinks Z is homed, but the problem is the Z limit switch isn't even plugged in .
X and Y home fine, and I'm using normally open limit switches: https://www.amazon.com/gp/product/B08736NP44/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Nothing is plugged in for the Z limit switch (see my picture of the board, pointing to the home switch location with a green pencil).
I was thinking it was some kind of torque limit or something, but I can move the linear stage with the X and Y drivers/cables no problem. With power off, I can turn it by hand and it seems normal.
I worked on it all morning and couldn't figure it out. Then I turned off power, ate lunch, came back half an hour later, and it worked! (for about 15 minutes). Then I kept having the same issue.
Seems like an intermittent driver issue. Has anyone had this before?
Maybe I hot swapped the motor at some point and it damaged the driver. But I don't know how that would affect the Z limit.
Files are attached. Has anyone seen this before, triggering home without anything plugged into home?
Maybe I'll buy a new 6HC and see if anything changes.
-
@solarsamuel The only time that end stops are checked is when you home the printer. So if the status changes to homed as soon as you start to move Z, then it means that the end stop is triggered. Now, as there is nothing plugged in to the board, and it's configured as a normally open switch, then it might mean that there is a short between the pins of the connector or a short on the board itself. I'm not familiar with the circuit diagram, but usually io pins have either a pull-up or pull down resistor so it might a fault there. Can you see any signs of damaged component anywhere or any debris that might be shorting the pins? Is the back of the board OK?
If you have another input that isn't being used, try configuring the Z end stop to use that instead of io2.
-
M574 Z1 S1 P"io2.in"The S1 in this says you have an switch-type endstop input.
Since the Duet3 has pullup resistors on these inputs, the endstop will be triggered when there is no switch plugged-in.
I do not know how this works with a normally-open endstop switch. It would be triggered all the time until the switch closed.
Are you sure they are normally-open?
Try inverting the signal by using a "!" in the pin name, but USE CAUTION since it might cause the switch to not be recognized during a homing move if I'm misunderstanding something.
You can see which switch is active in the output from the M119 command.
-
Thank you @alankilian
This was just my human error. I was using the normally closed contacts on the switch, (not normally open) and when I went to home Z with nothing plugged in, it instantly homed, as it should.
I simply forgot that I was using normally closed contacts. I was thinking, why isn't the Z axis moving when homing??!! Doy! It's been a while since I designed the thing. Man I feel dumb.
-
Excellent diagnosing process.
The things we are sure of are the hardest things to check and see if we're right.
You got something working again and that's the point of this process.
-
@solarsamuel As an aside, normally closed switches are usually better than normally open because if a switch fails, then the gantry will slam into the frame and the motors will continue to try and move it. But, the downside of using normally closed switches is that if a wire falls off, then it will appear to be open (as you have discovered), which will mean that the gantry is considered homed at a position which could be far away from it's true homing position. Strange or alarming things will then happen if you haven't noticed and try and run a print like that (this is the voice of experience talking)
.So here is a little tip that you might find useful. Essentially check the state of the end stop at the start of homing and abort if it's already triggered. You need to find which end stop is for which axis but generally X=0, Y=1 and Z=2 (at least that's how it is on my machine). So to check the state of the Y end stop for example, before homing Y I use ......
if sensors.endstops[1].triggered abort "Y endstop already triggered at the beginning of the homing move - aborting"Obviously the command for the X and Z axes would use ...endstops[0] or [3]) and the message would refer to the X or Z endstop.
HTH
