Error: Short-to-ground on drivers 1

  • Hello, on the dry-fire test on motor movement I received "Error: Short-to-ground on drivers 1" flashing frequently and menacingly. YAT reports the same thing. Before the error appeared the motor was moving quite slowly compared to the other one (CoreXY), now its unresponsive. Picture -

    Running on 12v (12.03 measured), the board is resting on one of the foam inserts that were in the box and it was bough from RepRapWorld, The Netherlands. Upon close inspection the driver has two small blobs on it.

    I searched the forum and I'm prepared for the bad news but I was hoping that there is some remedy.

  • Isn't that foam supposed to be conductive for ESD reasons?
    Try with a (different) insulator to rest your board on…

    missed the bit where you said "blobs in the chip". Well that's most likely bad news.

  • I did for the sake of the argument and nothing changed. Now I'm quite interested in that foam is a proper insulator or not.

    That being said is there any way I could have damaged the driver?!

  • administrators

    It's possible that you damaged the driver by having a short circuit in your stepper motor wiring. So please check your wiring. However, some drivers fail during the first few hours of use for no apparent reason. So please ask RepRapWorld to repair or replace your Duet under warranty.

  • I looked at the wiring and nothing is wrong to the naked eye.

    I did some more tests moving different motors with different drivers. What I discovered is that Z driver moves the motors without issues but when I try to move Y stepper with X driver it displays short-to-ground on driver 1 - previously it was only when I moved Y driver. Now X driver behaves the same way Y driver did before failing. Also, currently X driver is connected to Y stepper with the wiring from X stepper, so the wiring itself shouldn't be the issue. Can the stepper itself cause that?


    I played some more with the setup and I made the following observations:

    1. After I power up it takes some time (a minute) to be able to move the motors properly, before that they try to move but appear to not have the torque to do so.

    2. Before the update I was thinking if a stepper motor might be screwing everything up but I checked both steppers more diligently and they appear to behave identically.

    3. When I have X driver connected to X motor and Y driver not connected at all, and I move the X axis via the interface it moves properly, but I can move the same (X) axis by the same value according to the web interface but a shorter distance by using the Y axis movement button from the interface.

    4. I received a Warning Vin under-voltage event (2.9V). Just by looking at it the interface reports a steady 12-12.1V. The power wires are properly secured in the screw-in terminals of both the board and the power supply. The power supply is indeed a chinese copy I had lying around. Additionally, I ran M122 and this was the output:

    === Diagnostics ===
    Used output buffers: 3 of 32 (16 max)
    === Platform ===
    RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
    Board ID: 08DGM-95BNL-MGPSN-6JTDJ-3SJ6T-12YHZ
    Static ram used: 15448
    Dynamic ram used: 98976
    Recycled dynamic ram: 264
    Stack ram used: 1392 current, 5936 maximum
    Never used ram: 10448
    Last reset 00:02:51 ago, cause: power up
    Last software reset at 2018-02-16 13:56, reason: User, spinning module GCodes, available RAM 7912 bytes (slot 0)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min 35.8, current 36.1, max 36.3
    Supply voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max not available
    Driver 1: short-to-ground, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-02-17 16:27:24
    Cache data hit count 634789147
    Slowest main loop (seconds): 0.155786; fastest: 0.000110
    === Move ===
    MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 4, completed moves: 4
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
    === GCodes ===
    Segments left: 0
    Stack records: 1 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    Network state is running
    WiFi module is connected to access point
    Failed messages: pending 0, notready 0, noresp 0
    WiFi firmware version 1.20
    WiFi MAC address 2c:3a:e8:0a:ec:5d
    WiFi Vcc 3.42, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 16688
    WiFi IP address
    WiFi signal strength -53dBm, reconnections 0, sleep mode modem
    HTTP sessions: 1 of 8
    Socket states: 2 0 0 0 0 0 0 0
    Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

  • administrators

    Something isn't right with this:

    but when I try to move Y stepper with X driver it displays short-to-ground on driver 1

    Driver 1 is the Y driver.

  • Negative, wording is correct despite being a bit ambiguous, I'll try to rephrase.

    As CoreXY doesn't have true X and Y axes it has alpha and beta motors working together, which I've seen being addressed as X (left) and Y (right) motors and I have adopted it. What you have quoted is to be read as follows - when I have Y stepper (right stepper/beta motor) connected to X driver on the Duet Wifi and I move the X axis via the web interface I get error short-to-ground on driver 1.

    See 3) of my update as I go into bit more detail there.

  • administrators

    If attempting to move the motor connected to the Y motor output causes that error message to appear, that indicates that driver 1 (Y driver) has a shorted mosfet or that there is a short in the external wiring. If it produces that message even with no motor connected to the Y motor output, then it's the driver that is faulty.

  • Thanks for your input!

    Currently, I have the Z and X motors connected to their respective drivers i.e. Y driver is free. When I move Z axis no error appears. When I move X axis the error in driver 1 appears. When I move Y axis the carriage does move although just a short distance and quite slowly. If I'm understanding correctly what you have written, driver 1 (Y) is faulty.

    That is unfortunate but I'd rather think forward. I was wondering how can I remap the driver from E1 (which is free since I'm using a single extruder) to move the Y axis. I'm looking at the gcode but I must say its harder for me than I thought.

  • administrators

    Yes, to can use M584 X0 Y4 Z2 E3 in config.g to do that. But you are entitled to have your Duet repaired or replaced under warranty, assuming you have had it for less than 6 months.

  • Thanks for spelling it out for me, I appreciate your time.
    I only wanted to ask if I have to add some gcode to "deactivate" driver 1 (Y) or just add the remapping gcode, connect to the proper driver and go about my merry ways? Also, what should I make of the low voltage error I received earlier? I do have many more questions but I believe I should make use of the search feature.

    Also, thank you for bringing that up. I'd rather have a properly functioning board but I wanted to continue with finalizing my config. I did contact RepRapWorld so we'll see that will happen but yes I've had it for less than six months.

  • administrators

    The output MOSFETs won't be enabled on driver 1 if it is never used.

    The M584 command must come earlier in config.g than the M906 command, also earlier than the M350 command if you have one.

  • Thanks for clarifying. I did add that in my ;Drives and I can move all axes without any errors.

    I appreciate your help. I'm happy the support of the boards lives up to the expectations. Well done, to you, dc42, sir.

  • Now, as everything moves correctly I wanted to have my axes home in the correct direction. I flipped Z and it worked as expected. However, when I try to flip Y (drive 4) it goes south somewhere. I added M569 P4 S0 ; Drive 4 goes backwards but in that case when I move X from the interface Y moves in the wrong direction and when I move Y in the interface X moves in the right direction. If I add M569 P4 S1 the interface moves the correct axis and X moves in the right direction and Y moves in the wrong direction.
    ; Drives
    M584 X0 Y4 Z2 E3 ;remap drive Y to drive E1
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S0 ; Drive 2 goes backwards
    M569 P3 S1 ; Drive 3 goes forwards
    M569 P4 S0 ; Drive 4 goes backwards

  • administrators

    It sounds to me that your printer currently has a left-hand coordinate system. To change it to a right-hand coordinate system, swap over the X and Y motor connections or swap X and Y in the M584 command, then use M569 to get the correct directions.

  • By a lucky mistake I just read that RRF uses a right-hand origin. Where can I get more info why this is the case and wouldn't it result in mirrored prints?

  • administrators

    All 3D printing assumes a right-hand coordinate system - which means that looking from above, the +Y direction is rotated 90 degrees anticlockwise from the +X direction.

    On a CoreXY printer, the usual choice is that looking at the front of the printer, +X is to the right and +Y is away from you.

  • I think we both are talking about an origin of front/left like here -, do correct me if that's not the case.

    I had issues with it but after going out for a walk I now have it working properly with the following, if anybody ever needs it:
    ; Drives
    M584 X0 Y4 Z2 E3 ;remap driver Y to driver E1
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S0 ; Drive 2 goes forwards
    M569 P3 S1 ; Drive 3 goes forwards
    M569 P4 S1 ; Drive 3 goes forwards

  • This post is deleted!

Log in to reply