New firmware 2.0RC5 available

dc42

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.

BMMal

@dc42

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

dc42

@bmmal said in New firmware 2.0RC5 available:

@dc42

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.

BMMal

@dc42

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

Knaudler

hello
DWC 1.21.1
showing only 1 Fan slider ?
and that responds slower

on older Webgui 1.21 there are sliders for all pwm fans - works better

Synlor

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.

dc42

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

dc42

@bmmal said in New firmware 2.0RC5 available:

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

@bmmal, thanks for your report. It looks like it was reconfiguring a filament monitor at the time of the crash. Do you have any M591 commands in your start or end GCode, or anywhere else other than in config.g? What type(s) of filament monitor do you have? Are you using the 2.0RC5 binary downloaded from the Releases area of my github repo?

zerspaner_gerd

It seems the filament management is broken.

"filaments.csv" file is no longer updated automatically.
If I change this hand, I can not load filament via DWC anymore.

With M701 S"TEST" , an error occurs shortly before completion.

Can anybody confirm this!

MSquared

@zerspaner_gerd I also cannot seem to load filaments anymore.

zerspaner_gerd

@zerspaner_gerd said in New firmware 2.0RC5 available:

With M701 S"TEST" , an error occurs shortly before completion.

The error with M701 S "test" is due to the M502!
@dc42 Is this intended the M502, all tools and heaters off?

DocTrucker

Running 1.21.1RC5 and Christian Hammacher's 1.21.1.

I can see the simulation time appended to the end of the file, but not visible on DWC?

BMMal

@dc42 Yes, I'm using your RC5 binary

I do have simple switch filament monitors. The machine disables/deconfigures the filament monitors at the start of each print to make sure there are not any from a previous print, see start.g.

Then using KISSlicer's matl gcode tab, it automatically sets them back up appropriately as a tool is selected:

*G10 P<EXT> S<TEMP> R<TEMP> ; S Active Temp, R standby temp
M572 D<EXT> S0.045

; Retract Settings S Length, R Extra L
; F Feedrate, T Unretract Rate, Z Z-hop
M207 S4 R0 F900 T900 Z0

M98 P/macros/<EXT>_Config_T<EXT>_Trigger*

This is my Start.g:
*M84 ;Turn Motors off so tool change scripts are not exectued when initializing temps

M140 S85

G10 P0 S0 R0
T0
M207 S0 R0 F1980 T1980 Z0

G10 P1 S0 R0
T1
M207 S0 R0 F1980 T1980 Z0

G10 P2 S0 R0
T2
M207 S0 R0 F1980 T1980 Z0

G10 P3 S0 R0
T3
M207 S0 R0 F1980 T1980 Z0

T-1

;Disable the filament out triggers
M591 D0 P0
M591 D1 P0
M591 D2 P0
M591 D3 P0

;Reset the Flowrate Multipliers to 100% for all drives
M221 D0 S100
M221 D1 S100
M221 D2 S100
M221 D3 S100
;
M220 S100 ;Reset Speed Multiplier to 100%
;
M98 P/macros/High_Quality_Mode ; Set quality mode

M42 P7 S255 ; Turn on Vacuum Pump*

dc42

@bmmal said in New firmware 2.0RC5 available:

I do have simple switch filament monitors. The machine disables/deconfigures the filament monitors at the start of each print to make sure there are not any from a previous print, see start.g.

Thanks. I found a possible problem with configuring/deconfiguring filament monitors while a print is active. I believe I have fixed it. However, I advise against deleting filament monitors (or changing their type in other ways) once they have been configured. Instead, I suggest you use the M591 S parameter to enable or disable the filament monitor.

Can you explain what problems you were getting before, i.e. what you mean by "to make sure there are not any from a previous print" ?

dc42

@doctrucker said in New firmware 2.0RC5 available:

Running 1.21.1RC5 and Christian Hammacher's 1.21.1.

I can see the simulation time appended to the end of the file, but not visible on DWC?

That's correct, DWC doesn't support it yet (neither does PanelDue).

dc42

@zerspaner_gerd said in New firmware 2.0RC5 available:

@zerspaner_gerd said in New firmware 2.0RC5 available:

With M701 S"TEST" , an error occurs shortly before completion.

The error with M701 S "test" is due to the M502!
@dc42 Is this intended the M502, all tools and heaters off?

M502 used to just reset those configuration parameters that are overridden in config-override.g (if you have it). Following complaints that this doesn't match the behaviour of other firmwares, it now resets the machine by running config.g but not config-override.g. Therefore it redefines the tools - which means deleting the original definitions. That's why all the tool heaters are turned off.

Where are you running M502, and why?

DocTrucker

@dc42 In that case the append is working as intended! Very useful with the network drops. There are issues I know I need to wirk on at som point for the latter.

zerspaner_gerd

If you choose "Change Filament" via DWC, this error occurs:
Error: M701: Unload the current filament before you attempt to load another one
Filament loading is then no longer possible via DWC.

@dc42 said in New firmware 2.0RC5 available:

Where are you running M502, and why?

for example loading the filament, I set the acceleration smaller here.

And I was hoping that I can do this with M502 resets without deposit anywhere fixed values.

dc42

@zerspaner_gerd said in New firmware 2.0RC5 available:

If you choose "Change Filament" via DWC, this error occurs:
Error: M701: Unload the current filament before you attempt to load another one
Filament loading is then no longer possible via DWC.

Just to be clear: you are getting that error only if you run M502. Correct?

When you create a tool (for example because you run M502, which will recreate all the tools), if the tool uses exactly one extruder, the code looks to see if there is already a filament assigned to that extruder, and if so then it flags the tool as using that filament. That appears to me to be sensible behaviour. If you disagree, please explain why.

BMMal

@dc42 said in New firmware 2.0RC5 available:

@bmmal said in New firmware 2.0RC5 available:

I do have simple switch filament monitors. The machine disables/deconfigures the filament monitors at the start of each print to make sure there are not any from a previous print, see start.g.

Thanks. I found a possible problem with configuring/deconfiguring filament monitors while a print is active. I believe I have fixed it. However, I advise against deleting filament monitors (or changing their type in other ways) once they have been configured. Instead, I suggest you use the M591 S parameter to enable or disable the filament monitor.

Can you explain what problems you were getting before, i.e. what you mean by "to make sure there are not any from a previous print" ?

@dc42 For some reason I didn't realize the S parameter enabled or disabled them. I'll switch things over. I was basically trying to disable them all at the beginning so that only the ones needed for a print would be enabled and I didn't have to have material loaded in an unused extruder.