Unexpected end of JSON input
-
My duet (0.6) is regularly disconnecting with the error message above.
When I try to reload the page I am getting a download of a file called "download.gz". When I unzip that file I get a reprap.htm that loads the DWC interface without CSS. Only a powercycle gets control over DWC again. At first I suspected the SD card but I changed that for a modern quick one and the result is no-change.Firmware Name: RepRapFirmware for Duet
Firmware Electronics: Duet 0.6
Firmware Version: 1.24 (2019-06-13b2)
Web Interface Version: 1.22.6Since the machine is running it's job without issues, I suspect it is a DWC thing going on.
Anyone have an idea about this?If you think trial and error is dangerous, try routine. That's even more so!
-
After a reboot M122 shows me this:
M122
=== Diagnostics ===
RepRapFirmware for Duet version 1.24 running on Duet 0.6
Used output buffers: 5 of 16 (11 max)
=== System ===
Static ram: 44204
Dynamic ram: 42396 of which 3512 recycled
Stack ram used: 136 current, 2556 maximum
Never used ram: 5636
=== Platform ===
Last reset 00:03:58 ago, cause: power up
Last software reset at 2019-10-02 20:07, reason: User, spinning module GCodes, available RAM 2572 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 19.6, current 24.7, max 25.8
Date/time: 2019-11-06 19:15:32
Slowest loop: 9.59ms; fastest: 0.10ms
I2C nak errors 24, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 24
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== 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 ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 0, state: 4, listening: 20071bf4, 0, 0 -
The disconnection just happened again.
I downloaded pronterface and connected over USB with no issues. Now the gcode terminal says "Webserver: rejecting message with: not found" when I reload the page and m122 gives me:=== Diagnostics ===
RepRapFirmware for Duet version 1.24 running on Duet 0.6
Used output buffers: 14 of 16 (16 max)
=== System ===
Static ram: 44204
Dynamic ram: 42396 of which 3512 recycled
Stack ram used: 1080 current, 3940 maximum
Never used ram: 4252
=== Platform ===
Last reset 01:37:08 ago, cause: power up
Last software reset at 2019-10-02 20:07, reason: User, spinning module GCodes, available RAM 2572 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 4
[ERROR] Error status: 4Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 27.0, current 27.3, max 27.6
Date/time: 2019-11-06 20:48:41
Slowest looSo... it seems to not finish the command output completely.
-
can you try the latest firmware:
https://github.com/dc42/RepRapFirmware/releases/tag/2.04Duet Hardware Designer
www.duet3d.com -
@T3P3Tony , Thanks, I missed that one and thought my recent update was still the latest.
Will try, but I must say that this problematic behaviour was already showing many updates ago, but seems to be more problematic now, what could be since the update to 1.24 indeed. -
Also version 1.25 shiws this problem. It tries to reconnect, that succeeds after some time, but immediately followed by a new disconnect. DWC then shows "No more free sessions!". After a few times it does not reconnect at all anymore.
I connected the USB while printing (did not know if that would work but i does) and put in an M122:
=== Diagnostics ===
RepRapFirmware for Duet version 1.25 running on Duet 0.6
Used output buffers: 16 of 16 (16 max)
=== System ===
Static ram: 44204
Dynamic ram: 42380 of which 3528 recycled
Stack ram used: 1080 current, 4076 maximum
Never used ram: 4116That's all I get, a lot shorter than usual...
-
What's happening is that the firmware is running out of output buffers. This is an issue that I was unable to get to the bottom of before the 2.04/1.25 release. Unfortunately I have not been able to reproduce it.
-
DC I can imagine that you do not want to investigate this problem if it is confined to the 0.6 version of Duet. If you want me to do some tests or give you output/input of any kind, please let me know. I would be happy to do something in return of the great firmware
If you think trial and error is dangerous, try routine. That's even more so!
-
@DeltaCon, it's not confined to the 0.6 version, but the build for the 0.6 version has fewer buffers so if buffers are being lost then they will run out faster.
Let me know if you manage to find a way to reproduce it. It's probably related to network activity (multiple network clients? clients disconnecting?), or USB activity, or turning debugging on (M111).
