Best posts made by pandaym

Hi Duet,

I have lately gotten a lot of experience with Klipper, that I am currently running on my MK3S Bear on the original Einsy board. I do own a Duet WiFi and a Duet 3 too, and would very much like for these to get out of the drawer and onto my printers

I would therefore like to know what the plans are for implementing some of the features, that I find really good in Klipper:

• Input shaper - The implementation in Klipper to me is a complete gamechanger, and gave me the biggest benefit of any upgrades or tuning I have ever done to a 3D printer. I would really much like to see the same implementation in Duet soon. I have found a couple of discussions about it, but I only saw mention that something may be in the works for a later version, nothing too specific. Can you elaborate on these plans?

• Acceleration / square corner velocity / jerk - To be honest I do not fully understand the ins and outs of this. In my experience with RRF and Marlin, tuning jerk has always been something that caused problems, and I never really knew if I were "there". In Klipper, jerk is gone, and I believe this is one of the reason I found it much simpler to tune my printer that runs Klipper. Any chance we could see a similar functionality in RRF?

• Calibration scripts - Another thing that makes it really simple to calibrate a printer running Klipper are the integrated scripts. An example is pressure advance, which I have found to be much easier to deal with due to integrated calibration script. Is this something we can look forward to?

I hope you guys can elaborate on these points, and that there are plans in these regards to RRF.

Hey everyone,

First of all, I am a completely new Duet user, so excuse my lack of experience.

I just finished the initial assembly of my CoreXY 3D printer, running a Duet 3. When I wanted to start my first test print, I realized I had to change some things up, and therefore paused and cancelled it. I started printing again afterwards, but during homing, the nozzle crashes straight into my bed and made a hole in it - damn!

I cannot seem to figure out exactly why it crashed the bed, or how I can ensure it does not happen again. What I think is that when homing X or Y fails, it for some reason still goes on with the movements to home Z, but without deploying the probe. I plan to tune the sensorless homing to be more reliable, or even add micro switches for homing, but I would still like for this to not happen if something is off.

I don't know exactly which of these errors relate, but these are what I could find in my console:
16.6.2020 23.28.22 G28
Error: G0/G1: insufficient axes homed
16.6.2020 23.32.24 Error: Z probe was not triggered during probing move
Error: Z probe was not triggered during probing move
16.6.2020 23.33.29 M120 G91 G1 Z25 F6000 G90 M121
Error: G0/G1: insufficient axes homed

What I think might be relevant from my setup:

• Sensorless homing on X and Y and BLTouch on Z.
• All my motors are the E3D high torque motor.
• I am running true bed levelling

Trying to attach the relevant configs and the gcode I was trying to print here. It got flagged as spam when I initially tried. Hopefully this works:
3DBenchy.gcode
config.g
homeall.g
homey.g
homex.g
homez.g
bed.g

Here is a picture of what the printer looks like at the moment. Thank you in advance!

@bearer said in Nozzle crashed into bed while homing - can this be avoided?:

Nozzle crashed into bed while homing - can this be avoided?

in general test limit switchs first
then test motor directions with small moves
and use normally closed limit switches so that any failure of the switch will prevent movement when homing.

I was considering whether I should use switches, but I thought that, since I don't need that much accuracy on homing (unless if I have to resume after power loss), it should be fine without for the time being. I did test the motor directions and sort all of that out first, and also got sensorless homing working. It just seems that it sometimes fail homing X/Y when the tool head starts from the middle of the bed instead of close to where it homes against.

But is there not a way to halt everything in case it misses homing an axis instead of it just continuing to move stuff?

@Phaedrux said in Z probe was not triggered during probing move - bed crash:

Please keep us posted on if it continues to happen and if you remove the cancel.g file if that causes it to happen reliably again.

In addition to the motor current drop you can also add the BLTouch alarm release command to the start of homeall to clear any error state and retract the pin as a precaution. I think I may have mentioned that already.

Sorry, I did not press submit on the answer I had written here.

I disassembled the printer to redo some wiring etc. to finish it off. When I am done, I will continue testing it, and I will get back if it keeps happening. Also I will add the alarm release, just to have an extra precaution.

Thanks a lot for the help!