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

[crkochan]

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.

[ksummers92]

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]

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

[github-actions[bot]]

📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!

[trideetztz]

Hey @crkochan, any update on this? I'd love to see support for this added.

[crkochan]

None from my side. I've been running a series of post-kit-build prints for some new parts and future upgrades using my fork branch, and the pieces have been turning out just fine on my V2.4.

It may not be up to snuff in terms of being merged into mainline because of the need for users to add Contact-specific settings that are perhaps unique to their machine, or class of printer, into their overrides file in order to avoid the potential for cryptic and/or misleading error messages on Klipper start that would come from the Beacon module.

I'm happy to implement any feedback from the maintainers.

[KazachThi]

Hey, @crkochan I have been using your setup to run beacon contact with no problems. All is working as intended. One thing (and i might be wrong on this one), we have one unnecessary beacon contact calibration. Order in my case :

• Homing
• pre-heating hotend
• bed heating
• chamber heating
• Beacon contact calibration (first)
• QGL
• Beacon contact calibration (second)
• Beacon contact calibration (third)
• Bed mesh
• Beacon contact calibration (fourth)
• Heating hotend
• Nozzle clean
• Prime line
• Printing

So, second and third are redundant ? Hope this helps.

[crkochan]

So, second and third are redundant ? Hope this helps.

Yes. Per the Beacon docs, QGL/z tilt adjust and bed mesh should be book-ended by calibrations.

I'm not sure where the extra calibrations are coming from in your case.

[Frix-x]

Hello, thanks for the PR. I'm back on the subject and bought a beacon to test it. I'll merge it as soon as I get it installed :)

[tavalin]

Hi, is there any progress on this or plans to progress this? The Beacon contact functionality has been out for more than 6 months now so it's a shame that Klippain doesn't yet officially support it

[sima-it]

So I assume, this will not be intregrated then. Is the Poject dead?

[gueee]

So I assume, this will not be intregrated then. Is the Poject dead?

it seems to be dead at that point. nevertheless, I forked the repo and will extend the project, but I can't say when I'm ready to publish it.

for now I pulled my own repo, so it's not marked dirty and beacon contact and AWD are working for me.

[sima-it]

thx mate, i'm running also the changes from [crkochan] with no problems so far just the dirty repo keeps bothering me ;)

[gueee]

I already extended klippain a bit, especially regarding bed sizes with a dedicated configuration option to choose any bed size, which calculates the offsets for bed mesh and the configuration option for multiple motors on x and y, including tmc driver settings for the additional steppers.

I'm also trying to create a web based gui for automatically generating the configs, or rather the overrides.

if you're a little patient I'm gonna publish it, probably under a new name, since there are too many changes that somehow left the path of klippain...

[sima-it]

looking forward to test it out, thanks for your effort

[neptunus0001]

@Frix-x Can you give klippain users an indication of when this feature will be integrated? It would be great to get some feedback from you.