Only two of three towers are homing

[Velvia]

@phaedrux said in Only two of three towers are homing:

How exactly are you testing movement? What commands are sent or buttons used? How are you allowing movement if homing isn't succeeding?

I use the Z buttons here. Then everything moves just fine. When I press "Home all", only Z and Y moves and homed correctly, X does nothing.

@phaedrux said in Only two of three towers are homing:

Can you send M122 and M98 P"config.g" in the gcode console and copy paste the results here?

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3S0-7JKF0-3S86T-TAJR8
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 61988 of which 36 recycled
Never used RAM 147020, free system stack 188 words
Tasks: Linux(ready,79) HEAT(blocked,173) CanReceiv(blocked,927) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,50) MAIN(running,1203) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:39:23 ago, cause: software
Last software reset at 2022-06-17 18:39, reason: User, none spinning, available RAM 146980, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 35.1, current 36.3, max 37.6
Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: position 48328, standstill, reads 31221, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 48328, standstill, reads 31221, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 48328, standstill, reads 31221, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 31221, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 31224, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 31225, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2022-06-17 20:18:46
Slowest loop: 0.99ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 23845, send timeouts 53662, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 1
Last transfer: 1ms ago
RX/TX seq numbers: 13918/13918
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 35.31, max wait times: 16.7ms/0.0ms
Codes per second: 0.01
Maximum length of RX/TX data transfers: 2620/960
 

M98 P"config.g" only did this

[Phaedrux]

@velvia said in Only two of three towers are homing:

Duet Control Server v3.3.0

@velvia said in Only two of three towers are homing:

Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)

It looks like your DSF version and firmware version have gone out of sync.

Can you try sending sudo apt update and sudo apt upgrade on the pi and then run M122 again and post it here?

Everything should be on 3.4.1 at this point.

[Velvia]

@phaedrux said in Only two of three towers are homing:

Can you try sending sudo apt update and sudo apt upgrade on the pi

I already did this prior to all this. I'll do it again.

[Phaedrux]

Do you get any errors?

[Velvia]

@phaedrux said in Only two of three towers are homing:

Do you get any errors?

Two errors in the beginning of "sudo apt upgrade", then everything else is fine.

[Phaedrux]

Don't leave me in suspense. What are the errors?

[Velvia]

I don't remember. Was many hours ago, restarted the printer after that. Looked like it just failed to fetch the two first things. I'll try again tomorrow. Thanks a lot for the help so far!

[Phaedrux]

You may want to download a fresh copy of the Duet Pi image and flash a new SD card. You can backup your printer config files and restore them. That may be easier than trying to get things back in sync on the current install.

[Velvia]

Thank you, I'll try that!

[Velvia]

Flashed new image, updated and upgraded, no errors. Problem persists. M122 gives this:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3S0-7JKF0-3S86T-TAJR8
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 61988 of which 36 recycled
Never used RAM 147020, free system stack 200 words
Tasks: Linux(ready,81) HEAT(blocked,300) CanReceiv(blocked,927) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,53) MAIN(running,1203) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:45 ago, cause: power up
Last software reset at 2022-06-17 22:28, reason: User, none spinning, available RAM 147848, slot 2
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 26.6, current 32.9, max 33.0
Supply voltage: min 23.9, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: position 48328, standstill, reads 58518, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 48328, standstill, reads 58518, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 48328, standstill, reads 58518, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 58519, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 58522, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 58522, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2022-06-17 23:55:38
Slowest loop: 0.46ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 83, send timeouts 307, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 1
Last transfer: 1ms ago
RX/TX seq numbers: 57893/57893
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4.1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 2642.73, max time between full transfers: 63.1ms, max pin wait times: 14.7ms/34.2ms
Codes per second: 2.78
Maximum length of RX/TX data transfers: 2732/544
 

[Phaedrux]

@velvia said in Only two of three towers are homing:

3.2.2

Your firmware still isn't updating.

Can you try sending M997 in the gcode console to manually initiate a flash of the firmware? Then check your firmware version again with M115. It should be 3.4.1 to match the version of DSF on the Pi.

[Velvia]

