As a learning step, we were working through some of the sensor examples with the freshmen to get used to Labview and how sensors return data.
We worked through the encoder, encoder with motor, and the gyro examples, and then wired up the ADXL345 Accelerometer in SPI mode (What does SPI mean?) and we could not get it work.
We would hit the run on labview main panel, the checkerboard would go away, indicating it was running, but no data was being returned to the front panel. Bringing up the block diagram, and trying to probe any data wire, showed it was “Not executed” This was the same for the data prior to the loop, or in the loop, the whole diagram was not executed.
Turning on the light bulb showed nothing of interest either.
So if you have any idea, what I am doing wrong, let me know.
Or if you have done this example in the 2012 labview and it worked, please let me know that too, as that would confirm it was on my end.
SPI is a digital communication standard that involves 4 interfacing wires:
CK (SCLK) - Serial Clock, a clock signal that controls timing of signals in the device
DI (MISO) - Master In, Slave Out, or in our case, Data In
DO (MOSI) - Master Out, Slave In, or in our case, Data Out
CS - Chip Select, or often called slave select (SS), selects the chip for communication, this signal has inverted logic, meaning you pull the device to logic low to select the chip as active.
Of course, that’s not all… For the ADXL345, you also have 2 power wires:
Before executing the code, press the Highlight Execution button, and follow where the code stops. It is important to keep the block diagram open so it records what executes and what doesn’t execute. If it’s not open, it doesn’t show you the history.
When using the ADXL345 in previous years, I chose I2C instead of SPI because it uses fewer wires. I don’t remember ever trying SPI, so I can’t personally confirm that it works.
The “not executed” indication on a probe just means that it hasn’t been executed since the probe was attached. If you run the VI and then put a probe on a wire, you’ll never see any values for things that only produce an output once at startup. So nothing outside the loop will have a value unless you place the probe before running the VI.
If you somehow managed to stop the VI when you opened the block diagram, you won’t see any values either. Can you confirm that the “run” arrow at the top of the diagram is in the “running” state (solid black)?
Thanks for the links, a little better documentation, but it all matches the front panel of the example, and the way we wired it.
Alan and Joe, thanks for the response.
We have moved on to more pressing items, like bang-bang motor control vs. take-back-half for our shooter rpm control.
I will try and get back to this once we are looking for something to do, but at the moment, we are working on stuff we actually going to use on the bot this year. Being that we are not a climber, hopefully we don’t have to know how many G’s we pull when we fall 7’ and bounce off the floor.
First, here is the sensor manual from 2011. We found it sortof helpful in first learning how to use the sensor.
Some notes:
For SPI, there’s a hazy memory about not having the right DIO selected for a specific input from the SPI interface on the accelerometer, refer to the sensor manual or the datasheet for the ADXL345 to learn about what the various acronyms on the board are actually for (and thus know you have the right DIO selected in the LV example.)
I2C has been the most hasslefree for us
the code in the WPILib for the I2C ADXL345 expects a default hardware address, find out what that is. (For example, with I2C, we had plugged the 4 wires into the wrong I2C ports, and just moved it to the other ones. Hey presto, it worked.)
