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


  • administrators

    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


  • administrators

    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


  • administrators

    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.



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


Locked
 

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