6XD not moving the steppers unless I re-send M569 command

ComedianTF2

So I'm helping out a friend install a 6XD in his printer. Ideally we should have installed a 6HC, but we needed to get it up and running asap and it was out of stock locally so we went with a 6XD option.

We have managed to get movement out of the steppers, but it seems I need to re-send the M569 commands before the motors get "energized". Once they have had the commands sent, they can be moved with no issue.

The weird thing is that the commands are being sent in the config.g, but somehow aren't activating the drives there. It's only when I send them later on a second time that things work properly.

Adding these commands to the bottom tot he config.g doesn't seem to work either. Writing this out, i wonder if there is maybe there a time/power delay that would cause things?

If anyone has some clues on what to check/test for, let me know

The drivers used are SL2690A drivers, here is the manual: https://www.123-3d.nl/pdf/SL2690A--English.pdf

Per the manual, it seems that the config is 2us minimum step pulse, 2 us minimum step interval, 5us DIR setup time and 5us for the hold time. I am not 100% sure on the hold time. but testing 0, 2, 5 and 10 made no noticable difference so I kept it at 5us

The config.g is below. Note some parts of the config.g haven't been written out fully, as we're enabling things one by one to check the systems.

G90												; send absolute coordinates...
M83												; ...but relative extruder moves
M550 P"Everything3D"							; set printer name

; Network
M552 S1 P0.0.0.0								; enable network for 

; Drives
M569 P0 S0 R1 T2:2:5:5							; X axis, Drive 0, active high enable, 2us minimum step pulse, 2 us minimum step interval, 5us DIR setup time and no 5us time
M569 P1 S0 R1 T2:2:5:0							; Y axis
M569 P2 S0 R1 T2:2:5:0							; Z axis
;M569 P124.0 S0									; physical drive toolboard goes forwards using default driver timings. Update with the correct CAN address (the P value)
M584 X0 Y1 Z2 ;E124.0							; set drive mapping
;M350 E16
'M906 E1000 									; 1amp

;M350 E16 I1									; configure microstepping with interpolation
;M906 E1000 I50									; set motor currents (mA) and motor idle factor in per cent
; steps/mm and current set by external stepper motor 
M92 X200 Y200.00 Z2000.00 E400					; set steps per mm
M566 X600 Y600 Z50 E3600						; set maximum instantaneous speed changes (mm/min)
M203 X4800 Y4800 Z500 E5100						; set maximum speeds (mm/min)
M201 X600 Y600 Z15 E5100						; set accelerations (mm/s^2)
M204 P500										; travel move accelerations
M84 S100										; Motor idle timeout

; Axis Limits
M208 X0 Y0 Z-4 S1								; set axis minima. Updated from -2 to -4 on the Z
M208 X1200 Y580 Z600 S0							; set axis maxima

; Endstops
;M574 X1 S1 P"!io1.in"							; configure switch-type (e.g. microswitch) endstop for low end on X via pin io0
;M574 Y2 S1 P"!io2.in"							; configure switch-type (e.g. microswitch) endstop for high end on Y via pin io1
;M574 Z1 S2										; configure Z-probe endstop for low end on Z

; Z-Probe
;M950 S0 C"124.io0.out"							; create servo pin 0 for BLTouch
;M558 P9 C"^124.io0.in" H5 F120 T6000			; set Z probe type to bltouch and the dive height + speeds
;G31 P500 X-15 Y30 Z1.7							; set Z probe trigger value, offset and trigger height
;M557 X30:1150 Y30:570 S50						; define mesh grid

; Heaters
M140 H-1										; disable heated bed (overrides default heater mapping)
;M308 S0 P"temp0" Y"thermistor" T4700000 B4725	;C7.06e-8 ; configure sensor 0 as thermistor on pin temp0
;M950 H0 C"heat0" T0								; create nozzle heater output on heat0 and map it to sensor 0
;M307 H0 R1.929 K0.248:0.000 D6.80 E1.35 S0.90 B0 V25
;M143 H0 S285									; set temperature limit for heater 0 to 285c

; Fans
;M950 F0 C"124.out0" Q500						; HEATSINK FAN create fan 0 on pin fan0 and set its frequency
;M106 P0 S1 H0 T45								; set fan 0 value. Thermostatic control is turned on
;M950 F1 C"124.out1" Q41						; PART COOLING FAN create fan 1 on pin fan1 and set its frequency
;M106 P1 S0 H-1									; set fan 1 value. Thermostatic control is turned off

; Tools
;M563 P0 D0 H0 F1                            ; 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

; Custom settings are not defined
; Toolboard

