Streaming Data from 6537s to Disk with another card as well.

[jonnnnnnn]

Hello, we are planning to have a rig that has 3 PXI 6537s and another card for reading a Synchro signal (North Atlantic Instruments 75C3). We have to capture the PXI cards at 10MHz and the 75C3 at 10Hz to 20Hz, it doesn't matter if we sample a bit faster than that but we can't go much slower. We have to store the output in a known file format so we can analyse it later.

Starting with the Reference Example for Streaming Data from Dual PCIe 6537s to Disk example (http://zone.ni.com/devzone/cda/epd/p/id/5315), it seems straight forward enough to added another PXI card.  We're OK with that.

What is the best approach to take for the Synchro card?

Our first choice so far is:

Make it read a value from the Synchro each time it goes around the producer loop; i.e. every 20ms. This will sample at 50Hz but that's OK. We store the values in a fixed size zero value array and then push the array onto the queue at the end of the 'true' case.  This is easy enough but....Will the 3 Raw 1D U32 DAQmx reads run quick enough to allow the Syncro values to be pushed onto the queue, within the 20ms window? (We've worked out that there should be about 16MB of data per card, for each read). If not is it close enough that it could be tweaked to allow the Synchro data to be queued as well?

Our second option is:

We are considering reading the synchro data into an arbitarily large zero initilized array, mainly so we know the size when we write the data to the file. This can be populated, at 20Hz, in what I'll call (or the sake of argument) a second producer loop. We could protect access to it using Semaphores. In the consumer loop we can read the three blocks of data and then the Syncro data; i.e:

• read three lots of data from the queue
• lock the semaphore
• write the content of the array
• zero the contents of the array
• unlock the semaphore

Does anyone know of a decent/better way of doing this?

Are we on the right lines?

Thanks,

Jon.

[JTG_Wilson]

Hi Jon,

I think the first option sounds like it would be the simplest to implement. I don't know whether you would have a problem with the time taken to push all the values to the queue, that partly depends on the processing power of your PXI controller, I think the only real way to be sure is to try it.

Will this be running on a Real-Time PXI controller or Windows OS PXI controller? Because that will also affect the speed of the code execution as the processor will have lots of other tasks that it needs to do if you are running windows rather than Real-Time.

I hope this helps.

[jonnnnnnn]

Hi,

thanks for replying.

We came to the same conclusion  as that, try the simpliest one and see if it works. I am trying to set get a feel for anticipate level of success before we cough up for the hardware. We've run it with simulated equipment, in LabVIEW, but it needs to use different sample sizes to those specified by default; we are assuming this is because it's an emulated card and is therefor slower. Is that assumption correct?

It's a Windows OS PXI Controller, with Intel i7 Processor(s) in it. I think I need to look on how to set the LabVIEW to run at high priority, just in case. We are taking the LabVIEW Real-Time 1 course in May, hopefully that will also provide useful information.

Jon

[JTG_Wilson · Accepted solution]

Hi Jon,

Yes I think your assumption is correct.