Duet3D Logo

    Duet3D

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

    Issues with command execution delays in 2.01

    General Discussion
    5
    9
    687
    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.
    • gtj0
      gtj0 last edited by

      Is anyone seeing issues where the Duet delays executing commands at some point in a print?

      In this example, the print was a few minutes in, going fine, still on the first layer, then started pausing between drawing line segments. I did the following M122 while it was happening.

      The pauses aren't limited to printing. Now even when jogging from the DWC there's a pause of a few seconds before the status goes from idle to busy and the move is executed.

      12:41:17 PMM122
      === Diagnostics ===
      RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet Ethernet 1.02 or later + DueX5
      Board ID: 08DGM-95BNL-MGPSJ-6JTD8-3SS6K-11XHZ
      Used output buffers: 3 of 20 (16 max)
      === RTOS ===
      Static ram: 28476
      Dynamic ram: 96004 of which 0 recycled
      Exception stack ram used: 420
      Never used ram: 6172
      Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3564)
      Owned mutexes:
      === Platform ===
      Last reset 00:15:30 ago, cause: reset button or watchdog
      Last software reset at 2018-08-12 12:25, reason: User, spinning module GCodes, available RAM 6384 bytes (slot 3)
      Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0440f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
      Error status: 0
      Free file entries: 9
      SD card 0 detected, interface speed: 20.0MBytes/sec
      SD card longest block write time: 40.5ms, max retries 0
      MCU temperature: min 32.6, current 36.4, max 37.0
      Supply voltage: min 1.7, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0
      Driver 0: standstill, SG min/max 0/1023
      Driver 1: standstill, SG min/max 0/1023
      Driver 2: standstill, SG min/max 0/1023
      Driver 3: standstill, SG min/max 0/1023
      Driver 4: standstill, SG min/max 0/1023
      Driver 5: standstill, SG min/max 0/160
      Driver 6: standstill, SG min/max 0/162
      Driver 7: standstill, SG min/max 0/184
      Driver 8: standstill, SG min/max not available
      Driver 9: standstill, SG min/max not available
      Expansion motor(s) stall indication: yes
      Date/time: 2018-08-12 12:41:16
      Slowest loop: 259.62ms; fastest: 0.06ms
      === Move ===
      Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 228, MinFreeDm: 153, MaxWait: 441013ms, Underruns: 0, 22
      Scheduled moves: 1739, completed moves: 1735
      Bed compensation in use: none
      Bed probe heights: 0.000 0.000 0.000 0.000 0.000
      === Heat ===
      Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
      Heater 0 is on, I-accum = 0.3
      Heater 1 is on, I-accum = 0.3
      === GCodes ===
      Segments left: 0
      Stack records: 3 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 ===
      Slowest loop: 243.84ms; fastest: 0.02ms
      Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
      HTTP sessions: 1 of 8
      Interface state: 5
      === Expansion ===
      DueX I2C errors 1939
      12:33:17 PMT:222.0 /200.0 T0:222.0 /200.0 B:70.4 /70.0
      12:32:47 PMFile Calibration Square v1.gcode selected for printing
      

      The only thing that stands out are "DueX I2C errors 1939"

      Anyone seen anything like this before?

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

        dc42 just released a 2.02 beta version and has this in the release notes:

        Bug fixes:
        I2C errors sometimes occurred if there was a task switch in the middle of an I2C transaction

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

          Do you have a very short and thick wire between the VIN- terminals of the Duet and DuetX5, as specified in the DueX5 fitting instructions; and are the screws on those terminals still tight?

          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

          1 Reply Last reply Reply Quote 0
          • gtj0
            gtj0 @whosrdaddy last edited by

            @whosrdaddy said in Issues with command execution delays in 2.01:

            dc42 just released a 2.02 beta version and has this in the release notes:

            Bug fixes:
            I2C errors sometimes occurred if there was a task switch in the middle of an I2C transaction

            Yeah I just saw that and will upgrade.

            @dc42 said in Issues with command execution delays in 2.01:

            Do you have a very short and thick wire between the VIN- terminals of the Duet and DuetX5, as specified in the DueX5 fitting instructions; and are the screws on those terminals still tight?

            120mm of 16AWG stranded between the two boards and yes, they're tight.

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

              Well, 2.02b1 seems to have fixed the issue but now I'm getting crappy overextruded prints. Come on @dc42 how can you release software that produces crappy prints!!! How come there isn't a web page where I can just say "i'm getting crappy prints" and have it tell me exactly how to fix it???

              🙂 🙂 Sorry, that other thread had me rolling on the floor. My day job is being a core developer on a totally unrelated open source project that's more complex and difficult to configure than this one. I see posts like that weekly. 🙂

              T3P3Tony 1 Reply Last reply Reply Quote 2
              • T3P3Tony
                T3P3Tony administrators @gtj0 last edited by

                @gtj0 ohh you had me triggered there! I was about to jump up and down and then saw you were joking!

                www.duet3d.com

                1 Reply Last reply Reply Quote 1
                • dc42
                  dc42 administrators @gtj0 last edited by

                  @gtj0 said in Issues with command execution delays in 2.01:

                  120mm of 16AWG stranded between the two boards and yes, they're tight.

                  120mm is longer than I would be comfortable with. However, the standard ribbon cables we supply are a little short if you want to place the two boards side by side with the power connectors next to each other, which is what I do.

                  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

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

                    Hi,

                    With the boards side-by-side (10mm space) I use 14 gauge solid connecting the boards with 14 gauge stranded feeding the middle of the two pieces of solid.

                    The pieces connecting the boards are about as short as they can be for a side-by-side arrangement.

                    It takes a little more work to do that but it seems to work fine. Four printers setup that way and no issues.

                    Frederick

                    Printers: A FT-5 with the 713 upgrade bits. A custom MarkForged style. A small Utilmaker style and a CoreXY from kits. Various hotends. Using Duets (2 and 3) running 3.4.1

                    gtj0 1 Reply Last reply Reply Quote 1
                    • gtj0
                      gtj0 @fcwilt last edited by

                      @fcwilt said in Issues with command execution delays in 2.01:

                      Hi,

                      With the boards side-by-side (10mm space) I use 14 gauge solid connecting the boards with 14 gauge stranded feeding the middle of the two pieces of solid.

                      The pieces connecting the boards are about as short as they can be for a side-by-side arrangement.

                      It takes a little more work to do that but it seems to work fine. Four printers setup that way and no issues.

                      Frederick

                      Good idea. I didn't think of that.

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