Issues with command execution delays in 2.01



  • 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?



  • 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


  • administrators

    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?



  • @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.



  • 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. 🙂


  • administrators

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


  • administrators

    @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.



  • 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



  • @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.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.