Quad Z, 1 motor dead on G32

fs9

Hello,

I have encountered a really odd situation here, have searched the forums and sought help on Voron discord, but am still at a loss, so perhaps I can solve this with help from more experienced people here.

The machine is a Voron 2.4, so I got 4 steppers on the Z axis, and they perform correctly when I call homeall.g or press home all on paneldue. The gantry also moves properly on Z when I use the move pane on paneldue. When I call G32, however, Z0 won't move. Z1-3 move properly and the machine starts to probe for the bed levelling, but Z0 is still and even won't offer resistance if I try to move its belt, like when it's not powered. I triple checked wiring, console outputs no messages when the odd behavior presents itself.

My bed.g is as follows:

; bed.g
; called to perform automatic bed compensation via G32

; Clear any bed transform
M561

; Turn off noisy Extruder motor
M84 E0

; Home all axes
G28

Board is a Fysetc Big Dipper. It was running 3.4.0 Beta 3, then back to 3.3 without any behavior change. What strikes me as odd is I had the same config files on a Duet2 Wifi (I adjusted config.g for the pins, but that's about it) and this never happened before. Am I missing something? Thanks for any assistance provided.

dc42

@fs9 this is normal. RRF doesn't adjust the first Z motor when levelling the bed.

fs9

@dc42 Oh, I never actually noticed that Z0 doesn't move during leveling. But this is not that, I'm afraid, as G28 on the console will do XYZ homing properly but Z0 already doesn't move when G28 is called from within bed.g. That is the unusual behavior I'm looking to solve, as it stays idle as if the driver is unpowered and the gantry ends up more slanted than before running bed.g. It's also not doing the 3 passes on the same spots as it usually did, the head is stopping a little further from the set coordinates on each pass, I just noticed while letting the board run bed.g again, just now.

Edit, for clarification: What made me suspect that the driver might be powered off is that when the others move, the belt gives in to the movement, instead of holding its position. I then tried to move it by hand and it behaved like it does when the machine is unpowered.

fs9

I have no idea why, but the cause of the described behavior was the M84 E0 on bed.g. Drivers are assigned correctly on config.g and judging by all else, the board behaves as it should. However, running M84 E0 disables Z0 as a result. I tested this by running M84 and G28 in sequence on the console, same result as them run on bed.g happens. Maybe this is a firmware bug? Like I said, I have no idea. I can write a book but can't code for the life of me. But I'm glad it works now. @dc42, thank you for your time.

Phaedrux

firmware version?