11-21-2012 08:03 AM
You should not need the Wait Until Next ms Multiple in the loop that is reading the SPI Streaming. The read will wait until it has the required bytes. Is there a reason you have the bytes set to 56? It should be the amount of data bytes you expect for each read.
11-21-2012 01:10 PM
I have removed the the wait until next ms vi and it seems to get me closer to my desired result. I think I am unclear about the difference between the number of bits per sample on the SPI stream configuration and the number of bytes per read input on the SPI stream read vi.
My understanding is the number of bits per sample defines how many bits to set the clock up for. By default, the 8452 clocks 8 bits (1 byte) at a time before having to incurr overhead to set up the clock again (for another 8 bits). I believe this is about 2 microseconds on the 8452 and 10-20 microseconds for the 8451 (can't seem to find documentation on that right now). So with this number of bits set to 56, there would be 56 clocks before having to incurr clock setup overhead again. These 56 bits would be 7 bytes...1 for the SPI read command and 6 for each of the 6 registers with acceleration data. So the 8452 may read one complete set of data in one pass before having to perform clock overhead. Is this correct?
My understanding of the number of bytes per read input on the SPI stream read vi is that read command will read that many bytes using the clock parameters defined in the SPI stream configuration. In order to get any data output from the sensor, I had to change this value to 196 which is the full amount of the FIFO buffer for this sensor as defined on page 49 in the application notes which is attached. So for this set up, the 8452 will read 196 bytes in groups of 7 bytes for each call to the SPI stream read vi. Is this correct?
As a side note, the 196 bytes mentioned in the application notes does not seem to make sense because there are 32 slots in the FIFO for 6 addresses which would make 192 bytes of total data...not 196 but when I use 192 on the number of bytes per read input to the SPI stream read vi, I get garbage data while using 196 gives me accurate data (just not at the correct timing).
As I was writing this, I think my root problem was that I had forgotten in my VI there are two places to control the SPI clock rate. One is a tool on my VI which is only for standard mode and has NO effect on streaming mode as I have values for the clock timing in the SPI stream configuration. I think I need to change clock high and clock low times on the SPI stream configuration to be a consistent speed with the output rate from the accelerometer.
11-26-2012 07:46 AM
Yes, the number of bits per sample sets the number of bits to be clocked in from your device; this is dependent on your device specifications as you had mentioned previously. The number of bytes per read refers to reading from the buffered samples from the USB-8452. These are bytes that the SPI device has already read and buffered. It sounds like you may have figured out the discrepancy in your last reply, however.
12-05-2012 06:02 PM - edited 12-05-2012 06:09 PM
I have been able to get the SPI stream mode and daqmx working in the same loop. They aren't exactly in sync though. The DAQmx data seems to arrive before any data from the SPI. A time shift is not ideal but I may be able to live with that. I have seen that there is extra data coming from the SPI and haven't yet been able to resolve that. The current vi is attached.
Another question I have is can you use standard SPI vi's in the same loop as an SPI stream? I am trying to monitor the FIFO status of the sensor but which is the second register after the final data register (0x28 - 0x2D are data, 0x2F is the FIFO status). I was trying to use read 9 bytes (read command and address byte + 6 data registers + 2 registers for FIFO status) on the SPI stream read command with 72 bits per sample defined in the SPI stream configuration but that will not run at all (not even an error message). So I think the sensor or the 8452 are not capable of this many bytes at once. Any thoughts on this?
12-06-2012 12:25 PM
I am glad you are able to semi-synchronize your SPI and DAQ readings. Since the only synchronization we have here is software based, there will not be a high level of synchronization. As GPIB_GURU mentioned, to achieve a higher level of synchronization you would have to tie a line from the DAQ device to the DRDY pin on your SPI device. That would allow you to have hardware timing.
Streaming allows a constant, uninterrupted streaming read from your FIFO. If you want to read the status bits, that would interrupt the stream. If you are really wanting to read the status and read data, I don't believe streaming would be able to accomplish this. You would need to use either very low level scripting (not recommended if you are unfamiliar with scripting) or the basic palette and reading those bytes and the data bytes one-by-one. Also if the device, or the SPI device cannot send/receive 72 bytes fast enough, you may be unable to read that many bytes at once.
12-06-2012 01:14 PM
I think I understand what GPIB_GURU meant about tying a line from the DAQ device to the DRDY pin of the SPI device. So the concept is when the DRDY pin signals that data is ready on the SPI device, that will trigger the DAQ device to take data allowing tighter synchronization.
The NI page here states I could use a 9205 module (which I have but currently not used in the cdaq-9172). Will this then be able to control the entire chassis as I have my strain gages and analg accelerometers connected to the NI 9233 and 9236 as previously mentioned?
I believe I can use the instruction layed out in this white paper (pause triggering?) to get accomplish my goals.
12-07-2012 11:29 AM
What do you mean by controlling the entire chassis? All you would need is a digital output line coming from the DAQ device that feeds into the DRDY pin. I don't believe you would want analog thresholding or pause triggering; you just need a signal that you can synchronize with your DAQ device to send the signal to the SPI device.
12-07-2012 04:58 PM
I think I'm confussed about the concept.
The SPI sensor has it's own onboard timing for taking data which is specified in register 0x20. This sensor cannot operate on an external clock. So all items in the cDAQ 9172 (analog) must be dependent on SPI sensor clock, correct?
If so, then I need to have the DRDY bit from the SPI sensor tell the cDAQ when to poll data for all sensors. I'm not sure if that is even possible but this is the reason I thought pause triggering might work. When the DRDY bit goes high on the SPI device, that would trigger the cDAQ to take data.
If that is not the case, then start triggering may work as well as long as the SPI clock and cDAQ clock are identical speed, but the DRDY is contanstly changing between 0 and 1.
Am I missing a concept?
12-10-2012 08:43 AM
Sorry. I have been busy. I actually mean the exact opposite. The DRDY pin is an input the the 8452 streaming API. The streaming API can be configured to read a sample from the SPI bus on a rising (or falling) edge of DRDY. If you connected DRDY to your DAQ sample clock, you would read an SPI sample with each DAQ sample and the data would be synchronized.
12-10-2012 09:06 AM
Exactly. This information is stated in the 845x Hardware and Software Manual as well stating that DRDY is an input that can be used to trigger the streaming API.