[smart_effector] Fix error when use smart_effector as z virtual endstop

[Noisyfox]

The smart_effector's recovery_time and probe_accel are very useful options, even with a normal probe. However when using it as the z endstop the klipper gives the following error:

Option 'position_endstop' in section 'stepper_z' must be specified

And this PR should fix this issue and make smart_effector useable.

[KevinOConnor]

@dmbutyugin - do you have any comments on this?

-Kevin

[dmbutyugin]

I don't have a problem with this PR code-wise. However, I'm curious about the setup @Noisyfox has in mind. The smart effector is a device that was specifically designed for delta printers. And AFAICT, delta printer kinematics doesn't allow homing using a probe (it kind of doesn't make sense, since the rails must be homed instead in order to determine the position of the effector in 3D space). And in order to use a probe to determine a nozzle offset against the bed one should use different techniques. That's why this support wasn't implemented in the first place. And so the question is, are you trying to install a smart effector on a printer with a different kinematics? Or perhaps I overlooked something?

[Noisyfox]

I don't have a problem with this PR code-wise. However, I'm curious about the setup @Noisyfox has in mind. The smart effector is a device that was specifically designed for delta printers. And AFAICT, delta printer kinematics doesn't allow homing using a probe (it kind of doesn't make sense, since the rails must be homed instead in order to determine the position of the effector in 3D space). And in order to use a probe to determine a nozzle offset against the bed one should use different techniques. That's why this support wasn't implemented in the first place. And so the question is, are you trying to install a smart effector on a printer with a different kinematics? Or perhaps I overlooked something?

I'm using this as an advanced version of the original probe, on my voron 2.4 with under-heatbed piezo sensor, mainly to solve the 'probe triggered before z move' issue.

[willpuckett]

I'm not sure exactly of your setup, but using a piezo can be pretty sensitive. I find I have to turn off nearby heaters and fans for a successful probing, as well as drop the acceleration very low, and then dwell for a part of a second for the probe to settle. Have you tried something like the following?

[probe]
pin: !canth: PB11
z_offset: -0.125
speed: 5
lift_speed: 50 #The speed the probe raises before traveling or probing again. 
samples: 1
sample_retract_dist: 5
activate_gcode: 
  activate_probe
deactivate_gcode:
  deactivate_probe

[gcode_macro activate_probe]
description: Stills heaters calms acceleration before probing
variable_accel: 0
variable_bed_target: 0
variable_extruder_target: 0
gcode:
  # Save acceleration and target temps
  SET_GCODE_VARIABLE MACRO=activate_probe VARIABLE=accel VALUE={printer.toolhead.max_accel}
  SET_GCODE_VARIABLE MACRO=activate_probe VARIABLE=bed_target VALUE={printer.heater_bed.target}
  SET_GCODE_VARIABLE MACRO=activate_probe VARIABLE=extruder_target VALUE={printer.extruder.target}

  # Turn off heaters so probe doesn't freak out
  M140 S0
  M104 S0

  # Set acceleration really low (also so probe doesn't freak out)
  M204 S50

  # If there are fans in the vicinity of the piezos, you may need to still them as well... You may need to increase the dwell time below in order for the fan to spin down
  # SET_TEMPERATURE_FAN_TARGET temperature_fan=chassis target=55

  # Wait a sec for things to settle
  G4 P600

[gcode_macro deactivate_probe]
gcode:
  # Restore acceleration
  M204 S{printer["gcode_macro activate_probe"].accel}

  # Restore heater target temps
  M140 S{printer["gcode_macro activate_probe"].bed_target}
  M104 S{printer["gcode_macro activate_probe"].extruder_target}

  # If there are fans in the vicinity of the piezos, you'll want to restore them here
  # SET_TEMPERATURE_FAN_TARGET temperature_fan=chassis target=30

[gcode_macro G30]
# Implements G30 https://marlinfw.org/docs/gcode/G030.html
gcode:
    G0 X0 Y0
    G0 Z1

    # Via https://github.com/Klipper3d/klipper/issues/1221#issuecomment-462140220
    PROBE
    G92 Z0

I can then use G30 to probe the bed and adjust z-height to compensate for nozzle/bed expansion after heating and right before a print begins. I usually use some sort of WIPE move right before G30 to make sure there's no blob that would throw the probe reading.

[Noisyfox]

Yeah I know technically what I want can be done in gcode, by adding a simply delay in the activate_gcode. However since smart_effector already provided the recovery_time parameter which is more intuitive and simpler to use, and to be honest I think this parameter should be available to the probe as well, since any force probe will suffer from the vibration caused by the xy movement before doing the z homing.

And actually I didn't know what a smar effector is (not until now), but when I saw this in klipper doc, "The "Smart Effector" from Duet3d implements a Z probe using a force sensor. ", which is exactlly what I'm using for my printer (except my force sensors are mounted under the print bed instead of the toolhead).

I don't think we should limit this to delta printers only, despite of its name. Be able to limite the accls and delays without writing any extra gcode is pretty neet, for all printers I would say.

[willpuckett]

The smart effector is a specific piece of hardware made by duet 3D. IIRC, it does not use a piezo, so trying to configure your piezo sensor with it might not work very well.

If you do not have a smart effector, utilizing a different config object would probably be more appropriate.

[Noisyfox]

The smart effector is a specific piece of hardware made by duet 3D. IIRC, it does not use a piezo, so trying to configure your piezo sensor with it might not work very well.

If you do not have a smart effector, utilizing a different config object would probably be more appropriate.

I don't really care about what smart effector really is, all I know is in klipper, a [smart effector] is simply a [probe] with few extra paramters, which are useful for any probe. And as long as you don't set the 'control pin' paramter, it behaves just like a generic probe.

And as long as I could tell, a smart effector in klipper is just a normal probe with some gcode macro that can adjust the sensitivity on-the-fly. It doesn't really care about whether you are using an actual smart effector hardware or not.

[willpuckett]

Thanks for explaining further. It does seem to make sense to have a piezo sensor class that could allow for common configuration via the config file without having to write as much activate/deactivate gcode.

It seems like creating a new [piezo_probe] that inherits from probe and provides accel, and delay between probe would be reasonable and more descriptive. Then perhaps some work could be done as well to utilize the comparator onboard STM32 boards so that a piezo could be directly connected with only a small dampening circuit of some sort. Since piezos have some float with temperature variation, this might make software compensation of the trigger point viable, creating a more robust probing process.

FWIW, I've found that temporarily disabling the heaters (both bed and hotend) is necessary to avoid the "probe triggered prior to movement" in this case as well, and it might be worthwhile to include such behavior in [piezo_probe].

[Noisyfox]

Thanks for explaining further. It does seem to make sense to have a piezo sensor class that could allow for common configuration via the config file without having to write as much activate/deactivate gcode.

It seems like creating a new [piezo_probe] that inherits from probe and provides accel, and delay between probe would be reasonable and more descriptive. Then perhaps some work could be done as well to utilize the comparator onboard STM32 boards so that a piezo could be directly connected with only a small dampening circuit of some sort. Since piezos have some float with temperature variation, this might make software compensation of the trigger point viable, creating a more robust probing process.

FWIW, I've found that temporarily disabling the heaters (both bed and hotend) is necessary to avoid the "probe triggered prior to movement" in this case as well, and it might be worthwhile to include such behavior in [piezo_probe].

Ideally yes, but why preventing people from using the smart effector as the homing sensor? Feels like an artifical limit to me. Say maybe someone fingured out the way of adapting the real smart effector hardware to their non-delta printers (maybe he/she just happen to have a broken old delta printer and decide to make the most out of it). It's still, just a force sensor right?