Issues with Intermittent Stopping of the Z-Axis Motor

Aitor

I am experiencing issues with my new equipment using DUET3. The error generally occurs on the Z-axis, which has 3 independent motors, each connected to a different driver and with its respective endstops. Most of the time, it works correctly, but occasionally one of the motors (not always the same one) stops, causing the other two to descend, bending my print bed and preventing further movement.

My NC endstops are two-wire: one connected to GND and the other to io#in. Here is my configuration:

M584 X0.4 Y0.3:0.1 Z1.0:1.1:1.2 U0.5 E0.0:0.2                 ; Set drive mapping
M574 Z2 S1 P"1.io2.in+1.io1.in+1.io0.in"                      ; Set endstop configuration

As you can see, both the endstops and motors are connected to Duet3hc.

My home Z configuration is as follows:

; homez.g
; call to home the Y-axis

G91                                            ; Set to Relative Positioning
G1 H1 Z{move.axes[2].max*2} F3000              ; Move
G1 H2 Z-5 F6000                                ; Move
G1 H1 Z{move.axes[2].max/2} F360               ; Move
G90                                            ; Set to Absolute Positioning
M400                                           ; Wait for current moves to finish

I believe the configuration is correct since it works properly most of the time. However, as I’m experiencing this type of interference, could a pull-up or pull-down connection help? Additionally, I find it odd that on the Y-axis, which also has two independent motors (but connected to Duet6hc), I have not encountered this type of interference.

I would appreciate any input you can provide.

Best regards,

Aitor

Good morning @droftarts,

I have reviewed my circuit and can only implement a Pull-Up connection. My intention is to place a 220-ohm resistor from my 5V to io#in. Do you see this as correct?

Best regards,

droftarts

@Aitor usually when you have three endstops on a Z axis with three motors, each motor will stop when it hits it's respective endstop. So the first axis will stop when it hits the endstop, and the others will carry on until they hit their endstops.

Does the motor stop before any of the motors have hit an endstop? If so, I'd guess the problem was a poor/loose connection in the endstop wiring. Check the wiring to all the endstops. I don't think a pullup helps here, because they are wired NC.

If another motor does hit the endstop, but doesn't stop, but another motor does, the endstops do not refer to the correct motor. The order you define the motors in M584 corresponds to the endstop inputs in M574. In your config.g you have:

M584 ... Z1.0:1.1:1.2
M574 ... "1.io2.in+1.io1.in+1.io0.in"

Motor 1.0 is controlled by 1.io2.in, motor 1.1 is controlled by 1.io1.in, and motor 1.2 is controlled by 1.io0.in. Check these are correct, and that the cables from the IO go to the correct motor.

Also, change your homez.g to:

; homez.g
; call to home the Y-axis
 
G91                                            ; Set to Relative Positioning
G1 H1 Z{move.axes[2].max+10} F3000              ; Move
G1 H2 Z-5 F6000                                ; Move
G1 H1 Z{move.axes[2].max+10} F360               ; Move
G90                                            ; Set to Absolute Positioning
M400                                           ; Wait for current moves to finish

I vaguely remember it can cause the firmware an issue if you set too long a homing move.

Ian

Aitor

Good morning @droftarts,

@droftarts said in Issues with Intermittent Stopping of the Z-Axis Motor:

Does the motor stop before any of the motors have hit an endstop? If so, I'd guess the problem was a poor/loose connection in the endstop wiring. Check the wiring to all the endstops. I don't think a pullup helps here, because they are wired NC.

Exactly, my motor stops before reaching the endstop. Before writing this, I checked all my Z-axis connections and replaced all the relevant cables. To give you an idea of how it's connected, my endstop is connected to a custom-designed PCB; from this board, via a flat cable, it goes to another PCB, and from there, two of the motors (Z1 and Z2) connect to another PCB through a different flat cable. From here, the system connects to the Duet3hc, while Z3, due to its location, goes directly to this last PCB.

Today, I am running tests after modifying the Z homing routine, which I changed this way following your recommendation.

; homez.g
; Homing for the Y-axis

G91                              ; Set to relative positioning
G1 H1 Z{move.axes[2].max} F3000  ; Move
G1 H2 Z-5 F6000                  ; Move
G1 H1 Z{move.axes[2].max/2} F360 ; Move
G90                              ; Set to absolute positioning
M400                             ; Wait for current moves to finish

I'm running this testing macro while writing this message, and the Z3 motor failed on loop 53 out of 100. I re-ran the macro, and this time Z2 failed on loop 71 out of 100. In each case, it always fails during homing, never with regular movement commands. Yesterday, I ran this same cycle, moving the Z axis up and down 1000 times without homing, just moving it from position Z0 to Z{move.axes[2].max-1}, and there were no failures, so I can rule out a mechanical cause. As for the error itself, it happened while I was present, and I could see that the motor that stops does not even attempt to move, while the other two, which are always positioned lower, keep trying to move. This is logical since none of them have reached their endstop.

