New firmware 1.21RC1 available

okercho

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

dc42

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

okercho

@dc42:

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

Captain_sq

@dc42:

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?

Captain_sq

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

robm

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.

dc42

@Captain_sq:

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.

dc42

@robm:

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.

robm

@dc42:

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.

robm

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.

totalitarian

@dc42:

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!

andjan1964

FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20

Hello 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

dc42

@robm:

@dc42:

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.

BMMal

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

dc42

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.

Captain_sq

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

BMMal

@dc42:

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

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 retraction

This 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

k3lag

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.

Qdeathstar

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.