What's new
VORON Design

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members!

Accelometer based bed probe?


Well-known member
Has anyone read about using ADXL345 as a bed probe?

When the printer head is not moving or more technically "not accelerating" the ADXL345 will read about 9.8 meters per second squared acceleration in the Z direction due to gravity. But let's say the nozzle moves down and crashes into the build plate. There would be a spike in the Z direction, well above 9.8

What if the "crash" were controlled and happened at low speed and the direction was revered as soon as the crash was detected? If the crash were soft enough it could be used for bed probing.

Advantage? (1) Many Voron toolheads already have ADXL345 chips permanently attached. CAN bus boards seem to include the chip. so the bed probe is free and already installed and wired, all that is needed is software. (2) The V0.2 printer has no easy way to attach a tap or click style probe and again the ADXL345 is far less complex as there would be no moving parts. (3) Accuracy could be as good as one micro step in Z direction.

Disadvantage? Maybe a "controlled crash" is too hard to program and the technique would break stuff and dent the build surface.

Does anyone know if this has been tried?
If you were able to implement that, you could use it for X/Y homing as well.
It would effectively be "sensored sensorless homing". 😁

2) The V0.2 printer has no easy way to attach a tap or click style probe
'Boop' is the unofficial mini-TAP for V0.2 toolheads.

But the reason why Boop isn't recommended for the V0, the cantilever bed, will likely also preclude the probing you're thinking of doing...
It all depends on how small of a tap the accelerometer and associated software can detect.

This idea is not new. I got the 3D printers because of robotics. A small dog-size quadruped has feet made from cutting a hard rubber ball in half (squash balls) and gluing them to the bottom of otherwise flat feet. One way to detect ground contact is with accelerometers (most designs use pressure sensors) in each foot. But it is unlikely a squash ball hitting the floor is destructive.

What is needed is some compliance. The V0.2 has springs under the bad and a plastic toolhead.

This could also be another way to do X and Y endstop. I bet the accelerometer would detect the X or Y crash before the motor drive detects a stall and raises an error pin.

I'm looking for ways to put the accelerometer to use. If it lives full-time on the CAN bus toolhead board, even if the use is redundant it's free. Could we measure toolhead velocity in X,Y by integrating acceleration in X,Y? Compare this to expected acceleration to diagnose a problem.

Can the accelerometer detect rough linear rails?
The bed needs to resist the motion of the crash. This is not sounding like a good idea for anything leadscrew driven, but a V2.4 or micron ...
Accelerometers are commonly used for precision tasks in smartphones, drones and controllers, for example. Certainly, it is a sensor type to be considered.

As mentioned above, the ADXL for probing the Z-axis is a great solution for a variety of reasons. Many people are either familiar with it or have one on their toolheads, and it can also be used for multiple other purposes, such as input shaper calibration, belt tension calibration, XY homing, crash sensor, etc.

[Link to the GitHub repository: https://github.com/jniebuhr/adxl345-probe]
ADXL has a safety feature built in, called "int," used to detect crashes. This project utilizes this feature, senses a spike, and makes the ADXL act like a switch.
I have been using ADXL to probe the Z-axis for almost a year. If I had to make a simple compliment, I would say it performs better than most probes available for our beloved machines.

However, due to a lack of development, there are some concerns:
(Please note, theses are only a few, and without serious electrical engineering and python understanding)
  1. No safety feature:
    The ADXL, using the INT feature, could be set in a few different ways. If there is an INT disconnect, nothing will prevent the Z-axis from crashing into the build plate and eventually causing damages. There are some simple solutions that could be implemented, but they are mostly inconvenient.
  2. Not easy to make it work:
    Settings vary a lot from one printer to another, and there is a lack of development to calibrate it even more.
    The repo owner is working on an auto-calibration feature.
  3. Very sensitive to noises:
    Initially, I had a lot of issues because of the cable. It is not recommended but required to have a suited cable with twisted wires, shield grounded. Also, the length of the cable matters.
    In one case, I had the INT connected to an end-stop PIN on the controller board. I found out that it is very unreliable on some boards. For example, if a fan or heater is on, it will affect the probing and result in inaccuracy or failures.

I hope more people pay attention to this topic, and eventually, some with enough determination will help flourish it to the point where it becomes standard on 3D printers.

Last edited:
It's a great idea, I know Sandman, above, did a lot of work on it that proved positive. I think it merits further investigation.
This seems like an interesting idea, and it would heavily get rid of the problem with tap being a rail on rail design. no resonances to worry about, etc. ideally this might shave some weight too if you could find a way to use the one attached to the can board already.
This is very usable.

to make nozzle crashes not damage tool-head/xrail:
I think while doing tap operations we should lower amperage on z; within a script; much like sensor-less homing;

also- perhaps we put deflection in mount system with 800grams break force to hit micro-step to detect adxl failures as backup?

you've proven that its viable;

I will experiment; We can thereby bypass tap for any printer with a chamber temp lower than 60-70c due to canbus/usb toolboard temp limits;
i print my abs effortlessly in 30-40c regardless; so its looking viable;

i also think can-bus is not ideal for this; (the protocol not the toolboard) i suggest direct USB mcu communication; as over-travel will likely occur even with 1mill baudrate; and whilst it'l calculate the offsets due to kipper being very good at that; i think untill 4mill baudrate is standard; its not ideal for direct nozzle smashing; unless the deflection mount system is experimented with.

Great work sandman; like always. 🌈
  • Like
Reactions: Biz
I think while doing tap operations we should lower amperage on z; within a script; much like sensor-less homing;
I don't think that would work here... Lowering the current and getting a lost step while creating a bed mesh would be disastrous.. and relying on stepper skipping as your safety net in a quad gantry setup would make for some exceptionally interesting failure modes. 😁 You might prevent catastrophic damage during the probing, and then carve a rut right across the build plate.

also- perhaps we put deflection in mount system with 800grams break force to hit micro-step to detect adxl failures as backup?
This is where things get tricky... because if you have provisioned for that, you've basically done all of the work to have TAP. (And with that, inherited the negative aspects of TAP that an accelerometer-based probe could have improved upon.). Ultimately something has to be the "fuse"... it just isn't clear what that would be in this case. Something could be made that is "TAP-ish"... say a compliant but non-sliding mechanism... but any intentional compliance in the motion system also requires a robust and reliable rebound to the original position, or that Z measurement won't be accurate... hmmm...
This is an intriguing idea and Sandman has done some solid initial research into the topic which I'm sure we all appreciate. From reading the comments above it appears that we need a balance of the features of boop and tap without any of the compromises. I'm not sure if I can personally offer a contribution to this effort but if anyone is after someone to write some code (bearing in mind I would not be keen to test the hardware) in e.g. Python to support this potential offering then I might be able to assist. oliver5000 on discord.