Strain Gauge/Load Cell based Endstops

[Sineos]

@53Aries

Issue being we don’t have klipper support for the ads131m02 that this uses.

In its current form, this support isn’t even needed. Also, no flashing in any form is needed.

@53Aries

If support were added I’m confident this could be a standalone probe module.

It already is “standalone”, since it only emulates a switch (pin high or low). There is no direct Klipper support whatsoever needed, not even a code modification. It already works out of the box in Klipper.

The “lost opportunity” is most likely the incompatibility with @garethky’s logic. This would require:

• Proper electrical connections on the PCB, both for the load-cell evaluation and for acting as a Klipper MCU.
• Klipper support for the used ADC.
• Flashing Klipper firmware to its STM.

[53Aries]

I guess I should have made my pov a little more clear. I just prefer all my stuff to be controlled from inside klipper so that’s the concept I was discussing, using this with garethky’s control(if support for ads131 were added). It is indeed standalone as is, both physically and software. My reference to standalone is physical. Physical module separate from i.e. toolhead board, mainboard, but still utilizing klipper for control. Having to connect to this mcu and use a separate program to adjust settings while not the end of the world is annoying. that’s the view point I’m coming from. I’m certain the adc is using spi to the mcu, and the mcu can be a klipper mcu communicating over USB so nothing there is complicated. Probing to find which pins the mcu is using for the USB communication, and which pins are used for the SPI is all the work needed on that front to be able to make the klipper config, but none of it matters if ads131 support isn’t added. Personally I don’t plan to use the included control board simply because it’s not klipper enabled lol. I’ll still map is pins and make sure it’s flashable though before I officially make a request for ads131 support.

[Sineos]

Without hardware modifications to the PCB, these points are moot. The current PCB neither breaks out USB nor a USART interface that could serve as a connection point to the Klipper host SBC.

USB is probably completely out of the question due to the complexity of connecting it to the STM. Patching a USART connector might be possible, but this is quite makeshift overall.

Do not let yourself be led to believing that the documentation’s usage of “UART” means any form of bus communication interface. It is just two GPIOs broken out – one for the enable signal and one for the emulated switch. Nothing more.

Ah, wrong. It has a USB port. Then yes, this makes things possible. In this case, maybe the only blocking point is the missing ADC support for full compatibility with @garethky’s advanced logic.

[cardoc]

Actually it would be VERY difficult for most of us… But I’m hoping someone who agrees with this takes it on.

[mykepredko]

@cardoc

Actually it would be VERY difficult for most of us… But I’m hoping someone who agrees with this takes it on.

Just to be clear, it would be VERY difficult for ANY of us.

@Sineos

Ah, wrong. It has a USB port. Then yes, this makes things possible. In this case, maybe the only blocking point is the missing ADC support for full compatibility with @garethky’s advanced logic.

@Sineos has hit the nail on the head - the requirement isn’t just writing some code to poll the ADC on the board, it is to implement the processing that @garethky has been working on. This processing, as I understand it, involves noise elimination and waveform shaping that is, to a large degree, dependent on the capabilities of the ADC being used.

Personally, I wouldn’t want to even begin to take on the challenge without being thoroughly understanding the circuitry and the characteristics of the load cell. I would also want to have an SWD port interface for application debug.

As I was writing this, a question came to me; would it be easier to adapt the load cell to the ADC hardware @garethky is using rather than try to go through the effort of trying to figure out if the board here can be run his algorithms/processing code?

[cardoc]

The point is, if my understanding is correct, there isn’t a piece of hardware in existence that will interface a HX711 or 717 and attach to a Kipper host. I have a Sovol toolhead here that has a HX711 on the board so I guess one could use that board. BUT the 711 is slow and that board is $25 and 4x the physical size.
The ADC on the Mellow IS the ADC @garethky needs to be able to get filtered data out at a reasonable speed.

8x the speed, 1/4 the size, half the price. If the PGA is useable the board could be used with virtually any load cell. It just seems like an excellent opportunity.

EDIT 32x speed

[Sineos]

@mykepredko

This processing, as I understand it, involves noise elimination and waveform shaping that is, to a large degree, dependent on the capabilities of the ADC being used.

