Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support beacon_klipper version >= 2.0.0, a.k.a Beacon Contact #637

Open
wants to merge 46 commits into
base: main
Choose a base branch
from

Conversation

crkochan
Copy link

@crkochan crkochan commented Aug 9, 2024

My initial take on fixing #636.

Beacon Contact introduced code in their BeaconHomingHelper class that specifically balks when [homing_override] is present in the Klipper config.

My attempt at working around this was to...

  • Create a separate beacon_contact.cfg in the hardware probes folder
  • Specify beacon_contact as variable_probe_type_enabled to be used by future g-code conditionals
  • Update machine.cfg so that homing_override.cfg is not always included
  • Move the homing_override.cfg include into generic_probe.cfg base macro so that every other probe can still get it

There are still a couple more changes I want to make based on the Beacon documentation that are centered on the start_print macro, but I'm opening this as a draft PR so that I can also include any feedback, since this is my first contribution.

…plus some whitespace clean-up
Pretty sure this isn’t really neaded, but added just in case.
* Added macro include for activation and deactivation gcode
* Added macro include for homing hooks that re-implement portions of homing_override
Macros re-purposed from vorontap because the nozzle will be touching the bed surface
Pre and post homing hooks are being used to re-implement large portions of functionality from homing_override.

* Current adjustments for sensorless homing
* Endstop backoffs
* Status lighting
* Accel adjustments
Keeps the LEDs from quickly cyling between X and Y homing.
Variable can be used for conditional actions based on the active color value.
beacon_klipper has undocumented hook features that are called before or after homing either the x or y axis
* Fix incorrect command

* Add macro variable to STATUS_LEDS

Variable can be used for conditional actions based on the active color value.

* Present value as a string literal

* Case and quotes adjustments

* Change quote type

* More quotes

* Discard use of delayed_gcode

beacon_klipper has undocumented hook features that are called before or after homing either the x or y axis

* Add xy hooks

* Add activation macro

* Add contact macro

* Case change

* Add recommend homing configuration

* Revert status_leds
@crkochan crkochan marked this pull request as ready for review August 11, 2024 07:08
* Fix incorrect command

* Add macro variable to STATUS_LEDS

Variable can be used for conditional actions based on the active color value.

* Present value as a string literal

* Case and quotes adjustments

* Change quote type

* More quotes

* Discard use of delayed_gcode

beacon_klipper has undocumented hook features that are called before or after homing either the x or y axis

* Add xy hooks

* Add activation macro

* Add contact macro

* Case change

* Add recommend homing configuration

* Revert status_leds

* Add fast QGL/Z-Tilt macros

* Chomp whitespace
* Add calibration to G28 on probe activation

Guarantees some calibration occurs when home_method is set to proximity, and home_autocalibrate is set to none.

* Track probe activation status

Trying to avoid the probing hooks changing status LEDs when they shouldn’t
ksummers92 added a commit to ksummers92/klippain that referenced this pull request Aug 25, 2024
@ksummers92
Copy link
Contributor

I tried your implementation and there are some default values that are not included that causes an error "Option 'home_method' is not valid in section 'beacon'". This is likely due to home_xy_position not being defined by some kind of defaults. Probably best to retrieve the zero reference position/bed center like the homing_override.cfg does and assume that as the home_xy_position.

@crkochan
Copy link
Author

I started working on this PR after I already had Beacon more or less up and running, so you're right, I already had home_xy_position defined in my overrides.cfg file.

Unfortunately, the value needs to be defined outside of a gcode macro, so I can't use the same trick that homing_override.cfg does.

I'm not quite sure what the optimal solution is. I can add the documented recommended defaults into beacon_contact.cfg, and pick a set of coordinates that are not totally outlandish for a Voron Trident or V2, but that might not fly for users of other printers.

Maybe that, plus adding a commented beacon block to the user_templates overrides.cfg, basically some way of signaling that for contact, a user is probably going to want to have some sort of config override setup.

Just to share, this is my beacon block present in overrides.cfg.

[beacon]
serial: /dev/serial/by-id/usb-Beacon_Beacon_RevH_9AA5D66B5154354D38202020FF0A0B36-if00
x_offset: 0
y_offset: 26.5
mesh_main_direction: x
mesh_runs: 2
accel_axes_map: x, y, z
home_xy_position: 150, 150
home_z_hop: 5
home_z_hop_speed: 30
home_xy_move_speed: 300
autocal_speed: 5
home_method: proximity
home_method_when_homed: proximity
home_autocalibrate: never

If home_xy_position is unset, Klipper will throw an `Option 'home_method' is not valid` error message.

Adding it, plus other defaults from the Beacon Contact docs.
* Add calibration to G28 on probe activation

Guarantees some calibration occurs when home_method is set to proximity, and home_autocalibrate is set to none.

* Track probe activation status

Trying to avoid the probing hooks changing status LEDs when they shouldn’t

* Calibrate after tilt

* Update model prior to tilt

* Fix inconsistent indents
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants