Hello, I’m trying to get Input-Shaping working on my printer and I’m having a huge issue with the MPU-6050 Accelerometer. I’ve got everything wired up, I’ve checked and made sure that the wiring is right but whenever I try to get the ACCELEROMETER_QUERY results I get !! No accelerometer measurements found followed by a Klipper State Shut Down. I purchased two of the MPU6050’s yesterday and both of them are getting the exact same results. I’ve quadruple checked the steps to make sure I haven’t missed anything and changed out the Dupont jumper wires several times to account for a faulty cable. Nothing seems to be working. Any help would be really appreciated
Attached is my log file.
VCC is connected to Pin1
Ground is connected to Pin9
SDA is connected to Pin3
SCL is connected to Pin5
klippy (3).log (1.8 MB)
Hello @DrSkyentist !
I found this in the klippy.log:
MCU 'rpi' shutdown: Unable to open i2c device
As you have the GY-521 board you may read the corresponding section here:
Make sure to have followed: RPi microcontroller - Klipper documentation
Did you have any luck getting this to work? I have the same sensor wired the same and getting the same errors.
My condensed installation procedure for Accelerometer MPU6050:
- Measuring Resonances - Klipper documentation
- IMPORTANT: otherwise numpy runs on python 2.7
sudo apt install python3-numpy python3-matplotlib
- Install rc script (RPi microcontroller - Klipper documentation)
cd ~/klipper/
sudo cp “./scripts/klipper-mcu-start.sh” /etc/init.d/klipper_mcu
sudo update-rc.d klipper_mcu defaults
- Enable I2C
sudo raspi-config → enable I2C under the “Interfacing options” menu
add/uncomment dtparam=i2c_arm=on,i2c_arm_baudrate=400000 in /boot/config.txt (or /boot/firmware/config.txt in some distros).
reboot
this line is reset to default every now and then. Just redo and reboot to get it back up and running
- Flash firmware for 2nd MCU (the RPi itself)
cd ~
./kiauh/kiauh.sh
advanced → build & flash → select “Linux process” → Regular flashing method → UART → MCU #1: ttyAMA0
- config:
use section [mpu9250] for MPU6050 (the chip is identified automatically)
1 Like
Hi there,
Sorry for digging up that topic. After my ADXL345 has decided not working, I swapped it over a MP6050.I followed Klipper installation & yours. I still have “!! No accelerometer measurements found”.
I don’t know what to do… Hum…
klippy.log (680.5 KB)
Thanks for any reply.
Cheers
After I wasted a whole day on this same issue I came to the conclusion that the mpu-6050 only works with VERY short leads like 4" max to the MCU - so I wired mine to a remote RP2040 right on the print head and it worked fine…
I fixed my problem…
I separated both lines on the config.txt : dtparam=i2c_arm=on,i2c_arm_baudrate=400000
I then copy the « two » parameters on the same line like on klipper manual and it worked straight away…
I believe I have fixed a bug in the MPU-* handling code using the RPi <-I2C-> MPU sensors which makes them very unreliable, however before I submit it to Klipper I would like to work with you to see if it fixes your problem and does not break anything else. I have tested it with all the equipment I have at home already.
Would you mind donating some of your time (and possibly sanity) so we can fix this for everyone?
I would be very happy to hop on Discord and work with you.
My klipper fork is here:
Discord Friend sent - yes just wire a MPU to the RPi via I2C. The RPi has pullups so you don’t need those. If you are using git already though fluidd / mainsail whatever you can switch to my fork pretty easily and back - it is the same as Klipper but with some changes to the MPU code only.
What is the fate of this fix? I see the repo is archived but I don’t see any mention of the issue or fix in the main branch.
I’m having the exact issue as I’ve seen you describe here and elsewhere. I debugged everything else so I want to try this fix if it’s still viable.
Good news, the fix was merged a while ago into mainline klipper so if you have an up-to-date klipper install you have it.
If you are still having issues, a photo of your setup + wiring and MPU PCB would go a long way to figuring out what might be happening. A copy of a kilpper log where you tried commands would be helpful too.
Its a complex topic, sadly, as none of these solutions are user friendly - they all rely on using busses designed to work on a PCB (SPI or I2C) which are not nearly as friendly as USB for example. It relies on Klipper being configured correctly, the RPi or MCU configured correctly, and lastly the wiring sorted out correctly and any failures will cause nothing to happen.
Thanks. I tried your branch but didn’t have any better luck. Once I read your comment I went back to the latest version of klipper. Truthfully I’m having a hard time verifying the actual firmware load of the MCU because I don’t get any real indication that the load was successful and I don’t know how to check the loaded firmware version.
Things I’ve done so far:
- Fixed the VPU clock speed on the Pi. The default load-based clock speed of the VPU was throttling the I2C speed. It wasn’t running at the desired 400 kHz because apparently the I2C speed is set based on the maximum operating VPU speed. The I2C clock multiplier does NOT adjust to compensate, so when the VPU is at an idle speed it drags the I2C down with it.
- Removed the redundant pull up resistors on the sensors (I have GY-521 sensors which might be low quality and/or use counterfeit MPU chips?)
- Redid the wiring using salvaged USB cable and direct solder connections at the sensor. Reinforced the connections with hot glue.
I’ve attached some photos, as well as a clean klipper log where I homed the machine and attempted to run X-axis resonance measurement. This latest log was actually the farthest I’ve managed to get into the measurements before it crashed. Do note that I have two sensors on the same bus with the new cable being a Y-cable. I could use just 1 but the whole reason I went with the MPU is because I wanted to have them stay installed and both accessible.
I might try increasing the I2C speed slightly above 400 kHz and see if that helps. As I mentioned in item 1 above it wasn’t running at 400 kHz before, but it still seemed to function fine outside the test. It might be able to handle a slightly faster speed. If that doesn’t work and there’s no other obvious issue I’ll just try the ADXL over SPI instead and see if that goes better.
klippy(4).log (235.6 KB)
I have to reply to this with the photos because I’m a “New User” and can only have one file per post.
