... to all the Duet 3D programmers. I just updated the Duet and the PanelDue to 3.4.0 - and especially the latter part shows how far you have come with simplifying the task: upload, right-click, choose "install" and that's it.

This is light years away from the old process with Bossa. Congratulations for making this so effortless!

@oliof well, maybe you can reduce currents now again

But thanks for the feedback! I will mark the thread as solved then.

Once more @dc42: thank you very, very much for all that detective work you did!

If you use nested M291 commands with a messagebox mode S4... S7 (the ones that create an "input" variable), the last message box overwrites the initial one, which may result in the wrong initial task being executed:

Here is a quick example. If you choose "load filament into left hotend" which is the first option in the initial message box (--> input = 0) and then choose the option not to wipe or clean the hotend nozzles, then the input variable changes to 2 which causes the option "load filament for both hotends" of the initial message box to be executed.

M291 S4 K{"left","right","both","back"} P"Please choose the hotend to load" R"load filament"
    if input = 0
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - left"
            if input = 0
                ; wipe and finish
            if input = 1
                ; move to a convenient cleaning position and request cleaning
            if input = 2
                break ; finish
    if input = 1
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - right"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 2
        ; do stuff... 
                M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzles?" R"load filament - both"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 3
        ; finish

This behaviour is logical if you keep in mind that the message boxes fill the variable "input" which only exists once per macro, in opposite to the "iterations" loop counter.

But since I did not think this through and kept searching for some typo for days until the penny dropped , I hereby vote to add a corresponding remark to the notes of M291 in the Gcode dictionary - something like this maybe: " NOTE: If you use more than one message box with mode S4... S7 within the the same macro, keep in mind that the same input variable is used for all message boxes, which means it only shows the input from the last message box."

@Phaedrux:
Thanks again - it works perfectly. I removed the second step however - this is handled by the gcode of the print itself:

M307 xxxxx ; PID values for quick heating
G10 P0 S180 ; set temp of tool to 180°C
M116 ; wait for temp
M307 yyyyy ; PID values for stable temps during print
; final temp is supplied by part gcode

@dc42:
sure, I played a lot with autotune but for some reason did not get any satisfying results with the Duet that combined a quick heat-up and a stable print temperature. I do not remember though if I changed D that much - I will try that.

Interestingly, the autotune of the old Printrboard had yielded a better result, which is why I fell back to setting the PID values with M301 for a while and simply used what the Printrboard autotune had told me on the Duet as well, but I had to resort to setting an M307 setting to define a maximum PWM since the duet does not seem to provide another way to set this - and then overwrite this setting partly with M301. (On the Printrboard I could define the max. PID drive in the firmware eeprom.)
This did not work perfectly though (unsure why - maybe due to different response times of Duet vs. Printrboard?). But for now and with Phaedrux' trick I finally have a setting I feel comfortable with.

By the way - thanks a lot for including the german translation I had sent you into the PanelDue firmware

@oliof You are right, I forgot that when I did the last test - which means I can further increase the current.

For the next two days or so, I probably won't be able to redo the test with a higher current, but I will do as soon as I can!

Just in case anyone is interested, here is the working solution:

; XY calibration in a cavity that is normally covered by the print plate

; Variables
; print plate thickness in variable "global.Druckplattendicke" needs to be defined before running the macro, e.g. in config.g
var Eintauchtiefe = 1          ; how deep the nozzle shall dive into the cavity
var Referenzwert_X = 0
var Referenzwert_Y = 0
var Hotend2_X = 0
var Hotend2_Y = 0

G28 							; Home

; prepare printer - insert whatever you need here...

; heat up hotends and bed
M140 S60 						; heat up bed
T0 P0
M568 P0 S220 R220				; heat up Hotend 1
T1 P0
M568 P1 S220 R220				; heat up Hotend 2 auf 220°C 
T-1 P0
M116							; wait

; let the user clean the nozzles
G1 H2 X{move.axes[0].min+50} F3000 
G1 H2 U{move.axes[3].max-50} F3000 
M400								; wait

; Message
M291 "Please clean the nozzles" R"Notice" S3

