Unusual Driver Phase Warning
-
Railcore.
Usually if I get a warning it just means a broken connection on a wire. It also usually just says phase B.
I went over the wires and connectors carefully and there's no problem. I did fix one bad pin and I had been messing with the Z stepper connectors (power off) so I expected good results, but...
I'm running a well tested and not recently changed macro to move one of the 3 Z steppers individually.
It's giving both phase A and B, and it reliably happens on the second stepper I try to move. I can get any stepper to work using M999 as long as it's the first one I try to move. But the second and third, whichever ones they are, fail with this error. ("Warning: Driver n warning: phase A may be disconnected, phase B may be disconnected", where n is 5, 6 or 7)
I've never seen this happen before. What does it mean?
-
2/13/2024, 12:25:21 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.6 (2023-07-21 14:08:28) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3SN-6JKD0-3S06Q-9AY7D
Used output buffers: 1 of 26 (26 max)
=== RTOS ===
Static ram: 23896
Dynamic ram: 77040 of which 32 recycled
Never used RAM 8184, free system stack 148 words
Tasks: NETWORK(ready,13.7%,242) HEAT(notifyWait,0.0%,333) Move(notifyWait,0.0%,314) DUEX(notifyWait,0.0%,24) MAIN(running,85.6%,436) IDLE(ready,0.6%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:02:43 ago, cause: power up
Last software reset at 2024-02-13 11:47, reason: User, GCodes spinning, available RAM 8184, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x14
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 40.8, current 45.1, max 45.3
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/5, heap memory allocated/used/recyclable 2048/256/204, gc cycles 0
Events: 2 queued, 2 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10:
Driver 11:
Date/time: 2024-02-13 12:25:19
Cache data hit count 4294967295
Slowest loop: 130.23ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.8ms, write time 336.9ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 31654ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 6, completed 6, 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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Filament sensors ===
Extruder 0 sensor: no data received
Extruder 1 sensor: no data received
=== DueX ===
Read count 1, 0.37 reads/min
=== Network ===
Slowest loop: 492.68ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.27
WiFi MAC address 84:f3:eb:83:47:be
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25448
WiFi IP address 192.168.1.130
WiFi signal strength -49dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0 -
@DonStauffer I'm afraid I may have something wrong with my Duex board.
I decided to try to find if one of the steppers or drivers or set of wires was the problem by disconnecting each of the 3 steppers in turn. Numbers 5 and 7 have not worked since, not matter the configuration. Number 6 worked by itself.
So I got out my old steppers from before I replaced them. A couple of those still had the Molex connectors on them, so I got one of those and tried it on each of 5, 6 and 7. Again, only #6 worked. So it's not the wires and it's not the motor.
That leaves only configuration, or hardware. Since I haven't made any configuration changes lately, I think I have a hardware failure.
Anybody have any comments or suggestions?
UPDATE: I connected up 3 different steppers with entirely different wiring, and I'm back to the odd situation where only the first stepper after a restart will work. I get the impression that if you have a driver set up in config.g but don't connect the wiring, that affects other drivers somehow, so if you have all 3 Z steppers configured to be there, disconnecting any of them may do weird things. IDK. It's all very odd to me. I don't understand the situation at all.
-
@DonStauffer Apparently, besides the pin I fixed, this was a script issue. Possibly the way the script functioned changed with a new RRF version, and I didn't notice because it does still work the first time.
The script defined an A axis using M584 to refer to the Z stepper. At the beginning of the script was a variable definition for the driver number. I used to be able to set that, run the script, then change to a different driver, and run the script again, to adjust 2 Z axis lead screws. It was OK with me defining the A axis to be the appropriate driver, then doing it again with a different number. Apparently, now it's not, because I copied the script and changed the copy to use B for driver 6, then again using C for driver 7, and I can run the scripts fine and move more than one stepper.
The problem was masked because I had just fixed a wire, then was adjusting the bed level by moving the steppers individually. Often when I do that I only have to move one, but in this case I had to move more than one. When it didn't work I assumed I had broken something.
I haven't tested everything yet but I think this is it:
Don't use M584 to define one axis more than once using different drivers. I'm not sure why you can't do that, but reading the M584 documentation didn't tip me off. There is some language similar to that, but it doesn't seem to be the exact issue to me. I assume doing it all in one M584 line for multiple Z steppers still works:
M584 X0 Y1 Z5:6:7 E3:4:8:9
Possibly some other statement in my script is interfering. But I can handle that.
-
This post is deleted! -
@DonStauffer you should not need to split the axes out and then combine them together in more recent versions of RRF :https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_auto_levelling
-
@T3P3Tony Thanks! I'll look into it. I was able to get my issue resolved.
Once I got the connectors working correctly and changed my script, it works, although the script itself is clunky, so I'll look at what the new firmware allows to simplify it. I added backshells to the PH connectors to protect the pin crimps. I'll look into uploading the backshells to Thingiverse or something in case they're useful to someone else. I find bare PH connectors fragile.
I mainly use the script when the bed is too far off level to use G32, which usually happens if there's a problem with one of the stepper connectors.
-
undefined dc42 marked this topic as a question
-
undefined dc42 has marked this topic as solved