As far as my understanding goes, @garethky has a clear separation of intent:

• The ADC is just providing raw data and, as such, has indeed quite “limited” code in the sense of serving the correct registers of the ADC (e.g., klipper/klippy/extras/ads1220.py at master · Klipper3d/klipper · GitHub).
• The magic happens independently of the ADC in various other modules, like the SOS filter, bulk_sensor etc.

Still, it likely helps to know what you are doing.

[53Aries]

@mykepredko

be easier to adapt the load cell to the ADC hardware @garethky is using rather than try to go through the effort of trying to figure out if the board here can be run his algorithms/processing code?

That’s exactly what I’m planning to do, using an already supported ads1220 to keep it simple.

Now I could be totally wrong here, as I’m not versed in this topic deeply but I think all the code side “stuff” is somewhat universal. The adc chip sends data to the klipper mcu over SPI. That data is similar for all similar adc’s, so I’m assuming for example the data from this ads131 is basically the same as the data from the currently supported ads1220. The adc is only sending mv/v signal data over the SPI and then the klipper mcu is doing the fancy stuff which shouldn’t really need to change much? But I’m just spit balling here and could be totally wrong.

Edit. There is more to the data between the adc and mcu on a higher level. Take my over simple explanation as a grain of salt lol

[53Aries]

@cardoc

8x the speed, 1/4 the size, half the price. If the PGA is useable the board could be used with virtually any load cell. It just seems like an excellent opportunity.

Yeah this.

[cardoc]

@53Aries

That’s exactly what I’m planning to do,

Refresh my memory, if I recall you are running a RP2040 attached to a ADS1220 with custom circuitry?

[53Aries]

@cardoc

Refresh my memory, if I recall you are running a RP2040 attached to a ADS1220 with custom circuitry?

Yeah. It’s just a pico board with the ads1220 connected to it. Pico flashed with klipper, connect over USB to host just like a toolhead board basically. The ads gets some resistors and capacitors for filtering voltages on a few of it’s pins and the load cell connects to the ads. I have it all stuck on breadboard so it’s not exactly elegant, but works.

[Sineos]

@53Aries

The adc is only sending mv/v signal data over the SPI

• The ADC (Analog-to-Digital Converter) generates samples at a certain rate (samples per second). Each sample is a digitized representation (a “count”) of the analog voltage drop across the load cell, which is proportional to the force being applied.
• The ADC output is sent to the microcontroller (MCU), typically over a serial protocol depending on the chip.
• The MCU, but mainly the host process on the SBC, is collecting and processing this data - for example, reading data in batches, turning counts to grams, and filtering.
• Most importantly, it has advanced logic for detecting the “point of contact”.
• All this depends on the number of usable bits, i.e., the effective resolution that is left after removing noise and other artifacts. This in turn depends on the capabilities of the ADC and, especially, the quality of the supply voltage to the ADC and to the load cell.

At least, so far, that’s my layman’s understanding.

[cardoc]

@Sineos is FAR from a layman

One thing to note 64k 3 byte samples per second isn’t going to happen over USB.

BUT slowing down a ADC reduces the noise making the post processing much easier.

One of Klipper’s main strengths is the host does all the processing keeping everything in sync. The MCU is basically just a router getting data to/from specific pins. In this case that’s unfortunate as the STM32 could down sample/smooth/error correct the data stream and avoid transmitting all the noise to the host. Mellow claims to be running Kayman filter algorithms before converting the output to 1 bit data. I’d love to be able to see their raw vs filtered data.

At the end of the day the ADS1220 running a 2kSPS is going to loose 3 to 4 bits to various DSP processes. The ADS 131M running at 2kSPS is only going to loose 1 or 2. This results in the touch point being resolved to, for example, ±1g instead of ±4g. What that works out in microns depends on how rigid the printer is.

[garethky]

Writing a driver for ADS131M shouldn’t be too hard. its going to look a lot like the driver for ADS1220 since they are both SPI sensors. The programming section of the manual is here.