; Move print heads back to their parking position
G1 H2 X{move.axes[0].min} F3000 	
G1 H2 U{move.axes[3].max} F3000 	


; lift bed close to measuring level
G1 H2 Z5 F6000

; move hotend 1 to cavity and dive in
G1 H2 X0 Y0 F6000
M400
G1 H2 Z{-global.Druckplattendicke - var.Eintauchtiefe} F3000 

; begin reference measurement
T0 P0 						        ; activate tool 0
while iterations < 8				; measure 8 times in X
	M675 X R1 P0 F100
	M400
	set var.Referenzwert_X = var.Referenzwert_X + move.axes[0].machinePosition   ; save value
set var.Referenzwert_X = var.Referenzwert_X / 8 ; calculate final reference value
	
while iterations < 8				; measure 8 times in Y	
	M675 Y R1 P0 F100 
	M400
	set var.Referenzwert_Y = var.Referenzwert_Y + move.axes[1].machinePosition    save value
set var.Referenzwert_Y = var.Referenzwert_Y / 8 ; calculate final reference value

; move back hotend 1
G1 H2 Z2 F6000  
M400
G1 H2 X{move.axes[0].min} F6000

; delete old offset from hotend 2:
G10 P1 U0 Y0

; move hotend 1 to cavity and dive in
G1 H2 U0 Y0 F6000
M400
G1 H2 Z{-global.Druckplattendicke - var.Eintauchtiefe} F3000


; measure with hotend 2
T1 P0 						        ; activate tool 1

while iterations < 8				; measure 8 times in U
	M675 U R1 P1 F100 
	M400
	set var.Hotend2_X = var.Hotend2_X + move.axes[3].machinePosition   ; save data
set var.Hotend2_X = var.Hotend2_X / 8 ; ... and calculate final value

while iterations < 8				; measure 8 times in Y
	M675 Y R1 P1 F100
	M400
	set var.Hotend2_Y = var.Hotend2_Y + move.axes[1].machinePosition   ; save data
set var.Hotend2_Y = var.Hotend2_Y / 8    ; ... and calculate final value

; define new offset  and save it to a file that is read from config.g:     
G10 P1 U{var.Referenzwert_X - var.Hotend2_X} Y{var.Referenzwert_Y - var.Hotend2_Y}
echo >"Korrekturwert_xy_offset_tool1.g" "G10 P1 U"^{var.Referenzwert_X - var.Hotend2_X}^" Y"^{var.Referenzwert_Y - var.Hotend2_Y}^""

; bring printer back to idle state
T0 P0                                               
G1 H2 Z5 F6000						
G1 H2 U{move.axes[3].max} Y{move.axes[1].min} F3000 	
G1 Z120 F6000 
M568 P0 S0 R0
M568 P1 S0 R0
M140 S0

; notify user
M291 S2 P"XY-Offset of right Hotend is has been saved!"

(edit: added remark, removed unused variables)

@dc42 1st attempt:

Y homing error was 0.000
X homing error was 0.012
Y homing error was -0.012
X homing error was -0.012

Those offsets are within the tolerance of the endstops...

I will repeat the test once or twice tomorrow, but it seems it is indeed caused by the filament.

Edit: the printer had likely IS disabled in this test, please ignore it.

@oliof said in IDEX XY calibration by electrical nozzle contact:

@NeoDue great stuff! You should consider some way to filter out outliers in your 8 runs (use median or just track lowest/highest and reject runs where the difference is greater than some value you deem an acceptable range).

@oliof Now I finally had the time to dust off and actually use a bit of my old statistics knowledge... Got it - here is a test macro that removes outliers from a given array based on their z-score:

