Excessive number of disconnections
-
Firmware 2.01(RTOS) (2018-07-26b2) Web 1.21.2-dc42
I am experiencing a large number of time outs.
I am also running a Duet 6 with a laser and that is experiencing time outs as well
The results of M122 for the core XYUV printer
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-956GU-DJMSJ-6J9F6-3S86T-9BPVH
Used output buffers: 3 of 20 (12 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 95968 of which 0 recycled
Exception stack ram used: 620
Never used ram: 6008
Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3132)
Owned mutexes:
=== Platform ===
Last reset 02:23:32 ago, cause: power up
Last software reset at 2018-07-27 11:42, reason: User, spinning module GCodes, available RAM 6008 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: 10
SD card 0 detected, interface speed: 12.0MBytes/sec
SD card longest block write time: 18.3ms, max retries 0
MCU temperature: min 38.9, current 56.9, max 59.4
Supply voltage: min 24.1, current 24.8, max 25.2, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/239
Driver 1: standstill, SG min/max 0/213
Driver 2: standstill, SG min/max 0/1023
Driver 3: standstill, SG min/max 0/162
Driver 4: standstill, SG min/max 0/158
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max 0/0
Driver 7: standstill, SG min/max 0/126
Driver 8: standstill, SG min/max 0/127
Driver 9: standstill, SG min/max 0/131
Expansion motor(s) stall indication: yes
Date/time: 2018-08-03 13:02:31
Slowest loop: 70.04ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 120, MaxWait: 978601ms, Underruns: 3, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.185 0.153 0.171 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.3
=== GCodes ===
Segments left: 0
Stack records: 2 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: 96.86ms; 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 0 -
Have you made sure that your two Duets are not both using the same MAC address? The Duet Ethernet will create one from the board ID if you don't have a M540 command to define the MAC address in config.g.
-
Yes one mac ends in EE and the other ends in ED.
Just to be sue I have just commented out the M54 line in the Due Ethernet board.
I'll do some more testing -
Another possibility is an IP address conflict with something else on your LAN.
-
No I have checked that, I use fixed ip addresses for my machines.
I'll keep an eye on the issue and see if I can provide more information. -
I only have the laser on today (ormerod- Duet 6), I started a print and the next time I looked at the screen, less than 1 minuet the machine had been disconnected.
=== Diagnostics ===
RepRapFirmware for Duet version 1.22 running on Duet 0.6
Used output buffers: 3 of 16 (9 max)
=== System ===
Static ram: 44652
Dynamic ram: 41436 of which 4024 recycled
Stack ram used: 136 current, 6020 maximum
Never used ram: 2172
=== Platform ===
Last reset 00:05:30 ago, cause: power up
Last software reset at 2018-08-03 12:50, reason: User, spinning module GCodes, available RAM 1836 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 8
Free file entries: 9
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 27.9, current 41.1, max 45.0
Date/time: 2018-08-04 12:10:09
Slowest loop: 245.69ms; fastest: 0.09ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 88, MinFreeDm: 79, MaxWait: 30493ms, Underruns: 33793, 0
Scheduled moves: 47007, completed moves: 46997
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 1
Stack records: 1 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 doing "G1 X10 Y19.7" 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 not empty:
Queued 'M106 S83.1' for move 46997
Queued 'M106 S81' for move 46998
Queued 'M106 S80.5' for move 46999
Queued 'M106 S80.8' for move 47000
Queued 'M106 S82.8' for move 47001
Queued 'M106 S81' for move 47002
Queued 'M106 S79' for move 47003
Queued 'M106 S80' for move 47004
Queued 'M106 S80.3' for move 47005
Queued 'M106 S79' for move 47006
Queued 'M106 S0' for move 47006
11 of 16 codes have been queued.
=== Network ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 0, state: 4, listening: 20071c20, 0, 0 -
Disconnections between DWC and a Duet when using Ethernet are rare. The most likely reasons are:
- MAC address conflict
- IP address conflict (your router could be allocating an IP address that you are using for a Duet to a wireless device)
- Faulty cable
- Some older Duet 06/085 boards occasionally had poor soldering of the PHY chip to the PCB, which could lead to intermittent connection
-Using older firmware versions with microstepping that is too high for the CPU to manage, in particukar when homing the printer. In those older versions this could cause the network system to be starved of CPU cycles. The clue was that the MaxReps figure in the M122 report got very high.
I am assuming that the reason for disconnection given by DWC is Timeout. If you are getting a different message, please post it here.
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 -
@dc42 Yes the disconnections are due to Timeout.
I have noticed that I do not have a M350 Set micro stepping entry in config. So the default must be used which I believe is 16x. I have now made the entry just in case.
