Nice work. Wires are always a pain.
That’s a good idea about checking the ADS1220 presence - something @garethky should probably make sure is there in his implementation.
1 Like
A true word had been spoken calmly!
For testing there is LOAD_CELL_DIAGNOSTIC. It will tell you some info about the output of the ADC.
There is a bug in the code that’s verifying that the ADC was programmed correctly. It reads back the registers that were programmed to verify that they have been set as expected. When it compares the values to expected values it’s failing even when they are the same. I’m making up a board to verify the fix as we speak.
2 Likes
Tested and works.
Didn’t investigate that today, has to wait.
But i have thought about the reference voltage, taken from the 5V line of the CB1. The bridge has a combined resistence of 320 Ohm. That pulls about 16 mA from that line. Should i do that, or might it be a better idea to pick it from the Endstop connector I’m currently using for the DREADY Signal?
Can you explain in more detail or show a drawing?
The 5V input to the CB1 should be directly connected to the 5V output on the endstop connector and are the same (just coming off of different points on the M8P).
The 5 Volts produced on the M8P is pretty good but it won’t be completely noise free but I’d have to see exactly what you are proposing.
I think, that’s all I need to know. My concern was, if the CB1 had a separate supply it might got overloaded. As you say everything is the same I have to check my wiring again, since the Board does not start with the ADS connected.
If I can’t find a mistake I’d like to connect a ‘virgin’ ADS I have up in my sleeve, but without a bridge nor excitation connected.
That’ll hopefully allow me to configure the load cell and run the above mentioned LOAD_CELL_DIAGNOSTIC command.
I just checked with TI’s ADS1220 datasheet and it indicates that the chip uses very little power - on the order of 100µA.
Checking your wiring and then trying your virgin ADS1220 card sounds like a good plan.
Let us know how you make out.
1 Like
Code is updated in the testing branch. VREF and inputs are selectable and the bug with initialisation is fixed.
1 Like
Hi Gareth,
do you have some documentation at hand, how to install the testing branch? I’m quite a noob regarding to that, I do everything related to installation with the KIAUH package so far.
Will do, but takes some time. Have to do other stuff…
You can replace your regular Klipper with my repo and then hit checkout the branch. You’ll have to re-compile and flash the microcontrollers from that branch as well.
Sorry, but I don’t have a clue how to do that.
That shouldn’t be a problem.
Edit:
Found out about the file:
~/kiauh/klipper_repos.txt
But didn’t manage to enter correct source:
###### Cloning Klipper from https://github.com/garethky/klipper/tree/load-cell-probe-community-testing ...
Klone nach '~/klipper'...
Schwerwiegend: Repository 'https://github.com/garethky/klipper/tree/load-cell-probe-community-testing/' nicht gefunden
#=======================================================#
Cloning Klipper from
https://github.com/garethky/klipper/tree/load-cell-probe-community-testing
failed!
#=======================================================#
Sorry, but I’m quite not familiar with Github…
I don’t think I can really do technical support on that level. Unfortunately everyone does things differently.
I believe that what I’d do for my current setup was to do an initial install with kiauh. But I used rsync to overwrite Klipper from my
Mac for development. Once that’s don’t all the tools are screaming that the repo is ‘dirty’ and you just have to ignore that.
Idk if you can convince kiauh to use a specific branch if a repo?
Try:
cd ~/klipper
sudo service klipper stop
git remote add garethky https://github.com/garethky/klipper
git fetch garethky
git checkout garethky/load-cell-probe-community-testing
sudo service klipper start
So, first of all:
After double checking the wiring without success i followed my own advice…
I also made up a test wire from scratch, just 30cm long. Now the machine powers up with the ‘virgin’ ADS attached.
Okay, one obstacle done - time for the next one:
@Sineos
You are my Hero again! That worked out.
I had to reinstall numpy…
~/klippy-env/bin/pip install -v numpy
…and to flash the MCUs (cb1/linux) which I was able to do with KIAUH. Needed to power cycle, but that’s something I’m familiar with, to get the machine to come up again.
i can see now:
**klipper**
v0.12.0-322-g2955b0a3
Detached HEAD detected
And I can see I’m not able to update with KIAUH any more since it still points to v0.12.0-317. So if anybody has a clue how to manage that with KIAUH for further updates, please let me know.
Okay, two obstacles done - time for the next one:
Klipper meldet: SHUTDOWN
Internal error during ready callback: Failed to set ADS1220 register [0x0] to [0xe, 0x94, 0x0, 0x0]: got [0x0, 0x0, 0x0, 0x0]. This may be a connection problem (e.g. faulty wiring)
I won’t rule out my wiring, but i have my doubts.
@garethky Maybe I’m still running into your mentioned problem here?
@mykepredko Or might it be possible that the SPI Bus of EXP2 is not suitable?
Or do I just have configured things the wrong way?
[load_cell]
sensor_type: ads1220
cs_pin: PB12
# The pin connected to the ADS1220 chip select line. This parameter must
# be provided.
#spi_speed: 512000
# This chip supports 2 speeds: 256000 or 512000. The faster speed is only
# enabled when one of the Turbo sample rates is used. The correct spi_speed
# is selected based on the sample rate.
spi_bus: spi2
#spi_software_sclk_pin:
#spi_software_mosi_pin:
#spi_software_miso_pin:
# See the "common SPI settings" section for a description of the
# above parameters.
data_ready_pin: PF5
# Pin connected to the ADS1220 data ready line. This parameter must be
# provided.
#gain: 128
# Valid gain values are 128, 64, 32, 16, 8, 4, 2, 1
# The default is 128
#sample_rate: 660
# This chip supports two ranges of sample rates, Normal and Turbo. In turbo
# mode the chips c internal clock runs twice as fast and the SPI communication
# speed is also doubled.
# Normal sample rates: 20, 45, 90, 175, 330, 600, 1000
# Turbo sample rates: 40, 90, 180, 350, 660, 1200, 2000
# The default is 660
If I activate the still commented options as follows:
[load_cell]
sensor_type: ads1220
cs_pin: PB12
# The pin connected to the ADS1220 chip select line. This parameter must
# be provided.
spi_speed: 512000
# This chip supports 2 speeds: 256000 or 512000. The faster speed is only
# enabled when one of the Turbo sample rates is used. The correct spi_speed
# is selected based on the sample rate.
spi_bus: spi2
#spi_software_sclk_pin:
#spi_software_mosi_pin:
#spi_software_miso_pin:
# See the "common SPI settings" section for a description of the
# above parameters.
data_ready_pin: PF5
# Pin connected to the ADS1220 data ready line. This parameter must be
# provided.
gain: 128
# Valid gain values are 128, 64, 32, 16, 8, 4, 2, 1
# The default is 128
sample_rate: 660
# This chip supports two ranges of sample rates, Normal and Turbo. In turbo
# mode the chips c internal clock runs twice as fast and the SPI communication
# speed is also doubled.
# Normal sample rates: 20, 45, 90, 175, 330, 600, 1000
# Turbo sample rates: 40, 90, 180, 350, 660, 1200, 2000
# The default is 660
I get:
Klipper meldet: ERROR
Option ‘sample_rate’ is not valid in section ‘load_cell’
So I’m a bit clueless again.
Was able to find the solution, extracting the bits ans pieces @Sineos gave me:
/=======================================================\
| ~~~~~~~~~~~~ [ KIAUH Settings ] ~~~~~~~~~~~~~ |
|-------------------------------------------------------|
| Klipper: |
| ● Repository: |
| garethky/klipper (load-cell-probe-community-testing)|
|-------------------------------------------------------|
| Install unstable releases: |
| Mainsail: ● false Fluidd: ● false |
|-------------------------------------------------------|
| Backup before updating: ● true |
|-------------------------------------------------------|
| 1) Set custom Klipper repository |
| |
| 2) Allow unstable Mainsail releases |
| 3) Allow unstable Fluidd releases |
| |
| 4) Disable automatic backups before updates |
|-------------------------------------------------------|
| B) « Back | H) Help [?] |
\=======================================================/
the solution is:
put
garethky/klipper,load-cell-probe-community-testing
into
~/kiauh/klipper_repos.txt
and select it in the KIAUH Settings
But the version looks a bit strange:
/=======================================================\
| ~~~~~~~~~~~~~~~~~ [ KIAUH ] ~~~~~~~~~~~~~~~~~ |
| Klipper Installation And Update Helper |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
\=======================================================/
/=======================================================\
| ~~~~~~~~~~~~~~ [ Update Menu ] ~~~~~~~~~~~~~~ |
|-------------------------------------------------------|
| a) [Update all] | | |
| | Installed: | Latest: |
| Klipper & API: |---------------|--------------|
| 1) [Klipper] | v0.9.1-2078 | v0.9.1-2078 |
and it seems i have to update the MCUs again…
…which I did. Mainsails Update Manager shows now:
**klipper**
v0.9.1-2078-g2955b0a3
Unofficial remote url: https://github.com/garethky/klipper
Repo not on offical remote/branch, expected: origin/master, detected: origin/load-cell-probe-community-testing
And the Klipper message still apperars:
Klipper meldet: SHUTDOWN
Internal error during ready callback: Failed to set ADS1220 register [0x0] to [0xe, 0x94, 0x0, 0x0]: got [0x0, 0x0, 0x0, 0x0]. This may be a connection problem (e.g. faulty wiring)
Maybe I’m running in the completely wrong direction with my KIAUH experiment!?
Hm,
commented the whole [load_cell] out of the config. The Start went trough then.
Had seen the flashing of the MCU didn’t work out, stayed on version v0.12.0-322-g2955b0a3. Redid the flashing procedure and after power-cycle I’m on version v0.9.1-2078-g2955b0a3 now, like the rest of the system already is.
@garethky If my understanding is correct the version number corresponds to your repo?
In spite of that, Mainsail is complaining to update Klipper at least to version v0.11.0-257.
Sorry again, but i have absolutely no understanding about git/github. It’s absolutely overwhelming and confusing me.
After pulling the [load_cell] into the config again, it leads to the above mentioned error message again.
Will check the wiring again…
That looks like the bug that I fixed. The two blocks of bytes are in fact equal:
[0xe, 0x94, 0x0, 0x0] - Expected
[0xe, 0x94, 0x0, 0x0] - Actual
This should be fixed if you git pull the updated code.
Yeah, I think those tags are from when I created my fork and they don’t get updated when I sync with mainline klipper.
Sorry, that doesn’t really help.
I installed your fork half a day ago. Shouldn’t that include your bugfix already?
Just reinstalled your fork with KIAUH again, flashed both (CB1/linux) and got:
Klipper meldet: SHUTDOWN
Internal error during ready callback: Failed to set ADS1220 register [0x0] to [0xe, 0x94, 0x0, 0x0]: got [0x0, 0x0, 0x0, 0x0]. This may be a connection problem (e.g. faulty wiring)
The two blocks of bytes are in fact NOT equal:
[0xe, 0x94, 0x0, 0x0]
[0x0, 0x0, 0x0, 0x0]
And they weren’t equal in my posts above also!?
I’m not trying to be mean, but I cant do tech support on the internet like this. You need to learn enough Git to be able to check out a branch, pull in updates and verify that it has been done correctly. You want to learn about commands like git pull, git switch, git branch, git status and so on.
Sorry, must have made a copy paste mistake! If the two blocks are not the same then I’d look at wiring and configuration. On my breakout board I found 5V to be really unreliable, 3.3V works much better for the digital side of the ADS1220. Maybe your MOSI/MISO are reversed?
oh no, that’s a coding / documentation mismatch 
. Just push a fix for that.
I’m sure you’re willing to help, and I understand your point.
I’ve never had contact with modern compiler programming. My knowledge ends more or less with Locomotive BASIC which is the only language I ever mastered, when I was a child.
So I surely have to learn quite more other stuff in advance to understand whatever git might be.
I’m quite happy, if i can figure out how to setup a config file to get things running. I’m able to install software with apt and use it. What I’m doing here is already far beyond what I expected, when I started my 3D-printer-project - and yes, I’m proud to get that far.
May I not already have your bugfix installed then?
I’m using 3.3V already, the 5V were intended as reference for the bridge, which is not wired at the moment.
Would be pleased if it’s that easy, will check…
I’m pleased to be of use in debugging. So at least I can pay a little for the inconveniences I’m causing. 