I can’t contribute to how the code is packaged, distributed, or the way modules are “connected”. not my wheelhouse.
The finger push is not actually part of the calibration routine. It is a simply a sanity check. Do the counts change enough to be read against the noise floor and is output counts rising or counts falling. Squish is not a factor at point. The shift from force based to position based method needs to ensure there is a useable signal before putting the nozzle against the bed. Starting the calibration routine with the load cell unplugged is not a useful exercise, At my old job we’d measure tractive effort of off highway equipment with a 50kLbf load cell chained to an immovable object. Every test we’d position the machine with the chain just tight enough to lift the chain off the ground and step on the chain to make sure the line on the recorder wiggled. Didn’t care by how much just that it moved. The recorder had 16 inputs. Am I connected to the right one?
LOAD_CELL_DIAGNOSTIC is available for that kind of testing via the console. In the future we should get graphs of the live load cell data in the front end, same as temperature, so you’ll be able to check easily. In the meantime there is a graphing tool linked in the testing instructions. I encourage everyone testing to get that working so you can see what the data looks like.
Some fairly disruptive stuff is going to happen for folks using the testing branch. Kevin refactored the probing code so that I can (hopefully) re-use the bulk of it without having to copy/paste. He has also started thinking about fully refactoring homing. This would be “good stuff” looking forward and I don’t want to get in the way of that.
To make it easier for the coming refactor it would be much simpler if the load cell stuff was purely a probe and did not implement an ‘endstop’ or interact with the homing code. Removing this functionality will mean that:
The QUERY_ENDSTOPS and QUERY_PROBE commands will no longer work
To home the Z axis we will have to use a custom homing macro and [homing_override] to home the Z axis.
Because of the breakage of QUERY_ENDSTOPS and QUERY_PROBE there will have to be an alternative method to statically test that the probe works. I’m thinking of a command like LOAD_CELL_PROBE. But this will come a bit later once the refactoring is complete.
For the first item we will need a command that can do probing in a way similar to how endstops work. The load cell probe can evaluate the results of the probe as ‘failed’ and require a re-try. During that retry the user can add gcode to clean the nozzle. But that would be invalid to invoke without the machine being homed. So we would end up in a catch-22 situation. A custom command will be used that allows control over probe failure. Luckily I was already building something like this to use for data acquisition and testing. This will be a synonym for PROBE but support additional load cell specific options.
I cant easily do all of this all at once and get it reviewed efficiently. So I’m going to ship the change that breaks QUERY_ENDSTOPS first, then the change that breaks homing. Once all that looks correct I’ll ship the new diagnostic tool and updates to the directions to explain how to do the homing macros.
Hopefully this all gets turns around in a week or two.
This may be a little off-topic here, but I recently saw something interesting in the stm32g431 chips. These chips have three opamps on them that can be routed to each other or to the on-board 12-bit ADC. I do not know about the overall quality of the opamps, but I wonder if one could use them to directly monitor the voltage from a load cell. That is, configure the opamps as either a differential amplifier (ie, a PGA) or as an instrumentation amplifier, route the results to the internal ADC, and run the Klipper mcu code all on one stm32g431 chip.
The stm32g431 chip currently has a low price (eg, ~ $2 on jlcpcb) and it may be less expensive than some dedicated ADC chips. Similarly, the stm32g474 has 6 opamps and is currently not that much more expensive.
Anyway sorry for the noise if this is off-topic.
-Kevin
Further up there was a discussion about 12 bit sensors. I’m pessimistic about their use here because the voltage range is so small and the number of bits is small.
Based on the devices I have:
1 gram ~= 30 uV
Based on the Nextruder + HX717, I’m seeing less than 100 counts per gram on a 24 bit sensor with the gain cranked to the max (PGA=128). Voltage change for 1 gram = 5V / (2^24bits / 100counts)) = 0.0000298V
Whats the smallest voltage change you can detect with these ADCs?
ADC Bit Width
Calculation
Sensitivity V
Sensitivity uV
12 bit
5V / 2^12
0.001V
1000uV
16 bit
5V / 2^16
0.00008V
80uV
24 bit
5V / 2^24
0.0000003V
0.03uV
So the smallest weight you could detect with 12 bits, theoretically, is 1,000uV or about 33 grams. That doesn’t account for noisy bits, which is likely at least 3. I’d be surprised if they will measure anything less than 100g. With most taps coming in at 200g, its like your sensor only counts from 0 to 2. For the critical range it has 1 1/2 bits or resolution.
Maybe another way to cross-check this idea: What is the typical voltage change for 1 degree C on an NTC thermistor?
I’d be thrilled to be wrong! I want everyone to be able to try this probe. But I haven’t seen math or results that conflict with the above.
Privately someone shared results where they used over-sampling to make up for the lack of bits. This worked, but it required a HUGE amount of CPU overhead, requiring a dedicated MCU. Their conclusion after this was that the 24 bit sensors are good value. Maybe there is some way to to do this faster/cheaper?
That’s where the opamp comes in. An Operational Amplifier can amplify the incoming voltage prior to measurement. Most micro-controllers don’t have opamps, which is why I was surprised to see they come standard on the stm32g4.
Typically an stm32 mcu has a 3.3V analog reference and a 12bit ADC. That would be 806uV per ADC tick (3.3 / (2**12)). However, if one uses an opamp to amplify the voltage by 64 prior to the ADC, then one can sample 12.6uV per ADC tick (3.3 / (2**12 * 64)). That is, for example, if one knew the voltage range was between 1V and 1.05V one could setup an opamp to amplify that 0.05V range by 64 to a voltage range of 0V to 3.3V for the ADC to then measure.
So, as I understand it, the resolution of the sensor as a whole becomes mostly dependent on how good the opamp is and not really dependent on the resolution of the ADC. I have no idea how good the opamp is on these chips though. I figured I’d raise it here though as it may provide some interesting possibilities.
I wouldn’t call this an accurate statement; every MCU family that I’m aware of has part numbers with OpAmps available for “mixed signal” conditioning/operation.
It’s not that simple. At best, the performance of the built in OpAmps should be considered “fair” to “moderate” because of the other signals executing on the chip and whether or not the inputs/outputs of the Op-Amps run through the pin multiplexors of the chip. If you look at the features of MCUs with Op-Amps built in you’ll see that much less than half of them have USB built into them because USB can induce noise on the chip that will affect the operation of an OpAmp.
The typical applications for OpAmps on MCUs consist of input/output smoothing (ie implementing a low-pass filter), notch filters and waveform inverters. Waveform periods vary, depending on the hardware and the MCU’s floating point capabilities.
I know there are some MCUs with high performance OpAmps (ie their inputs/outputs go directly to package pins and are not passed through pin muxes) and have greater than 12 bit ADCs (and built in FFTs) but they are very costly and are designed for specific applications.
It’s an interesting idea to put an amplifier on the signal before routing it to the MCU ADC pins but I don’t think that using the internal OpAmps of an MCU is the right way of doing that.
Honestly, I think the approach @garethky used originally going with a high performance ADC designed for this type of application is the right way to go.
UPDATE:
I just saw @Sineos 's reply and I would think the CMMR values make this approach a non-starter (at least using STM32G4xx parts).
Just wanted to throw this in. I have this https://www.amazon.com/dp/B0FBGDNF2W in hand and it’s machined REALLY nice, so if the actual flexture properties are as well done this should work great. Will know more in the coming days, waiting for caps and resistors for filters on the ADS1220. I also ordered this https://www.aliexpress.us/item/3256809216184183.html kit since they dont seem to sell just the hotend, I wont use their control board I’ll just use an ADS1220 again. Some cool stuff I found. I plan to use the ads1220 hooked to a pico2 as a standalone probe module.
A loadcell that is 100% concentric with the filament and nozzle
An ADS131M02 ADC chip (64kSPS, 24 bit)
The other side of the board has a USB port and a STM32F072xx MCU
Currently the MCU is simply supplying a switched output VIA SPI but could Klipper firmware be flashed and attached to the printer host VIA USB as “Force_MCU”? Find the correct pin ID and read it at whatever rate you want.
ALSO the ADS131M is available on Digikey. It could probably be connected to a RP2040
Well, I’ll let you know when my package arrives! I was pretty happy when I stumbled across that kit, hopefully it ACTUALLY works. Even if I ditch their control board, as long as the hotend/strain gauge is good I’ll be thrilled. Plus it uses Dragon mounting pattern so adaptation should be simple for most toolhead.
Which I assume the two buttons are your standard boot and reset so getting to bootloader of the stm shouldn’t be an issue which means klipper shouldn’t be an issue.
The load cell design is a thing of beauty. Hopefully the execution is good also.
BUT if that board can be flashed to Klipper and deliver A to D counts to the host THAT would be (IMHO) a real game changer. I run an accelerometer as a separate MCU and it works perfectly. I see no reason a load cell wouldn’t work also.
I did send a querry to Mellow support asking if the chip was flashable.
Let me know if they respond. The only slight downside is your stuck with v6 heaters, but there’s the trianglelab CHC series that fits v6 threads which I’ve been using for years with no issues. So I guess no so much a downside as it is a constraint.
They only simulate a regular endstop, meaning they just provide a high/low signal.
All the advanced logic that @garethky is developing will not be applicable since the electrical connections are most likely not provided.
In addition, the selected ADC is currently not supported and would need some work to make it compatible with Klipper.
Ah didn’t think about the adc being unsupported. @garethky maybe once I get it I’ll map pins if that would help adding support? If not, I’m still pretty excited about the strain gauge even if I hook it to my ads1220.
The ADC is obviously supported by the STM32F072xx. Forgive my ignorance but I thought Klipper addressed the pins directly. I assume there must be a disconnect at the MCU firmware level so that the ADC is initialized and starts sending samples on the specified pin.
The STM32<> ADS131M code must be out there. I really doubt Mellow ported it from scratch. Where is the place to find a Klipper MCU firmware expert?
