Z-motors moving out of sync
-
Hi,
I have been running into an issue with the printer I am developing where the z motors move out of sync (see linked video). This only seems to happen after a print has been completed. Power cycling fixes the issue every time.
Any ideas? Let me know if you need more info.
-
That's funny! OK, not really.
Exactly what gcode is the printer trying to execute? Some kind of a home to Z max?
Have you separated the Z motors into separate axis letters at that point or are they still combined to Z?
When the one of the motors stops is it skipping/binding?
Are you using stall detection for anything? -
Haha yeah, it's pretty weird.
The z motors are connected to the default z inputs, so both are driven by the same driver. The connector wires the motors in series, so one motor should not be able to move without the other...
At the end of a print, a home to z max is triggered using sensorless homing. After a print has finished even regular z movement happens like this, not just the homing. Sensorless z homing is also used at the beginning of a print and during startup when the printer is powered on. There is no issue then, everything works fine.
As far as I can tell there is no skipping/binging. My only theory was that is had something to do with idle currents and that for some reason the motor current wasn't at full during these moves. This doesn't really seem possible, but I changed my idle current setting to set 100% current to all motors at all times. This did not fix it.
-
The sensitivity of the stall detection will vary with motor temperature. That may explain why it works fine at the start, but doesn't work right after a print.
-
What is the specification of the Z motors, what current are you running them at, which Duet are you using, and what supply voltage?
Please post the homing file (homez.g or homeall.g?) that it executes at the end of the print.
-
@dc42 said in Z-motors moving out of sync:
What is the specification of the Z motors, what current are you running them at, which Duet are you using, and what supply voltage?
Please post the homing file (homez.g or homeall.g?) that it executes at the end of the print.
And also end gcodes of the print might be interesting as well.
This looks to me like something I had when I switched the Duet and had my steps/mm wrong (much too high). IIRC it moved in a similar pattern. Do you by any chance modify the steps/mm anywhere outside your
config.g? -
I'm aware of the motor temp affecting stall detection, which is why I switch to limit switches for the x and y. This could be causing the issue for z, I will investigate this further.
Z motor currents and steps per mm are not modified anywhere other than in config.g
Z Motors
- 0.4A
- 1.8deg,
- 320mA (80% of rated current)
- StallGaurd is set at 21
- Microstepping 128
- Stepps per mm 3200
Supply voltage = 24V
Duet 2 WiFi v1.04himez.g
M400 ; make sure everything has stopped before we make changes
M574 Z2 S3 ; set endstops to use motor stall
G91 ; use relative positioning
G1 S1 Z240 F1200 ; home z
G90 ; back to absolute positioning
M400 ; make sure everything has stopped before we reset the motor currents -
Low current motors like those will work better if you connect them in parallel instead of in series. Alternatively, if the E1 motor output is free, connect one Z motor to Za, put 2 jumpers in Zb, and connect the other Z motor to E1. Put this command in config.g, before you set motor currents or microstepping:
M584 Z2:4 E3
-
All drivers are currently in use. I have parallel splitter pcbs that connect to the KK type terminals, so I'll give that a go as well.
-
@jckray, you will probably need to adjust the stall detection settings. Getting stall detection working with two motors connected in either series or parallel is likely to be tricky anyway, because the signal from one motor gets attenuated by the other, unless both of them stall at the same time.
-
Yes, I'm all too aware of the finikyness of stall detection. I'll update this topic once I have had a chance to test some of these things. Thanks for your help.
