New firmware 1.21RC1 available

okercho

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.

nyt

@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

This is video of the unintended move after the head lowers.

https://www.youtube.com/watch?v=q9tc9erTGgY

Captain_sq

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.