New firmware 1.21RC1 available
-
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.
-
With this release I have noted that the extruder motor is 'stuttering' on the retract move but never on the restart move. I lowered the acceleration and instantaneous speed change settings but no change. Right now it retracts 7mm @5600 mm/min.
Anybody else noted this?
[[language]] ; Drives 569 P0 S1 ; Drive 0 goes forwards 569 P1 S1 ; Drive 1 goes forwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S1 ; Drive 3 goes forwards M92 X100 Y100 Z100 E141.8 ; Set steps per mm M566 X1200 Y1200 Z1200 E1300 ; Set maximum instantaneous speed changes (mm/min) M203 X18000 Y18000 Z18000 E12000 ; Set maximum speeds (mm/min) M201 X2200 Y2200 Z2200 E2200 ; Set accelerations (mm/s^2) M906 X960 Y960 Z960 E1750 I60 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeoutA snapshot of the current status:
[[language]] M122 === Diagnostics === Used output buffers: 2 of 32 (11 max) === Platform === RepRapFirmware for Duet version 1.21RC1 running on Duet 0.6 Static ram used: 44836 Dynamic ram used: 41068 Recycled dynamic ram: 112 Stack ram used: 1192 current, 6752 maximum Never used ram: 5536 Last reset 01:38:32 ago, cause: power up Last software reset at 2018-02-04 14:43, reason: User, spinning module GCodes, available RAM 5316 bytes (slot 0) Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00000000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 9 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 235.3ms MCU temperature: min 18.3, current 28.0, max 30.3 Date/time: 2018-02-04 16:23:21 Slowest main loop (seconds): 0.235901; fastest: 0.000100 === Move === MaxReps: 5, StepErrors: 0, LaErrors: 1, FreeDm: 20, MinFreeDm 20, MaxWait: 131817219ms, Underruns: 16, 0 Scheduled moves: 139052, completed moves: 139032 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 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.6 === GCodes === Segments left: 1 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 doing "G1 X31.778 Y-5.048 F5200" 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 -
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.
Here is the Pronterface log after enabling debugging and executing a move. There is a delay immediately after sending the command. Once the command is executed the info is received more or less simultaneously. The move itself is executed smoothly as expected.
[[language]] >>> M111 S1 SENDING:M111 S1 Class GCodes spinning Class Move spinning Class Heat spinning Class Scanner spinning Class PrintMonitor spinning Class Platform spinning Class Network spinning serial: M105 aux: M408 S1 serial: M105 aux: M408 S0 R1311 >>> G1 X200 F24000 SENDING:G1 X200 F24000 serial: M105 aux: M408 S1 serial: M105 aux: M408 S0 R1311 serial: G1 X200 F24000 aux: M408 S1 Transformed 200.00 -54.99 390.30 to 16060 4294962880 312240 serial: M105 aux: M408 S0 R1311 DDA: start=[300.000000 -54.993771 390.299988] end=[200.000000 -54.993771 390.299988] d=100.000000 vec=[-1.000000 0.000000 0.000000 0.000000 0.000000] a=3900.000000 reqv=275.000000 startv=0.000000 topv=275.000000 endv=0.000000 daccel=9.695513 ddecel=9.695513 cks=407014 sstcda=0 tstcdapdsc=407014 exac=33052 DMX: dir=B steps=8030 next=1 rev=8031 interval=2369 2dtstc2diva=45072011441 accelStopStep=779 decelStartStep=7252 2CsqtMmPerStepDivA=5612965 mmPerStepTimesCdivtopSpeed=43473 fmsdmtstdca2=0 cc=0 acc=0Also noticed that when the machine is in this state, I cannot get DWC to connect but saw this output in the Pronterface terminal when attempting to connect
[[language]] HTTP connection accepted Received 426 bytes Sending reply, file = no HTTP req, command words { GET /rr_connect HTTP/1.1 }, parameters { password=reprap time=2018-2-4T13:16:20 } Can't send anymore
