New firmware 1.21RC1 available
-
There are some new bugs in G29 bed probing in firmware 1.21RC1. I will fix them in the next RC.
-
Hi,
Just to clarify if I see a RepRapFirmware.bin file in the release folder it is safe to assume it runs on the Duet v0.6?
Saw some notes on the 1.20 that this was the last release that you planned for v0.6 / v0.8.5 boards other than 1.20.x bug fixes (such as the 1.20.1RC)?
Thanks.
-
Version 1.20.1 got turned into 1.21 because I added some new features. It will be available for the older Duets.
-
Ah ok, that makes sense. Thanks for the explanation.
To save me bothering you in the future if there is a RepRapFirmware.bin in a release folder then it is safe to upload onto the v0.6?
-
Yes.
-
There are some new bugs in G29 bed probing in firmware 1.21RC1. I will fix them in the next RC.
Hi David, What is this bug related to? I'm having some issues with my bed levelling that is driving me nuts, but I think in my case is a mechanical problem (I've bought a new rods to discard the issue, hopefully I will get them by the end of this week).
Cheers
-
The known issues are:
- G92 on a delta causes a square height map to be displayed
- The new multi tap facility doesn't work with G92
-
The known issues are:
- G92 on a delta causes a square height map to be displayed
- The new multi tap facility doesn't work with G92
Mechanical issue is still winning the raffle then xD
-
The known issues are:
- G92 on a delta causes a square height map to be displayed
- The new multi tap facility doesn't work with G92
Do you mean G29 or G92?
-
This evening my Duet 0.6 quit midprint due to a software reset. Diagnostics points to the Network loop. I'm running with fixed IP address.
[[language]] M122 === Diagnostics === Used output buffers: 2 of 32 (10 max) === Platform === RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6 Static ram used: 44836 Dynamic ram used: 40972 Recycled dynamic ram: 208 Stack ram used: 1192 current, 4316 maximum Never used ram: 7972 Last reset 00:00:16 ago, cause: software Last software reset at 2018-02-01 22:59, reason: Stuck in spin loop, spinning module Network, available RAM 5496 bytes (slot 1) Software reset code 0x6041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0000080f, BFAR 0xe000ed38, SP 0x20087cd4 Stack: 000c0f57 0000000a fffffff9 00000000 7f7f8000 0000000f 0000000a 01010101 000a89f9 000a89f8 81000000 000000be 00000004 000babb1 000ac38f 0000003a 00000001 00000006 2007a9e0 20087d4e 2007ab18 20087d90 20087d48 00000027 Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 27.5, current 28.5, max 28.7 Date/time: 2018-02-01 22:59:43 Slowest main loop (seconds): 0.004105; fastest: 0.000100 === Move === MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, 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, 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: 1, state: 4, listening: 0x20071bf0, 0x20071bd4, 0x0 -
for the filament monitor, m591 r-1:-1 or similar gives 'allowed movement 2147483647% to 2147483647%' for the probe result - which makes sense to me but is probably not desirable. This is on P3 the rotating magnet filament monitor.
Is there a new way to enter the calibration mode?
thanks
Rob. -
This evening my Duet 0.6 quit midprint due to a software reset. Diagnostics points to the Network loop. I'm running with fixed IP address.
On my list to look at.
-
for the filament monitor, m591 r-1:-1 or similar gives 'allowed movement 2147483647% to 2147483647%' for the probe result - which makes sense to me but is probably not desirable. This is on P3 the rotating magnet filament monitor.
Is there a new way to enter the calibration mode?
thanks
Rob.The parameters for filament monitors have been changed in firmware 1.21. See https://duet3d.com/wiki/G-code#M591:_Configure_filament_sensing. However, I haven't tested the rotating magnet sensor with firmware 1.21RC yet.
-
The parameters for filament monitors have been changed in firmware 1.21. See https://duet3d.com/wiki/G-code#M591:_Configure_filament_sensing. However, I haven't tested the rotating magnet sensor with firmware 1.21RC yet.
Thanks, I saw that - but don't see anything in the 1.21 section at all re: calibration mode other than that the 'data will be collected even when filament monitoring is disabled'.
Current print with R-1:-1 is generating calibration data so seems to be working and apparently -1 still puts it into calibration mode
thanks,
Rob. -
Also on the report message for the P3 monitor, it seems to be truncated at the end:
Duet3D rotating magnet filament monitor on endstop input 3, disabled, sensitivity 28.80mm/rev, allowed movement 2147483647% to 2147483647%, check every 3.0mm, current position 298.5, measured sensitivity 26.29mm/rev, measured minimum 3%, maximum 6% over 6
From other messages I am guessing that is over 6xx mm extruded.
Otherwise 1.21RC1 working beautifully on my DIY Prusa i3 variant.
Cheers,
Rob. -
I'll probably change the next RC firmware version to print a warning but take the average of all readings, if the maximum count was reached without being within the tolerance.
Looking forward to that!
-
FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20Hello dc42
I have the 1.21RC1 firmware, but i had the problem with the 1.20 also
When i "uppload", or put "directly" a big gcode ( 64mb) to the sd card i get kicked out of the webgui. ( and when i reconnect i see that gcode is "loading" the gcode. And it is a * in the beginning of the filename. and get kicked out again.
I have to delete the gcode from the sd card to get into the webgui, so i not are beeing kicked out.
What can this be ?
Jan Erik
-
The parameters for filament monitors have been changed in firmware 1.21. See https://duet3d.com/wiki/G-code#M591:_Configure_filament_sensing. However, I haven't tested the rotating magnet sensor with firmware 1.21RC yet.
Thanks, I saw that - but don't see anything in the 1.21 section at all re: calibration mode other than that the 'data will be collected even when filament monitoring is disabled'.
Current print with R-1:-1 is generating calibration data so seems to be working and apparently -1 still puts it into calibration mode
thanks,
Rob.Because calibration data is now always collected, there is no longer a separate calibration mode. Instead there is the S parameter to determine whether the output of the filament monitor is checked or not.
-
I just noticed that I'm not getting time estimates based on layer times nor the actual layer times anymore. Using 1.21RC1 on a Duet Ethernet.
I'm also seeing an issue where the Duet Ethernet becomes very slow after completing a print. Moves are executed at the speed commanded, but the time between commands is very long, almost a minute. Here is the diagnostics from Pronterface when it is in such a state.
[[language]] === Diagnostics === Used output buffers: 1 of 32 (16 max) === Platform === RepRapFirmware for Duet Ethernet version 1.21RC1 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X Static ram used: 11992 Dynamic ram used: 100496 Recycled dynamic ram: 2200 Stack ram used: 3568 current, 8440 maximum Never used ram: 7944 Last reset 00:37:26 ago, cause: software Last software reset at 2018-02-03 10:13, reason: User, spinning module GCodes, available RAM 7952 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 [ERROR] Error status: 0 Free file entries: 7 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 27.1, current 27.4, max 31.0 Supply voltage: min 24.2, current 24.5, max 24.7, under voltage events: 0, over voltage events: 0 Driver 0: standstill, SG min/max 0/777 Driver 1: standstill, SG min/max 0/801 Driver 2: standstill, SG min/max 0/1023 Driver 3: standstill, SG min/max 0/80 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-02-03 10:51:11 Slowest main loop (seconds): 0.006912; fastest: 0.000057 === Move === MaxReps: 4, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 154, MaxWait: 43644ms, Underruns: 0, 0 Scheduled moves: 635, completed moves: 635 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 3 is on, I-accum = 0.7 === GCodes === Segments left: 0 Stack records: 4 allocated, 1 in use Movement lock held by file http is idle in state(s) 0 telnet is idle in state(s) 0 file is doing "M116 P2" in state(s) 0 8 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 === State: 5 HTTP sessions: 1 of 8 Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) === Filament sensors === Extruder 0 sensor: ok Extruder 2 sensor: ok >>> m122 SENDING:M122 Done printing file Finished printing file 0:/gcodes/20mmTestCube_repaired.gcode, print time was 0h 19m === Diagnostics === Used output buffers: 3 of 32 (16 max) === Platform === RepRapFirmware for Duet Ethernet version 1.21RC1 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X Static ram used: 11992 Dynamic ram used : 100536 Recycled dynamic ram: 2160 Stack ram used: 3568 current, 8440 maximum Never used ram: 7944 Last reset 00:52:51 ago, cause: software Last software reset at 2018-02-03 10:13, reason: User, spinning module GCodes, available RAM 7952 bytes (slot 2) So ftware reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 [ERROR] Error status: 0 Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 162.5ms MCU temperature: m in 26.7, current 30.1, max 32.1 Supply voltage: min 24.2, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0 Driver 0: standstill, SG min/max 0/819 Driver 1: standstill, SG min/max 0/812 Driver 2: standstill, SG min/max 0/685 Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max 0/1023 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-02-03 11:06:32 Slowest main loop (seconds): 4.127969; fastest: 0.000066 === Move === MaxReps: 4, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinF reeDm 159, MaxWait: 121006ms, 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 0 is on, I-accum = 0.0 === 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 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 === State: 5 HTTP sessions: 1 of 8 Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) === Filament sensors === Extruder 0 senso r: ok Extruder 2 sensor: ok -
Thanks for you report.
Regarding the printer becoming very slow, I have one other report of this, also on a Duet Ethernet. Next time it happens, please use M111 to enable GCodes, Move and DDA debugging. Then send a movement command. It will echo the gcode, then the move details, then do the move. What I am interested in is where the delay occurs.
