Not homing X on Delta build
-
Are the endstops ordinary normally-closed microswitches, or something else?
-
They are NC
-
I think the issue might be caused by leakage on the endstop input. Try firmware 1.20RC4 when I release it, which I hope will be later today.
-
I'll be waiting in anticipation.
-
Unfortunately 1.20RC4 hasn't made any difference.
-
Are you certain that the switches are wired to the correct endstop inputs? So that the motor that is wired to the X motor connector drives its carriage up to the switch that is wired to the X endstop switch; and similarly for the other two?
-
Yes positive, plus is homes fine on FW 1.11-dc42
-
What were you doing to trigger the endstop switches in that video?
-
Moving the carriages slightly by hand.
-
I've gone back as far as RepRapFirmware 1.18.1 which still doesn't work, the only other FW I have older is 1.11 which does work.
-
Were the carriages:
(a ) initially on the stop and you moved them off and back again, or
(b) initially short of the stop, and you moved them up to the switch and back again?If (b) then your endstop switches are operating in reverse and you need to change the polarity in your M574 command.
Are you absolutely certain that you installed 1.20RC4 correctly - did you confirm with M115 that RC4 was running?
-
When the carriage is making the limit switch, leds on the duet are OFF and DWC is showing YES (that's at power up) soon as the carriages are moved away from the limit switches leds are ON and DWC turns to NO, but X won't go back to YES once the limit is triggered.
Yes definitely running RC4
-
It sounds like a leakage issue. Here are a couple of things to check:
1. Does the X stop go back to reading Yes if you leave it for some time with the carriage against the switch?
2. Temporarily plug the X endstop cable into the Y endstop connection on the Duet, and vice versa. So when the X carriage is against the stop, Y will read Yes in DWC. When you move the X carriage away from the stop, does Y read No immediately, or is the fault still there? If the fault is not there, has the fault moved to the Y endstop (which shows up as X in DWC)? This will tell us whether is it the switch/cable that is at the root of the problem, or the board/firmware.
-
Yes it does switch back after a couple of minutes.
Switched the over X and Y still the same fault.
But every time I go back to 1.11 all is well…
-
@Hozza:
Switched the over X and Y still the same fault.
So did the fault stay with the X switch (which is connected to Y endstop input and shows as endstop 1 in DWC), or did it move to the Y switch (which is connected to X endstop input and shows as endstop 0 in DWC)?
-
Moved to the Y switch, so endstop 0 at fault not the switch.
Yeah sorry I wasn't very clear there.
-
Each endstop LED should light up when the corresponding endstop switch is closed, which for NC switches means when the carriage is not against the switch. Can you confirm that they all do, in particular the endstop 0 LED? The LED + resistor act as the pullup, which is required for reliable operation.
-
Yes they all light up and switch as expected.
-
I think there must a fault in the endstop 0 circuit. It may be a simple as a blob of flux or other contaminant on the PCB, most likely either on the microcontroller pins (where it would be easy to see and remove with isopropyl alcohol), or under the endstop connector (where it would not be visible). If you would like to contact your supplier, I will authorise a replacement under warranty.
I can understand why firmware 1.19 is more sensitive to that fault than earlier versions, but not why 1.20RC4 hasn't restored it back to the previous behaviour.
-
David if I may this is on a 0.6 board so def not under warranty.