; constraints out of experience: 
; - electrical nozzle contact never gets activated too soon (=> too low values will never happen and are not taken into account here)
;   if that does not apply, a lower acceptance limit for the z-score needs to be defined as well
; - values that are too high are usually at least 0.15...0.2mm off
var Referenzwert = {1,1.02,1.05,1.2,1.22,1.3,1.01,}  ; test values - the three values that are too high need to be detected and removed from the mean value
var Referenzmittelwert = 0.0
var Referenzstandardabw = 0.0
var ReferenzZScore = vector(#var.Referenzwert,null)
var ZScoregrenze = 0.5
var Anzahlgueltig = 0

; calculate mean value
while iterations < #var.Referenzwert
    set var.Referenzmittelwert = var.Referenzmittelwert + var.Referenzwert[iterations]
set var.Referenzmittelwert = var.Referenzmittelwert / #var.Referenzwert

; calculate standard deviation
while iterations < #var.Referenzwert
    set var.Referenzstandardabw = var.Referenzstandardabw + (var.Referenzwert[iterations] - var.Referenzmittelwert) * (var.Referenzwert[iterations] - var.Referenzmittelwert)
set var.Referenzstandardabw = sqrt(var.Referenzstandardabw / (#var.Referenzwert - 1))

; calculate z-score of each measurement value
while iterations < #var.Referenzwert
    set var.ReferenzZScore[iterations] = (var.Referenzwert[iterations] - var.Referenzmittelwert) / var.Referenzstandardabw

; re-calculate mean value without detected outliers 
set var.Referenzmittelwert = 0
while iterations < #var.Referenzwert
    if var.ReferenzZScore[iterations] < var.ZScoregrenze
        set var.Referenzmittelwert = var.Referenzmittelwert + var.Referenzwert[iterations]
        set var.Anzahlgueltig = var.Anzahlgueltig + 1
set var.Referenzmittelwert = var.Referenzmittelwert / var.Anzahlgueltig

echo var.Referenzmittelwert

While I do not use that for XY calibration (at least yet - that one works perfectly well as it is so far...), I did add it to the two macros I wrote for z calibration and z-leveling of the U axis relative to the X axis. It definitely makes sense there since slight drops of filament coming out of the nozzle can cause errors.

@dc42 This means "M111 S1 P0 B4096" or "M111 S1 B4096"? Okay, thanks!

edit: 1st "dry" test (print w/o filament, measure x and y offset) ist running right now!

... and once again @dc42 has fulfilled the picture of an electronics wizard that I have of him:

(no, I cannot draw at all, this was generated with hotpot.ai art-generator, and I could not get that stupid KI to make the PCB larger)

Three prints up to over 6mm without filament and one with filament, all with Input shaping enabled - and not a single "bang" or layer shift! For the first time ever!

Congratulations, Sir!

As far as I can tell, it seems you have solved the issue!! THANK YOU!

Now I guess I can finally throw all these away

(By the way, the larger blob is still there, however not in the first affected layer but in the other two for some reason. But now the printer simply runs over it, so this is a minor annoyance now and nothing more. I will check if including the retract/unretract command into the print file instead of letting it the Duet do has an effect or such. In case I find something, I will open a new thread for that)

Edit: @adrian @oliof Please also write here if the current version solves the issue for you, then I would mark this as solved

@dc42 said in Software bundle 3.6.0-beta.1 now available:

@NeoDue no we haven't implemented that yet, it's separate from input shaping.

Thanks! Then I will wait until 3.6 is final.

@dc42 does the new input shaping algorithm also mean that something similar to the Klipper "minimum cruise ratio" (https://www.klipper3d.org/Kinematics.html#minimum-cruise-ratio ) is supported by RRF 3.6.0?

@droftarts Thanks! I can only state that it did indeed work on my old printer as well (on 3.3 or an early 3.4 release). Let's see what some testing will yield.

@droftarts Hm, on my mobile phone there are about 6cm distance and three fan sliders between them. I cannot fully rule it out since I admit I was tired at the moment, but I hope my brain was not that offline...

Currently I am printing the parts I need once more - this time without touching those sliders. When that is done, I can start testing

Just to be sure: can you confirm that the slider only sets M220?

@oliof It is still the same - IDEX, Duet 3 6HC and no toolboards, no SBC or such . I will add or link to everything in a possible bug report of course.

A clog or insufficient cooling was my first thought as well, but the Duet should have detected that within short due to the filament sensor that triggers every 2mm of filament. The amount of material that was or rather should have been printed was a generous multiple of that. Therefore and due to the fact that a start of another print after letting everything cool down did not cure the issue (while manual extrusion via PanelDue worked fine at the same time) but a reboot did, I am somewhat tempted to rule out something mechanical.

But I want to test more first before I bother the team here again, and if DWC really only sets an M220 or M221 value, this should be easy to confirm, hence the question.

I tried to use the "speed" slider (or rather the buttons controlling it) in DWC yesterday for the first time. The reason was to find a printer speed that makes the printer more silent since the print took longer than expected and you can hear some of the machine moves from our bedroom. Therefore my intention was to move down to 80%, then 70%, 60% 50% and listen a while.

1st observation: the buttons reacted rather laggy and the displayed value went down with each click by 5% (as it should be) but then went up again by 5% after maybe half a second or a little less.
2nd observation when I went so the printer: at one step it seemed the extruder speed got out of sync, if I interpret the result correctly: the print head moved perfectly fine, but the material that came out of the nozzle was just enough for cobwebs. When I increased speed again to 100%, more came out but still far from enough. The filament sensor did not cause the Duet to complain though even if it should.
I stopped the print and started a new one, and extrusion was still far from where it ought to be. A restart of the whole printer however immediately cured the issue.

For now, this is a one-time error which I need to recreate first, but I would like to know what those DWC buttons do to be able to check the values set by them via the console if that happens again to be able to file a decent bug report.

Could anyone explain this to me?

@droftarts you are right, "elif" works as well - and is easier. Thanks!

But I would add the note nevertheless, in case someone relies on the input variable for something else.

If you use nested M291 commands with a messagebox mode S4... S7 (the ones that create an "input" variable), the last message box overwrites the initial one, which may result in the wrong initial task being executed:

Here is a quick example. If you choose "load filament into left hotend" which is the first option in the initial message box (--> input = 0) and then choose the option not to wipe or clean the hotend nozzles, then the input variable changes to 2 which causes the option "load filament for both hotends" of the initial message box to be executed.

M291 S4 K{"left","right","both","back"} P"Please choose the hotend to load" R"load filament"
    if input = 0
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - left"
            if input = 0
                ; wipe and finish
            if input = 1
                ; move to a convenient cleaning position and request cleaning
            if input = 2
                break ; finish
    if input = 1
        ; do stuff... 
        M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzle?" R"load filament - right"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 2
        ; do stuff... 
                M291 S4 K{"wipe","manual clean","done"} P"Wipe or clean the hotend nozzles?" R"load filament - both"
                    if input = 0
                        ; wipe and finish
                    if input = 1
                        ; move to a convenient cleaning position and request cleaning
                    if input = 2
                        break ; finish
    if input = 3
        ; finish

This behaviour is logical if you keep in mind that the message boxes fill the variable "input" which only exists once per macro, in opposite to the "iterations" loop counter.

But since I did not think this through and kept searching for some typo for days until the penny dropped , I hereby vote to add a corresponding remark to the notes of M291 in the Gcode dictionary - something like this maybe: " NOTE: If you use more than one message box with mode S4... S7 within the the same macro, keep in mind that the same input variable is used for all message boxes, which means it only shows the input from the last message box."

@Thalios On my printer, the z homing sensor is at maximum z., therefore I do not have any issues with homing with a print.

But the Duet saves the z position at shutdown. Therefore, if you have the usual lead screw for z which stays where it is, it should suffice to just reload the z value with a G92 command as suggested here: https://docs.duet3d.com/en/User_manual/Tuning/Resume

If anyone happens to have the same issue: use the file name as variable. That complicates somewhat the code in resurrect-prologue.g (you need to check for each possible file name if that file exists and recreate the associated variable(s) instead of just executing it), but shortens the string significantly:

M913 X0 U0 Y0 Z40 E0:0 echo >{""r""^global.Modus} G91 M83 G1 Z1 F12000

(I added "r" as a bit of luxury to place the file close to "resurrect.g", since the variable only consists of a number in my case. Using only the variable gives you six precious characters more)