Using onboard Accelerometer as Z Probe

[Dakota]

Couldn't quite find a discussion that dived into this topic, but I also did not spend half an hour trying to find it. I Was setting up an accelerometer to figure out my input shaping setting and I found this comment under limitations (linked picture in post), "use of an accelerometer as Z probe is not currently supported". I assume most people looking through this documentation page probably missed that, but I noticed it big time because I would love to see that become a thing. I'm not sure if @dc42 would be able to confirm any development of such a feature, but I do believe it is important for when multi axis printing becomes prominent in the community. To be able to utilize the accelerometer on the tool board for probing the bed will get rid of low hanging Z probes that inhibit true 3D-Printing to take place. The printer I have in mind is a V-core from RatRig, but I see Vorons, Hextrudorts, and Delta's being able to use this.

[T3P3Tony]

@Dakota it was tried years ago by SeeMeCNC on their delta effector. From memory they then switched to the smart Effector style strain sensor due to issues with the accelerometer based sensing.

[oliof]

I know the people that tried this with ADXL and Klipper and the knock sensing results of the accelerometer did not have enough repeatability to serve as a Z probe. It's about as bad as trying sensorless Z homing with stall detection.

Also to avoid possible damage to the bed, dive speed is severely limited, which reduces the utility compared to modern probes.

[Dakota]

Thanks @T3P3Tony and @oliof, that does make sense as I wondered how repeatable the measurement could be. The use of a strain gauge in replacement of the accelerometer I like, but is there anyway to utilize the signal of the strain gauge in RRF and tune it for such a purpose? I would guess if others have used it on a delta effector then there must be some success with getting it working.

[T3P3Tony]

@Dakota have you seen the smart Effector? It's built in PCB stain elements and the signal processing.

[Dakota]

@T3P3Tony I knew of its existence for delta's but never really looked into its capability since I've not worked with a delta. Looking over the documentation and M672 programing code, I do wonder if there are open source strain gauges that could use the framework developed for the smart effector. A lot of the machines I work with and/or build are standard cartesian and core xy printers, so sadly I don't think id be able to slap a smart effector on there and start using it lol. I'd be more interested in some how hooking up a strain gauge to a gpio pin on the duet tool board if possible.

[dc42]

@Dakota I'm not convinced that the accelerometer couldn't be used. For the Smart Effector we recommend a probing speed of 20mm/sec. The trigger height comes out as about -0.1mm so the response time of the probe is about 5ms from when the nozzle just starts to contact the bed. Of course the effector and belts of a delta are compliant enough that diving the nozzle 0.1mm into the bed doesn't damage it. So if we can have the accelerometer detect and report the reduction in acceleration in just a few milliseconds, and the hot end mounting is compliant enough to allow the nozzle to dive into the bed 0.1mm without causing damage, then I think it's viable.

I'll take a look at the datasheets and see how fast the knock sensor is supposed to be. Or we might be able to poll the accelerometer Z acceleration fast enough anyway, especially when the accelerometer is on a tool board which isn't having to perform any motion at the same time.

Doing this would be more difficult in Klipper because the Pi isn't running an RTOS, so the latency of responding to the accelerometer will almost certainly be greater, and the command to stop motion has to be sent to the driver board over USB - which introduces another latency.

[oliof]

@dc42 default timeout for host to MCU communication loop in Klipper is 25msec, which indeed is a lot.

[Dakota]

@oliof @dc42 I agree for klipper it does sound like such a feature would be slower. Though now that I am thinking about it, I believe the series of Bambu printers do use accelerometer data for nozzle probing of the bed. And they are klipper based firmware, so I imagine if they were able to make it work with a higher latency then hopefully the accelerometer on the DTB could perform the same task if not better? I won't pretend to know exactly as my expertise is in mechanical design engineering, not software.

[oliof]

@Dakota Bambu uses piezo under bed sensors.