ADXL burnt out?

[normal phoenix]

At what point can I conclude my ADXL is dead? Is there a way to test? I have wired a harness to test the board using an extremely short Ethernet shielded cable and still get the (got ff vs e5) error.

I don’t think I have ever once been able to get an ADXL to work, how unreliable are these cheap boards? Should I just order a 3 pack and hope for the best?

[timber phoenix]

In my experience it's more than likely a wiring issue not the board. I ran into the same thing and had to recrimp the dupont connectors to fix the issue

[meager rock]

i made the same experience, i actually ordered a multi-pack, and thought one was burnt, but in the end it was ofc some wiring quirk. Not with the cables or connectors themselves in my case, but the way it was wired to the hardware - and more importantly - how it was adressed in the software! can't help you with that, but it's highly likely that you're chasing in the wrong direction 🙂

[normal phoenix]

Do you have any suggestions? I am following the instructions to the letter, I have it wired as shown in the diagrams, I have the crimped ends soldered, I have the required lines uncommented in config (unless there is some secret there?), I have tripple checked wiring with a multimeter, and I have tried two Adxl boards with more on the way… i truely don’t know what else I could try

[normal phoenix]

When you say the way it was wire to the hardware, do you mean the schematic is wrong? Do I need to flip cables?

[normal phoenix]

Can the Vcore use the rpi for measuring the ADXL

[meager rock]

its too long ago that i had this problem, my problem was that i was using the adxl on a toolboard and the other one wired directly to the Raspi. i had to change some stuff to get it to run because the standard was expecting a different configuration - so sorry, but i can't hlep

[normal phoenix]

ive just tried wiring directly to Rpi and cat6 cable as done in another chain, my only option left is to wait for my new ADXLs to arrive today.
@steel granite is there anything i my have failed to do in my printr.cfg? i have looked at and tried all the options as tried in other threads and cannot get it to respond

[steel granite]

yes but it won't make any difference. You'll also have to test with chip=rpi for that or you won't be querying the correct port.

[steel granite]

Config looks fine

[steel granite]

So it looks like the board config for the h723 is the culprit. The spi pin definition is wrong. Give this a shot:

[adxl345]
spi_software_sclk_pin: PB3
spi_software_mosi_pin: PB5
spi_software_miso_pin: PB4

Put that in user overrides and try agian.

Let me know if that fixes it, i'm pretty sure this is a bug. This is one of the user contributed boards i don't own myself so i can't test.

[normal phoenix]

Thanks my man, I’ll give it. Shot, I figured it must be something like that, I had tried every other option

[normal phoenix]

same thing i am afraid, though i get the feeling this is the right track

[steel granite]

Don’t touch that klipper maintained section, it won’t end well. Put it in user overrides.

We can try the spi bus instead, but we’ll have to define a new ADXL section

[adxl345 test]
spi_bus: spi3
cs_pin: PA15

and query it with ACCELEROMETER_QUERY CHIP=test

[normal phoenix]

I got this

[steel granite]

spi3a maybe?

if that doesn't work either, it seems to me there might be something wrong with that particular SPI port, it's possible it's not defined for the chip in klipper or something.

Maybe you should try wiring it to the pi afterall.

[normal phoenix]

if i try wiring it to the pi, would i need any more user over-rides? it did not read when plugged into the pi either, but i could have done something wrong i suppose

[steel granite]

Yes you need

[include RatOS/boards/rpi/config.cfg]

And

[include RatOas/sensors/rpi-adxl345.cfg]

and you need to query it with ACCELEROMETER_QUERY CHIP=rpi

[normal phoenix]

ok so some progress, spi3a seems fine now it has an issue with pa15

[steel granite]

That means adxl345_cs_pin is used in the config elsewhere. You can't use two different aliases for the same pin, you also can't use the same pin twice. Question is where you've used the adxl345_cs_pin.

If you upload your klipper.log i can find out

[normal phoenix]

i looked at it this is what i suspect is the culprit

[steel granite]

ah right, yeah that makes sense, can't do the [adxl345 test] with the same cs_pin obviously.

Would have to do something like:

[adxl345]
cs_pin: somerandomunusedpin

Then the [adxl345 test] config should work

[normal phoenix]

Ah cool, im still very new to this board, what would be an an unused pin? some fan pin thats not hooked up?

[steel granite]

Any of the gpios on the board that you're not using, for example one from the exp port or the i2c port or whatever you don't use. Check the pinout diagram

[normal phoenix]

i got a 0 vs e5 now

ok i got it

i think i passed the learning curve on this particular thing

[steel granite]

Huh.. That was the first thing i suggested: https://discordapp.com/channels/582187371529764864/1146901116286668881/1147238931046346763

Prolly wiring the first time then?

either way, looks like i should change the default adxl configuration on the H723

[normal phoenix]

It was what you suggested plus the PA15 thing because that that time the CS pin was assigned to something else, what specifically i don't know, and yes there was some sketchy wiring at various points but i also fixed some bad connections

does the Z have to be below 100 when i do a MEASURE_AXES_NOISE? its at 159