[FR] Use accelerometer as Z probe

[Apsu]

Now that Input Shaper and ADXL support has been given heavy attention for the past 6 months or so, it seems like it wouldn't be too difficult to mount the accelerometer to a toolhead and use it for Z probing.

There's been some work on this in the past, from SeeMeCNC and Nicholas Seward. I realize that some piezo approaches exist, but if we could get support added for using the accelerometer as a Z-probe (even in just a test branch), we could spend some time exploring how viable tuning can be for probe repeatability and accuracy.

If it can be done well enough, then you can use it for Input Shaping, probing, and that gives a starting point for doing tilt measurements as well (flying gantry, or 4/5 axis toolhead tramming, or even a second accelerometer on the bed, etc).

[Apsu]

SeeMeCNC is still selling their accelerometer probe toolhead, FWIW: https://www.seemecnc.com/products/he280-hotend-with-accelerometer-probe

[klipper-gitissuebot]

Hi @Apsu,

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.

[dmbutyugin]

Hmm, interesting! In principle, it is not completely out of question: adxl345 supports tap detection, which can be used for this purpose. In this case, ADXL345 must be connected to the MCU board of the printer, and that MCU must have SPI support (to be more precise, to the board that controls Z axis/es). And an additional wire is needed that would go to the Z endstop pin (though this is not a problem really).

What I'm concerned a bit is if it can really reasonably detect the 'homing' event. From its specs, the minimum tap acceleration it can detect is ~600 mm/s^2. I'm not sure what is the order of magnitude of acceleration the toolhead experiences if it hits the print bed with the nozzle, for instance. And unlike other types of sensors (mechanical, optical, piezo, servo bl touch), setting the incorrect scale may have a catastrophic failure mode: the nozzle will crash into the bed without being detected and the printer will keep pushing the nozzle, which can damage the bed, the toolhead, and other parts of the printer. Like, piezo sensor or mechanical endstop will eventually detect the crash even if they are offset, but accelerometer won't, if the scale of a tap is off.

On the positive side, it can be a really useful probing sensor if proves to work well. It can be used for homing and bed meshing. Like, Smart Effector has a piezo sensor and it probes with the hotend nozzle itself, and it probes the surface of the bed, so there are no issues with sensor offset or sensor sensing the metal under the glass/etc. However, Smart Effector only works for delta printers.

[Apsu]

Hmm, interesting! In principle, it is not completely out of question: adxl345 supports tap detection, which can be used for this purpose. In this case, ADXL345 must be connected to the MCU board of the printer, and that MCU must have SPI support (to be more precise, to the board that controls Z axis/es). And an additional wire is needed that would go to the Z endstop pin (though this is not a problem really).

What I'm concerned a bit is if it can really reasonably detect the 'homing' event. From its specs, the minimum tap acceleration it can detect is ~600 mm/s^2. I'm not sure what is the order of magnitude of acceleration the toolhead experiences if it hits the print bed with the nozzle, for instance.

Yeah, I considered this functionality and it's interesting, but I was actually thinking that you could just use the existing code added for input shaping to query the sensor value data stream on the SBC side instead of MCU, allowing you to do analysis the ADXL doesn't have baked in already.

For example, if you know the homing speed being requested, you can likely use that in conjunction with an impulse equation (Force * dTime = mass * dVelocity) to set an expected range of acceleration spike, then configure a threshold based on it.

And unlike other types of sensors (mechanical, optical, piezo, servo bl touch), setting the incorrect scale may have a catastrophic failure mode: the nozzle will crash into the bed without being detected and the printer will keep pushing the nozzle, which can damage the bed, the toolhead, and other parts of the printer. Like, piezo sensor or mechanical endstop will eventually detect the crash even if they are offset, but accelerometer won't, if the scale of a tap is off.

This is certainly true that misconfiguration can cause a failure that leads to damaging parts, but I disagree it's different than other sensors. It's possible to misconfigure, miswire, or mount incorrectly pretty much all those other types, leading to potential damage.

On the positive side, it can be a really useful probing sensor if proves to work well. It can be used for homing and bed meshing. Like, Smart Effector has a piezo sensor and it probes with the hotend nozzle itself, and it probes the surface of the bed, so there are no issues with sensor offset or sensor sensing the metal under the glass/etc. However, Smart Effector only works for delta printers.

Yes indeed, I agree strongly, and since I am personally working towards a simultaneous parallel 5-axis design, I would already like to make use of tilt/orientation detection of accelerometers to tram the toolhead vs the bed, and this seems like a good first step in that direction. More general purpose functionality out of accelerometers the better!

[dmbutyugin]

Yeah, I considered this functionality and it's interesting, but I was actually thinking that you could just use the existing code added for input shaping to query the sensor value data stream on the SBC side instead of MCU, allowing you to do analysis the ADXL doesn't have baked in already.

I'm not sure I fully understand the proposal. But at any rate, homing endstop must be connected to the MCU that controls the respective stepper; this is by the current Klipper design and may not be very feasible to change. Also, querying accelerometer data and processing it would have higher latency (probably?).

For example, if you know the homing speed being requested, you can likely use that in conjunction with an impulse equation (Force * dTime = mass * dVelocity) to set an expected range of acceleration spike, then configure a threshold based on it.

That would define the lower limit for the detection threshold. But we are interested in detecting toolhead hitting the bed (deceleration), and in that case neither dTime nor dVelocity is not really known.

And unlike other types of sensors (mechanical, optical, piezo, servo bl touch), setting the incorrect scale may have a catastrophic failure mode: the nozzle will crash into the bed without being detected and the printer will keep pushing the nozzle, which can damage the bed, the toolhead, and other parts of the printer. Like, piezo sensor or mechanical endstop will eventually detect the crash even if they are offset, but accelerometer won't, if the scale of a tap is off.

This is certainly true that misconfiguration can cause a failure that leads to damaging parts, but I disagree it's different than other sensors. It's possible to misconfigure, miswire, or mount incorrectly pretty much all those other types, leading to potential damage.

In principle, yes, but due care can minimize the chances of things going wrong. Like, misconfigured piezo will still detect the nozzle hitting the bed, just a bit later (but before any damage is caused). For the mechanical switch, one can test when (and if) it triggers by manually moving Z axis with the motors turned off. With the accelerometer, safe testing process needs yet to be defined. It is similar to sensorless homing with the difference that the latter is usually done only on X and Y axes, and there failure to detect homing event would typically cause less damage.

