Not homing X on Delta build

  • Hi,

    So I've been building a delta on and off for the past 18 months around a Duet 0.6 controller, finally found some time in my life to get it finished but that's where the excitement ends.

    On powering up the printer for the first time I hit home and that worked flawlessly, that was on FW 1.11, knowing this was out of date I've flashed the firmware to 1.20RC3.
    Unfortunately this is where my problem started, all end stops on the Duet show the switches operating: I've even swapped switches but X isn't seeing the switch on the web interface, consequently it won't home, it just grinds the belt.

    I've tried backdating the FW but it has made no difference, however going to 1.11 and it works.

    The only thing I have noticed is if I power up with the end stops made the printer will home but just the once as it won't see the end stop again.

    Can anyone shed some light on my issue?


  • administrators

    Please share your config.g file.

  • I haven't even looked at this yet, it's just what a friend sent me.

    ; Configuration file for Duet 0.6 (firmware version 1.20 or newer)
    ; executed by the firmware on start-up
    ; generated by RepRapFirmware Configuration Tool on Mon Dec 18 2017 11:03:47 GMT+0000 (GMT)

    ; General preferences
    M111 S0 ; Debugging off
    G21 ; Work in millimetres
    G90 ; Send absolute coordinates…
    M83 ; ...but relative extruder moves
    M555 P2 ; Set firmware compatibility to look like Marlin
    ; Automatic saving after power loss is not enabled
    M665 R178 L360 B145 H280 ; Set delta radius, diagonal rod length, printable radius and homed height
    M666 X0 Y0 Z0 ; Put your endstop adjustments here, or let auto calibration find them
    M208 Z0 S1 ; Set minimum Z

    ; Endstops
    M574 X2 Y2 Z2 S1 ; Set active high endstops
    M558 P1 H5 F120 T6000 ; Set Z probe type to unmodulated and the dive height + speeds
    G31 P500 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height
    M557 R135 S20 ; Define mesh grid

    ; Drives
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S1 ; Drive 2 goes forwards
    M569 P3 S1 ; Drive 3 goes forwards
    M92 X200 Y200 Z200 E410 ; Set steps per mm
    M566 X1200 Y1200 Z1200 E1200 ; Set maximum instantaneous speed changes (mm/min)
    M203 X18000 Y18000 Z18000 E1200 ; Set maximum speeds (mm/min)
    M201 X1000 Y1000 Z1000 E1000 ; Set accelerations (mm/s^2)
    M906 X1000 Y1000 Z1000 E800 I30 ; Set motor currents (mA) and motor idle factor in per cent
    M84 S30 ; Set idle timeout

    ; Heaters
    M305 P0 T100000 B4008 C0 R4700 ; Set thermistor + ADC parameters for heater 0
    M143 H0 S120 ; Set temperature limit for heater 0 to 120C
    M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
    M143 H1 S280 ; Set temperature limit for heater 1 to 280C

    ; Tools
    M563 P0 D0 H1 ; Define tool 0
    G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
    G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    ; Network
    M550 PKosselXL ; Set machine name
    M540 PBE:EF:DE:AD:FE:ED ; Set MAC address
    M552 P0.0.0.0 S1 ; Enable network and acquire dynamic address via DHCP
    M586 P0 S1 ; Enable HTTP
    M586 P1 S1 ; Enable FTP
    M586 P2 S0 ; Disable Telnet

    ; Fans
    M106 P0 S1 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off

    ; Custom settings are not configured

  • administrators

    Are the endstops ordinary normally-closed microswitches, or something else?

  • They are NC

  • administrators

    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.

  • administrators

    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

  • administrators

    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.

  • administrators

    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

  • administrators

    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…

  • administrators


    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.

  • administrators

    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.

  • administrators

    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)

Log in to reply