Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    SOLVED Printer stop moves mid-print but extrudes while stationary

    Using Duet Controllers
    2
    9
    85
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jandcando
      jandcando last edited by jandcando

      We've had this issue for a few months now, where prints that seem longer than a few hours can't complete. What happens is all XYZ motion stops but the extruder sits there dumping filament into a blob and grinding filament in the extruder with no end until we unplug it or do an emergency stop. The PanelDue is completely unresponsive during this, but emergency stopping from the web page works. It's happened seemingly at random, but it's shown some consistency within a given gcode. We've sliced models on various versions of PrusaSlicer, and when we started trying to fix this problem I was on ReprapFirmware v2.04. We've since successfully upgraded to v3.20 in hopes of solving this issue, but it just happened again. I'm running a Duet Ethernet. I was able to run diagnostics as it was happening just now, so I've attached that below. Some things that stand out are very long maxWait values in the Move section, as well as slowest loops of about 200ms. Not sure if this is nominal, but it seems pretty long.

      Is this a problem with gcodes that are too long? We recently cleared the SD card too, but it doesn't seem to have helped. Can someone who knows how to interpret this log please offer some guidance? We're a bit stumped and somewhat frustrated at all the filament wasted in these failed prints.

      M122
      === Diagnostics ===
      RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2 running on Duet Ethernet 1.02 or later
      Board ID: 08DGM-9T6BU-FG3SN-6J9F2-3SN6S-1UWMH
      Used output buffers: 3 of 24 (20 max)
      === RTOS ===
      Static ram: 23460
      Dynamic ram: 68856 of which 60 recycled
      Never used RAM 19704, free system stack 108 words
      Tasks: NETWORK(ready,174) HEAT(blocked,309) MAIN(running,421) IDLE(ready,19)
      Owned mutexes:
      === Platform ===
      Last reset 02:54:57 ago, cause: software
      Last software reset at 2021-01-14 18:40, reason: User, GCodes spinning, available RAM 19740, slot 1
      Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
      Error status: 0x00
      Aux0 errors 0,0,0
      MCU temperature: min 35.6, current 39.4, max 40.8
      Supply voltage: min 11.0, current 12.4, max 13.3, under voltage events: 0, over voltage events: 0, power good: yes
      Driver 0: position 9879, standstill, SG min/max 0/482
      Driver 1: position 8396, standstill, SG min/max 0/491
      Driver 2: position 4566, standstill, SG min/max 0/734
      Driver 3: position 0, ok, SG min/max 0/1023
      Driver 4: position 0, standstill, SG min/max not available
      Driver 5: position 0
      Driver 6: position 0
      Driver 7: position 0
      Driver 8: position 0
      Driver 9: position 0
      Driver 10: position 0
      Driver 11: position 0
      Date/time: 2021-01-14 21:35:49
      Cache data hit count 4294967295
      Slowest loop: 216.07ms; fastest: 0.11ms
      I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
      === Storage ===
      Free file entries: 9
      SD card 0 detected, interface speed: 20.0MBytes/sec
      SD card longest read time 2.0ms, write time 9.8ms, max retries 0
      === Move ===
      DMs created 83, maxWait 194850ms, bed compensation in use: mesh, comp offset 0.000
      === MainDDARing ===
      Scheduled moves 104550, completed moves 104510, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 6], CDDA state 3
      === AuxDDARing ===
      Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === Heat ===
      Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
      Heater 0 is on, I-accum = 0.3
      Heater 1 is on, I-accum = 0.9
      === GCodes ===
      Segments left: 1
      Movement lock held by null
      HTTP is idle in state(s) 0
      Telnet is idle in state(s) 0
      File is doing "G1 X99.872 Y70.322 E3.12365" in state(s) 0
      USB is idle in state(s) 0
      Aux is idle in state(s) 0
      Trigger is idle in state(s) 0
      Queue is idle in state(s) 0
      LCD is idle in state(s) 0
      Daemon is idle in state(s) 0
      Autopause is idle in state(s) 0
      Code queue is empty.
      === Network ===
      Slowest loop: 194.31ms; fastest: 0.05ms
      Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
      HTTP sessions: 1 of 8
      Interface state active, link 100Mbps full duplex
      === Filament sensors ===
      Extruder 0 sensor: ok
      

      Thanks to anyone who has any advice here!

      1 Reply Last reply Reply Quote 0
      • Phaedrux
        Phaedrux Moderator last edited by

        Please include your config.g and a sample gcode file.

        Did you try a new SD card, or just cleared it?

        Was that M122 captured when it was stalled, or after it was power cycled?

        Z-Bot CoreXY Build | Thingiverse Profile

        1 Reply Last reply Reply Quote 1
        • jandcando
          jandcando last edited by

          config.g

          None of the gcode files are small enough to be allowed to be posted so instead here is a Google Drive link for the latest one which failed.

          Sliced GCode

          Just deleted most of the gcode files by plugging it into a computer separate of the Duet board. Did not wipe it but have updated the firmware and configs on the card and board. This error was after the update but in the exact same manner.

          The m122 was while it was still extruding and then we turned it off after running the command.

          1 Reply Last reply Reply Quote 0
          • Phaedrux
            Phaedrux Moderator last edited by Phaedrux

            Why only x8 microstepping on Z and E?

            I don't see anything out of place in config.g, but you can send M98 P"config.g" to check for any other syntax errors.

            I also notice that your file is sliced with absolute extruder moves. Might want to try setting your slicer to use relative extrusion instead. If that does end up fixing it, it would be worth investigating why absolute extrusion is having an issue.

            I would also try a fresh SD card.

            Z-Bot CoreXY Build | Thingiverse Profile

            1 Reply Last reply Reply Quote 1
            • jandcando
              jandcando last edited by

              I'll definitely try a fresh SD card (might just reformat this one and copy the system folders over again), and I'll put it on relative extruder moves too. The absolute extruder moves could explain why it fails in exactly the same spot within a gcode. The 8x microstepping is just me trying to put more holding torque where I think it is needed, although on E it is probably unnecessary. On Z however I'm just really trying to keep both motors in sync.

              Thanks for the help, and I'll let you know how these changes go!

              1 Reply Last reply Reply Quote 0
              • Phaedrux
                Phaedrux Moderator last edited by

                x8 microstepping won't really get you more torque. x16 with interpolation is definitely the recommended setting on a Duet 2. Best of all worlds.

                To keep Z in sync you have 2 options, mechanical linkage via belt, or using a leveling routine to sync them up after the fact. When the motors power off and on they will naturally snap to the nearest full step which could be in different directions.

                The reason I say fresh SD card is that it could be failing. A full surface format may help, but only if it has enough spare cells left to replace any bad ones it finds.

                Z-Bot CoreXY Build | Thingiverse Profile

                1 Reply Last reply Reply Quote 1
                • jandcando
                  jandcando last edited by

                  Ah ok, I'll put all the axes on 16x with interpolation then. I ran M98 and it didn't come up with anything other than reporting the network options that were set so I think that's good. Thank you again for looking into this.

                  1 Reply Last reply Reply Quote 0
                  • jandcando
                    jandcando last edited by

                    UPDATE: It looks like setting the slicer to relative extruder moves has worked! Looking back I'm surprised it did as well as it did with these wires crossed. We were just able to print a part that we've had fail on numerous past occasions, so I'm feeling like this is actually fixed now.

                    I also want to thank you for the 16x microstepping tip for the Z axis. It's so quiet now 😮

                    I'll mark this as solved for now, I think we'll try out some other models that didn't work before. Thanks for the help!

                    1 Reply Last reply Reply Quote 0
                    • Phaedrux
                      Phaedrux Moderator last edited by

                      That's great that it appears to be working now. Not sure why absolute extrusion would fail like that. Please let us know if it really is resolved now.

                      Z-Bot CoreXY Build | Thingiverse Profile

                      1 Reply Last reply Reply Quote 1
                      • First post
                        Last post
                      Unless otherwise noted, all forum content is licensed under CC-BY-SA