High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

scalar measurements in multi-record fetch mode

Hi all,

I'm programming (first time) with niScope in the Labwindows/CVI environment (v6.0) for a PCI-5124.  I've tackled my task by making incremental changes to one of the example programs: MultiRecordFetchMoreThanAvailableMemory (MRFMTAM). The goal (for now) is to create a simple text file with the timestamp and maximum waveform voltage for each triggered record. The Timestamps and MeasurementLibrary example programs seemed like good candidates for merging with MRFMTAM to accomplish this.

The timestamps work great, but I'm having trouble with fetching scalar measurements: inside the acquisition loop in MRFMTAM, I make the following call (verbatim from GenericMeasurementLibrary.c, and where timeout = 5.0):

      handleErr (niScope_FetchMeasurementStats (vi, channelName, timeout, scalarMeasurement,
                                                scalarResult, mean, stdev, min, max, numInStats));

If I request just one record, the result is correct: scalarResult[0] contains the maximum voltage of the sampled waveform (reading just one channel). So I believe the variables are correctly set, initialized, etc. But if I try to read multiple records, the value of scalarResult[0] stays fixed at the voltage from the first record -- it never changes. And numInStats = 1 even though the stats function is called each time through the loop.

I've gone through all the docs to find out if there's something special about measurements in multi-record mode, but haven't found anything. Why does FetchMeasurement think it's only be called once when in fact it's being called many times?

Thanks for any advice.

Zaven

p.s. Sorry about not including code -- I'm writing from home after hours...
0 Kudos
Message 1 of 8
(7,683 Views)

Hello Zaven,

scalarResult[0] will always be the measurement for the first record, or record 0.  The measurement for the second record, or record 1, will be stored in scalarResult[1].  The numInStats parameter should increase each time you call niScope_FetchMeasurementStats unless you call the niScope_ClearWaveformMeasurementStats function.  Take a look at the attached CVI code.   I modified this from the Measurement Library shipping example to display 2 records of measurements.  Notice that the numInStats indicator increases continuously until the program is stopped or the niScope_ClearWaveformMeasurementStats function is called.

I hope this helps.  Please let me know if you have any further questions.

Regards,
Sean Close
Product Support Engineer:  High Speed Digitizers

0 Kudos
Message 2 of 8
(7,668 Views)

Hi Sean,

Thanks for your note. Unfortunately, this doesn't really address my problem. The array index for scalarResult and numInStat counts waveforms, not records (right?). I look only at index 0 because I'm only reading one channel.

My code is attached. Please run it and let me know if you see the numInStats value increase above 1.

I must be doing something wrong with the measurement setup, but the only difference between my code and MeasurementLibrary
is that I put the ATTR_MEAS stuff outside (before) the loop, instead of in it -- most of them default to sensible values anyway.

Thanks again,

Zaven

0 Kudos
Message 3 of 8
(7,664 Views)

Hi Zaven,

The scalarResult array returned for a channel list of "0,1" would be:

statistics for record 0, channel 0,
statistics for record 0, channel 1,
statistics for record 1, channel 0,
statistics for record 1, channel 1

Since you are only acquiring from one channel, the index of the scalarResult corresponds to record number.  However, you are only fetching one record at a time, so you will never have anything beyond index 0 in your scalarResult array.

I ran your code as is, and I didn't notice any strange behavior.  It runs as I would expect it to.  In the Standard I/O window, I see 100 rows displaying the record number, scalarResult[0], 0.0000 (because there is no value in scalarResult[1]), and the numInStats (which increases from 1 to 100).

Attached are some screenshots.  Is this not what you are seeing?  What are you using as an input signal?  Please attach some screenshots of what you are seeing.

Regards,
Sean Close

Download All
0 Kudos
Message 4 of 8
(7,653 Views)
Good morning, Sean.

I definitely do _not_ see what you're seeing. Screenshots of my code's (same as the copy you ran yesterday) output are attached. You can see that scalarResult[0] stays constant no matter how many records I request, and numInStats is always 1.

I should have mentioned that I've got version 2.9.1 of NI-SCOPE (shipped with the hardware). I see that newer versions are available from your site, so maybe I'll try upgrading while you're mulling this over.

Thanks!

Zaven

Download All
0 Kudos
Message 5 of 8
(7,639 Views)

Hi Zevan,

This makes sense now.  There was a bug in Scope 2.9.3 and lower which caused this bahavior.  If you fetch records or measurements one at a time, it will always give you the first record's information.  As a workaround in 2.9.x, you can fetch all 100 records in one call.  Then your scalar Result Array will include all 100 measurements, not just the first record's measurement.

This bug was fixed as of NI-Scope 3.0.  You should not see this behavior once you upgrade.

Regards,
Sean Close

0 Kudos
Message 6 of 8
(7,633 Views)

OK, cool. Thanks for confirming that, Sean.

My only problem now is that NI-SCOPE 3.0 and higher want CVI version 7 or higher, and I only have v6.0. How hard & fast is that version requirement?

I'm doing some parallel development using gcc (in cygwin) -- sounds like I may be restricted to that environment once I upgrade NI-SCOPE.

Thanks,

Zaven


0 Kudos
Message 7 of 8
(7,629 Views)
NI-Scope 3.1 and later should, for the most part, still work with CVI 6.  The installer will detect that you have CVI and install the header files, function panels, and examples to the correct places.

Some examples have updated .uir files (saved in a higher version) that will result in errors if you try to build and run them.  However, I think the example you're interested in (MultiRecordFetchMoreThanAvailableMemory) has not been updated and will continue to work in CVI 6.

You may also run into errors when accessing certain functions in the function panel. 

However, neither of these changes should affect your ability to build applications in CVI 6 that use NI-Scope.
0 Kudos
Message 8 of 8
(7,606 Views)