Short-To-Ground Different Drivers on Different Prints



  • I am having recurring short-to-ground errors intermittently with my Duet Maestro upgraded Anycubic Kossel Linear Plus.

    The beginning of the print will go fine, short prints will not have a problem at all. After some amount of time one of the steppers will stop working and I will get a stream of "Error: shotr-to-ground on drivers 2", sometimes drivers 3 or 1, always just one number listed.

    This is what the printer looks like:
    failed print

    A few layers just fine, then a big mess (I assume this is when the one stepper stops and the others carry one), then when it tries to home at the end of the print the other 2 towers home properly and the other never recovers.

    I have checked for shorts around the drivers, raised the board on non-conductive foam, and checked all the wiring. Since it works for some amount of time I don't think it can be an exploded chip. If I simply reset the machine it will happily print a calibration cube with no problems.

    Thanks for any help or tips, I'm at a bit of a loss on this one.

    =================================
    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 Maestro version 2.01beta1(RTOS) running on Duet Maestro 1.0
    Board ID: 08DJM-956DU-LL3T0-6JKD4-3SD6S-KB26N
    Used output buffers: 3 of 20 (14 max)
    === RTOS ===
    Static ram: 22420
    Dynamic ram: 92388 of which 16 recycled
    Exception stack ram used: 344
    Never used ram: 15904
    Tasks: NETWORK(ready,460) HEAT(blocked,1292) MAIN(running,608)
    Mutexes: FilamentSensors(null) DHT(null) W5500(null) TelnetGCodeReply(null) HttpGCodeReply(null) Telnet(null) HTTP(null) SD1(null) SD0(null) DirSearch(null) FileSystem(null) Aux(null) USB(null) MessageBox(null) ToolList(null) SPI(null) Malloc(null) NetworkGCodeInput(null) NetworkGCodeInput(null) FileInfoParser(null)
    === Platform ===
    Last reset 16:11:45 ago, cause: power up
    Last software reset at 2020-06-02 22:00, reason: User, spinning module GCodes, available RAM 15960 bytes (slot 0)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x04418000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 15.0MBytes/sec
    SD card longest block write time: 54.0ms
    MCU temperature: min 24.4, current 35.8, max 52.6
    Supply voltage: min 12.6, current 13.0, max 13.2, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, read errors 0, write errors 0, ifcount 14, reads 17087, timeouts 641
    Driver 1: standstill, read errors 0, write errors 0, ifcount 14, reads 16733, timeouts 354
    Driver 2: short-to-ground standstill, read errors 0, write errors 0, ifcount 14, reads 16400, timeouts 332
    Driver 3: standstill, read errors 0, write errors 0, ifcount 10, reads 16012, timeouts 392
    Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 15665, timeouts 351
    Date/time: 2020-06-05 13:07:16
    Slowest loop: 4581229.00ms; fastest: 0.07ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 10, FreeDm: 240, MinFreeDm 120, MaxWait: 3409856623ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: none
    Bed probe heights: -5.184 -4.845 -4.605 -4.526 -4.308
    === Heat ===
    Bed heaters = 0, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 1 is on, I-accum = 0.6
    === GCodes ===
    Segments left: 0
    Stack records: 2 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
    lcd is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 4581228.50ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state: 5


  • Moderator

    Are you actively cooling the board?

    Your firmware version is quite out of date and beta. I suggest upgrading to 2.05.1 and DWC 2.0.7.

    Please post your config.g



  • No active cooling on the board, if it is getting too hot I can try and lift my machine up and give the board some more space, add a fan blowing on it.

    I will update, add the cooling and try another print.

    Here is my config.g:
    ; Configuration file for Duet WiFi (firmware version 1.20 or newer)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool on Thu Jul 12 2018 20:54:00 GMT-0500 (Central Daylight Time)

    ; General preferences
    G90 ; Send absolute coordinates...
    M83 ; ...but relative extruder moves

    ;*** The homed height is deliberately set too high in the following - you will adjust it during calibration.

    ; After G32 auto-calibrate, copied from config-override.g
    ; Note: G31 Z (below) affects M665 H, and this is NOT yet calibrated.
    M665 L271.500 R134.638 H296.189 B105.0 X-0.477 Y-0.304 Z0.000
    M666 X-0.910 Y0.111 Z0.799 A0.00 B0.00

    ;Manually copied from Marlin config.h in Anycubic's github repository
    ;M665 R135.4 L271.5 B105 H300 ; Set delta radius, diagonal rod length, printable radius and homed height
    ;M666 X0 Y0 Z0 ; Put your endstop adjustments here, or let auto calibration find them

    ; Network
    M550 PAKL Plus ; Set machine name
    M552 S1 ; Enable network
    ;*** Access point is configured manually via M587
    M586 P0 S1 ; Enable HTTP
    M586 P1 S0 ; Disable FTP
    M586 P2 S0 ; Disable Telnet

    ; Drives
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S1 ; Drive 2 goes forwards
    M569 P3 S1 ; Drive 3 goes forwards
    M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
    M92 X80 Y80 Z80 E96 ; Set steps per mm
    M566 X300 Y300 Z300 E300 ; Set maximum instantaneous speed changes (mm/min)
    M203 X12000 Y12000 Z12000 E12000 ; Set maximum speeds (mm/min)
    M201 X3000 Y3000 Z3000 E3000 ; Set accelerations (mm/s^2)
    M906 X1000 Y1000 Z1000 E1000 I30 ; Set motor currents (mA) and motor idle factor in per cent
    M84 S30 ; Set idle timeout

    ; Axis Limits
    M208 Z0 S1 ; Set minimum Z

    ; Endstops
    M574 X2 Y2 Z2 S1 ; Set active high endstops

    ; Z-Probe
    M558 P4 H15 F120 T6000 ; Set Z probe type to switch and the dive height + speeds
    G31 P1000 X0 Y0 Z15.9 ; Set Z probe trigger value, offset and trigger height
    M557 R105 S20 ; Define mesh grid

    ; Heaters
    M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
    M143 H0 S120 ; Set temperature limit for heater 0 to 120C
    M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
    M143 H1 S280 ; Set temperature limit for heater 1 to 280C

    ; Fans
    M106 P0 S0.3 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P2 S1 I0 F500 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on

    ; Tools
    M563 P0 D0 H1 ; Define tool 0
    G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
    G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    ; Automatic power saving
    M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; Set voltage thresholds and actions to run on power loss

    ; Custom settings are not configured

    ; Miscellaneous
    M501 ; Load saved parameters from non-volatile memory
    T0 ; Select first tool


  • Moderator

    @colinmcglone said in Short-To-Ground Different Drivers on Different Prints:

    MCU temperature: min 24.4, current 35.8, max 52.6

    Yes I suspect that active cooling will be required especially if the Maestro is enclosed. If your MCU is hitting 52c, the drivers are likely much hotter. Your motor currents are also on the higher end for the Maestro so active cooling is recommended.

    https://duet3d.dozuki.com/Wiki/Mounting_and_cooling_the_Duet_2_Maestro
    https://duet3d.dozuki.com/Wiki/Mounting_and_cooling_the_board



  • OK, that's great, cooling is easy.

    Thanks!



  • Bad news, got exactly the same problem just a few layers short of last time.

    The board had a lot more room to breathe and a fan on it most of the print, highest temp was 44c but at the time of the error it was 34c (once I added the fan it got cool and stayed at that temp).

    I reset the board and homed all axis and the one that was giving the error worked just fine.

    I have also updated the firmware and DWC to the versions you suggested, I will try running another print.

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 Maestro version 2.01beta1(RTOS) running on Duet Maestro 1.0
    Board ID: 08DJM-956DU-LL3T0-6JKD4-3SD6S-KB26N
    Used output buffers: 1 of 20 (14 max)
    === RTOS ===
    Static ram: 22420
    Dynamic ram: 92388 of which 16 recycled
    Exception stack ram used: 344
    Never used ram: 15904
    Tasks: NETWORK(ready,460) HEAT(blocked,1292) MAIN(running,608)
    Mutexes: FilamentSensors(null) DHT(null) W5500(null) TelnetGCodeReply(null) HttpGCodeReply(null) Telnet(null) HTTP(null) SD1(null) SD0(null) DirSearch(null) FileSystem(null) Aux(null) USB(null) MessageBox(null) ToolList(null) SPI(null) Malloc(null) NetworkGCodeInput(null) NetworkGCodeInput(null) FileInfoParser(null)
    === Platform ===
    Last reset 01:35:50 ago, cause: watchdog
    Last software reset at 2020-06-05 13:16, reason: User, spinning module GCodes, available RAM 15904 bytes (slot 1)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x04418000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 15.0MBytes/sec
    SD card longest block write time: 4.4ms
    MCU temperature: min 33.7, current 34.0, max 44.2
    Supply voltage: min 12.6, current 13.2, max 13.2, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, read errors 0, write errors 1, ifcount 29, reads 49066, timeouts 28
    Driver 1: standstill, read errors 0, write errors 1, ifcount 28, reads 49051, timeouts 15
    Driver 2: short-to-ground standstill, read errors 0, write errors 1, ifcount 28, reads 49037, timeouts 14
    Driver 3: standstill, read errors 0, write errors 1, ifcount 21, reads 49025, timeouts 15
    Driver 4: standstill, read errors 0, write errors 1, ifcount 13, reads 49012, timeouts 16
    Date/time: 2020-06-05 14:52:46
    Slowest loop: 4581229.00ms; fastest: 0.07ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 1, FreeDm: 240, MinFreeDm 120, MaxWait: 4271228863ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: none
    Bed probe heights: -4.421 -4.907 -5.017 -4.738 -4.070
    === Heat ===
    Bed heaters = 0, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 1 is on, I-accum = 0.5
    === GCodes ===
    Segments left: 0
    Stack records: 2 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
    lcd is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 4581228.50ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state: 5



  • This post is deleted!


  • @colinmcglone I would update the firmware first, because I found your LaErrors to be a rounding error of RRF2.01 (see https://forum.duet3d.com/topic/8362/duet-2-wifi-laerrors/3), maybe there are other errors fixed.

    A detail that I really don't understand in your M122 is the high value of Slowest loop.



  • Quick follow up.

    I have completed an 8 hour print with no problems, so it seems like the old firmware was the root of the problem.

    Thanks again for the help!



  • @colinmcglone Good to know, thanks for information.


Log in to reply