Sampling two channel simultaneously in NI PCI-5922.

[ritesh777]

I want to sampling two channel simultaneously using LabView programme which is basically ProducerConsumerDataAcq vi. in PCI-5922 (32MB per channel) DAQ card. I want to know that the LabView vi I am using here is the correct for performing sampling of two-channel simultaneously.

Another problem,It is showing error "The requested data has been overwritten in the memory" after few second fetching data When I sample two channel at the sampling rate about 10Mhz and 10368 sample each. I want to acquire data for 1hr approx but using this LabView vi, I can't acquire data for an hour.

How can I fetch data for an hour for both channel simultaneously and save in the file?

thanks

Ritesh

[LocalDSP]

There are possibly different limitations to be aware of

1 - You are displaying your data continuously, so quite CPU demanding at 2 x 10 MS/s. Can you try to disconnect your graph and see if that helps? If it does, then you could consider graphing snapshots instead so either a small subset of each iteration or only graph every N iterations.

2 - The PCI-5922 is a PCI board, not a PCIe (express) and fetching two channels of 24 bit (3 bytes) at 10 MS/s adds up to 60 MB/s. While theoretically possible it may be challenging for your PCI bus. However the 5922 does not have a full 24 bit dynamic at a sample rate of 10 MS/s, so maybe you can get away with 16 bit (??). Can you try to Fetch binary I16 data instead and see if that resolve your problem?

Note that when you fetch binary data you'll have to manage the calibration coefficients separately, so it will complicate you code.

[ritesh777]

Sir/ Madam, Thank you so much for your reply. 

In your first answer, You want to say that your LabView programme is correct to perform simultaneous sampling of two channel but I have to disconnect the graph pallet. I don't understand, Please clarify it.

The resolution of PCI-5922 at 10MS/s is 18bits. I am saving the data in WDT formate because I want to do spectroscopy analysis of the data. If I am saving in I16 data formate then it is well to perform spectroscopy of this data type. I don't know that is why I am think about the programme through which I acquire the data in WDT formate for a long period about 30minute or above. 

I am newbie in LabView, Please help me regarding to this.

Ritesh

[LocalDSP]

Hi ritesh777,

     Let me clarify.

   Yes the VI you are using is fine for logging your two channels Scope data. Also I understand it works well for you until you get the data overwrite error. That error occurs if you are not able to fetch your data fast enough and save it to disk. If that happens you'll 'run behind', that is you will fill your acquisition buffer and at some point (after a number of seconds) it will be filled with data that you have not yet stored to disk.

   There are two types of buffers to take into account

1 - You acquisition buffer. That buffer will be filled with the continuous data stream coming from your board. That data is retrieved with the niScope MultiFetch VI. So if the top loop is not running fast enough you'll overwrite that buffer after some time. I suspect this is what happen in your case

2 - Then there is the queuing buffer that holds the data until it gets written to disk. For now I would not suspect that one to be a problem as it is configured with no limit sizes. But if you only have 1 GB of RAM available it is after all only 15 sec worth of data. So a slow disk is still possibly a problem.

When you are plotting the data on the front panel you are using a lot of CPU and that may be the reason why your top loop isn't running fast enough. That is why I suggested you to try to disconnect the graph. If you do that you will not be able to see the data on the front panel anymore but it will still be stored on disk. If that fix your problem (that is you can sustain streaming to disk for 30 minutes without error), then you know the graphing was the root cause of your slow down.

If that doesn't help I suggested you to try to reduce the data size to for example 16 bit to start with. If that help, you can then try to increase to 32 bit. So in general reduce stress in your system (fewer data, no display, eventually lower sample rate...) until it works. Then you can start increasing requirements. It's a trial and error approach that starts from a working system.

Hope this helps!