It has 4 channels and has a much larger register map, but odds are you only need to implement one channel and a handful of features (input selection, data rate, PGA) to get things up and running. All of the device setup is done in Python (setting and verifying registers etc.) The actual reading from the device is in C, but you are scoped down to just having to read the bytes out of the device and then convert the data to an integer.

All the hairy math stuff is totally offloaded to other modules in C and Python. Somebody ambitious could take a crack at this.

[53Aries]

@garethky

Somebody ambitious could take a crack at this.

I know a coder whos REAL ambitious, but not very good
Checkout what chatgpt put together. This is mostly a joke but I’m curious how it did at the same time.

ads131m04.zip (3.2 KB)

[cardoc]

@garethky

If you could have any sample rate (up to 64kHz) what would it be?

Looking at the data sheets, the ADS131M has half the noise at 4 kHz as the ADS1220 does at 1 kHz

[garethky]

Much over 2K is not as useful as you might expect. Sampling speed is mostly about stopping the toolhead when its probing quickly. It just needs to be fast enough to keep things safe. There is a ~25ms delay on multi-mcu homing. So sampling faster doesn’t cut down on the delay to stop the axes as much as you might think.

The pullback move where the actual Z=0 point is calculated is a separate move, with its own speed. That speed is set such that 1 sample = 1 micron of motion. Much over 1K SPS and I think you will get diminishing returns. Both the electrical noise (due to stepper driver current increasing) and the physical noise (due to stepping) start to rise with faster speeds.

So on that sensor, 250SPS is too slow, 500 and 1k SPS look interesting. Everything faster is going to see increased electrical noise.

There are other places to look for a speedup. Probing from a lower height is one. I have a change to do “adaptive” probing so the start height can be lower for bed meshes. Like 0.25mm low.

[Sineos]

@garethky

Writing a driver for ADS131M shouldn’t be too hard.

What I really would like to understand eventually is how such manufacturers think during their development cycle. Their chain of thought must be something like:

1. Hmm, I’m tasked with creating a pressure-sensitive toolhead.
2. I’ll need a sensitive load cell and a single-channel ADC that reads the data. Let’s see what TI offers.
3. Hey, nice! TI has about 728 ADCs that are specifically recommended for load cells. I’m going to pick one with a matching price/performance ratio.
4. Oh, wait! There is the ADS131M. It has four channels and is specifically recommended for power sensing applications.
5. It can’t get any better. Let’s use ADS131M in case the user connects the load cell to AC mains.

[mykepredko]

@Sineos

What I really would like to understand eventually is how such manufacturers think during their development cycle. Their chain of thought must be something like:

Most Chinese manufacturers are part of a large conglomeration of companies.

As I have observed, part selection goes something like:

First. A search is made of parts in stock that they have no need for. Many of these parts are from cancelled programs while others were picked up on the spot market because their price was so low and they should be useful in the future. Often components are part of a trade deal involving other parts with other manufacturers. These parts have a book value of essentially zero.

Next, they look to see what their sibling companies manufacture. When you’re talking a large organization they have silicon as well connector and passive manufacturing and the engineer will review what’s available there. The parts in this case cost a fraction of what buying them on the open market will be.

Third, their buyers will look to contacts at other organizations to see if they have anything in their stocks of unrequired parts. A swap with no money changing hands is the ideal situation but sometimes parts are purchased at pennies to the dollar.

Fourth, they look to the spot market. This involves local manufacturers as well as distributors both local and international.

Finally, they go to the large multi-national distributors (Arrow, Avnet, Digi-Key, Future, etc.) and see what is available there.

In my experience, the parts used in a product designed by a company that is in a large conglomerate are rarely procured beyond the third tier.

So, you’re asking why did they choose the four channel ADC when a single channel one would do the job? It’s because they get the four channel ADC free or very close to it.

I hope I don’t sound cynical but this is a very successful parts procurement model that keeps product costs low and landfills free of unwanted components. On the downside, it makes it extremely hard for companies outside China to compete or take advantage of the stocks of parts that are not being used.

[Sineos]

Thanks for the insight @mykepredko. Absolutely makes sense, but it is, of course, diametrically opposed to my engineering heart.

It’s like “what is the proper technical solution, then find the best price” vs. “what is the best price, while being technically somehow acceptable”.