New firmware 2.0RC5 available
-
I ran into an issue I have never seen before in the 1 series of firmware. I almost always run prints via Octoprint over the usb serial connection. About 3.5 hours into a print the connection died.
I am running firmware 2.0(RTOS)RC5 (2018-05-22b1).
Here was the error on the Octoprint terminal:
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2417
In the DWC console it had this:
g-code buffer 'serial' length overflow
I ran an M122 in the DWC console interface:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet WiFi 1.0 or 1.01 + DueX5 Board ID: 08DAM-999TL-MQ4S8-6J9D8-3SJ6N-15B3W Used output buffers: 1 of 20 (10 max) === RTOS === Static ram: 28452 Dynamic ram: 96644 of which 16 recycled Exception stack ram used: 380 Never used ram: 5580 Task NETWORK ready, free stack 420 Task DHTSENSOR blocked, free stack 36 Task HEAT blocked, free stack 1256 Task MAIN running, free stack 3620 === Platform === Last reset 00:04:46 ago, cause: software Last software reset at 2018-05-24 21:58, reason: Assertion failed, spinning module Platform, available RAM 5284 bytes (slot 1) Software reset code 0x0090 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f80e, BFAR 0xe000ed38, SP 0x2001ffb4 Stack: 2001e6a0 2001e6d4 00445509 00000000 00000000 00000001 20006c68 20006bf4 00444885 2001e6ec 20006bf4 00000000 00f00000 e000ef34 c0000018 00000003 004449c7 00444738 61000000 b082b430 b33b9d04 b2c96804 41b4f041 3480f444 Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 12.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 46.6, current 46.7, max 49.5 Supply voltage: min 24.0, current 24.2, max 24.4, 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 Driver 5: standstill, SG min/max not available Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Expansion motor(s) stall indication: yes Date/time: 2018-05-24 22:03:05 Slowest main loop (seconds): 0.372014; fastest: 0.000069 === 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.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 3 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 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 === Responder states: HTTP(4) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.21 WiFi MAC address 5c:cf:7f:2c:27:2d WiFi Vcc 3.38, reset reason Turned on by main processor WiFi flash size 4194304, free heap 15000 WiFi IP address 192.168.2.143 WiFi signal strength -65dBm, reconnections 0, sleep mode modem Socket states: 0 5 0 0 0 0 0 0 === Expansion === DueX I2C errors 0
I know I am weird to still use Octoprint with a Duet Wifi, but I like the various plugins and record keeping that it provides over the DWC interface. Thanks!
-
Running FW: 2.0(RTOS)RC5 (2018-05-22b1), DWC: 1.21.1
Tested on small print and no issue occured.
Just one glitch on first print (macro with delta calibration, heat and cooldown) when reloading DWC in browser caused "Emergency STOP". But can't reproduce. -
Running 2.0rc5 and dwc121. 1, I have noticed odd behaviour of M122 included in slicer end script. At the end of the print, the M122 report does not appear. The gcode console accepts an M122, but no report. YAT connection accepts M122, and provides a report, but this does not relate to the print, so I guess the original M122 cleared. The DWC console accepts other commands when in the M122 blocked state, and M122 works fine after reset. The effect is seen with S3D and kislicer end scripts.
-
I just finished a print with a strange message:
Error: G1/G2/G3: intermediate position outside machine limits Finished printing file Upgrades/Spool_Holder.gcode, print time was 4h 9m
X is now reported as being -253.69
My end code is the following
G10 P0 R-273.15 S-273.15 ;extruder heater off M140 S-273.15 ;bed heater off G91 ;relative positioning G1 Z+4 X-20 Y+20 F9000 ;move nozzle away from object G0 S1 X-250 ;move X to the left, so the head is completely out of the way G90 ;absolute positioning G0 Y190 F5000 ;move bed to the front M84 ;steppers off
Could it be that the
G0 S1 X-250
in contrast to aG1 S1 X-250 F3600
that is used in myhomex.g
is the problem here? AFAIKG0
andG1
are aliases on a cartesian setup.This might not be directly related to RC5 but I never had this message before and I have not modified my end code since updating to RC5.
-
@sigxcpu said in New firmware 2.0RC5 available:
How do you think this should be integrated?
- create a new command like
rr_compactfilelist?dir=xxx
- add a parameter to existing
rr_filelist
likerr_filelist?dir=xxx&compact=true
The solutions we are looking at are:
-
DWC to revert to using rr_files instead of rr_filelist.
-
Extend rr_filelist to take a "skip the first N files" parameter, and in the response to return the value of N that should be used to get the next chunk of the file list, with N=0 meaning the list is complete.
Most likely we will implement #2.
- create a new command like
-
@wilriker said in New firmware 2.0RC5 available:
I just finished a print with a strange message:
Error: G1/G2/G3: intermediate position outside machine limits Finished printing file Upgrades/Spool_Holder.gcode, print time was 4h 9m
X is now reported as being -253.69
My end code is the following
G10 P0 R-273.15 S-273.15 ;extruder heater off M140 S-273.15 ;bed heater off G91 ;relative positioning G1 Z+4 X-20 Y+20 F9000 ;move nozzle away from object G0 S1 X-250 ;move X to the left, so the head is completely out of the way G90 ;absolute positioning G0 Y190 F5000 ;move bed to the front M84 ;steppers off
Could it be that the
G0 S1 X-250
in contrast to aG1 S1 X-250 F3600
that is used in myhomex.g
is the problem here? AFAIKG0
andG1
are aliases on a cartesian setup.This might not be directly related to RC5 but I never had this message before and I have not modified my end code since updating to RC5.
What printer geometry do you have?
That message is new in RC5 but I don't think it should ever be reported except for G1 moves on SCARA printers and G2 or G3 moves on any type of printer. Maybe it was the G1 Z+4 X-20 Y+20 F9000 command that provoked it? What was the head position prior to executing that command?
A G0 S1 move should behave the same as a G0 S1 move, but I haven't actually tested it.
-
@dc42 said in New firmware 2.0RC5 available:
What printer geometry do you have?
Cartesian
That message is new in RC5 but I don't think it should ever be reported except for G1 moves on SCARA printers and G2 or G3 moves on any type of printer. Maybe it was the G1 Z+4 X-20 Y+20 F9000 command that provoked it? What was the head position prior to executing that command?
Last movement command in gcode file was
G1 F2250 X16.307 Y159.991 E0.02498
(only followed by aG10
before executing end code)
and Z was at 7.1 at this point.EDIT:
My limits are- X: -35..220
- Y: -7..216
- Z: 0..234
-
I had canceled a print and then started another using the "Upload and Print" button. As the machine started the print, the controller reset. I can repeat this reliably. This does not appear to be an issue if I manually select a file to print though.
Here are the diagnostics after:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 1 of 20 (16 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 96508 of which 0 recycled
Exception stack ram used: 420
Never used ram: 5692
Task NETWORK ready, free stack 332
Task HEAT blocked, free stack 1200
Task MAIN running, free stack 3556
=== Platform ===
Last reset 00:04:22 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 5764 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.6ms
MCU temperature: min 25.4, current 26.9, max 27.1
Supply voltage: min 24.0, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/642
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-05-25 13:12:03
Slowest main loop (seconds): 0.082818; fastest: 0.000076
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 161, MinFreeDm 161, MaxWait: 4294887172ms, Underruns: 0, 0
Scheduled moves: 636, completed moves: 606
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 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.2
=== GCodes ===
Segments left: 1
Stack records: 4 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 X250.665 Y48.861 E0.00098" 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 ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Filament sensors ===
Extruder 0 sensor: ok
=== Expansion ===
DueX I2C errors 0 -
Not sure what is going on, but I started a print earlier today, the print vcompleted ok, but the web interface disconnected & 'died' in that I could not connect. This happened a few hours after the print had started:
19:55:55
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet Ethernet 1.02 or later
Board ID: 08DGM-95BNL-MGPSJ-6J1F2-3SD6L-9JZHX
Used output buffers: 3 of 20 (8 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 95460 of which 16 recycled
Exception stack ram used: 332
Never used ram: 6812
Task NETWORK ready, free stack 468
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3564
=== Platform ===
Last reset 00:01:06 ago, cause: reset button or watchdog
Last software reset at 2018-05-24 05:50, reason: User, spinning module GCodes, available RAM 6616 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 45.4, current 46.3, max 46.5
Supply voltage: min 24.1, current 24.3, max 24.4, 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-05-25 19:55:55
Slowest main loop (seconds): 0.008304; fastest: 0.000065
=== 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: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
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 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 ===
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 ===
19:54:58
Connection established!
09:04:54
Disconnected.
06:55:39
M32 "Panobot/panobot-pan-Top and Bottom-PLA.gcode"
File Panobot/panobot-pan-Top and Bottom-PLA.gcode selected for printing -
@dc42 OK, I will not take this then I've already did it, but I couldn't manage to configure IDE for RTOS branch. Compiled 1.21 without issues, but 2.0 is not compilable yet (used v2-dev branch in both ReprapFirmware & CoreNG, imported DuetWifiSocketServer & FreeRTOS projects in workspace).
-
@sigxcpu said in New firmware 2.0RC5 available:
@dc42 OK, I will not take this then I've already did it, but I couldn't manage to configure IDE for RTOS branch. Compiled 1.21 without issues, but 2.0 is not compilable yet (used v2-dev branch in both ReprapFirmware & CoreNG, imported DuetWifiSocketServer & FreeRTOS projects in workspace).
The IDE should need no additional configuration for the RTOS build, except that you need to configure build variable GccPath in the FreeRTOS project just as in the other projects.
-
@bmmal said in New firmware 2.0RC5 available:
I had canceled a print and then started another using the "Upload and Print" button. As the machine started the print, the controller reset. I can repeat this reliably. This does not appear to be an issue if I manually select a file to print though.
Here are the diagnostics after:
The diagnostics show that the most recent reset was a user-commanded software reset. So unfortunately I can't tell the reason for the reset. But I will test the Upload & Print function.
-
@bmmal said in New firmware 2.0RC5 available:
I had canceled a print and then started another using the "Upload and Print" button. As the machine started the print, the controller reset. I can repeat this reliably. This does not appear to be an issue if I manually select a file to print though.
Here are the diagnostics after:Thanks for your report. Sadly I can't tell anything from those diagnostics, they look normal.
-
I have found a bug in RC5 that could explain some instances of not being able to maintain a reliable network connection. If the firmware times out trying to get information for a file (which is most likely when there are large GCode files and the SD card has a small cluster size), it doesn't close the file. This could result in the firmware running out of file handles. It also explains the report by a user who was unable to delete a GCode file until he restarted the Duet.
I will release RC6 to fix this, probably tomorrow.
-
Just had an instance where a print finished, I manually uploaded another, then selected it for printing and the controller reset.
I just replaced my mechanical relay, that I previously suspected of putting my controller in a slow state, with an SSR. Strangely, the end.g file did not turn this relay off as it should have when the previous print finished... M42 P7 S0 ; Turn off Vacuum
-
@bmmal said in New firmware 2.0RC5 available:
Just had an instance where a print finished, I manually uploaded another, then selected it for printing and the controller reset.
If you haven't restarted the Duet since the reset, please run M122 and post the results here.
-
the end.g did turn off the vacuum relay properly. Sorry, I forgot that I had turned it back on manually.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 20 (16 max)
=== RTOS ===
Static ram: 28452
Dynamic ram: 96544 of which 0 recycled
Exception stack ram used: 420
Never used ram: 5656
Task NETWORK ready, free stack 332
Task HEAT blocked, free stack 1200
Task MAIN running, free stack 3556
=== Platform ===
Last reset 00:19:27 ago, cause: software
Last software reset at 2018-05-25 15:36, reason: Hard fault, spinning module GCodes, available RAM 5480 bytes (slot 3)
Software reset code 0x4033 HFSR 0x40000000, CFSR 0x00000400, ICSR 0x04417803, BFAR 0xe000ed38, SP 0x20004994
Stack: 004307cf 004307d0 01000000 00000002 00000000 00000001 00000001 00000007 0042abab 00430a26 81000000 00000000 20004cdc 20004a78 a5a5a5a5 a5a5a5a5 0044c3ab 200001e0 00000000 0000000a 2000b170 2001e828 004322c9 00000000
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 2.2ms
MCU temperature: min 25.2, current 27.0, max 27.2
Supply voltage: min 24.0, current 24.2, max 24.6, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/103
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-05-25 15:56:29
Slowest main loop (seconds): 0.085543; fastest: 0.000076
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 156, MinFreeDm 150, MaxWait: 4292056348ms, Underruns: 0, 0
Scheduled moves: 6445, completed moves: 6415
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 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.2
=== GCodes ===
Segments left: 0
Stack records: 4 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 X224.503 Y63.367 E0.069" 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 ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Filament sensors ===
Extruder 0 sensor: ok
Extruder 2 sensor: ok
=== Expansion ===
DueX I2C errors 0 -
hello
DWC 1.21.1
showing only 1 Fan slider ?
and that responds sloweron older Webgui 1.21 there are sliders for all pwm fans - works better
-
I had a print fail again, but this time it wasn't through Octoprint; I ran it straight off the SD card in DWC. It just said disconnected, and when I connected back again the Duet had reset itself.
Here is the M122:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC5 running on Duet WiFi 1.0 or 1.01 + DueX5 Board ID: 08DAM-999TL-MQ4S8-6J9D8-3SJ6N-15B3W Used output buffers: 1 of 20 (9 max) === RTOS === Static ram: 28452 Dynamic ram: 96600 of which 16 recycled Exception stack ram used: 348 Never used ram: 5656 Task NETWORK ready, free stack 440 Task DHTSENSOR blocked, free stack 36 Task HEAT blocked, free stack 1256 Task MAIN running, free stack 3588 === Platform === Last reset 00:00:18 ago, cause: software Last software reset at 2018-05-25 20:34, reason: Assertion failed, spinning module Platform, available RAM 5284 bytes (slot 3) Software reset code 0x4090 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f80e, BFAR 0xe000ed38, SP 0x2001ffb4 Stack: 2001e6a0 2001e6d4 00445509 00000000 00000001 00000001 20006c68 20006bf4 00444885 2001e6ec 20006bf4 00000000 00f00000 e000ef34 c0000018 00000003 004449c7 00444738 61000000 b082b430 b33b9d04 b2c96804 41b4f041 3480f444 Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 12.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 50.2, current 50.6, max 50.7 Supply voltage: min 24.0, current 24.1, max 24.4, 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 Driver 5: standstill, SG min/max not available Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Expansion motor(s) stall indication: yes Date/time: 2018-05-25 20:35:16 Slowest main loop (seconds): 0.005176; fastest: 0.000070 === 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.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 3 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 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 === Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.21 WiFi MAC address 5c:cf:7f:2c:27:2d WiFi Vcc 3.38, reset reason Turned on by main processor WiFi flash size 4194304, free heap 13136 WiFi IP address 192.168.2.143 WiFi signal strength -58dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0 === Expansion === DueX I2C errors 0
This was a different GCode file then the one that failed previously in Octoprint. Funny enough it was about 3.5 hours into the print again.
-
@synlor, thanks for your reports. The task that manages the DHT sensor ran out of stack in both cases. I will increase the stack size for that task in the next build.