Duet3D Logo

    Duet3D

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

    Duet 3 stops in the middle of a print, thinks its finished

    General Discussion
    4
    6
    109
    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.
    • cack
      cack last edited by

      Hey!

      I'm sorry if I'm writing in the wrong category, I'm new here.

      So I have set my new Duet 3 to run a big 2 meter by 1,5 meters printer. The purpose of the printer is to print on flat materials so the z-axis is only about 90 millimeters.

      Im currently using the printer to paint on acoustic panels. I have set up a stepper to press the valve on a spray can as extruder. Z axis is disabled in this scenario.

      Sometimes the whole print prints fine, but a few times in the past and today especially the printer just halts in the middle of the print. It thinks it's finished, at least it says 100% on the progress bar. I have finished this file before with no problems.

      The file that im running is a custom file that we compiled in python. It moves to a coordinate and then uses extruder, moves to another etc. To my knowledge there shouldnt be any problems in the file. The file has been attached to the message.

      After this happens and i try to run a modified file where i skip the already printed bits, duet gives a M32 error claiming it cannot parse major gcode numbers. And after this when I try to run any files duet says its already printing while it is not.

      Before I can print anythin i need to reset the duet and upload the file again, modified. It wont run if I dont upload it again.

      Is this a known problem? Could there be problems in my file?

      I ran an M122 before reseting the board.

      M122
      === Diagnostics ===
      RepRapFirmware for Duet 3 MB6HC version 3.01-RC3 running on Duet 3 MB6HC v0.6 or 1.0
      Board ID: 08DJM-956L2-G43S4-6J1FG-3SJ6S-KB6LH
      Used output buffers: 1 of 40 (7 max)
      === RTOS ===
      Static ram: 153948
      Dynamic ram: 158816 of which 36 recycled
      Exception stack ram used: 512
      Never used ram: 79904
      Tasks: ETHERNET(blocked,844) NETWORK(ready,1972) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1436) CanClock(blocked,1436) TMC(blocked,76) MAIN(running,5372) IDLE(ready,76)
      Owned mutexes:
      === Platform ===
      Last reset 01:03:15 ago, cause: software
      Last software reset at 2020-03-03 23:31, reason: User, spinning module LinuxInterface, available RAM 80008 bytes (slot 0)
      Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
      Error status: 0
      Free file entries: 10
      SD card 0 not detected, interface speed: 37.5MBytes/sec
      SD card longest block write time: 0.0ms, max retries 0
      MCU temperature: min 33.8, current 34.9, max 35.2
      Supply voltage: min 12.3, current 12.5, max 12.6, under voltage events: 0, over voltage events: 0, power good: yes
      12V rail voltage: min 11.4, current 11.6, max 11.7, under voltage events: 0
      Driver 0: standstill, reads 26976, writes 11 timeouts 0, SG min/max 0/0
      Driver 1: standstill, reads 26932, writes 55 timeouts 0, SG min/max 0/385
      Driver 2: standstill, reads 26960, writes 28 timeouts 0, SG min/max 0/1023
      Driver 3: standstill, reads 26925, writes 63 timeouts 0, SG min/max 0/647
      Driver 4: standstill, reads 26925, writes 63 timeouts 0, SG min/max 0/630
      Driver 5: standstill, reads 26930, writes 59 timeouts 0, SG min/max 0/552
      Date/time: 2020-03-04 00:34:59
      Slowest loop: 3.12ms; fastest: 0.14ms
      === Move ===
      Hiccups: 0(0), FreeDm: 375, MinFreeDm: 371, MaxWait: 1138591ms
      Bed compensation in use: none, comp offset 0.000
      === MainDDARing ===
      Scheduled moves: 0, completed moves: 7, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
      === AuxDDARing ===
      Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
      === Heat ===
      Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
      === GCodes ===
      Segments left: 0
      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
      trigger* is ready with "M122" in state(s) 0
      queue is idle in state(s) 0
      lcd is idle in state(s) 0
      spi 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: 1.10ms; fastest: 0.01ms
      Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
      HTTP sessions: 0 of 8

      • Ethernet -
        State: 2
        Error counts: 0 0 0 0 0
        Socket states: 0 0 0 0 0 0 0 0
        === CAN ===
        Messages sent 15196, longest wait 0ms for type 0
        === Linux interface ===
        State: 0, failed transfers: 71
        Last transfer: 19ms ago
        RX/TX seq numbers: 20385/57538
        SPI underruns 211, overruns 201
        Number of disconnects: 0
        Buffer RX/TX: 0/0-0
        === Duet Control Server ===
        Duet Control Server v1.1.0.5
        Code buffer space: 4096
        Configured SPI speed: 2000000 Hz
        Full transfers per second: 32.43

      Thanks for your help and sorry for the inconvenience.
      prime_numbers_2.gcode

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

        Hmm, could it be that empty lines are not good in gcode? It would seem that the parsing problem was solved by removing them.

        Shouldnt be the cause for the stalling tho.

        1 Reply Last reply Reply Quote 0
        • dc42
          dc42 administrators last edited by

          The version of DSF you are running is somewhat older than the version of RRF, so I suspect an incompatibility between them. I suggest you upgrade DSF to the latest unstable version which AFAIR is 1.2.4. Alternatively, wait for RRF 3.01-RC4 and DSF 1.2.5 which we hope to release tomorrow.

          Duet WiFi hardware designer and firmware engineer
          Please do not ask me for Duet support via PM or email, use the forum
          http://www.escher3d.com, https://miscsolutions.wordpress.com

          A Former User 1 Reply Last reply Reply Quote 0
          • A Former User
            A Former User @dc42 last edited by A Former User

            @dc42 said in Duet 3 stops in the middle of a print, thinks its finished:

            I suggest you upgrade DSF to the latest unstable version which AFAIR is 1.2.4. Alternatively, wait for RRF 3.01-RC4 and DSF 1.2.5 which we hope to release tomorrow.

            just checked the current DuetPi-lite.zip it tracks the stable repo, will the RC4 be pushed to the stable repo or does OP need to add the unstable repo in any case?

            echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list

            1 Reply Last reply Reply Quote 0
            • dc42
              dc42 administrators last edited by

              3.01-RC4 has now been pushed to the unstable feed.

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              Tinchus 1 Reply Last reply Reply Quote 0
              • Tinchus
                Tinchus @dc42 last edited by

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