Tap detection with ldc1612 inductive sensors

Developers
1

I’ve been working on tests using an ldc1612 based inductive sensor to detect contact between nozzle and bed. That is, it may be possible to use this hardware to probe by “tapping” the nozzle into the bed.

This capability would have two major advantages over traditional inductive sensors:

  • It does not suffer from “thermal drift”.
  • There is effectively no probe “xy offset”.

The ldc1612 inductive sensor operates similarly to traditional inductive sensors, except it provides more information on the measured “inductive resonance frequency”. Basically, the sensor oscilates a small electic current in a coil and can detect the resonant frequency of that oscilation. As the probe moves closer to the bed the resonant frequency increases. This can be used to estimate the distance between bed and probe. Klipper currently has basic support for the ldc1612 ( Configuration reference - Klipper documentation ).

Crucially, if the Z carriage is descending and the probe detects that the resonant frequency stops increasing, then that can be used to infer that the nozzle has contacted the bed. That is, instead of using the sensor to directly estimate Z distance, it can be used to detect when the Z distance stops changing. A brief stall on the Z carriage, due to the nozzle contact with the bed, can thus be detected.

Interestingly, this also avoids issues with “thermal drift” - the temperature of the probe electronics, the probe coil, and the metal bed can slightly influence the measured resonant frequency. The “tap” approach, however does not rely on a precise mapping from resonant frequency to Z distance. The sensor only needs to detect when the resonant frequency stops increasing.

In many ways this functionality appears similar to recent discussions on “loadcell” support.

Some caveats I’ve seen in my tests so far:

  1. It is not a fully general “nozzle tap” detection like one might find on a loadcell. The bed still needs to be metal. Even though the system detects contact between nozzle and bed, the sensor still needs to be above the metal bed (which can limit probing near the edges). It’s likely possible to have a surface on top of the metal bed, but the point of contact still probably needs to be within 5-6 Z millimeters of the metal.

  2. There needs to be a strong mechanical link between nozzle and probe on the toolhead carriage. The idea is that when the nozzle contacts the bed, it’ll briefly stop moving, which causes the probe to stop moving, which can then be detected. As a contrary example, if the probe was mounted on the other side of the toolhead carriage, such that when the bed presses into the nozzle the probe gets cantilevered closer to the bed, then the system would not work.

  3. The system does not work well at slow Z probing speeds nor slow Z accelerations (at least in the test code I implemented). At slow speeds, stepper motor “cogging” (aka detent forces) causes jittery movement. It’s difficult to distinguish those stop/start oscillations from stops due to nozzle contact. Also, the test code I implemented only works when the toolhead is at a constant Z velocity, so a very low Z acceleration would not work well.

  4. Error checking looks like it may be difficult to implement. In particular, I think detecting “false positives” may be a challenge. That is, if something causes the probe to think a contact is made, it’ll halt Z movement. And once the Z movement is halted, there isn’t really anything to indicate that a contact truly was made. (To wit, a halt in Z movement due to nozzle contact is indistinguishable from a halt in Z movement due to no longer commanding Z movement.)

  5. A “tap” system does require contact between nozzle and bed (obviously). That may not always be desireable. In particular, it’s probably not a good idea to probe with a fully heated nozzle. It’s unclear (to me) if many taps will eventually wear out the nozzle, bed, or carriage. And, of course, any debris or plastic remnants on the nozzle will skew Z height results.

I have implemented some basic test code. The code implements checks in the MCU to detect when measured frequencies stop increasing. The mcu code can then signal an event which causes the toolhead to stop moving. The curent code does not produce accurate Z height results - good accuracy would require host based “knee” detection. (Along with additional error and false positive checks.) If interested, the code for the test implementation is below.

Important - the development code below is known to not be accurate and is very likely to cause nozzle crashes!

Some brief usage notes at:

Cheers,
-Kevin

2

Sounds interesting.

What are you using as a coil for the sensor? I took a quick look at the ldc1612 datasheet:

as well at application notes, like:

But I haven’t found any that I would consider appropriate for a 3D printer implementation.

3

I’ve been testing with a Bigtreetech prototype “Eddy” device New Product Launch Spring 2024 – Biqu Equipment (also GitHub - bigtreetech/Eddy ).

I’m told that Duet3D also has a board as well as Cartographer3D, though I don’t know if the Klipper support will run out of the box with those implementations.

-Kevin

4

Cool. Thanx for the pointer - I’ve ordered a couple to try out.

I don’t know if this is true for everybody but I found ordering through the BTT store at AliExpress will save you a few bucks on the cost of the product and provide free shipping (I’m in Canada).

5

How is this affected by external magnetic fields? For example some beds have integrated SmCo magnets, while not common, just wondering how these eddy current sensors are affected.

Example:

Also, How is it affected by material types?

Most beds are aluminum sure, but people use spring steel plates with a magnetic sheet under it. Aluminum is great for eddy currents, highly conductive and very low permeability. Magnets are their own set of issues, Steel has much higher permeability due to mostly being iron.

Are they any issues with the magnetic field saturation? Probably not since the steel sheets are thin, but it’s something I’ve always wondered about.

Does the “stack” of materials cause any issues either? Since they all have different conductivity and react differently to magnetic fields.

Looks like the LDC1612 has some built in adjustments for it, but if I’m reading it right the eddy current sensing is basically an LC tank circuit. I’d be curious about the frequency drift due to the temperatures inherent in 3D printing. Especially if using ceramic capacitors.

These aren’t directly issues with this implementation. More of things I’ve been wondering about since people have started moving toward eddy current sensors.

6

I don’t know!

As far as I know, the ldc1612 operates using the same principals as other common inductive sensors. There’s a long history of using inductive sensors (eg, pinda, omron) on 3d printers. I’d guess the same lessons with those devices would apply.

As to using “tap” vs “frequency to height mapping” on varied surfaces - I’d guess that “tap” has the potential to be more accurate as a precise mapping isn’t needed. I don’t know though - only testing will tell.

Cheers,
-Kevin

7 
I don’t know!

That’s a valid enough answer for me, I didn’t know if you had any experience from testing it.

Inductive sensors have their quirks like every sensor type, like everything in life it’s one trade off vs. another. I’ve been semi-curious to how eddy currents fare as they’re the current “hot new trend”.

The tapping idea is a pretty novel approach though and is my opinion is much more useful than a “fast bed mesh”, because how often are people honestly bed mesh calibrating? If they need to do it before every print that sounds like there are bigger issues.

Besides the LDC1612 portion, are you using one of the beacon derivatives? Or is there another version of this sensor out there that I haven’t seen? I’m curious if it works out of the box with the ones designed for bed meshing or if an alternate PCB design might work better for what you’re describing.

8

If you are not aware. Beacon is developing this method in closed source and cartographer is working on it in open source. Both have demonstrated this functionality publicly and they are both in closed betas. Beacon will release it this month and Cartographer “soon”.

I just wonder if there is real value in developing another method if the Cartographer implementation will be open source.

9

That’s assuming there will be a large technical difference between the two implementations. It could be that the carto version is easily transferred into klipper code itself rather than being in its own package.
Speculation on my part, but I can’t imagine there are too many ways to get the same result from the same hardware. Maybe more/less filtering and detection logic.

It’d be great if all the LDC1612 probes end up using the same klipper-native code with all the bells and whistles (nozzle detection and temp compensation, though maybe the temp comp won’t be relevant with a working nozzle detection feature)