LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-8451 SPI interface with analog devices isensor

Ok. I needed to focus on other aspects of the project, but now I'm back in focus on making the ADIS sensor work with labview. Right now, I switched to ADIS16362, which communicates in identical way with the older sensor, but with different accelerometer range.

 

I tried your latest vi. This is what happens:

For the first few reads, it seems to work fine. But then after 5-6 readings, the data output is only giving 0x11, 0x0, 0x11, 0x0, and so on for the burst read. The gyro read also behaves similarly. Now if I unplug the 8451 from the computer, re-connect it, it will read some seemingly useful data for 5-6 reads again, and do the same thing again.

 

Any ideas? I'm still in process of reading articles and understanding how this ADIS sensor and SPI interface works. 

 

-Leo-

ps: i attach the datasheet for ADIS16362

 

0 Kudos
Message 11 of 30
(1,807 Views)
Sorry for the delayed response. This dropped off my radar, as the email notification of the response got buried in my inbox. Anyway, I can't really say for sure what's going on. If I had the device in my lab here I'd put a scope on it. The VIs I sent you were not designed to be run in a continuous matter. For insance, it makes no sense to configure the 8451 with each run. If you are going to be reading continuously then you need to have a loop around the "Write Read" VI. I'm not saying that's the problem - just pointing out its intended usage as an example.
0 Kudos
Message 12 of 30
(1,779 Views)

I managed to get a consistent reading without the problem described in my previous post if I do it without the while loop.

 

Now I'm trying to do this with a while loop. I tried to loop it in this way (vi attached). but i got an error (read data is 0x11, 0x00, 0x11, 0x00) reading after few hundred iterations. ideas?

0 Kudos
Message 13 of 30
(1,760 Views)

elpiar wrote:

I managed to get a consistent reading without the problem described in my previous post if I do it without the while loop.


Tad confused here. I thought you said when you ran the example VI I had posted you were getting bogus data after a while. If you were running it without the loop, what exactly were you running, and how were you running it?

0 Kudos
Message 14 of 30
(1,755 Views)

sorry for the confusion.

 

In my first post, I got bogus data after 3 runs without using while loop. After changing the evaluation board connection, I no longer got bogus data no matter how many runs I do, as long as without using the while loop.

 

However, when I use the while loop per vi attached, I still got bogus data after some time. So now that I think of it, maybe I have not solved the problem after all. 

 

I guess my question is specifically about the while loop. Did I do it right in the vi i attached?

0 Kudos
Message 15 of 30
(1,749 Views)

The error cluster tunnels for the loop should be shift registers. If an error occurs in one iteration it will be lost since you do not stop the loop on an error, and the Write Read function only ever sees the original error that was passed in. So, you should change the tunnels to a shift register, and you should probably stop the loop if you get an error. You may very well be getting an error but the way it's coded you'll never know.

 

I am assuming that you were using some non-zero value for the loop delay. You may wish to try a really long delay to see if the hangup is a timing issue.

0 Kudos
Message 16 of 30
(1,740 Views)

Am I correct in placing the configuration property node and the 845x close reference outside the while loop?

 

I am still new to the SPI communication protocol. do you have any suggested reading (especially regarding the timing issue, if any)

 

0 Kudos
Message 17 of 30
(1,734 Views)

elpiar wrote:

Am I correct in placing the configuration property node and the 845x close reference outside the while loop?


Yes. In general the configuration and close should be done outside the loop.

 


I am still new to the SPI communication protocol. do you have any suggested reading (especially regarding the timing issue, if any)


The timing issue, if any, would be related to how fast you can request information from the device, rather than a general SPI bus timing issue. If there were a SPI timing issue you'd get no data. For instance, with some devices you can continuously request data, but the device may have a limit on how fast you can request it since it may be busy doing other stuff. This information would be in the device datasheet. 


As for general SPI protocol information, just Google for "SPI tutorial". There's lots of info on the internet regarding the protocol itself. 

 

0 Kudos
Message 18 of 30
(1,727 Views)

There is no error being reported and inquiring the status of the isensor also yield no error code.

 

Here is what happens, reading from x-axis rate gyro

 

1st read: 0xBFF3 (normal data)

2nd read: 0x BFF4 (still normal data)

3rd read: 0xBF00 (bogus data)

4th read: 0x1200 (bogus data)

5th read: 0x1200

 

and so forth

 

now when I change to a read a different address (ex: different axis rate gyro)

1st read: 0x1200 (bogus data)

2nd read: 0xBF00 (bogus data)

3rd read: 0xBFF6 (normal data)

 

gives about 4-5 reading of normal data, and then the same thing happens again.

 

 

 

0 Kudos
Message 19 of 30
(1,717 Views)

Is the above with your VI (the one with the loop), or with the VI that I had posted (the one without the loop)? What happens if you change that first value in the array control on your VI from a 5 to a 4?

0 Kudos
Message 20 of 30
(1,688 Views)