New Accelerometer and LabView

[gwpierson]

So the new accelerometer for 2010 gives you the choice of hooking up to either spi or i2c. The documentation says that these should be attached to the digital sidecar in either the i2c area or DIO 1-4. However, the vi's associated with the accelerometer only allow analog inputs. I know last year's accelerometer required analog inputs, so i'm assuming the vi's are a carry over. So: A) Does someone have some accelerometer vis that will allow digital inputs? or B) Can this accelerometer be plugged into the analog breakout?

[kamocat]

Unfortunately, it's not analog this year; it goes into the I2C port on the digital sidecar.
Perhaps this thread will help:
http://www.chiefdelphi.com/forums/sh...d.php?p=900068

[gwpierson]

Hmm, thanks for the reply. I had a feeling that was the response i was going to get about B). However, here's hoping someone has a workaround for the analog .vi's. If not, the team will probably just have to use the analog acc from last year.

[Joe Ross]

There is an example in LabVIEW for the I2C accelerometer.

[kamocat]

Really?
I see no mention of "accelerometer" or "I2C" in Begin.vi.

[Joe Ross]

Originally Posted by kamocat

Really?
I see no mention of "accelerometer" or "I2C" in Begin.vi.

In the LabVIEW examples, not the framework code.

[kamocat]

Thank you!
I'll move the functions to my palette.

Do you know if the I2C port supports multiple-byte reads?
If so, does this mean it could do continuous measurement, without having to re-address to the accelerometer?

[jhersh]

Originally Posted by kamocat

Do you know if the I2C port supports multiple-byte reads?
If so, does this mean it could do continuous measurement, without having to re-address to the accelerometer?

It does... but only up to 7 bytes per transaction (i.e. without readdressing).

[kamocat]

Well, as a follow-up:

I finally got around to wiring the accelerometer up. For some reason, I'm not getting any accelerations back from it.

I haven't bothered yet to see if I'm actually connecting to it in the first place. However, I did test the wiring before turing the robot on.

Did you know: Only one of the two sets of PWM-style I2C headers are connected? (The lego-style female RJ-14 is connected as well)

[jhersh]

Originally Posted by kamocat

Did you know: Only one of the two sets of PWM-style I2C headers are connected? (The lego-style female RJ-14 is connected as well)

That's cause the 4 pins farthest from the RJ connector are slow digital outputs, not I2C. You'll notice that the silk screen on the Sidecar says "OUT" next to them. We never bothered to add support for them to WPILib, but the FPGA layer supports them.

[kamocat]

Originally Posted by Error code -44095

The I2C sensor identification string did not match. The expected sensor is not at the address and bus specified. The sensor was expected to return "Address: 58" but instead returned "Sensor did not respond."
I2C.lvlib:Read.vi>>I2C.lvlib:Open.vi>>ADXL345 I2C Open.vi>>i2c accel.vi
<time>06:23:27 02/05/2010
<unique#>1

Any ideas why this might be? I double-checked the wiring. I even checked the code to make sure it had the right address.

[jhersh]

Originally Posted by kamocat

Any ideas why this might be? I double-checked the wiring. I even checked the code to make sure it had the right address.

Triple check the wiring? It's usually cause by a wiring issue. Do you happen to have a logic analyzer that you can use to look at the bus?

[kamocat]

No, I just have an O-scope. (I don't think it'd show me much in this case, or I would use it)
The battery was low, so I put the bench-test on an external 13v supply. No change in response.
Should I try running a Driver Station, to see if that makes a difference?

I guess this brings up the other question:
How easy is this board to fry from heat or static electricity?

[jhersh]

Originally Posted by kamocat

No, I just have an O-scope. (I don't think it'd show me much in this case, or I would use it)

Well... if you can watch the data and clock lines you can check that the address is being sent correctly and that the address is actually not acked.

Originally Posted by kamocat

The battery was low, so I put the bench-test on an external 13v supply. No change in response.
Should I try running a Driver Station, to see if that makes a difference?

The driver station should not need to be connected as long as your code is getting called. Never hurts to have it, though. One less variable to worry about.

Originally Posted by kamocat

I guess this brings up the other question:
How easy is this board to fry from heat or static electricity?

No idea... I've never seen one die.