Not homing X on Delta build
-
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
-
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.
