New firmware 1.21RC1 available

robm

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.

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.

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.

nyt

Any idea about the move on resume? Bug or bad script?

dc42

@nyt:

Any idea about the move on resume? Bug or bad script?

Are you sure that isn't a normal printing move? It looks to me that it is printing one full line of the inner perimeter.

peirof

Hi,

i have try to update to 1.21RC3… but i have not acomplish.

1- Download [c]DuetWiFiServer.bin[/c] from https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease
2- Upload by web interface
3- When finish upload, star flashing, and at the end, in DWI, can see [c]WiFi Server Version: 1.21RC1[/c]
** This seems ok** NEXT
3- Download [c]DuetWiFiFirmare.bin[/c]from https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease
4- Upload by web interface
5- But… when finish upload, can read a message: [c]M997 S0 Error: M997: In-application programming binary "iap4e.bin" not found
[/c]

Where i can find [c]iap4e.bin[/c]?
Where i have to upload?
The file [c]iap4e.bin[/c] depends on the firmware you have installed? (In this moment: 1.20.1RC2 (2018-01-01))

Edit: I have read Wiki and [c]iap4e.bin[/c] is in https://www.duet3d.com/wiki/Where_to_get_Duet_firmware_and_tools

coredump

I am having slow upload speeds via the DWC. Via FTP it works as expected but over the web control it goes to like 20 K/s speeds.

Starscream83

Hi,

I have lot's of disconnects using wifi server version 1.21 (every 2 minutes or so) but no disconnects using Wifi Server 1.20. Wifi Signal strength is quite good at -43dBm

Here are the diagnostics:

Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 2c:3a:e8:0b:16:1c
WiFi Vcc 3.41, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 17024
WiFi IP address 10.0.0.104
WiFi signal strength -43dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)