Yes indeed, I agree strongly, and since I am personally working towards a simultaneous parallel 5-axis design, I would already like to make use of tilt/orientation detection of accelerometers to tram the toolhead vs the bed, and this seems like a good first step in that direction. More general purpose functionality out of accelerometers the better!

If the accelerometer can work as a Z 'probe', then all the related functionality should become available.

[Apsu]

Fair point about the endstop requirement. I wasn't certain that was the case.

My thinking on the impulse equation was that we know dVelocity will be homing speed, since we're going from homing to stopped. That leaves dTime, and it's not easy to derive analytically, but on this point and your other points about likelihood of risks, I suspect there's a way to empirically calibrate it in a safe way.

For example, using Zmax comes to mind. Starting off with a relatively 'safe' speed, and move towards Z+ until you get a spike above bare minimum. Measure the spike duration, repeat, derive threshold and window duration from it, reverse for Zmin to probe bed.

I'm sure there's other clever ideas too, but I can see this as a safer way to calibrate, much like sensorless homing as you mentioned.

[Apsu]

Looking through the data sheet the tap detection seems really good, actually. It's relatively granular to set the threshold and window/duration, and you can even restrict the axes to detect in. Finding lots of example Arduino builds using values as high as 2-3G for threshold with 20-50ms windows and it's easy to detect taps with fingers. This seems viable, as long as a safe calibration method can be derived.

[dmbutyugin]

@Apsu, OK, so I've put together a branch which adds Z probe functionality to ADXL345. Use it at your own risk. Similarly to sensorless homing, ADXL345 may fail to trigger if the sensitivity is set too low, and Z axis motor(s) are typically powerful enough (due to high reduction ratio) to cause some damage to the printer if they don't stop at the right time. I also suspect that if a noisy stepper driver is used for Z axis (and not TMC stepper driver or other reasonably silent drivers), it is possible that you may not be able to get stable result with it.

Now here are my thoughts about how to try to experiment with it.

