Possible driver 0 issue on newly purchased Duet Wifi

  • I just purchased a Duet Wifi from Filastruder last week. I have an existing delta printer that has been running with a 24V, BBB-Cramps controller for around 2 years. I did a direct swap of the old control board for the Duet Wifi. After completing the wiring connections and configuring the delta parameters in the various system files (config.g, homing.g, etc) I started up the web control server and checked my motor move directions, hotend operation/sensor, heatbed operation/sensor, limit switches, and proper fan operation. Everything was properly connected and functioning as expected.

    I then proceeded to home all axes with the homeall function on the web control. Everything seemed to home ok, with the limit switches triggering properly twice as expected. The homing program then moved the effector down about 5mm below the switches and finished.

    This is where the issues started. On a g-code console command, "G1 Z200 F1500" to move the effector down from the homing height of Z338.16, the "X" motor experienced a severe skipping of steps. It was a loud buzz/grind sound and the x-axis carriage barely moved at all while the y- and z-axes both moved normally. Went to re-home and try again, but now the issue occurred during homing. Restarted the duet wifi and tried again. This time it homed and moved down to Z200, but moving it back up to Z300 again had the skipping steps. I tried flashing to the version 20 firmware, but the issue didn't go away. It seemed rather random and "glitchy" so I thought it might be wiring. I checked the "X" motor lead connection to make sure the pins were all properly inserted and making contact - no issues. After much troubleshooting adjustments: micro-step settings, speeds, accel, motor amperage, I was unable to software resolve the issue. I then proceeded to troubleshoot the connections further. I swapped the "X" motor lead on driver 0 with the "Y" motor lead on driver 1 (as well as the x and y limit switches). The motor with the issue was now "Y", still on driver 0.

    I contacted Filastruder for support and they suggested I post here. I think there might be a driver, power control, or step generator issue on this particular board. I was wondering if there are any other troubleshooting ideas to try. Otherwise, I would be interested in a direct swap, if possible, so you could inspect the current board.

    More machine parameters if necessary…
    24V, 14.5A Meanwell power supply
    24V E3D v6 hotend
    250mm 24v heated bed (capton heating element)
    0.9deg motors, GT2 belts on 20 tooth pulleys
    32x microstepping setting (320 steps / mm)
    1500mA setting for X, Y, Z
    1200mA setting for E0
    Was not running heat on hotend or bed at the time of these skipped steps.


  • administrators

    Hi Eric

    If the issue stays with driver when you swap the axis it certainly sounds like a driver issue. If you do M122 what is reported for that driver?



  • The occurances are pretty random, but happen often enough that I don't feel comfortable running any sort of bed calibration (manual). I have removed my effector arms so as not to damage them and ran the carriages up and down in the z at 50mm increments several times. The stuttering in the driver 0 did not appear until maybe 20-30 moves in. It then increased in strength of skips/tremors, then decreased and mostly went away. It came back again around move 50 or so.

    Here's the driver section from the m122 command…

    MCU temperature: min 24.4, current 33.3, max 33.6
    Supply voltage: min 23.6, current 23.8, max 24.1, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max 0/1023
    Driver 1: standstill, SG min/max 0/245
    Driver 2: standstill, SG min/max 0/242
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-01-16 22:29:23
    Cache data hit count 4294967295
    Slowest main loop (seconds): 0.158098; fastest: 0.000110
    === Move ===
    MaxReps: 3, StepErrors: 0, FreeDm: 240, MinFreeDm 234, MaxWait: 743926933ms, Underruns: 0, 0
    Scheduled moves: 51, completed moves: 51

  • administrators

    The SG max of 1023 isn't normal, which I think confirms a problem with that driver.

  • So, does that mean I need duet3d authorization to return to filastruder? I have already contacted Tim, and that is pretty much what he needed to start a replacement process.

    Thanks for your help and confirming my suspicions.

  • administrators

    No, you need just Tim's agreement.

  • Thanks David

  • Agreed and sorted!

  • Just out of curiosity, what is the "SG" value (and why is 1023 not normal?)

    The reason for my curiosity is that on my machine (which seems to be working fine) I have a max SG of 1023 on one of my extruder motors (but I haven't noticed any issues with it):

    Driver 0: ok, SG min/max 0/256
    Driver 1: ok, SG min/max 0/198
    Driver 2: standstill, SG min/max 0/498
    Driver 3: ok, SG min/max 0/1023
    Driver 4: standstill, SG min/max not available

    (The above was reported while in the middle of a print that's using the E0 motor (drive 3.)

  • administrators

    Interesting, I assumed SG 1023 was not normal because I haven't see it go that high. It is a measure of the maximum motor load that was detected since you last ran M122.

Log in to reply