New Accelerometer and LabView

[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.