Not homing X on Delta build
-
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.
-
I'll remove it and give it a clean. But if it can only run FW 1.11 will it work with the smart effector?
-
It should be quite easy to lift the plastic bit on the header as well (small blade just to prise it up a little)
-
It should be quite easy to lift the plastic bit on the header as well (small blade just to prise it up a little)
Correct, somehow I forgot that you can do that.
-
I've cleaned the board, even went as far as re-soldering the 2 pins still no different. Have tried several different older firmware options and the newest that will run is RepRapFirmware-1.13b, soon as I tried RepRapFirmware-1.14 got the same fault back.
-
1.14 is such a long time ago that I can't think what might have changed to trigger the fault.
As a workaround, you could try adding a 1K pullup resistor between the STP and +3.3V pins on that endstop connector.
-
I'm only using STP and GND
-
Tried the 1k resistor and it works.
Thank you very much for your time and patience, it's very much appreciated and have a Merry Christmas.
Paul
