Issues with command execution delays in 2.01

gtj0

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?

whosrdaddy

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

dc42

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?

gtj0

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

gtj0

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

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

dc42

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

fcwilt

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

gtj0

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