frequent short-to-ground on Z and extruder



  • I have 0.9deg steppers on dual-Z and extruder. They require many steps/mm, for example, Z needs 798steps/mm. I've found that no matter what current I use, as low as possible, it seems to be a matter of speed.

    Is there a realistic limit to how many steps/mm/sec it can go? I also noticed the shorts happen during rapid direction changes, like, at the bottom of the homeZ movement, it quickly moves up, 99% of the time, that's when the Z locks up and the short-to-ground shows up in the logs a few minutes later. I'm guessing it's the same thing with the extruder: extrude/retract.

    I print with z-hop, so my bed frequently goes down/up, down/up and so on. That seems to tickle it at times also.

    So far I've...

    • on the extruder
      • wide range of currents, again going as low as 100ma
      • swapped motors
      • swapped cables
      • swapped motor/cable combinations
      • swapped drivers
      • changing microstepping to every value between 1 and 256
    • on the Z
      • tried many currents, as low as it'll go and still move
      • swapped motors
      • swapped cables
      • swapped motor/cable combinations
      • slowed down all scripted movements <---
      • slowed down print speed <---
      • changing microstepping to every value between 1 and 256
    • on the entire unit
      • swapped duetmaestro
      • swapped PSU
      • tried slightly increasing voltage
      • tried slightly decreasing the voltage

    ---> these are the only changes that seem to help.

    Also, when it homes Z and locks, you can hear it try to change direction then just lock. It sounds like a thunk.

    I'm also playing with driver mode, spread-cycle seems to have a positive impact on the Z.

    P.S.

    Why is there no category for Help my machine is broken!



  • It would really help if you posted your config.g and homing files as well as a description of the mechanics of your printer. The z axis usually has to lift something heavy using lead screws. It can be sensitive to binding and motor current.



  • You’re saying “short to ground”? If that’s happening, that would be a hardware (wiring or motor or Duet) problem that you need to fix before fiddling with gcode settings.


  • administrators

    We've had one or two other reports of spurious short-to-ground reports on the Duet Maestro. Please try the following:

    • Try using spread cycle mode on the drivers concerned. [We'll have the drivers automatically switch from stealthchop2 to spread cycle at high speeds in a firmware update soon.]
    • Make sure that your first move on the drivers concerned is a slow homing move. This is needed to for the drivers to tune the stealthchop2 settings. If you don't do this then stealthchop2 mode will use the wrong parameters. For this reason it is probably better to configure the extruders in spread cycle mode.
    • Try using the firmware binary at https://www.dropbox.com/s/m0r3ldy424mxf4v/DuetMaestroFirmware.bin?dl=0. This won't solve the problem, but if the drivers are on the verge of overheating then it will warn you. Caution: this isn't an official release yet, so use it with care. You may wish to reduce motor currents to reduce the chance of damage if something goes wrong.

    HTH David



  • Yeah, it exactly was stealth chop as the culprit. It's a shame, I've been tearing apart, redesigning, and replacing one part after another on my Promega for months. Turns out, all that was needed was changing the driver setting and unrelatedly, replacing the crappy Z motion system. I've spent almost 750 hours and $1000 on rebuilding this thing, only for it to be a setting.

    Nothing was overheating. No voltage or current problems.

    Are you also saying that the first move for every driver should be a long, slow move to tune the driver?

    That could explain why I got intermittent success.

    The default settings on the pmega we're not particularly slow for homing.

    What's your definition of slow?


  • administrators

    Please try the 2.02RC1 firmware. It lets you configure the speed at which the drives switch over from stealthChop to spreadCycle, to avoid the issues with stealthChop at high speeds. See the new V parameter of the M569 command.





  • tried it, didn't even tune it, just seems to work. btw, where can i find docs on the V parameter?


  • administrators



  • @dc42 It's doing it again. The only thing I can think of is that I removed the fan that was blowing on the board. Temps are averaging 42C now rather than 35C before. Is that really hot enough to cause these problems?


  • administrators

    No, that's not too hot. If you adjusted the V parameters in the M569 commands, what values did you use?



  • Well, I used Excel to plot the curve that maps the value to speed crossover.

    I played with it for a bit and ultimately just set it to 1.

    I'm feeling lost at this point on how to choose a value.


  • administrators

    When the stepper drivers switch between stealthChop and spreadCycle mode, there is a motor jerk. You obviously don't want this to happen in the middle of a printing move. So I think there are two sensible settings for the V parameter:

    1. Choose a value that corresponds to very low movement speeds. So stealthChop will be used when the motor is stationary, but it will switch to spreadCycle as soon as it starts moving.

    2. Choose a value that corresponds to movement speeds above the highest printing speed, so that the transition will not occur during printing moves, but may occur during travel moves.

    You will probably want to use the same setting for the X and Y motors, but for a Cartesian or CoreXY printer you may want a different setting, because the Z steps/mm is usually higher and because the only Z movement during printing moves is normally slow movement to do bed compensation.

    To see what movement speed your chosen V value corresponds to, send M569 P# where # is the driver number.



  • @dc42

    Thank you so much, that makes total sense.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.