I2C errors in 2.02, using DWC 2.0.0 RC3
-
Some good news, some bad. When I do I get I2C errors now the printer performs a few moves, stops, and does a few more moves. Previously it would only do one move.
Unfortunately I reset it before thinking to grab a screenshot of M122. Here's a recreation. I'll get the real thing next time it happens.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98292 of which 0 recycled
Exception stack ram used: 352
Never used ram: 6904
Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,3844) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:04:18 ago, cause: power up
Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 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: 0.0ms, max retries 0
MCU temperature: min 32.7, current 32.9, max 33.5
Supply voltage: min 11.6, current 11.7, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-01-17 15:04:48
Cache data hit count 645630772
Slowest loop: 94.64ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 12345, receive timeouts 0, finishTimeouts 12345 (something similar to this)
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 25, completed moves: 25
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.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "M190 S65 " 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: 11.51ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state 5, link 100Mbps full duplexThe next time it happens I'll be sure to grab the real M122 output. It has been a while since I posted, but we've been through all of the usual troubleshooting as far as I know. I also saw that the I2C communication was redone for 2.02, which is why I am bringing this up.
-
It finally happened again after a few hours of testing.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 1 of 20 (17 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98292 of which 0 recycled
Exception stack ram used: 416
Never used ram: 6840
Tasks: NETWORK(ready,544) HEAT(blocked,848) MAIN(running,3844) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 02:23:39 ago, cause: power up
Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 8
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 41.0ms, max retries 0
MCU temperature: min 33.1, current 33.6, max 35.0
Supply voltage: min 11.4, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 7/594
Driver 1: standstill, SG min/max 0/659
Driver 2: standstill, SG min/max 10/602
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max 0/492
Driver 7: ok, SG min/max 0/0
Driver 8: standstill, SG min/max 0/0
Driver 9: standstill, SG min/max not available
Date/time: 2019-01-17 17:24:08
Cache data hit count 4294967295
Slowest loop: 248.05ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 28776, receive timeouts 0, finishTimeouts 28776
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 239, MinFreeDm: 104, MaxWait: 1342116ms, Underruns: 0, 0
Scheduled moves: 64, completed moves: 63
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.0
Heater 1 is on, I-accum = 0.9
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 1 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 1 5
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: 87.35ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex -
We are discussing it also over here:
https://forum.duet3d.com/topic/7269/duet-sometimes-really-slow-i2c-error-or/33
A suggestion is to put some resistors on the duex5 header, but I haven't tried it yet.
