Web interface - shutting down during printing



  • Sometimes, usually during prints longer than an hour, the web interface become unreachable. Printer is still running as it should. Wifi should be working, becouse status led is on. Wifi-Router says that board is conected. After router reboot, status led blinks, and the board connects, but web interface is still unreachable.

    Settings -> General -> Software Information
    Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
    Firmware Electronics: Duet WiFi 1.02 or later
    Firmware Version: 2.01(RTOS) (2018-07-26b2)
    WiFi Server Version: 1.21
    Web Interface Version: 1.22.3

    Is there a way to reboot the web interface, without rebooting the whole board? Does anyone having the same issue? it is very desirable to avoid updating, because of some custom app that we developed for this specific version of firmware.


  • administrators

    You can reboot WiFi by creating and running a macro file that contains

    M552 S0
    M552 S1

    When the printer becomes unusable again, could you send the output of M122 from a USB connection?



  • how do I run that macro when I can not connect to a web interface?
    "M122: Diagnose" surely I can.


  • administrators

    @jan-doubrava You could do this either via USB or register a trigger via M581 and use an external switch. Nevertheless it would be nicer to resolve this problem but I am not sure what exactly could be causing your problem. Unfortunately I cannot reproduce it with my printer. Perhaps an M122 dump will help.



  • I've had this happen when rapidly clicking the baby-step button


  • administrators

    @Jan-Doubrava, have you tried pressing F5 to reload the web interface?



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



  • @dc42 yes, and disconnected and reconnected the cable.



  • 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)



  • I suspect babystep button. testing if it is related



  • 0_1543562927996_82e83774-caff-4dce-97f7-219f36f18d14-image.png



  • reloading did not help



  • 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



  • 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


  • administrators

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



  • @dc42 yes, only M999 helped


  • administrators

    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.



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



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


  • administrators

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


  • administrators

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



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


  • administrators

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



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



  • @dc42 yeah Iā€™m on 2.03RC5 so I will update and see what happens.


Log in to reply