if state.status = "processing" || state.status = "paused"
	M118 S{"Cannot use during "^state.status}
	M99

var cycle = 0
var count = 0
M291 R"Number of Cycles" P"Enter the number of cycles you want to perform" S5 L1 F10
set var.cycle = input
M400
while var.count <= var.cycle
	M118 S{var.count^" of "^var.cycle}
	G28 Z
	G0 Z{move.axes[2].max-20} F{move.axes[2].speed}
	set var.count = var.count+1

On another note, if I wanted to test enabling the internal Pull Up, would it be safe to configure it like this in my case?

M574 Z2 S1 P"^1.io2.in+^1.io1.in+^1.io0.in"                      ; Endstop configuration

Best regards,
Aitor

Aitor

Good morning @droftarts,

I activated the internal pull-up resistor, as I mentioned earlier, and it seemed to work well; I completed a cycle of 100 without any issues. To be sure, I then ran a cycle of 1000, but this time it failed on cycle 115 out of 1000. This time, it was Z2 again, but I can confirm that both Z1, Z2, and Z3 have failed at different times. I think it’s unlikely that this is due to the connections. I also checked that the endstop isn’t getting stuck, and it isn’t. So, I’m not sure where this error might be coming from. I also ran this macro for over 12 hours and didn’t get the error message, though the machine was completely stationary during that time.

while true
    if sensors.endstops[2].triggered == true
        break;
M400
M291 R"Final de carrera Z" P"Final de carrera Z pulsado" S2

Best regards,

droftarts

@Aitor my impression has always been that you don’t need the pull-up resistor on Duet 3, because it’s activated by default. I’m checking with @dc42.

It would be good to check if the motor stop is actually caused by a false trigger. I’m not ion the office, so can’t check if the Object Model shows the individual triggering of the endstops on a multiple-motor axis.

There are a lot of connections between the endstop and the main board. Ribbon cables are also more susceptible to interference. It way even be due to proximity of tracks on your custom PCBs, or in the shared wiring. Enabling the pull-up may only be a temporary fix. Separating the endstop wiring, and using shielded (properly grounded), twisted pair wiring from endstop to mainboard would be the ideal solution.

Ian

Aitor

Good morning @droftarts,

In my case, the sensors.endstops[2].triggered object model shows true whenever any endstop is triggered, and I haven’t found an alternative to monitor them individually.

An alternative solution I thought of was to stop all motors whenever any endstop is detected. I tried using the G0 H4 command, hoping it would work this way, but it didn’t. My idea was to send G0 H4 repeatedly and then keep the Z homing as is. My approach would look something like this:

; homez.g
; Homing for the Y-axis

G91                              ; Set to relative positioning
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H1 Z{move.axes[2].max} F3000  ; Move
G1 H2 Z-5 F6000                  ; Move
G1 H1 Z{move.axes[2].max/2} F360 ; Move
G90                              ; Set to absolute positioning
M400                             ; Wait for current moves to finish

The pause was just to check if it would work and give me time to react, but H4 did not stop all motors. If it had worked this way, I could avoid any false trigger, and it would only be noticeable in cases where it actually occurred, preventing issues with the Z-axis.

I know my circuit has many connections, but this shouldn’t be an issue. Moreover, I haven’t noticed this behavior in XYU, where X and U have even more connections (two more than Z), so I’d like to think that’s not the case.

Best regards,

dc42

@Aitor do the endstop wires run close to the stepper motor wires over a significant length? If so then the current flowing in the stepper motor wires may be inducing current in the endstop wires. To avoid this, either separate the endstop wires from the motor wires, or use twisted pair wiring for the motor wires (one pair for each motor phase), or the endstop wires, or both.

If using ribbon cables for motor wires then the two conductors for each phase should be adjacent conductors. If using ribbon cables for endstop wires then the two conductors for each switch should be adjacent conductors. The aim is to minimise the area inside the loop formed by the two conductors. If motor wires and endstop wires are in the same ribbon cable, put the motor wires at one and and the endstop wires at the other end and put several grounded conductors between the two groups.

If it was a pullup resistor problem then the symptom would be motors not stopping when endstops are triggered.

Aitor

Good morning @dc42,

The endstop cables run close to the stepper motors, and they are also the longest cables on the setup. After the tests I conducted over the weekend, I’ve concluded that the issue is indeed signal interference, likely caused by the motors. Unfortunately, I can’t change the wiring at this time, so I’ll only be able to make this adjustment later on.

As a workaround, is there any way to make all the independent motors stop upon detection by any endstop sensor? If not, could this option be added as G0 H5?

Best regards,

dc42

@Aitor said in Issues with Intermittent Stopping of the Z-Axis Motor:

As a workaround, is there any way to make all the independent motors stop upon detection by any endstop sensor?

Only by wiring all 3 normally-closed endstop switches in series.