New firmware 1.21RC1 available
-
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 timeout A 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=0 Also 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 -
I notice when I pause and resume, it adds some strange extra move in after running the resume script. It's also writing a resurrect.g, not sure if it's supposed to do that on pause?
It moves back into place, then moves about 2cm out of the way at print height, then moves back.
10:40:16 PM Resume-after-power-fail state saved
This is my resume script
; Resume macro file
M83 ; relative extruder moves
G1 R1 X0 Y0 Z2 F6000 ; move to 2mm above resume point
G1 X0 Y0 Z0 R1 ; lower nozzle to resume point
G1 E12 F3600 ; undo the retractionThis is the pause script
; Pause macro file
G91 ; relative moves
M83 ; relative extruder moves
G1 E-12 F3600 ; retract 12mm
G1 X1 ;wipe
G1 Z2 F1200 ; raise nozzle 2mm
G90 ; absolute moves
G1 X0 Y300 F6000 ; move head out of the way of the print -
I don't have any data for you but my printer went into 'slow mode' yesterday. I hadn't printed anything in a couple days before this. I used the upload and print button in DWC to print a file and after homing the print started moving VERY slowly. Like one move every minute or something. I rebooted the printer and the same gcode file printed fine. This is with a DuetWiFi.
Sorry I don't have a M122 or anything for you but I just saw this thread and I have had several successful prints since then.
I'm running 1.20, not the latest RC.
-
Hi,
I updated my duet and now i’ve noticed that the blue led on the esp8266 stays on when the duet is operational. Is there a way to turn it off, it’s quite peircing.
-
@nyt:
I notice when I pause and resume, it adds some strange extra move in after running the resume script. It's also writing a resurrect.g, not sure if it's supposed to do that on pause?
It moves back into place, then moves about 2cm out of the way at print height, then moves back.
10:40:16 PM Resume-after-power-fail state saved
This is my resume script
; Resume macro file
M83 ; relative extruder moves
G1 R1 X0 Y0 Z2 F6000 ; move to 2mm above resume point
G1 X0 Y0 Z0 R1 ; lower nozzle to resume point
G1 E12 F3600 ; undo the retractionThis is the pause script
; Pause macro file
G91 ; relative moves
M83 ; relative extruder moves
G1 E-12 F3600 ; retract 12mm
G1 X1 ;wipe
G1 Z2 F1200 ; raise nozzle 2mm
G90 ; absolute moves
G1 X0 Y300 F6000 ; move head out of the way of the printThis is video of the unintended move after the head lowers.
-
Additional information regarding the extruder motor stutter. It's rather random, but about 1/3 of retract/unretract moves exhibits this jerky movement. Its like the interrupt for driving pulses to the motors are lagging. It moves in short 'bursts' but doesn't miss steps. At some rare times the retract move is smooth but extremely slow and returns to full speed when unretracting. I'll try to shoot a little movie clip of the phenomena.
Duet 0.6 board. I haven't tried it out on the Duet WiFi yet as this printer is undergoing a complete hardware makeover right now.
-
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.
My machine just finished a print and since I was sitting by it, I immediately commanded it to turn on relay output after it finished the end.g script. It responded quickly. However a short while after that, I attempted to home the machine and it was slow to respond.
-
Any idea about the move on resume? Bug or bad script?