First, ADXL345 must be connected to the printer MCU (the one controlling Z axis motors if there are many MCUs), and either int1 or int2 pin must be wired to some pin on the MCU that can work as an endstop pin (theoretically, only int1/2 pin must be connected to the printer MCU, however that has some chance of working only if the same power source is used for both printer and the RPi, and given the associated dangers of doing something wrong, e.g. if buck converter for RPi is connected inappropriately, I wouldn't recommend it). I recommend to keep Z endstop connected for initial experiments; so only connect ADXL345 in a 'probe' mode.

Then, the initial configuration must be set, e.g.

[adxl345 hotend]
cs_pin: ...
spi_bus: ...
axes_map: ...
probe_pin: ...
int_pin: int1  # or int2
tap_thresh: 5000
tap_dur: 0.01
speed: 20
z_offset: -0.2
# If the probe triggers prematurely, this should allow to
# detect this and run a few attempts to get good measurements
samples: 5
sample_retract_dist: 5.0
samples_result: median
samples_tolerance: 0.05
samples_tolerance_retries: 3

[stepper_z]
position_min: -0.5  # must allow hotend nozzle to 'hit' bed everywhere
homing_speed: 20
second_homing_speed: 20

[printer]
max_z_velocity: 25

Do not forget to increase the maximum z velocity, and also increase the z homing speed (at least, for now).

First of all, in [adxl345] the parameter axes_map must be set correctly (this is used to subtract G acceleration). Once its set, restart the printer and issue a command ACCELEROMETER_QUERY CHIP=hotend (if adxl345 has no name, juts ACCELEROMETER_QUERY command should be used). It should return some small values, e.g.

Send: ACCELEROMETER_QUERY CHIP=hotend
Recv: // adxl345 values (x, y, z): 627.625600, -0.000000, -235.359600

If it returns 2 big values (in the order of 7000-12000), or 1 very big number (15000-25000), it means that axes_map is not configured correctly; correct it before proceeding further.

Next, we need to figure the right tap_thresh value. Home the printer, move the toolhead to a place where Z homing using the normal Z endstop can be done (e.g. at X=0,Y=0), Z must be 5-10 mm, and then run the following commands:

ACCELEROMETER_MEASURE CHIP=hotend
G28 Z
ACCELEROMETER_MEASURE CHIP=hotend

Wait for homing to complete before running the second ACCELEROMETER_MEASURE... command. This will write the raw accelerometer measurements during homing. You can plot them on RPi using the command (copy the CSV file name from the output of ACCELEROMETER_MEASURE command)

~/klippy-env/bin/python ~/klipper/scripts/graph_accelerometer.py /tmp/adxl345-2021...csv -r -o /tmp/homing.png

It will look like this (approximately):

So the accelerometer happily picks up the various noises, for example from stepper driver (I'm using TMC2208 on Z axis in spreadcycle mode). The tap_tresh must be above that noise with some safety margin. For example, I ended up using tap_thresh=6500 on my printer. Note that tap_thresh value does not need to be very precise - it is anyway heavily rounded for ADXL sensor. BTW, one can also see a homing event on the chart where a spike is (when the printer abruptly stops Z axis when Z endstop is triggered). Restart the printer once the good tap_thresh value is set.

Now we can test if the wiring of the probe endstop works. Fortunately, ADXL345 can work as a probe and measure acceleration data simultaneously. Move the toolhead a bit above the bed, maybe 5-10 cm. Run the following commands:

QUERY_PROBE ; should report 'open'
SET_ADXL345 CHIP=hotend REG=0x2E VAL=0x40
ACCELEROMETER_MEASURE CHIP=hotend
QUERY_PROBE ; should still report 'open'

Now hit the hotend nozzle with your finger (e.g. nail) or some small metal tool. Run QUERY_PROBE command again. Now it should report TRIGGERED. If not, try hitting harder. If it still doesn't work, the wiring (or pin configuration) may be wrong. To finish with this, run ACCELEROMETER_MEASURE CHIP=hotend again, this will write the acceleration data from your attempt. You can plot it with graph_accelerometer.py to see the amplitude of acceleration the adxl345 experienced when you hit the nozzle (though in real probing the amplitude may be different).

Then, we need to figure the right probe speed parameter. This one is admittedly tricky. My thoughts are as follows. In my measurements (on Ender 3 pro with a DD extruder and a glass bed) it seems that when the nozzle hits the bed, the 'hit' event takes ~1-2 msec to occur:

Note that this is also indicative that the default tap_dur: 0.01 is good enough guess for most cases.

In general velocity = accel * dt. For accel amplitude, we want it to be at least 2 * tap_thresh. So for example if tap_thresh = 6500, velocity = 6500 * 2 * 0.001 = 13 or 6500 * 2 * 0.002 = 26. So, in this case I'd say the probing speed should be roughly in the range of 15-25 mm/sec.

For testing, I suggest to start with higher value and reduce it if proves to be safe. Make sure that max_z_velocity is sufficiently high, move the toolhead to the location where probing can be done and then run the following commands:

ACCELEROMETER_MEASURE CHIP=hotend
PROBE_ACCURACY PROBE_SPEED=25
ACCELEROMETER_MEASURE CHIP=hotend

If probe is triggered and everything goes well, the results can be plotted using the same command (with the right filename):

~/klippy-env/bin/python ~/klipper/scripts/graph_accelerometer.py /tmp/adxl345-2021...csv -r -o /tmp/probing.png

For example:

If the acceleration of the 'taps' is high enough, then maybe PROBE_SPEED can be reduced. I still think that it should be at least 15 mm/sec, but YMMV. If the acceleration is insufficient, the velocity should be increased instead. The final value can be stored in [adxl345] section as speed parameter. Then homing speeds can be returned to normal.

However, if you really want to use ADXL345 as Z endstop too, you can do so by setting

[stepper_z]
endstop_pin: probe:z_virtual_endstop
position_min: -0.5  # must allow hotend nozzle to 'hit' bed everywhere
# both speeds must be equal to `speed` in `[probe]` section
homing_speed: 20
second_homing_speed: 20

and define the section

[safe_z_home]
home_xy_position: 100,100 # Change coordinates to the center of your print bed
speed: 50
z_hop: 10                 # Move up 10mm
z_hop_speed: 5

You will also need to configure the Z offset of the probe.

My experience. I ended up using probing speed 16 mm/sec and tap_thresh = 6500 mm/sec^2. I tested it on Ender 3 Pro with a DD extruder only with a glass bed, not the steel PEI sheet, for instance. I suspect that if the bed cover is too soft, it may work poorly for this purpose. Also I would suggest to clean up the nozzle from the remaining strings of filament if anything is left from printing. The probe accuracy I usually achieve:

Send: PROBE_ACCURACY
Recv: // PROBE_ACCURACY at X:100.000 Y:100.000 Z:20.000 (samples=10 retract=5.000 speed=15.0 lift_speed=15.0)
Recv: // probe at 100.000,100.000 is z=-0.313750
Recv: // probe at 100.000,100.000 is z=-0.320000
Recv: // probe at 100.000,100.000 is z=-0.315625
Recv: // probe at 100.000,100.000 is z=-0.313750
Recv: // probe at 100.000,100.000 is z=-0.313125
Recv: // probe at 100.000,100.000 is z=-0.312500
Recv: // probe at 100.000,100.000 is z=-0.309375
Recv: // probe at 100.000,100.000 is z=-0.311250
Recv: // probe at 100.000,100.000 is z=-0.310000
Recv: // probe at 100.000,100.000 is z=-0.309375
Recv: // probe accuracy results: maximum -0.309375, minimum -0.320000, range 0.010625, average -0.312875, median -0.312813, standard deviation 0.003090

@Arksine, in your experience, how good or bad such a probe is? I was also able to build a bed mesh with this 'probe', not sure if it makes sense though

#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  -0.148750, -0.087500, -0.108125, -0.090625, -0.183125, -0.228750
#*# 	  -0.143750, -0.078125, -0.109375, -0.099375, -0.195625, -0.251875
#*# 	  -0.166250, -0.098125, -0.122500, -0.110625, -0.196875, -0.243125
#*# 	  -0.150625, -0.083750, -0.113750, -0.100625, -0.188750, -0.236250
#*# 	  -0.156250, -0.098125, -0.127500, -0.117500, -0.211875, -0.265000
#*# tension = 0.2
#*# min_x = 20.0
#*# algo = lagrange
#*# y_count = 5
#*# mesh_y_pps = 2
#*# min_y = 50.0
#*# x_count = 6
#*# max_y = 200.0
#*# mesh_x_pps = 2
#*# max_x = 200.0

[Apsu]

Wow, this is phenomenal work! I didn't expect you to get so far so fast. Your final probing graphs and repeatability measurements seem to show extremely consistent results, that's very promising!

I will definitely check out the branch and test it as soon as I can. I look forward to seeing input from others who I know are interested in this, as I'm sure we can streamline the calibration process a bit and most likely improve safety with enough clever folks looking at it.

Thanks for all your work so far, this is awesome.

[dmbutyugin]

Wow, this is phenomenal work! I didn't expect you to get so far so fast. Your final probing graphs and repeatability measurements seem to show extremely consistent results, that's very promising!

Note that across probing the bed, the amplitude of peaks did vary quite a bit (sometimes they are below 10K mm/sec^2, so that threshold 6500 mm/sec^2 is pretty tight at 16 mm/sec probing speed). Repeatability is usually that though (within 0.01 mm) if the sensor triggers at the right time. So if the Z axis doesn't move evenly, it may trigger prematurely. For example, I figured that my lead screw was a bit misaligned and was causing some uneven movement and sensor triggering :) After I aligned it it works more reliable. Also in initial experiments when I set insufficient sensitivity the printer bent the X carriage slightly, so it had a bit of play on X profile.

[Apsu]

Note that across probing the bed, the amplitude of peaks did vary quite a bit (sometimes they are below 10K mm/sec^2, so that threshold 6500 mm/sec^2 is pretty tight at 16 mm/sec probing speed). Repeatability is usually that though (within 0.01 mm) if the sensor triggers at the right time. So if the Z axis doesn't move evenly, it may trigger prematurely. For example, I figured that my lead screw was a bit misaligned and was causing some uneven movement and sensor triggering :) After I aligned it it works more reliable. Also in initial experiments when I set insufficient sensitivity the printer bent the X carriage slightly, so it had a bit of play on X profile.

That's an interesting point all on its own. In theory this gives some insight into gantry dynamics and rigidity, by graphing accelerometer measurements from the toolhead during various moves, such that problems that might be hard to see like you had can be discovered.

[Arksine]

This is nice! The range looks good for the PROBE_ACCURACY command. It depends on the Z step distance but a range of .01 is generally acceptable. With regard to the mesh, the deviation across the mesh looks normal for a bed at room temperature. What doesn't look normal is the entire mesh is offset in the negative direction. If you are homing at (100, 100), the Z value in the mesh should be near zero at that location. Looking at the profile, the closet value to (100,100) in the mesh is Z=-.1225.

What this suggests to me is that the probe might be triggering lower during the mesh calibration than it did during the homing operation. Could it be due to a change in probing speed?

[dmbutyugin]

The bed mesh was built at room temperature, and I used the normal Z endstop for homing, with its own offset set by a paper sheet method (before all these adxl345 tests happened). I did a paper probe calibration at 100,100 I believe though. I didn't use adxl345 for homing much (I just tested that it works in principle). So the bed mesh being offset in general is possible, I guess, due to some misalignment between different offsets (which I don't claim I got right from the first attempt).

[Arksine]

Ah, that explains it. If you homed using an endstop then its just a difference in the z_offset. In that situation you can use the relative_reference_index option in [bed_mesh] to have it override the z_offset.

[AlmightyFrog]

@dmbutyugin first of all thank you very much for (maybe) making my secret wish come true to be able to use homing and probing with ADXL.
By the way I did test around lately much with piezos and let me tell you: to get perfect trigger condition is at least printers where Z Axis moves during homing can be a nightmare.
I did many times crash nozzle into the bed, so the fail safe argument you pointed out before for other methods than ADXL seem to be not too strong for me.

First, ADXL345 must be connected to the printer MCU (the one controlling Z axis motors if there are many MCUs), and either int1 or int2 pin must be wired to some pin on the MCU that can work as an endstop pin (theoretically, only int1/2 pin must be connected to the printer MCU, however that has some chance of working only if the same power source is used for both printer and the RPi, and given the associated dangers of doing something wrong, e.g. if buck converter for RPi is connected inappropriately, I wouldn't recommend it). I recommend to keep Z endstop connected for initial experiments; so only connect ADXL345 in a 'probe' mode.

Q1: Ok, this means I could just use my current setup which uses ADXL at RPI for input shaper calibration and I just need to add the interrupt pin connection?

Q2: If i change the ADXL to MCU, can i still use it as before for input shaper calibration with all the graphs and so on? I am asking as I am playing around with different print head configurations and there it might make a difference if it is e.g. direct extrude with heavy motor, remote extruder or just bowden setup.

Q3: Is there any performance downside connecting ADXL to MCU insteat of RPI? I (mostly) use SKR 1.3 boards so they should be reasonably fast enough, but one printer still runs on RAMPS.

[Apsu]

@dmbutyugin Was just looking into how to wire this thing to an SKR 1.3, for example, and it's turning out to be quite difficult. The I2C pins are all repurposed for critical things, and one of the two SPI buses is the SD card. The other being for motor drivers, of course. You could hijack one of the slots if using UART drivers, but the pins are hidden if using all 5 drivers, and it's just a mess.

So looking at your statement:

theoretically, only int1/2 pin must be connected to the printer MCU, however that has some chance of working only if the same power source is used for both printer and the RPi, and given the associated dangers of doing something wrong, e.g. if buck converter for RPi is connected inappropriately, I wouldn't recommend it

This has me thinking that maybe the MCU agnostic way to do this is hook to the rPi the same as for Input Shaper, but use an optocoupler for the interrupt signal pin, to avoid mismatched power supply concerns. Something like

for a convenient breakout board with easy optoisolation could let you run everything on the pi.

Thoughts?

[dmbutyugin]

Optocoupler should certainly work, and it is an easy and safe way to attach the adxl int pin to the printer MCU (int1/2 pin as + and gnd pin as -).

Q1: Ok, this means I could just use my current setup which uses ADXL at RPI for input shaper calibration and I just need to add the interrupt pin connection?

If you figure galvanic isolation between the RPi and MCU, then yes (e.g. with an optocoupler).

Q2: If i change the ADXL to MCU, can i still use it as before for input shaper calibration with all the graphs and so on? I am asking as I am playing around with different print head configurations and there it might make a difference if it is e.g. direct extrude with heavy motor, remote extruder or just bowden setup.

Yes, if adxl345 is connected to the mcu, it can still be used for measuring resonances and such.

Q3: Is there any performance downside connecting ADXL to MCU insteat of RPI? I (mostly) use SKR 1.3 boards so they should be reasonably fast enough, but one printer still runs on RAMPS.

On some slow boards, maybe. I think SKR 1.3 should work just fine, not sure about RAMPS though.

[mental405]

If this pans out, it might be good for deltas as an alternative to FSR's

[AlmightyFrog]

I just want to point out, that error messages might be misleading.
It was complaining Error: Option 'int_pin' is not valid in section 'adxl345'
but for real i only missed to add probe_pin (besides removal of old deprecated probe section).

[AlmightyFrog]

Ok, I am some steps further, but now can't continue.

If I restart, QUERY_PROBE says open always.
Then when i execute step SET_ADXL345 CHIP=hotend REG=0x2E VAL=0x40 it directly shows triggered always.

Btw when it comes to pullup - what is the right setting: with or without?

Another strange finding is, that my numbers in initial measure tests are way off in comparison to @dmbutyugin shown values.
This is my noise floor without any movement:

Here you can see it when i move X, Y and Z (don't mind Z not showing up, it is so smooth that there is no spike as you can see from about 25s till end):

A graph of homing ( i always have forced X, Y, Z order where it lifts Z first to not crash nozzle into bed clips) seems fine:

BTW as my values are about factor 10 higher than yours, also query in stillstand varies a lot:

ACCELEROMETER_QUERY
// adxl345 values (x, y, z): -5256.364400, 3687.300400, -18279.595600
ok
ACCELEROMETER_QUERY
// adxl345 values (x, y, z): -941.438400, 2981.221600, -18122.689200
ok

[dmbutyugin]

I just want to point out, that error messages might be misleading.
It was complaining Error: Option 'int_pin' is not valid in section 'adxl345'
but for real i only missed to add probe_pin (besides removal of old deprecated probe section).

That's because the probe functionality (along with all additional parameters) is enabled only if probe_pin parameter is set. At least, that's how it is for now. I may change it in the future, but I'm not sure yet how to change that best.

So, are you sure you've set axes_map correctly? I think your z axis has the wrong sign (and so you get ~-18K (== 2 * 9800) instead of close to zero).

Then when i execute step SET_ADXL345 CHIP=hotend REG=0x2E VAL=0x40 it directly shows triggered always.

Wrong axes_map may also affect this behaviour.

Then, if your noise level is ~5-7K, you probably need to increase the threshold to 7-10K.

Btw when it comes to pullup - what is the right setting: with or without?

I think you don't need any pullup or pulldown, since accelerometer already pulls it down on low.

Here you can see it when i move X, Y and Z (don't mind Z not showing up, it is so smooth that there is no spike as you can see from about 25s till end):

In general, that's bad because it actually needs to be noticeable. Are you sure you have increased the homing speed (and the max speed for z axis)? Edit: or did you mean just the regular axes move? If the latter, it's fine. You just need to look at the homing graph.

[dmbutyugin]

If this pans out, it might be good for deltas as an alternative to FSR's

In principle, yes, though for delta printers there's also smart effector available. It works pretty well as the Z probe (assuming the default sensitivity is fine for the printer).

[AlmightyFrog]

So, are you sure you've set axes_map correctly? I think your z axis has the wrong sign (and so you get ~-18K (== 2 * 9800) instead of close to zero).
Pretty sure as it is basically same config I use for input shaper calibration. I have axes_map: z,y,x set in config.
Silkscreen is as following:

• X arrow on silkscreen points for real Z Axis downwards
• Y arrow on silkscreen points for real Y Axis in direction of min
• Z arrow on silkscreen points for real X Axis, but direction i can't tell

Then, if your noise level is ~5-7K, you probably need to increase the threshold to 7-10K.
Currently I use tap_thresh: 50000, I changed it to 10k and now it is always open.

BTW high noise on this ADXL might be as I have had a issue with capacitor on that specific pcb.

Just for completeness here a G28 run

Whereas at about 13s it was X axis home, about 15s it was Y axis home and about 23s it was Z axis home (endstop switch).
Please not that this is a CoreXY Printer so the behavior seemed fine for me, as probe is mounted on head and gantry did not move during z home. Of cause in the following picture for failed probe where nozzle crashes into bed I'd have expected something.

Here you can see it when i move X, Y and Z (don't mind Z not showing up, it is so smooth that there is no spike as you can see from about 25s till end):

In general, that's bad because it actually needs to be noticeable. Are you sure you have increased the homing speed (and the max speed for z axis)? Edit: or did you mean just the regular axes move? If the latter, it's fine. You just need to look at the homing graph.
The graph was only axis move but same is also at probing. Here you see the graph when nozzle crashes into bed:

I honestly can't tell you when exactly it was, but i guess about 10 seconds in or so.
Values in cfg are adxl345.speed = stepper_z.homing_speed = stepper_z.second_homing_speed = 20.
I did same with 40 and same results.

Might it be, that the ADXL is just "too tightly" mounted at the carriage that there is too less movement possible?

[dmbutyugin]

So, are you sure you've set axes_map correctly? I think your z axis has the wrong sign (and so you get ~-18K (== 2 * 9800) instead of close to zero).

Pretty sure as it is basically same config I use for input shaper calibration. I have axes_map: z,y,x set in config.

No, that's not good enough that the config is the same. Input shaper calibration doesn't care about the axes_map, it can be whatever and shaper calibration will still work just as well. In the main branch the axes_map is only for your own convenience (for charts), it doesn't serve any real purpose for the shaper calibration.

Then, sorry, I did not fully understand your explanation about chip orientation, but as a random guess, try to invert the sign for z printer axis as axes_map: z,y,-x and see if that helps.

BTW high noise on this ADXL might be as I have had a issue with capacitor on that specific pcb.

I'm not sure which capacitor your are talking about and how it would affect the measurements? Note that the adxl - board connection for accelerometer data is digital. Maybe the fans are noisy? Anyway, tap_threshold around 7000 could be a start.

Please not that this is a CoreXY Printer so the behavior seemed fine for me, as probe is mounted on head and gantry did not move during z home.

So, you have the bed moving in Z direction (and not, say, the XY portal)? I'm not sure what the best setup is in this case. I mean, should the accelerometer be mounted on the toolhead or on the bed. If you choose the toolhead,

Might it be, that the ADXL is just "too tightly" mounted at the carriage that there is too less movement possible?

then it should actually be mounted tightly, so that its movements follow the movements of the toolhead exactly (and hopefully it can pick any 'echo' from the hit). In my tests, the adxl345 triggers the interrupt even if I pinch the motionless hotend with my finger. So there's certainly some hope. Though the charts with crashing the bed don't show anything, which is strange and surprising. Is it possible that the file is wrong (from a different measurement)?

[AlmightyFrog]

I moved sensor to bed, changed axis accordingly and now have had at least two successful probe runs.
Tap threshold 12k is on the edge of working.
Sadly i have no trace of it:

PROBE_ACCURACY at X:200.000 Y:200.000 Z:12.648 (samples=10 retract=5.000 speed=25.0 lift_speed=40.0)
probe at 200.000,200.000 is z=-2.435000
probe at 200.000,200.000 is z=-2.437500
probe at 200.000,200.000 is z=-2.442500
probe at 200.000,200.000 is z=-2.437500
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.442500
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.445000
probe at 200.000,200.000 is z=-2.437500
probe at 200.000,200.000 is z=-2.437500
probe accuracy results: maximum -2.435000, minimum -2.445000, range 0.010000, average -2.439500, median -2.438750, standard deviation 0.002915

PROBE_ACCURACY at X:200.000 Y:200.000 Z:2.563 (samples=10 retract=5.000 speed=25.0 lift_speed=40.0)
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.440000
probe at 200.000,200.000 is z=-2.445000
probe at 200.000,200.000 is z=-2.442500
probe at 200.000,200.000 is z=-2.435000
probe at 200.000,200.000 is z=-2.442500
probe accuracy results: maximum -2.435000, minimum -2.445000, range 0.010000, average -2.440500, median -2.440000, standard deviation 0.002449

But before and after i had massive issues with triggering to early or not at all.

I'm not sure which capacitor your are talking about and how it would affect the measurements? Note that the adxl - board connection for accelerometer data is digital. Maybe the fans are noisy? Anyway, tap_threshold around 7000 could be a start.

It might not make sense to continue with the ADXL board i have here. Tantal capacitor which should smooth input voltage was soldered wrong way in and got burning hot. Now I use the board without it but that of cause should result in worse measurement accuracy. Of cause you read out signal digital, but in case the adc within the chip is not getting stable voltage it might cause measurement deviations.
This means for me i have to stop here, find another board or wait till another is shipped and then only i can continue.

If this pans out, it might be good for deltas as an alternative to FSR's

In principle, yes, though for delta printers there's also smart effector available. It works pretty well as the Z probe (assuming the default sensitivity is fine for the printer).

What would be the way you expect to best work on a delta. On the effector itself or on the (rigid mounted) bed?

[dmbutyugin]

I see, yes, if the voltage regulator is busted due to capacitor, then yes, I presume it can work incorrectly. You can also try the MEASURE_AXES_NOISE command, which in my case gives the following results:

Send: MEASURE_AXES_NOISE
Recv: // Axes noise for xy-axis accelerometer: 82.637596 (x), 133.620911 (y), 135.221446 (z)

But I imagine it will be much larger in your case. In that case, the sensor is faulty and needs to be replaced.

What would be the way you expect to best work on a delta. On the effector itself or on the (rigid mounted) bed?

It is generally a good question where to mount the accelerometer for probing. I think the effector is the best place to mount it for delta. And even in other kinematicsl it might make more sense to mount it on the hotend, even if the bed is moving for Z homing/probing instead. Otherwise, the probing amplitude of acceleration may depend on the probing point within the bed (and so it may be too low in the farthest corners of the bed), which would defeat the purpose. At least if the accelerometer is mounted on the hotend, the amplitude of the vibrations it experiences will be more consistent and predictable and much less depend on the probing location. Even though you had more success setting up the probe on the bed; but maybe your current probe is not very representative. Anyway, it would be very interesting to see other results and experiences; I think only the practice can tell.

[dmbutyugin]

BTW, I made the adxl345 to self-calibrate its freefall acceleration offset, so it will no longer depend on the correct axes_map parameter. And now other adxl345s (besides the one that is used as a probe) can be (again) connected on-demand. Also if the probe was disconnected and then reconnected, one can run ACCEL_PROBE_CALIBRATE to force the probing to be re-calibrated.

[AlmightyFrog]

BTW, I made the adxl345 to self-calibrate its freefall acceleration offset, so it will no longer depend on the correct axes_map parameter.

Interesting Idea. Didn't think it through, but maybe think of, whether you also want to have X and Y auto detection for resonance calibration. Trivial as you only need to G0 one axis to see what moved, and from my current point of view useless, but at least then you'd get the direction of acceleration if that is of any worth.

And now other adxl345s (besides the one that is used as a probe) can be (again) connected on-demand.

So I guess that is only for bed slingers relevant, as I got from texts before that otherwise best idea is to mount for common printers (like CoreXY/H-Bot and Delta) there you anyhow connect one for all axis to the hotend. Any other printer style I didn't think of? For documentation purposes i guess it is worth to point stuff like that out then.

I just found another ADXL board which seems to work fine, so I'll continue tests this weekend at least with the CoreXY, maybe a bed slinger also. My delta is physically too unstable to get any use of tests out there. So if anyone here has a delta, I'd be happy to hear about test results.

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

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

[ogland]

I'm totally stoked about this! Any progress?

[JiMcNulty]

@dmbutyugin Amazing work!
Would be really cool, too bad it didn't got more attention

I believe that It didn't work on PEI because like you said, its soft, but also the toolhead itself has some give, not so stiff and together they "absorb" the tap and round the graph

But this give can help!
Did you see any tilt readings (different axis)? it might be enough to combine them both

Also, is there a more sensitive accelerator that is small low power and relatively low cost? how is the LIS3DSH compared to the adxl345?
Or maybe combine it when an angle sensor?

[dmbutyugin]

@the-cobbler

ADXL345 does not have a tilt sensor. But I'm not sure if there would be any sufficient tilt to detect in the first place: I imagine it would be maybe a few degrees max. And LIS3DSH is unsupported by Klipper.

It is too bad that it didn't receive a lot of attention and user base. But I think that happens for a reason. After this attempt, I personally got BLTouch, and was happily using them ever since. I think the main troubles with adxl345 as a Z probe are:

1. Requires that the nozzle is clean from any remnants of the filament from the previous prints. Otherwise, that sticking filament will soften the impact and adxl345 won't trigger. TBH, that's the biggest blocker for me: I oftentimes forget to clean the nozzle; and it is generally a lot of bother.
2. "Z-Probe" failure mode: if it does not trigger, it does not trigger. Most (all?) other probes, even if they have repeatability issues, will trigger eventually (e.g. BLTouch, switch-based probes, piezo sensors, inductive and capacitive sensors probably), and then it is possible to just discard the wrong measurement. In this case, it does not trigger, and homing or bed meshing process stops with error; besides this can cause significant damage.
3. Noise-to-signal ratio: the spikes of acceleration are not very high vs the average noise level when the Z axis operates (and this is even with stealthChop on Z axis enabled, which might be a bad idea (New TMC docs: don't use hold_current; avoid interpolate #4977). Increasing probing speed increases acceleration spikes, but also increases the noise, so in general it is not helpful. This leads to occasional probing errors.
4. Apparently does not work for all surfaces. Maybe PEI sheet gives in, or maybe it's just that the glass has bigger mass, and so it resists the impact more, slowing the toolhead more abruptly.

But I understand that in some situations this probing sensor might be beneficial vs others (e.g. in some heated chambers). So, I will update my branch for further testing if others want to after (#4931), if that gives some good results.

[JiMcNulty]

@dmbutyugin Thanks for replying!
I understand, its not robust enough
But I do Like the concept, as I have toasty enclosure, bltouch does not hold up, inductive as well
Only the klicky give some comfort
But this solution will be much better, easier and lighter

Check out this sensor, it has an accel and a gyroscope that will detect the tilt, all we need is the 0.5 degrees detection

https://www.adafruit.com/product/1714
https://www.adafruit.com/product/4569 - built-in tap detection

This will give the full picture of what's happening
(It can also help with a lot of other problems like side crashing and a nozzle that touches the print because of wrap for example)
It may also really improve the input shaping calibration and technically can tell you what is the position of the nozzle at any given point, enabling you to detect missing steps or uncalibrated steps (not sure, need to understand the accuracy)

[Sineos]

https://github.com/adafruit/Adafruit_CircuitPython_ADXL34x/blob/main/examples/adxl34x_tap_detection_test.py
Standard ADXL345 seems to have a dedicated "tap detection" as well

[JiMcNulty]

https://github.com/adafruit/Adafruit_CircuitPython_ADXL34x/blob/main/examples/adxl34x_tap_detection_test.py Standard ADXL345 seems to have a dedicated "tap detection" as well

It does, but its about sensitivity and cross checking with another sensor (gyro) that increase the overall resolution
Anyway, its just suggestion :)

[dmbutyugin]

Yep, the current ADXL345-as-Z-probe implementation uses tap detection. The problem is indeed that during Z axis movements, there are lots of spiky noises that can be detected as tap events. It is the balance between too low and too high sensitivity that is hard to achieve. Perhaps there are sensors with more sophisticated tap event detection, but I don't know about them (and it is still unclear if that would help).

@the-cobbler I looked at the specs a bit, and the gyroscopes detect angular velocity (rotation) only, rather than the angular position. So, I'm still worried that the speed of tilting will be insufficient to detect a tap event from the operational noise. It would be a pity to spend considerable amount of time to program the communication protocol with such a device only to learn that it is useless.

[JiMcNulty]

Yep, the current ADXL345-as-Z-probe implementation uses tap detection. The problem is indeed that during Z axis movements, there are lots of spiky noises that can be detected as tap events. It is the balance between too low and too high sensitivity that is hard to achieve. Perhaps there are sensors with more sophisticated tap event detection, but I don't know about them (and it is still unclear if that would help).

@the-cobbler I looked at the specs a bit, and the gyroscopes detect angular velocity (rotation) only, rather than the angular position. So, I'm still worried that the speed of tilting will be insufficient to detect a tap event from the operational noise. It would be a pity to spend considerable amount of time to program the communication protocol with such a device only to learn that it is useless.

True.
I will try to find another sensor that will have our requirements.
Just another thought, it will be less cool but still cool:
We can put the accel with tap detection on the bed itself (with a mount, away from the heat) , that will reduce most if not all of the noise because the bed is not moving while descending

[ogland]

@the-cobbler my bed is moving while ascending for homing.

[JiMcNulty]

@the-cobbler my bed is moving while ascending for homing.

Sorry, only had the voron 2 in mind
In that case it wouldn't work, but the tilt detection will still work

@dmbutyugin I don't know if its already in klipper, and i'm surprised I didn't find any python packages for it, but you can get an angle from the adxl345 with less then 1 degree accuracy

The theory:
https://www.analog.com/en/app-notes/an-1057.html

Some old code that can help:
http://wizmoz.blogspot.com/2013/01/simple-accelerometer-data-conversion-to.html?_sm_au_=iVVrPJjs44Sjbntq

Another example:
https://wiki.dfrobot.com/How_to_Use_a_Three-Axis_Accelerometer_for_Tilt_Sensing

There is also a nice read here (there is also some angle calc code):
https://www.best-microcontroller-projects.com/adxl345.html

It says something that I think not everyone is aware of, because I saw people mounting the sensor in different positions.
He basically says that the way the adxl345 is positioned can affect its measurements accuracy

Why not ±90°?
Why can't the ADXL345 accelerometer indicate ±90°?

If you run the program below you will see that the accelerometer is extremely good at indicating tilt at low angles (on a flat surface) to about 70°, but does not reach ±90°. In fact it can't seem to reach that magic number ±90°!
At first, I thought there was something wrong with the accelerometer since no one seems to talk about this. Why should it not be possible to measure all angles?

If you think about holding a piece of wood - the maximum force on it is when you hold it horizontally. The more you point it upwards, to the vertical position, the less gravity can affect it, hence - the accelerometer becomes less sensitive.

So it turns out that the sensitivity of the accelerometer decreases with increasing angle and follows a near sinusoidal response, and accuracy decreases the closer you get to ±90° of tilt.

"The sensor is a polysilicon surface-micromachined structure built on top of a silicon wafer. Polysilicon springs suspend the structure over the surface of the wafer and provide a resistance against forces due to applied acceleration." [datasheet]
You can imagine the sensor as a beam suspended on springs, with the capacitance between the beam and the support base giving the acceleration measurement. When the beam is perpendicular to the acceleration field small tilt changes will have a large effect as gravity acts over a larger area.

As the beam tilts vertically, the sensor becomes less sensitive (interacting with the gravity vector less) until, at full vertical orientation, it can not return a reading since the gravity vector has no effect on the beam.

What do you think? is there hope?

[dewi-ny-je]

@dmbutyugin

Yep, the current ADXL345-as-Z-probe implementation uses tap detection. The problem is indeed that during Z axis movements, there are lots of spiky noises that can be detected as tap events. It is the balance between too low and too high sensitivity that is hard to achieve. Perhaps there are sensors with more sophisticated tap event detection, but I don't know about them (and it is still unclear if that would help).

You could integrate the readings and stop when the offset between expected position and actual position crosses a threshold.
It makes the process much more resistant to noise.

Use the initial "constant speed" motion as baseline and detect the offset compared to that. No need of absolute calibration.

Any bed or gantry has enough give to tolerate such a solution based on offsets.

[jakep82]

I personally don't think this is a good candidate for mainline Klipper based on what has been discussed. It's unfair to the devs, mods, helpers, and users to merge a feature that is difficult to make work reliably and has the potential to damage printers. It creates a huge maintenance burden, and inevitably someone will damage a printer and blame Klipper.

[JiMcNulty]

I personally don't think this is a good candidate for mainline Klipper based on what has been discussed. It's unfair to the devs, mods, helpers, and users to merge a feature that is difficult to make work reliably and has the potential to damage printers. It creates a huge maintenance burden, and inevitably someone will damage a printer and blame Klipper.

Lets just wait until there is a workable solution to determined that :)

[hamster65]

I tried a piezzo once. Despite all attempts with analog filters and microcontroller adc, it did not work as reliable as bltouch or other sensors. Either because filament at the tip of the nozzle was dampening the impact, vibration from the Z axis (bed) triggered it, or because the bus driver was late and shook the house.

[ReprapRyn]

Note that I wouldn't use piezos on any sort of printer where the bed moves. On my deltas they are amazing. The accelerometer probing system is similar. I have managed to make it work but it is very slow on probe and requires a graceful acceleration curve with no jerking. Also so sensitive a stomp or a loud noise will throw it off. A switchwire like coreXY might be able to do it as well but lead screw is just too jerky vs servo touch pin types. If it does merge up, should note it's only appropriate for delta type robots.

…

On Fri, Dec 3, 2021, 12:17 PM hamster65 ***@***.***> wrote: I tried a piezzo once. Despite all attempts with analog filters and microcontroller adc, it did not work as reliable as bltouch or other sensors. Either because filament at the tip of the nozzle was dampening the impact, vibration from the Z axis (bed) triggered it, or because the bus driver was late and shook the house. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3741 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALZK3JTVZTM6NPC4QBGA3TLUPECUFANCNFSM4V2V4B2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dmbutyugin]

I personally don't think this is a good candidate for mainline Klipper based on what has been discussed. It's unfair to the devs, mods, helpers, and users to merge a feature that is difficult to make work reliably and has the potential to damage printers. It creates a huge maintenance burden, and inevitably someone will damage a printer and blame Klipper.

Yeah, I agree with your concerns. I think in the current state it is too fiddly and unreliable.

We can put the accel with tap detection on the bed itself (with a mount, away from the heat) , that will reduce most if not all of the noise because the bed is not moving while descending

I have two accelerometers on my printer: one on the hotend, one on the bed (it is an Ender 3 Pro). I previously tried to get the data from the accelerometer on the bed too. It didn't look too promising though: there was still quite a bit of noise from the stepper motor that gets transmitted through the frame. And the acceleration spikes from when the nozzle hits the bed were smaller (presumably, because the bed is more massive, so when the hotend and bed collide, bed takes some impulse from the hotend, but ultimately the velocity gain is smaller). I didn't run excessive tests though, because back in the day, multi-mcu homing was not supported on Klipper (and the bed accelerometer is connected to the RPi). So, I cannot rule out the possibility that this way may work better.

@the-cobbler my bed is moving while ascending for homing.

In that case, attaching the accelerometer to the hotend potentially makes more sense, as the hotend is stationary during homing.

@dmbutyugin I don't know if its already in klipper, and i'm surprised I didn't find any python packages for it, but you can get an angle from the adxl345 with less then 1 degree accuracy

Though if your read the linked articles, this approach requires some integration and averaging over some period of time, and it also is less precise if the accelerometer is moving (so it works better for stationary objects). So, probably not a very good fit for homing.

I tried a piezzo once. Despite all attempts with analog filters and microcontroller adc, it did not work as reliable as bltouch or other sensors. Either because filament at the tip of the nozzle was dampening the impact, vibration from the Z axis (bed) triggered it, or because the bus driver was late and shook the house.

I have experience with SmartEffector. It worked pretty well and quite reliably. I suppose on other systems there is a question of mechanical integration of a piezo into the system - it is more difficult to make the hotend mount stiff and yet allow piezo to work. That being said,

If [adxl345 as a probe] does merge up, should note it's only appropriate for delta type robots.

I'm not sure if that's true. I haven't tried it on Delta, so maybe it is more reliable there. But I'd think it is more or less the same everywhere. In fact, on many Cartesian and some CoreXY kinematics you can install something like oldham coupling, which greatly reduces the damage (pretty much eliminates the risk of it) due to failed probe triggering. On a delta, that's not possible, and the amount of damage due to failed triggering can be even greater.

You could integrate the readings and stop when the offset between expected position and actual position crosses a threshold. It makes the process much more resistant to noise.

Use the initial "constant speed" motion as baseline and detect the offset compared to that. No need of absolute calibration.

Any bed or gantry has enough give to tolerate such a solution based on offsets.

That's definitely a promising idea and it might work. The only issue is that no sensor offers a feature like that out of the box. Tap detection that we tried here is supported natively by ADXL345: you simply configure it via registers, connect a pin as an endstop, and you are good to go. Integration will require a lot of work: it either needs to be done on the microcontroller (and will require a lot of additional work like decoding adxl345 data there), or on the main RPi board, but then adxl345 - RPi data transmission latency must be made very small. Also it will require fiddeling with the multi-mcu homing code. So, while this is, potentially, the most promising approach, I'm not sure I'll be able to get to it any time soon due to other projects.

[dewi-ny-je]

@dmbutyugin

That's definitely a promising idea and it might work. The only issue is that no sensor offers a feature like that out of the box. Tap detection that we tried here is supported natively by ADXL345: you simply configure it via registers, connect a pin as an endstop, and you are good to go. Integration will require a lot of work: it either needs to be done on the microcontroller (and will require a lot of additional work like decoding adxl345 data there), or on the main RPi board, but then adxl345 - RPi data transmission latency must be made very small. Also it will require fiddeling with the multi-mcu homing code. So, while this is, potentially, the most promising approach, I'm not sure I'll be able to get to it any time soon due to other projects.

MPU-6050 is an old accelerometer/gyro which has an integrated and programmable MCU which can integrate the analog readings and output a digital signal when conditions are met, or also simply the integrated values.
There are code examples online which already do that.

I am not suggesting to use this specific chip, just that some chips have all its needed to offload the critical part of the process which may render any other "pure" accelerometer unsuitable for the approach I suggested.

Of course it's always a matter of time available!

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

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

[ogland]

Ok so not sure if this has been discussed, but instead of using this as a Z-probe, could it be used for XY homing on corexy machines? As an option to sensorless homing which can be kind of unreliable and hard to tune.

[AlmightyFrog]

Long time i had no time to tinker around with my corexy but as i needed it now for some special prints i woke it up from long sleeping.
During update process of the RPI (very old installation) klipper and octoprint broke so i took that as a occasion to upgrade to latest klipper.
Would you mind @dmbutyugin to update your branch https://github.com/dmbutyugin/klipper/tree/adxl345-probe to latest version or at least V0.10 so we can use it with the new rotation_distance configuration?

If you want to wait for it till #4931 is merged that is also fine for me.

I just now had to level my bed fully manually as the old mesh does not match anymore and i did use back then one year ago or so successfully adxl z probing for it...

[piotrekmonko]

@dmbutyugin - I'd love to try this out too. Bumping AlmightyFrog's request for a rebase.

[bernhardberger]

+1 for a rebase from me.

I'd love to find an alternative nozzle probe that doesn't require a smart effector. The smart effector is nice but I'd love an alternative that makes it easier to install a direct drive extruder.. and Deltas are just much easier to use with a nozzle-probe without an offset.