My team has been having some trouble with the ADXL345 accelerometer. When we try to read from it, the loop within the spi read vi falls into an infinite loop. We have downloaded the updated ADXL 345 SPI vi’s, and we tried it with i2c with the same results. We also know that it is not a problem with the accelerometer, because the problem exists with a second accelerometer.
does anyone think of any reason why this would happen, or what we could do to correct it?
A good place to start is the examples that you’re given. You already have functional code for both ways to read that sensor. Go under Help->Find Examples and then go under FRC Robotics->Sensors. You’ll find example code for reading the ADXL345 with both I2C and SPI interfaces.
I’d also suggest that you double check your wiring and make sure everything’s connected correctly (IIRC, the front panel diagrams to the examples also have some wiring drawings to check against).
I just tried deploying the example code on the CRIO, and the wiring is the same as the wiring diagram, it’s still getting stuck inside an infinite loop.
What could possibly be the problem, as this is not specific to this accelorometer, I am not sure what mistake I could possibly be making…
we are having the same problem, the infinite loop, and we are lost too…
The example code is supposed to be an infinite loop. It’s an example to show you how to read the accelerometer in code. If the front panel controls are showing you correct values, then everything’s working fine. You can then use that code as a springboard to write your own code for your robot project. Remember that the examples are just that: examples.
I understand that, but the problem is that it’s not getting any data. The infinite loop is in the “read spi” vi, and the problem is that it’s not reading anything. screen cap attached of the problem area attached.
in the picture, the problem is that that while loop isn’t ending.
Update: Not sure what we did, but we’re no longer getting stuck in that loop. Unfortunatly, while we’re getting data back, that data is consistently zero. Is it reading from the correct register? or do we need to set that ourself?
So does anyone know what you need to change in the example in order for it to work? I checked my ports, and they’re all correct, but I’m only getting data of zero…
One thing we found was that the accelerometer example read loop was set to stop if read status showed an error (in the I2C code.) By removing that stop condition we were able to get readings even though there was an occasional read error. Adding a graph indicator allowed us to see the values read over time.
Just to save some time, I’ve done the latest Utilities update, used both round and flat cable, triple checked my wiring. We are using I2C.
When I have the right digital module (1) selected, I get “0” as the reading. Bypassing the stop from “status” I can read the error.
-44095 It is anticipating address 58 but received … “Sensor did not respond”.
When selecting the wrong module (2), I just get no errors and “0” as a reading.
Any ideas?
I had the same problems, and the only thing that worked for me was to use the flat cable and use I2C. I couldn’t get SPI to work no matter what (in fact, I can’t figure out for the life of me how the SPI VIs are supposed to work, they’re arranged in a very strange way). Even the supposedly fixed example didn’t work, and I even noticed the problem and tried to fix it before the fix was posted.
Anyway, use a flat cable, and use I2C. Make sure your cable is fixed according to these instructions: http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2012_Assets/DB37%20Ribbon%20Cable%20Assembly%20-%20Rework%20Instructions.pdf
Well I got an accelerometer working, but not the ADXL 345. The electrical head on my team found an ADXL 335 in the drawers, and we just wired that up to the analog and read the voltage.
I’m not sure if this is an option for other teams, but it’s working fine for us now. I hope you guys figure out why the 345 isn’t working though…
