[Feature Request] Adding support for the Pyr0-Piezo Z-probe

pyr0ball commented 5 years ago

Description

I've been working on a self-calibrating piezo sensor for a while, and I'm nearing completion, so I wanted to reach out and start working on code integration with Klipper.

Information and sources can be found here: https://github.com/pyr0ball/pyr0piezo

Requirements from Klipper

The sensor has been designed with UART and I2C input to allow the user to adjust the auto-calibration parameters on-the-fly. These sensors imitate a standard active-low endstop signal for it's output, so they can work out-of-the-box without these inputs, but there are a number of possible benefits for being able to adjust the sensitivity of the circuit:

Different sized piezo disks produce different amplitude signals
Decrease sensitivity during X/Y movements while probing, increase once probing Z
Different mechanical structures for the piezo mount effect the signal amplitude

This integration could be implemented using GCode commands, and/or an LCD menu option

Input Syntax

To set the auto-tuning parameters using serial input, use the following:

To change trigger active duration: TRG_D [integer for milliseconds]
To change gain factor: GAIN_F [integer for gain state - see note*]
To change sensor input pullup vRef high threshold: VADJH [float value]
To change sensor input pullup vRef low threshold: VADJL [float value]
To change comparator trigger high threshold: VCOMPH [float value]
To change comparator trigger high threshold: VCOMPL [float value]

These commands should be wrapped in this format: <CMD, INT, FLOAT>

You must include the unused variable for each instance.

Examples: <GAIN_F, 3, 0.00> <VADJH, 0, 2.35>

*Note for Gain Factor:

The gain STATE is representative of these values:

0 = 3x
1 = 3.5x
2 = 4.33x
3 = 6x
4 = 11x

klipper-gitissuebot commented 5 years ago

Hi @pyr0ball,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

KevinOConnor commented 5 years ago

Interesting. However, I'm not sure what you're requesting or reporting.

-Kevin

pyr0ball commented 5 years ago

@KevinOConnor

Well I've designed this sensor to be able to accept new auto-tuning parameters from the 3d-printer's controller, and that requires the firmware for the controller (klipper in this case) needs to know how to communicate with this sensor. I've got a couple of devs on my beta team who might be able to assist me with a PR to get it rolling, but I wanted to open the issue for tracking purposes, and to see if anyone else wanted to assist in integration

FHeilmann commented 5 years ago

Unless you're willing to provide someone with the hardware, I don't think a lot of people will sit down and blindly try to implement something they don't know or own, just my 2c.

pyr0ball commented 5 years ago

I'm absolutely willing to do that. I've got about 20 people signed up for beta hardware testing right now. There's a link to the discord channel on the github page, if you'd like to be part of it. Just post in #beta-signup channel

KevinOConnor commented 5 years ago

Well, Klipper isn't really setup to send commands via UART right now. It's certainly possible to that (as Klipper does for SPI and I2C), but that will require enhancing the micro-controller code on all interested architectures. In contrast, for sending i2c commands, it mostly involves a new python "extras" module to generate the command to be relayed (see the Klipper developer docs for details).

I'm not sure what your target hardware is, but if you are using a micro-controller in the device itself, you may wish to consider running the Klipper micro-controller code directly on the device. That may simplify the wiring and control for users.

-Kevin

pyr0ball commented 5 years ago

the current revision is using an Atmega328PB, but I'll be migrating to ATSAMD21 ARM eventually. as far as running klipper microcontroller code, I'd be concerned about making it compatible with other firmwares, as right now, it should (theoretically) work with anything.

UART isn't a must, as I didn't want to tie up the main MCU's UART connections if avoidable, which is why I planned to have it accept I2C. Having UART input as an option just leaves that door open for developers or users to interface more directly with it

pyr0ball commented 5 years ago

I should also reiterate that the sensor works without input from the main controller, as it simply sends an active-low signal like any endstop. The I2C input allows the controller to adjust sensitivity parameters programmatically.

I'd be happy to send a Beta unit to anyone willing to help with integration.

KevinOConnor commented 5 years ago

Okay. FWIW, I don't think I'll get time to evaluate the hardware, so I'm not a good candidate. Let us know what your results are.

-Kevin

KevinOConnor commented 5 years ago

I'm going to close this ticket as it looks like the conversation has concluded.

-Kevin

pyr0ball commented 5 years ago

I disagree about it being concluded. I'm just busy with a release for my real job and haven't had a chance to make any progress on this project for about a month. I'll be jumping back into it in the next couple of weeks.

Also if there is any particular format of input that would make integrating this sensor easier, I'd like to get that feedback now so I can take that into account during the beta.

If you'd rather I wait to reopen this till I'm closer to finalizing, that's ok too

On Sat, May 25, 2019, 7:21 AM KevinOConnor notifications@github.com wrote:

Closed #1547 https://github.com/KevinOConnor/klipper/issues/1547.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/1547?email_source=notifications&email_token=ACAW75KHMXMSBEXW6ZIYRHLPXFDOLA5CNFSM4HF3UNR2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGORUNRO5I#event-2367362933, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAW75I6G2MACHQCJITELU3PXFDOLANCNFSM4HF3UNRQ .

KevinOConnor commented 5 years ago

Thanks for the feedback.

It's difficult to manage an issue list - I want to try to keep the "open" items manageable as I find there is no value in an "open" state once an issue list contains hundreds of "open" items. Yet I don't want to dismiss active work, and I certainly don't want to imply a potential contribution isn't of value.

For this issue my observation was that it isn't actively "pending" right now. I'm happy to re-open it when there are additional questions, observations, or results.

Cheers, -Kevin

pyr0ball commented 5 years ago

That's perfectly reasonable, I'll reply again once I've gotten more progress finish ed

CorvetteCole commented 5 years ago

I am willing to implement this in Klipper if I can get a test board to work with @pyr0ball

pyr0ball commented 4 years ago

@KevinOConnor Necro-ing this issue because the sensor is now ready!

I can get in touch with you over this or discord to work out sending you a couple of units to play with.

They're configurable over I2C so you could even potentially use the I2C onboard the Pi and skip integrating with the motion firmware altogether

Klipper3d / klipper