;M308 S2 P"124.temp1" Y"thermistor" A"toolboard temp" T100000 B4092


;LCD
;M950 P1 C"LCD_D4"
;M42 P1 S0
;G4 P500
;M42 P1 S1
;M918 P2 C30 F50000 E4

;********
;TESTING ONLY REMOVE ME IN FINAL BUILD
M564 H0 S0								; allow unhomed moves + moves out of min/max area. Only for testing. Remove later on
;TESTING ONLY REMOVE ME IN FINAL BUILD
;*********

T3P3Tony

@ComedianTF2 if you send M17 instead of resending the M569 command does that allow the driver to subsequently move?

ComedianTF2

@T3P3Tony it doesn't seem to do the trick.

It's also weird that it doesn't seem like the M569 command enables it 100% if the time, I seem to work around 70% of the time, and then sometimes I gotta send it multiple times in a row until it "takes"

I'm currently testing settling the idle timeout to a very large number as well to make sure that once it takes it stays

ComedianTF2

This post is deleted!

ComedianTF2

After further testing, it seems that sending a small move command, after which sending the M569 command seems to enable them reliably.

At the bottom of the config.g I've added a M98 command calling for motor_enable.g, with the contents below

M98 P"motor_enable.g" ; enable motor at boot

M564 H0 S0					; allow unhomed moves + moves out of min/max area. Only for testing. Remove later on
G91 						; relative moves
G1 X0.1 					; move 0.1mmm
G1 Y0.1 					; move 0.1mmm
G1 Z0.1						; move 0.1mmm
M569 P0 S0 R1 T2:2:5:2.5	; X axis, Drive 0, active high enable, 2us minimum step pulse, 2 us minimum step interval, 5us DIR setup time and 5us hold time
M569 P1 S0 R1 T2:2:5:2.5	; Y axis
M569 P2 S0 R1 T2:2:5:2.5	; Z axis
M564 H1 S1 				; re-enable safety stuff

T3P3Tony

@ComedianTF2 which version of firmware are you running?

I am not sure if this is something strange about how those motors behave or an issue with firmware.

ComedianTF2

@T3P3Tony it's on 3.5.4

T3P3Tony

@ComedianTF2 do you have access to a scope or logic analyser? It would be good to understand if the enable and step lines are behaving as expected after the first M569, i.e it's an issue with those drivers, or not

droftarts

@ComedianTF2 The M569 command shouldn't enable the drivers, only configure them. Only sending M17, or sending a motor move, should enable the driver. You should be able to send M569 commands as often as you like after running config.g, and the driver should not enable. At least, that's what happens on the Mini 5+ I have here. Unfortunately I don't have a 6XD to test. You can send M569 P0 to check how the each driver output on the 6XD is configured.

How have you wired the stepper driver? I assume you have wired the EN+ from the driver to +5V on the 6XD, and EN- to D0 EN- on the 6XD, as shown here https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Mainboard_6XD_Hardware_Overview#connecting-external-motor-drivers. How is the 'Driver Enable Polarity' (En_Pol) jumper set?

In the table, it says

Drive initial time 2 - - s

The 'Drive initial time' of 2 seconds might be the reason that enable appears to be delayed. Try sending M17, wait 2 seconds, then a move. The manual also says:

The 4-28V signal level is used for protection of pulse, direction and enable.

It's possible that it's not reliably picking up the enable signal, which is 5V from the 6XD. Check your wiring. If you disconnect the enable wires, the driver should be enable at power on, and be enabled the whole time, which might be easier.

Ian

ComedianTF2

@T3P3Tony

I will be able to check that in January, once I'm back from holidays

@droftarts

Same, will test it out in January once I'm back. The wiring I've done per the guide you've shown. I had missed the driver enable polarity jumper, so that's quite likely the issue there.

With re-sending the commands we were able to get the printer up and running, and the printer has completed a successful print, though hopefully we won't need to use the driver_enable.g file I used before with the fixes recommended.

Thanks both for the help, I'll enjoy the Christmas break for now and get back to it in Jan

T3P3Tony

@ComedianTF2 do you have an update on this?

ComedianTF2

@T3P3Tony @droftarts

The 'Driver Enable Polarity' (En_Pol) jumper was on the left position, set to GND

Flipping the M569 R value from R1 to R0 fixed the issue. I think that by re-sending the M569 values, it basically sent the drive enable command to 0, which then allowed things to work.

Thanks for the support, I read the post and thought I had tested the R value inversion, but for some reason I must have done that testing incorrectly before, which caused me to not look at it properly until now.

T3P3Tony

@ComedianTF2 glad you have resolved it.