Continuous multiple channel and multiple record fetching with the 5105

[jswalwell]

This is just a note for anyone pulling their hair out...I pulled all of mine out this week.

In my application I am continuously acquiring 5 channels of data, triggering on any of the 5 channels, waveforms are 300 points long, and I retrieve 300 records at a time.

Here's the deal: in order to pull the data out of the waveform array (5 channels, 300 points, and 300 records) you need to know that the first record will contain data for 8 channels, then 5 channels thereafter.  Why is this important? Because if you need to index your data array in a loop to retrieve channel data you need to setup the index so that on itteration 2, 3, 4...n the indexes count in  your active channel count beginning at 7.  In my case I had 5 channels configured.  On the first loop iterration indexing the array for whatever reason channels 0-7 spew data, then 0-4 thereafter.  So my indexes go 0, 7, 12, 17, 22, etc.  Look at my code.

[S_Hong]

Hi jswalwell,

I tried running your code on one of our test machines, but unfortunately, I did not observe the same behavior. Could you tell us what version of the NI-Scope driver you are using? Can we also try running the shipping example "niScope EX Multi Record Fetch More than Available Memory.vi" in your Example Finder under Hardware Input and Output » Modular Instruments » NI-SCOPE » Continuous Acquisition?

[jswalwell]

I am using NI-Scope 3.5. 

Did you mean to ask me to run that example?  It runs with no problem...because it only acquires from a single channel.  If you were to acquire from multiple channels, but fewer than 8, you should observe the same behavoir: the first record in the returned data array contains data from all 8 channels, subsequent records only contain data from the channels configured in the scan list.

[dklipec]

I also spent some time experimenting with your example.  I removed the queuing code and the part where you ignored errors, and added in a small graphing test which I think should show the problem if it is related to the scope acquisition.

The VI now plots ten waveforms, which should be enough to see a difference between the data format if the two records return different data sets.  The first two waveforms from each record set (which should be channels 0 and 1) are plotted with a different waveform format compared to the rest.  This should highlight them, and make it easy for you to see if they are coming out of the scope in the correct order.  Try running this VI with your test setup with single iteration (front panel's stop button pressed before running the VI), and multiple iterations in the while loop.

Using this configuration, I am not seeing any erratic behavior in which waveforms are plotted, and where they are indexed in the array.  However, it is not unreasonable that there is something unique to your configuration, so I hope that this simplified VI will help us track down what is going on.  I'm using NI-Scope 3.5 and a PXI-5105.  My test waveform is simply a sine wave fed into channels 0 and 1, with 2, 3, and 4 unconnected.  I'm acquiring channels 0-4 as in your original example.

You were getting the "Acquisition in Progress" error because the fetch can return before the board has gone to idle, potentially allowing you to try to reconfigure the board while it is still busy.  You can eliminate this spurious error by calling niScope Abort after the fetch.  Also, if your trigger times out and you want to change the trigger source, you must call Abort to stop the untriggered acquisition.  Timeout only applies to the fetch, not the acquisition.

[S_Hong]

Hi jswalwell,

After experimenting a bit further with the code you posted earlier, I believe I see what you were referring to. It seems like there may be a problem with the way the NI-Scope 3.5 driver is fetching multiple records with the Enable Record > Memory enabled. One additional note to this bug is that it does not simply seem to be adding extra waveforms to your record to offset the rows in your array, but rather it seems that any record aside from the first one may be incorrect. As a temporary work around, I suggest you disable this option as it does not seem that memory will be an issue with the current settings in your application. I have tried this on my test setup and it seems that the waveforms are now placed correctly in the 2D array.

I have filed a Corrective Action Request (CAR) regarding this issue. Please let me know if this is not a viable for you application so we can think of another workaround.

[jswalwell]

I have since added the abort.  This is a work in progress, but thanks for the reminder.  If the queu doesn't overflow, data is not lost and it doesn't matter where you pick up the data array and plot.  I have run a completely stripped version of this code.  Queing and error checking add an insignificant amount of overhead to the loop speed.  Acquire 5 channels using channel 0 as your trigger channel with a real signal only connected to channel 0.  You can then index through the record array and you will find that the first index (0) contains the measured signal (other channels unconnected = noise), index 7 contains the channel 0 measurement for the second record, then in index multiples of 5 to the end of the 300 record data array.  So you have to index = 0, 7, 12, 17, 22...300.  If there were no bug you would simply index the records by fives with index = 0, 4, 9, 15...300.  I haven't had a chance to test your code yet, I will later today.

[jswalwell]

I tested dklipec's modified code and it exhibits exactly the same behavior.

[S_Hong]

Hi jswalwell,

We have investigated the problem and have identified the issue. We are currently suggesting the following potential workarounds:

1. Downgrade the NI-Scope driver to version 3.4.

2. Reduce the number of records to fetch. You can try fetching one record at a time such as in the shipping example.

3. Reduce the transfer block size.

Please note that your current workaround is not a valid solution to the problem as even with shifting the index of your data array, the data may be incorrect. Please let me know if you have any questions.

[jswalwell]

Is scope 3.4 compatible with labview 8.6?

[Wallace_F]

Hi jswalwell,

If you haven't done so already, please don't downgrade to NI-Scope 3.4 if you are programming in LabVIEW 8.6.  NI-Scope 3.4 does not support LabVIEW 8.6.  At least, support for LabVIEW 8.6 was not in the list of features to install when I downgraded to NI-Scope 3.4 from version 3.5.

Regards,

Wallace F.