Web interface - shutting down during printing

atfphoto

This may be totally unrelated but I was having the same problem with the Ethernet port disappearing during long prints. Usually after the first hour or so.

Turns out my motor and motor cables were not grounded. After I installed shielded cabling, the problem has never reappeared. Even with 23 hour prints I haven't had the problem return.

Could be static.

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

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