[3.4.0beta6] Home/Limit switch bug

Catalin_RO

Just partially upgraded my CNC and in the process I have also re-positioned the electronics. After years of working flawlessly I have been immediately hit with countless "motor phase disconnected" messages for the axis that I was trying to home.
Sometimes, by power cycling the whole system, it apparently recovered, to be hit again after another power cycle.
Long story short, if any of the home/limit switches is triggered when powering/rebooting the Duet, there is no indication of the triggered switch and the dreadful error comes up!

The issue should be pretty old as I have experienced it first with latest stable 3.3 firmware and I upgraded to 3.4.0 beta 6 only as a last resort!

T3P3Tony

@catalin_ro said in [3.4.0beta6] Home/Limit switch bug:

if any of the home/limit switches is triggered when powering/rebooting the Duet, there is no indication of the triggered switch and the dreadful error comes up!

What sort of limit switches do you have? As you say it is odd that this is a repeatable error that has not been seen before.

To summarise, depress a limit switch and the axis gives a motor phase disconnected error? Does this only happen if the limit switches are depressed on startup?

Catalin_RO

@t3p3tony It happens only if any limit switch is depressed on startup!

What actually bother me most is that after the electronics repositioning I had a broken wire in one of the limit switches connectors, just by the pin so barely not easy to spot. My limit switches are microswitches, used as NC to reduce effects of electrical noise, and thus it looked actually like a triggered switch. With the new electronics position it was quite difficult to see the LEDs on the board.

Of course, a much clever configuration, with extended homing scripts, could be applied to circumvent the situation and gracefully signal the problem. But, still, it is a hidden bug in the end!

T3P3Tony

@catalin_ro Does it happen if the carriage is in the centre and you manually hold down the switch. Does it happen for all axis?

Please can you add your config.g, homing macros and anything that they reference here.

Catalin_RO

@t3p3tony It doesn't matter where the carriage is. As long as a limit switch is triggered, no matter how it is triggered, I see the problem.

If any limit switch is triggered, all axes that involve movements while homing show the error - I have a B axis that is rotational and it doesn't have any switch/homing indicator.

I will share tomorrow the config.g and the homing files. Now the CNC is powered off.

Catalin_RO

@t3p3tony As promised, here are the various configuration files.

config.g

; General preferences
M111 S0                     ; Debugging off
M453                        ; CNC mode
G21                         ; Work in millimetres
G90                         ; Send absolute coordinates...

; Touch probe configuration
M558 P5 C"!^zprobe.in" H5 F100 T2500 A5 S0.01 ; Set Z probe type to switch and the dive height + speeds
G31 P600 X0 Y0 Z0                             ; Set Z probe trigger value, offset and trigger height
M557 X15:530 Y15:500 S20                      ; Define mesh grid

; Drives & Axis
;
; Define axis X on drive 0, axis Y on drives 1 and 4, axis Z on drive 2 and axis B on drive 3
M584 X0 Y1:4 Z2 B3
;
; Set stepper drives parameters for all the used ones
M569 P0 S1                       ; Drive 0 goes forwards
M569 P1 S0                       ; Drive 1 goes backwards
M569 P2 S1                       ; Drive 2 goes forwards
M569 P3 S0                       ; Drive 3 goes backwards
M569 P4 S0                       ; Drive 4 goes backwards
M350 X16 Y16 Z16 B16 I1          ; Configure microstepping with interpolation
M906 X2400 Y2400 Z2400 B2400 I50 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30                          ; Set idle timeout
;
; Set axis dynamic parameters
M92 X400 Y400 Z400 B888.89 ; Set steps per mm
M566 X400 Y400 Z12 B12              ; Set maximum instantaneous speed changes (mm/min)
M203 X2500 Y2500 Z2500 B3060        ; Set maximum speeds (mm/min)
M201 X150 Y150 Z150 B150            ; Set accelerations (mm/s^2)
;
; Set per-axis travel distances
M208 X0:545 Y0:780 Z0:120 B-360:360 C0:530
;
; Set axis endstops
M574 X1 S1 P"xstop"           ; Set X active high endstops
M574 Y1 S1 P"ystop+e1stop"    ; Set Y active high endstops
M574 Z2 S1 P"zstop"           ; Set Z active high endstops
M574 B0                       ; Set B no endstops
M581 X Y Z S1 T0 R0           ; Enable endstop triggers

; Network
M550 PWorkBee              ; Set machine name
M540 PBE:EF:DE:AD:FE:ED    ; Set MAC address
M552 P192.168.1.200 S1     ; Enable network and set IP address
M553 P255.255.255.0        ; Set netmask
M554 P192.168.1.254        ; Set gateway
M586 P0 S1                 ; Enable HTTP
M586 P1 S0                 ; Disable FTP
M586 P2 S0                 ; Disable Telnet

; Miscellaneous
M501                       ; Load saved parameters from non-volatile memory

; Enables the spindle PWM controlled through fan 1 PWM
M950 R0 C"fan1" L24000 Q1000
M563 P0 R0 S"Spindle"
T0
M3 S1000
M5

; Change to workplace coordinates set 1
G54

homex.g

; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time)
M581 T0 R-1        ; disable trigger for endstop X
G91                ; relative positioning
G1 H1 X-1500 F1000 ; move quickly to X axis endstop and stop there (first pass)
G0 X5              ; go back a few mm
G1 H1 X-100 F100   ; move slowly to X axis endstop once more (second pass)
G0 X1              ; go back a few mm
G90                ; absolute positioning
G53
G92 X0             ; reset the X coordinate
G54
M581 T0 R0         ; enable trigger for endstop X

homey.g

; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time)
M581 T0 R-1        ; disable trigger for endstops Y
G91                ; relative positioning
G1 H1 Y-1500 F1000 ; move quickly to Y and C axis endstops and stop there (first pass)
G0 Y2              ; go back a few mm
G1 H1 Y-10 F100    ; move slowly to Y axis endstop once more (second pass)
G0 Y1              ; go back a few mm
G90                ; absolute positioning
G53
G92 Y0             ; reset the Y coordinate
G54
M581 T0 R0         ; enable trigger for endstops Y

homez.g

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool on Sat Feb 17 2018 22:55:40 GMT+0200 (GTB Standard Time)
M581 T0 R-1             ; disable trigger for endstops
G91                     ; relative mode
G1 H1 Z300 F1000        ; move Z towards the switch until it triggers
G0 Z-5                  ; move Z back 5mm
G1 H1 Z10 F100          ; move Z slowly towards the switch until it triggers
G0 Z-0.5                ; move Z back 0.5mm
G90                     ; back to absolute mode
G53
G92 Z{move.axes[2].max} ; reset the Z coordinate
G54
M581 T0 R0              ; enable trigger for endstops

homeb.g

G92 B0

Phaedrux

@catalin_ro said in [3.4.0beta6] Home/Limit switch bug:

M581 X Y Z S1 T0 R0 ; Enable endstop triggers

The only thing that sticks out to me is the use of triggers for the endstop switches. Maybe something is going on with that. It seems like that shouldn't matter since they are disabled during homing.

Catalin_RO

@phaedrux The homing switches are also used as safety limits, thus there is a small retraction before resetting the coordinates. In series with the homing switches, there is another set of switches that are really used as safety limits.

The trigger based solution is the most simple that insures an abrupt stop if any switch is activated when it shouldn't.

theolodian

@catalin_ro Yes, but set the M581 T0 say at the end of homeall.g. If you put it in config.g you will cause a reset loop. You will also need to cancel it at the beginning of homeall.g in case you run it more than once.

Catalin_RO

@theolodian The reset loop is something that I have also seen and I properly understood immediately. The problem is that if the board is powered on with any homing/limit switch triggered, it doesn't enter the reset loop and, instead, it falsely reports issues with the steppers.

While I intend to make a lot more clever homing scripts, separating the homing and limits switches electrically (different inputs) and not enabling the triggers for an axis until homes, the problem is still there...

Catalin_RO

More to this...

Just upgraded to 3.4.0beta7, mostly out of curiosity. Immediately after the update everything looked OK. I homed the machine several times without a glitch.

So I decided to do a minor change in the config.g file. I saved it, soft rebooted the machine and there it was! The problem hit me again...

In the end I was able to get rid of the issue after a quick series of power cycles. As previously observed, once properly started, everything worked flawlessly.

As this time I had no homing switch triggered that brings me to a very poor conclusion - somehow the Duet board degraded over time and in certain situations it starts to wrongly indicate motor related errors. I do not suspect issues related to its relocation after upgrading the machine as I have moved it along with its support structure.

Overheating is not an issue for sure. Last time I have extensively used the machine about 6 months ago, with environment temperatures not exceeding +30°C. These days, the room where it is located is at a rather cool 21-22°C and there is a fan continuously cooling the whole board. No matter what I do, the CPU never reports more than 31°C. I don't suspect any of the drivers getting too hot, especially while doing these simple homing tests.

Is there any way of getting around the phase disconnected check in the Trinamic drivers? Right now it seems to be mostly a bogus error more than anything else. Or should I consider getting a new controller?

dc42

@catalin_ro at what movement speeds do the "phase may be disconnected" warnings happen? Bogus warnings most commonly occur when the movement speed is quite high and the back EMF from the motors at that speed is greater than the power supply voltage. So if the warnings have only started recently, check that the power supply voltage is good and that the VIN connections to the Duet are sound.

If you only see warnings from one phase and it is always the same phase, then most likely the warning is genuine and you have a bad connection to that phase.

Catalin_RO

@dc42 It always happens when trying to home the machine after a software reset. Right now I can easily reproduce it:

power on the whole machine
do a homing cycle - everything is OK during this run if none of the end-stops is triggered
do an emergency reset through the web interface
try to home again the machine - the errors start popping up

I can't blame it any of the connectors because the errors do not come up after the initial power on. Also, if instead of trying to do a complete homing sequence I try to home a specific axis, the errors will come up for that axis. Even more, as I have a dual-Y setup, when I try homing the Y axis, the errors come up for both drivers/steppers.

Once the machine is homed, I can used for days with no errors!

More to that: the machine is a QueenBee mechanics (similar to WorkBee), with high torque steppers left from the original WorkBee - 3A, 4mH, 1.2Ohm.