Accelerometer Example of New Crio

Does anyone know if the ADXL345 SPI example works on the new Crio? I tried to run it and it gave me an error along the lines of ‘I can’t find DIO module 2’ Any ideas?

The obvious question is: do you actually have a second DIO module installed in your cRIO? It would go in slot 4 of a 4-slot cRIO-II, or slot 6 of an 8-slot cRIO.

The first DIO module is number 1, even though it’s actually installed in slot 2. That’s a different way of numbering things from previous years, and I expect it’ll trip up a few teams.

That is what i suspected as well, so I added a control to select crio slot (which defaulted to DIO2 BTW) and changed it to 1 but i received the same error. I know thats not a lot to go on, I will do some more investigative work tomorrow afternoon (how does school always seem to get in the way).

You selected Digital Module 1 and still got an error that said you have no Digital Module 2? Maybe you didn’t actually change the value. Did you make it a control on the panel of a VI and then deploy it? Did you re-build?

-Joe

“DIO2” sounds like a pin number, not a module number. You might have wired the control up to the wrong terminal on the Open function.

What Joe said to do should work - wire a control to the DIO Module terminal and set it to Digital Module 1. It looks to me like we have a “bug” in our example. By default the ADXL345 SPI Open.vi should have Digital Module 1 as default. We should probably also wire and show that on the example front panel. I will fix this.

Sorry if this has been covered elsewhere, I could not find the info we are looking for and I am not versed enough in LabView to figure it out…yet. :wink:

We can figure out how to run the I2C ADXL345 example, but where we are struggling is how to go about integrating the vi’s into our robot project.
As far as we can see, the vi’s to add the ADXL345 I2C are not available anywhere in the Functions pallet.

Can someone please point us in the right direction to help us figure out how to add support for the ADXL345 via I2C to our project?

In the project explorer in the example project, there is a folder called ADXL driver. Just copy these VI’s to your robot project

I’ve spent half of yesterday and all of today trying to get the ADXL345 working. I’ve tried both examples using two cRIOs, and nothing works. I did change the DIO module constant/control to 1 instead of 2. I did make sure the sensor is wired correctly. I see no reason why it wouldn’t be working.

I posted my question here after somehow missing this thread.

Please help! :frowning:

There’s updated files for the SPI ADXL345 example attached to the firstforge bug report. http://firstforge.wpi.edu/sf/go/artf1432

The fixed SPI example still doesn’t work for me. I’ve finally gotten I2C working though, apparently it only works with the flat cable.

Not sure what “flat cable” you are talking about. If it is the DB-37 cable from the kit, then it “only works” if you fix the cable end to not be reversed.

Yes, I meant that flat cable the replaced the thick round ones in previous years. What I meant to say is that the ADXL345 doesn’t work with the old cable, in other words only works with the newer flat one. (our cable needed to be flipped but we already did that)

It works with my thick round one. Maybe yours is just damaged.

-Joe

Taken from this thread: http://www.chiefdelphi.com/forums/showthread.php?t=100324

Sure, these are Java, but I’m still seeing a recurring pattern…

Several people have reported it worked with the fixed cable in this year’s kit, but not the DB37 from a previous year’s kit.

Looking through previous year’s KOP lists, it looks like there have been several sources. In 2009 and 2010, it was a cablestogo pn 02688. Last year it was SF Cable pn D720-03. Maybe one of these was missing a pin that related to I2C.

We also struggled with the ADXL345 in I2C mode. Running the included LabVIEW example the device worked intermittently. I looked at SDA and SCL with an O-Scope and noticed they where kind of floating when communication had error-ed out. My fix for this was to place a 100 ohm pull up resistor on both SDA and SCL. This made the ADXL345 perform wonderfully on the I2C bus. We have implemented this fix on our robot and so far have been very happy with the ADXL345’s performance.

100 ohms seems like a lot for I2C to me. The Digital Sidecar is supposed to have 3.16k on SDA and SCL. Can you check if those pullups are working?

You might take a look at the tutorial. From the LabVIEW Getting Started Window, click Tutorials, and then choose Tutorial 7 - Integrating Examples into Robot Code.

Thanks Doug, I’ll have our programmers do this today.
I believe I have a handle on it now, but I want them to understand the process. So, between the tutorial and my experience, we should be if fine shape!