Hi everyone!
I just released a candidate for the Input Shaping plugin for Octoprint and Marlin if you have a Raspberry Pi 3B or superior and are willing to test and provide feedback on the github repo please let me know, the plugin was tested with my Ender 3 V3 SE so I'm looking for another printers and setups feedback too.
Refer to the github readme to set it up.
Interesting! I mentioned this over on the Marlin discord as well. It's pretty common for users to ask about using an accelerometer there.
This pluggin is really interesting
I want to test it in a prusa printer with a steel frame
I have been trying to install everything and works perfectly, even the options within Octoprint so that they move the axes work, but I have a accelerator problem.
When I reached step 7 of the installation in which I am going to verify reading the accelerometer values, it does not happen, everything arrives in zeros in the 3 axes
I checked the connections multiple times but I still do not receive values
At the beginning I thought it was the accelerometer but verifying with a simple sketch in Arduino and works
Maybe it may be the Raspberry model, I am using a Raspberry Pi 4 Model B with the Octoprint version 1.11.0
I am also using this type of accelerometer:
Did you do the automatic setup or manual setup to enable SPI?
https://github.com/navaismo/Octoprint-Pinput_Shaping#manual-dependencies-installation
As @jneilliii pointed looks like a SPI issue.
Can you confirm that the line:
dtparam=spi=on
Exist in your /boot/config.txt and check also the output of:
ls ls /dev/spidev*
If all looks good, can you run from console:
sudo adxl345spi -f 5
To see if the gpiod service is running and communicating with the spi bus.
I did both. Initially with the automatic setup but when I didn't get any result when reading the accelerometer I completely reinstalled Octopi and proceeded with the manual setup giving me the same result.
in config.txt file there is “dtparam=spi=on”.
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
then I tried with spidev and this two files appear:
pi@octopi:~ $ ls ls /dev/spidev*
ls: cannot access 'ls': No such file or directory
/dev/spidev0.0 /dev/spidev0.1
Finally I ran the accelerometer reading again and this is what comes out:
I apologize in advance if I am missing any process in the use of command line, I still don't have very good knowledge in using SSH or programming in raspberry pi..
Can you double check the connection diagram of the sensor to the board?
If everything looks good try the following:
lsmod | grep -i spi
You should see spidev and the bcm driver loaded. If so try to run SPIDEV_TEST program to check that the hardware is working: GitHub - rm-hull/spidev-test
the drivers you mentioned came up with these
pi@octopi:~ $ lsmod | grep -i spi
spidev 20480 0
spi_bcm2835 20480 0
then I followed the SPIDEV_TEST steps and everything worked perfectly proving that the SPI connection is working correctly.
I was curious enough to try to run again
sudo adxl345spi -f 5
but only with the test connections
connect pin 19 (BCM 10 = MOSI) to pin 21 (BCM 9 = MISO)
and it worked, proving that there is no problem with the Raspberry
is from this point I will explain what happened to me to make it work:
I tried to do the reading of values but using an Arduino UNO using the SPI connection which gave me the same result as at the beginning, everything came to zero.
I am using the ADXL345 GY-291 accelerometer, I asked Chat GTP about any compatibility issues and he mentioned the following:
Quick explanation
The GY-291 has:
- A 10kΩ resistor connected between CS and VCC (3.3V).
- That means that the CS pin is always HIGH by default → forced I2C mode.
- Even if in your sketch you lower CS to LOW, the resistor pulls to HIGH, that's why the ADXL345 never switches to SPI mode.
After removing the accelerometer resistor I tried again to run the arduino sketch but I am still getting zero values.
This is when I came across the following post that mentions the problem between ADXL345 and SPI communication:
https://forum.arduino.cc/t/adxl345-gives-wiring-error-in-spi-mode/650191/7
daanvV mentions that the only way to make it work was by repositioning the CS pin and adding a 500 ms delay on the arduino.
so under that same logic I was looking in your fork that you made and the only thing I modified was a line in /ADXL345/adxl345spi/adxl345spi.c
const double coldStartDelay = 0.1;
to
const double coldStartDelay = 500;
I ran sudo adxl345spi -f 5 again and this time all the axes started to arrive with the numbers I was expecting.
with that I modified the adxl345spi.c file to the way it was originally and for some strange reason it still works as it should be
I don't know if removing the resistor helped with the solution but for now I will continue with the pluggin installation and the input shaping test.
Very good investigation. I will cross post this in the github as a reference too.
Thanks for sharing.
update:
I have been trying during these days the pluggin but I can't get it to analyze the results. After running the resonance in the X axis and finishing it in the octoprin interface, it stays in the loading window “Starting Input Shaping analysis...” I have left it for a whole day but it is still the same.
I have reinstalled the pluggin in manual as well as in automatic, I have also reinstalled Octopi, I even bought another accelerometer of the same model (which when I connected it and tested it, the reading of values worked at the first attempt) but the loading screen remains the same.
Sorry to hear(read) that.
Can you please open an Issue in the GitHub repo sharing the Octoprint.log and the Pinput_Shaping.log? Both logs are located under youruser/. octoprint/logs
With that I can take a look on the issue, looks like I missed a dependency in the plugin's deps requirements and some process is not finishing because of that.