@Phaedrux
That worked, but problem persists:

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.4.1 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2022-06-01 21:09:12

[Velvia]

@velvia
M122:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.1 (2022-06-01 21:09:01) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3S0-7JKF0-3S86T-TAJR8
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 64296 of which 96 recycled
Never used RAM 135208, free system stack 154 words
Tasks: SBC(ready,0.5%,448) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,267) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,333) TMC(notifyWait,7.7%,92) MAIN(running,91.3%,1231) IDLE(ready,0.4%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:04:15 ago, cause: software
Last software reset at 2022-06-18 00:59, reason: User, none spinning, available RAM 146980, slot 2
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 187
MCU temperature: min 33.2, current 34.9, max 35.4
Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 776, reads 49468, writes 19 timeouts 0
Driver 1: standstill, SG min 0, mspos 456, reads 49468, writes 19 timeouts 0
Driver 2: standstill, SG min 0, mspos 968, reads 49468, writes 19 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 49473, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 8, reads 49476, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 49477, writes 11 timeouts 0
Date/time: 2022-06-18 01:08:30
Slowest loop: 53.25ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 3, maxWait 40471ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 5, completed 5, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 2272, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 1277/0/0
Tx timeouts 0,0,1276,0,0,994 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 10160/10160
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 40.42, max time between full transfers: 84.5ms, max pin wait times: 54.0ms/14.7ms
Codes per second: 0.29
Maximum length of RX/TX data transfers: 3032/864
 

[Phaedrux]

@velvia said in Only two of three towers are homing:

That worked, but problem persists:

Well it was worth a shot and likely fixed other future issues as having a mismatch like that will cause havok eventually.

@velvia said in Only two of three towers are homing:

; Drives
M569 P0.0 S1 ; physical drive 0.0 goes forwards
M569 P0.1 S1 ; physical drive 0.1 goes forwards
M569 P0.2 S0 ; physical drive 0.2 goes forwards
M569 P0.3 S1 ; physical drive 0.3 goes forwards
M584 X0.0 Y0.1 Z0.2 E0.3 ; set drive mapping

The only thing that stands out as odd to me is the motor direction config for X Y Z motors has X Y going forwards and Z going backwards.

Which towers are not moving correctly during homing?

Take a look at this test please: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_linear_delta#testing-the-motors-and-endstops-individually

[Velvia]

@phaedrux said in Only two of three towers are homing:

Which towers are not moving correctly during homing?

X

@phaedrux said in Only two of three towers are homing:

Take a look at this test please: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_linear_delta#testing-the-motors-and-endstops-individually

This worked just fine. All towers moved individually as they should.

[Velvia]

@velvia
That makes this so weird.
H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).

homedelta.g

; homedelta.g
; called to home all towers on a delta printer
;
; generated by RepRapFirmware Configuration Tool v3.3.10 on Wed Jun 15 2022 16:15:51 GMT+0200 (Central European Summer Time)
G91                       ; relative positioning
;*** Slow homing has been configured. Change F180 to F1800 below when your configuration is working
G1 H1 X375 Y375 Z375 F360 ; move all towers to the high end stopping at the endstops (first pass)
G1 H2 X-5 Y-5 Z-5 F1800   ; go down a few mm
;*** Slow homing has been configured. Change F180 to F360 below when your configuration is working
G1 H1 X10 Y10 Z10 F180    ; move all towers up once more (second pass)
G1 Z-5 F6000              ; move down a few mm so that the nozzle can be centred
G90                       ; absolute positioning
G1 X0 Y0 F6000            ; move X+Y to the centre
 
 

[dc42]

@velvia most likely the X endstop switch is not connected properly. Use M119 or the Object Model DWC plugin or the Endstops DWC plugin to test that endstop switch.

[Velvia]

@dc42
M119 gave me this:

M119
Endstops - X: at max stop, Y: not stopped, Z: not stopped, Z probe: not stopped

So I'll check the connections. Just figured it worked since the light is on and responds.

Edit: that was the issue. Crimping these tiny cables and connectors are annoying
Thanks everyone for your help! I have other issues as well (hotend not heating, hotend fan always on even though it has temperature control), but will make a new thread for those I guess.