Multiple loop timers for data acquisition

[TheSnark]

Hello All,

I am currently developing a VI for FPGA deployment. My hardware consists of a cRIO-9072 chassis/controller with 1-9211 thermocouple module, 1-SD card module, 3-9215 AI modules, and 2-9219 Universal modules. I will be collecting data from two thermocouples on the 9211, 14 channels on the 9215, and 6 channels on the 9219 modules. This system is communicating to the host via ethernet. 

I prepared a vi (see attached) that used two DMA FIFOs to write DAQ data at different frame rates. I will be sampling from the 9219s and 9211 much slower (500 ms per samples), than the other channels (40 kS/ch/s). Currently, my FPGA vi is only trying to sample two different modules. When I run this on the host vi and try to read the data, i only get snippets of data at different intervals. If this a results of the latency asscoiated with the connection, or the host vi cannot refresh fast enough? I am relatively new to labview, so any help is appreciated. Thanks.

Gaussy

[Jeremy_B · Accepted solution]

Hi Guassy,

There are a couple things you'll need to change:

1)  You need to separate your acquisition in the FPGA into two separate loops if they are to run at different rates.  As it is, it will probably run at the slower rate of the two settings.

2)   You need to do the same in your real time VI, or set up the DMA reads so that they will be read at the same rate.  For example, suppose one module acquires at 1000 hz and the other at 200 hz.  If you want to read 100 samples from the first module (so your reads will occur at 1000 hz / 100 samples = 10 hz), you will need to read 20 samples from the slower module so it is synchronized with the first module.

3)  Your timeouts are too short on your DMA reads.  Your slow acquisition is at 500 us.  It will take 50 ms to read the requested 100 samples, but the timeout is set for 10 ms, so 4 times out of 5 the read will return nothing.  

4)  You are using graphs rather than charts.  A graph will only display the current buffer of data that has been written to it.  The front panel's update rate is non-deterministic, so you may not see every update.  If you use a chart, the chart will record all data written to it up to a specified depth (default is 1024 elements).

Also keep in mind that you can only have three DMA FIFOs between the host and FPGA target, so use them wisely.  Often it is easier to run your acquisitions on the FPGA all at the same rate and send everything through the same DMA FIFO to the real time VI.  If you need some channels to log at a lower rate, you can always throw away the excess samples (there are some decimate waveform VIs which are great for this).

I hope that helps! 

[TheSnark]

Hi Jeremy,

Thanks for the information. I will give this a try and see how it improves. I wanted to sample all at the same rate, and decimate, but I figured my data throughput would be too high for ethernet communication between host and vi.  That would be a limitation, no? 

Thanks again.

Gaussy 

[Jeremy_B]

Hi Gaussy,

You can decimate your data on the real time controller, before you send it over ethernet.  Also, the amount of data you can stream will depend on your network.  If you want reliable datalogging, it is best to stream over TCP/IP, use shared variables, or log to the filesystem on the controller itself and download your datalogs later.