I have finally solved my issue.
I have unmounted and checked the IR probe and discovered that a copper trace was exposed and in contact with a mounting screw. Initially there was a Kapton tape under this screw to isolate the trace as advices in DC42 blog post, but this have finally gone.
Surprisingly, the probe was perfectly functional, as long as the bed was not heating.
Hope this could help someone a day.
After some investigation, I have found exactly what cause the crash, but I have not found how to solve IT. The mini IR probe is restarting every time the bed heater start. Each time the heat bed led on the Duet2 lit, the mini IR probe restart. Checking 3V3 with an oscilloscope is not showing any tension drop. Disconnecting the analog pin of the IR probe does not change anything.
Have you an idea of what could this ? Thanks
Hello,
I have a strange issue on my printer. When my bed heater is active and set to 60°C and the bed sensor have reached 60°C, if a start a Z homing, the nozzle crash into the bed.
If the heater is OFF, Z-homing is working well. If bed sensor temperature have not reached yet the bed heater active temperature, Z-homing is working well. If I start a Z-homing without making action on bed, Z-homing is working well.
The issue only occurs when the bed heater is active and set to a temperature and bed temperature sensor is equal or superior to the bed heater set temperature.
Main board is a Duet 2 wifi, zprobe is a mini ir probe.
I have upgraded my setup to 3.5 and started to make a fresh config.g. Commissioning is done. Heaters, motors and sensors are working well. I have tuned heaters and start to make a fresh calibration. Before upgrading to 3.5 I was on 3.3 and all was working fine.
I think there is a problem in config.g but I can't figure where it is.
Can you help me please ?
Thanks.
My config.g file :
; Configuration file for RepRapFirmware on Duet 2 WiFi
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.5.0 on Thu Jun 06 2024 20:34:51 GMT+0200 (heure d’été d’Europe centrale)
; General
G90 ; absolute coordinates
M83 ; relative extruder moves
M550 P"BLV MGN Cube" ; set hostname
; Accessories
M575 P1 S1 B57600 ; configure PanelDue support
; Network
M552 S1 ; configure WiFi adapter
M586 P0 S1 ; configure HTTP
; LED Strips
M950 E0 C"connlcd.db7" U1 ; configure SO3 LED #0
M150 E0 R0 U0 B0 P0 S1
; Smart Drivers
M569 P0 S1 D2 ; driver 0 goes forwards (X axis)
M569 P1 S1 D2 ; driver 1 goes forwards (Y axis)
M569 P2 S1 D2 ; driver 2 goes forwards (Z axis)
M569 P3 S1 D2 ; driver 3 goes forwards (extruder 0)
; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout
; Axes
M584 X0 Y1 Z2 ; set axis mapping
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M906 X1600 Y1600 Z1600 ; set axis driver currents
M92 X200 Y200 Z400 ; configure steps per mm
M208 X-28:310 Y0:330 Z0:450 ; set minimum and maximum axis limits
M566 X900 Y900 Z12 ; set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z600 ; set maximum speeds (mm/min)
M201 X3000 Y3000 Z100 ; set accelerations (mm/s^2)
; Extruders
M584 E3 ; set extruder mapping
M350 E16 I1 ; configure microstepping with interpolation
M906 E850 ; set extruder driver currents
M92 E690 ; configure steps per mm
M566 E300 ; set maximum instantaneous speed changes (mm/min)
M203 E7200 ; set maximum speeds (mm/min)
M201 E8000 ; set accelerations (mm/s^2)
; Kinematics
M669 K1 ; configure CoreXY kinematics
; Bed
M671 X35:35:275:275 Y35:275:35:275 S3 P0.7 ; adjusting screws at rear left (-15,190), front middle (100,-10) and rear right (215,190), thread pitch 0.5mm
; Probes
M558 P1 C"zprobe.in" H5 F1200:120 T15000 ; configure analog probe via slot #0
G31 P500 X-2 Y20 Z1.4 ; set Z probe trigger value, offset and trigger height
; Endstops
M574 X1 P"xstop" S1 ; configure X axis endstop
M574 Y2 P"ystop" S1 ; configure Y axis endstop
M574 Z1 S2 ; configure Z axis endstop
; Mesh Bed Compensation
M557 X20:280 Y20:280 S14:13 ; define grid for mesh bed compensation
; Sensors
M308 S0 P"bedtemp" Y"thermistor" A"TempHeatedBed" T100000 B3950 C7.06e-8 ; configure sensor #0
M308 S1 P"e0temp" Y"thermistor" A"TempNozzle" T100000 B4337 C6.483002617e-8 ; configure sensor #1
M308 S2 P"e1temp" Y"thermistor" A"TempExtruder" T100000 B3950 C7.06e-8 ; configure sensor #2
; Heated beds
M140 P0 H0 ; configure heated bed #0
; Heaters
M950 H0 C"bedheat" T0 ; create heater #0
M143 H0 P0 T0 C0 S80 A0 ; configure heater monitor #0 for heater #0
M307 H0 R0.194 K0.189:0.000 D6.13 E1.35 S1.00 B0 ; configure model of heater #0
M950 H1 C"e0heat" T1 ; create heater #1
M143 H1 P0 T1 C0 S285 A0 ; configure heater monitor #0 for heater #1
M307 H1 R4.853 K0.469:0.000 D4.17 E1.35 S1.00 B0 V24.1 ; configure model of heater #1
; Fans
M950 F0 C"fan0" ; create fan #0
M106 P0 C"FanPart" S0 B0.1 H1 T45 ; configure fan #0
M950 F1 C"fan1" ; create fan #1
M106 P1 C"FanExtruder" S0 B0.1 H1 T45 X0.60 ; configure fan #1
; Filament senspor
M950 J3 C"connlcd.encb"
M581 P3 T3 S0 R0
M581 P3 T3 S1 R0
;M591 D0 P1 C"connlcd.encb" S2 ; define filament-out sensor
; Buttons https://docs.duet3d.com/User_manual/Tuning/Triggers
M950 J2 C"connlcd.enca"
M581 P2 T2 S1 R0 ; unload button, run trigger1.g
; Tools
M563 P0 D0 H1 F0 ; create tool #0
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures to 0C
M98 P"SO3_RGB_update.g" ; Init SO3 extruder RGB leds
; Miscellaneous
T0 ; select first tool
@dc42 Ok, thanks. I think I would give it a try on my next upgrade.
I was thinking about the closed loop this afternoon. Does Duet team have investigated the feasibility of closing the acceleration loop ? With linear composite encoder, or maybe ultra-fast sample rate accelerometer ?
The idea would be a sort of closed loop feature merged with an input shaping feature. A sort of real time input shaping.
Theoretically, a motion system with sufficient sample rate and response speed could compensate and remove mechanical resonance (motors, belt, frame, leadscrew, etc.) in real time. Inputs data filtering and tuning could be a nightmare, but I wonder if there is not a track to explore on this side.
@droftarts Thanks for those reply.
Do you know if the tests of those new features have shown motor consumption reduction or MRR and VFA improvement? Maybe motor noise reduction?
Anyway it's an impressive technology improvement. Great job !
@dc42 Thanks for those details.
So the loop is closed at the 1HCL or M23CL board software level. Can you tell me if it is a velocity loop or a position loop ?
A velocity loop here could be the software detecting in real time that the required speed of the running Gcode command is not reached. And so react by requiring more power to the driver, to motor reach the required speed, and catch up the theoretical position a T moment.
A position loop could be the software checking at the end of a Gcode command if the required position is reached or not. And so react by delaying the motion execution to wait the system reach the good position, before starting the next Gcode command.
It could be done in real time too, by checking current position in real time, and react by requiring more power to the driver too, to reduce the position error.
Anyway, if the loop is closed in real time during Gcode command execution, this should reduce and adapt the motor current to what is really needed, and so maybe reducing MRR and VFA.
One more thing. Is a linear encoder support could be added in future ? To check the axis carriage linear position instead of axis motor angular position ? The final idea would be to make a dual-loop system and so eliminate all possible belt / leadscrew / mechanical backlash on each axis.
I ask those questions just by curiosity, it's an interesting domain.
Thanks
Hello,
About closed-loop motion system, what are the benefits to go with 1HCL cards or 23CL motors, over using external closed loop motors+drivers connected to step/dir signals ? Is there some firmware features only implemented through those Duet solutions ? May be multiple feedback loop, current/torque/speed loops ?
Is it just working at driver level (error correction) without any acts of the firmware ?
Can someone explain to me how closed loop is actually implemented on Duet boards and RRF ?
Currently preparing an upgrade phase on my printer (BLV MGN Cube), I search information about the different solutions to maybe go in closed loop. I am familiar with the concept and already have used it on other project with position control.
I already read 1HCL doc and 23CL doc.
Thanks 
Yes, you are right. I did not try to prove you are wrong.
But I have "phases" every 6/12 month in which I try to upgrade, or just tinker on my printer, just for fun. And I generally do not touch my printer between those phase, other than for printing things. So I do not have good memories on what is on my printer, how I have done this part or this part, etc. It is not well documented on my side.
So I prefer to backup what is actually working, so what is on chips, rather than what was used to make it work. It is just personal taste, not certainly logical or the best 
@infiniteloop said in How to make a full backup of a Duet 2 wifi board:
@pit34 Why on earth do you want to scrape the firmware from the boards with Bossa, if you can load the images as well from GitHub? Must be personal taste, eh
I am a bit of a maniac. I like to backup what is directly on the board and is working. Like a "master" in cinema.
I am afraid of backuping the wrong file or something like that.
Reading directly on chip is a way for me to avoid some way of error. And to be sure to have what is working.
But yeah, it may be quite strange 
May be some rest of an ancient work in electronic board factory ? I'll ask my psy...
Ok. Thanks.
So as i can see, the way to do a full recovery backup from a fully fonctionnal printer is :
To backup :
To recover :
I think this is the simple and more reliable way. Can you confirm this ?
For the wifi module, I think a "hard" way is possible, by reading the firmware directly on the wifi module. This is a simple Esp8266 module. Accessing Rx and Tx pins with an FTDI adapter should permit to read and write binary. This implies to solder some wire on board or use spring probes, and could be risky, but this should work.
Ok, thanks.
I am on 3.2 and have found multiples .bin files on the sd-card, like the combined one, the wifi one, etc.
I remember those files need to be flash in a specific order. So I presume this is not a copy of the firmware binary.
Can Bossa still be used to read et save a full firmware backup ?
Like for the PanelDue ?
My goal is to compare RRF 3.4 solution with Klipper solution. As the SAM4e8e will be fully erased by Klipper firmware installer, I would like to be able to re-flash it with a third-party program, to be able to come back to RRF 3.4 easily.
Those multiple .bin files with specific flash order make me worry about how to return easily to RRF =/
Thanks for your help.
Hello,
I would like to be able to backup my entire Duet 2 wifi board, not just my config files via DWC.
Is there other things that config files and firmware binary to backup ?
If yes, what are there more ?
If no, is there a standard way to read and backup firmware binary ? Maybe with Bossa?
Thank in advance
Regards.
Thanks for your fast answer !
Do you have any idea of the approximate release period for 3.5? Quarter or year. I am just curious about this
Nobody can give somes informations about this subject ?
@dc42 maybe ?
Maybe i have posted on wrong section. In this case, feel free to move this post in the correct one.
Thanks in advance.
Hello,
I have read in 2021 road map thread that inout shaping would be implemanted, and jerk would be replaced with s-curve profile.
As I can read in RRF release changelog, inout shaping is already implemanted.
But i cannot find anything about s-curve acceleration and motion system improvement.
Can you tel me if we could hope for this improvement in 3.4 release ? As it is already in release candidate state, i doubt about this.
Thanks.
And great thanks for your amazing works !!