Web interface - shutting down during printing

[gnydick]

@dc42 yes, and disconnected and reconnected the cable.

[Jan Doubrava]

update - issue not resolved
printer was not running since last time
today small 2h print, web interface is down
I canot connect with pronterface for M122
repetier host returns after connect atempt
16:04:11.737 : Ran out of output buffers at ../src/Networking/HttpResponder.cpp(950)

[Jan Doubrava]

I suspect babystep button. testing if it is related

[Jan Doubrava]

[Jan Doubrava]

reloading did not help

[Jan Doubrava]

SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DDM-9FAM2-LW4S8-6JTDJ-3S06Q-TJZ7W
Used output buffers: 13 of 20 (20 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 97124 of which 16 recycled
Exception stack ram used: 436
Never used ram: 5020
Tasks: NETWORK(ready,328) HEAT(blocked,1240) MAIN(running,544)
Owned mutexes:
=== Platform ===
Last reset 09:34:43 ago, cause: software
Last software reset at 2018-11-29 22:56, reason: User, spinning module GCodes, available RAM 5036 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
[ERROR] Error status: 4

Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 15.8ms, max retries 0
MCU temperature: min 29.7, current 31.5, max 33.3
Supply voltage: min 1.9, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/194
Driver 1: standstill, SG min/max 0/185
Driver 2: standstill, SG min/max 0/195
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2018-11-30 08:31:24
Slowest loop: 92.72ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 120, MaxWait: 1518588ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.079 -0.050 -0.032 -0.084 0.055
=== Heat ===
Bed heaters = 3 -1 -1 -1, chamberHeaters = 2 -1
Heater 1 is on, I-accum = 0.6
Heater 3 is on, I-accum = 0.1
=== 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 ready with "M122" 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: 89.10ms; fastest: 0.01ms

[Jan Doubrava]

SENDING:M552 S0
WiFi module is idle

SENDING:M552 S1
WiFi module is connected to access point TRILAB24G, IP address 192.168.1.223

SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DDM-9FAM2-LW4S8-6JTDJ-3S06Q-TJZ7W
Used output buffers: 14 of 20 (20 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 97124 of which 16 recycled
Exception stack ram used: 436
Never used ram: 5020
Tasks: NETWORK(ready,328) HEAT(blocked,1240) MAIN(running,544)
Owned mutexes:
=== Platform ===
Last reset 09:38:09 ago, cause: software
Last software reset at 2018-11-29 22:56, reason: User, spinning module GCodes, available RAM 5036 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
[ERROR] Error status: 4

Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 31.4, current 31.7, max 32.0
Supply voltage: min 24.2, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0
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
Date/time: 2018-11-30 08:34:51
Slowest loop: 0.89ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.079 -0.050 -0.032 -0.084 0.055
=== Heat ===
Bed heaters = 3 -1 -1 -1, chamberHeaters = 2 -1
Heater 1 is on, I-accum = 0.6
Heater 3 is on, I-accum = 0.1
=== 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)

Still not working

[dc42]

Is it still giving that "JSON error: unexpected token" message when you try to reload DWC, or was that a one-off message?

[Jan Doubrava]

@dc42 yes, only M999 helped

[dc42]

Next time you get that JSON parse error message, please press F12 to get the developer console. It should display the complete unparsable JSON response. Please post that here.

[Jan Doubrava]

08:17:32.178 : Ran out of output buffers at ../src/Networking/HttpResponder.cpp(950)
again

[Jan Doubrava]

Is there a way to log info from web control into file? I need the info that has been lost douring the WC shutdown. (print time etc.)

[dc42]

The print time is already logged to file if you enable logging using M929.

[dc42]

@jan-doubrava said in Web interface - shutting down during printing:

08:17:32.178 : Ran out of output buffers at ../src/Networking/HttpResponder.cpp(950)
again

1. Did you have just one browser connected to the Duet before that happened, or multiple browsers/devices? I'm trying to work out what provokes this situation.

2. I have made a change for 2.02RC6 to return a 503 status response to DWC if the firmware runs out of buffers. I hope this will allow the apparent deadlock to be broken.

[gnydick]

@dc42 I got the 503 error but the dwc still went dead after several minutes. It won't even TCP handshake on port 80.

[dc42]

Is this still happening? There were changes made in RRF 2.04 and 2.05 to address the issue with running out of buffers.

[richardmckenna]

@dc42 Recently, I'm seeing this on a my Duet2 WiFi running 2.x not sure of the exact version, but will check when I go home at lunch. I've not updated it in a while as other than this it has been running fine.

I access DWC to start the print usually from my iPad, leave the browser/put the iPad in standby or something along those lines. Go back to check the status an hour or so later, refresh the page as it says it has lost connection, it will not load.

The strange thing about it, up until a few weeks ago it did not happen and connected fine each time. I've not updated the firmware on it in several months.

Let me check what Firmware/DWC versions I'm running and if needed I will update to the latest RRF 2.x to see if it still happens.

[richardmckenna]

@dc42 yeah I’m on 2.03RC5 so I will update and see what happens.