Measurement Studio for VC++

cancel
Showing results for 
Search instead for 
Did you mean: 

Locating most recent data when Overwriting unused samples

Software: VC++ 6.0
Driver: NIDAQmx 7.3
Hardware: PCI6602

I have a need to provide 8 frequency measurements to clients whenever requested, these are actually the average of the last 6 measurements. My original thought was to create a background thread as we have done in the past and read the values from the driver and store them in local variables to be reported as needed. 95% of this information will never be needed at all.

It occurred to me that a more efficient method might be to set the overwrite mode to DAQmx_Val_OverwriteUnreadSamps and set the buffer size to 6 (exactly the number of readings I want to average). Then whenever a request comes in I would read the last available readings and be on my way. It seems there is something I don't understand regarding the RelativeTo and Offset properties. What is the way to set these so that I always read from the oldest unread sample up to the most recent - this may be anywhere from 0 to 6.

I've tried setting the overwrite mode and the RelativeTo to the value DAQmx_Val_MostRecentSamp, but I get strange results so it seems I have something wrong. If I try to get the available samples for setting the Offset using DAQmxGetReadAvailSampPerChan it always comes back with 0 available after it overwrites.

Ed
0 Kudos
Message 1 of 10
(5,622 Views)
Ed,

When setting RelativeTo to DAQmx_Val_MostRecentSamp, the DAQmxGetReadAvailSampPerChan will always come back as 0, since this function is always looking at available samples ahead of the current sample. Since the most recent sample is set as the current sample there is nothing in front of it, so the available samples is always 0. To read the last 6 measurements acquired the Offset needs to be set to -6, since it is look backward into the buffer for the last six samples. When using these settings however, make sure there is six samples in the buffer before it is read, otherwise an error should be generated.

Andy F.
Applications Engineer
National Instruments
-----------------------------------------------------------------
National Instruments
0 Kudos
Message 2 of 10
(5,604 Views)
This all makes sense, but if I can't use DAQmxGetReadAvailSampPerChan to determine how many samples are available how do I make sure there are 6 samples available? This function is the only way I know of that provides this information.

Ed
0 Kudos
Message 3 of 10
(5,599 Views)
There really isn't a good way to programmatically look backward into the buffer. One way to make sure that there are enough samples in the buffer would be to use the timing information of the acquisition to calculate how long the program should wait before reading. For example, if the acquisition was running at 6 Hz, wait one second. Another way you could make sure there are enough samples in the buffer would be to read as you normally would, and if there was an error, ignore it and read again (basically continue to read until there isn't an error). Not very elegant, but it will get the job done.

Andy F.
Applications Engineer
National Instruments
-----------------------------------------------------------------
National Instruments
0 Kudos
Message 4 of 10
(5,588 Views)
That is too bad, because these are variable frequencies. I am measuring accelerations of motors so that creates a problem with this approach.

Ed
0 Kudos
Message 5 of 10
(5,585 Views)
DaytonaEd

The value returned by DAQmxGetReadTotalSampPerChanAcquired is independent of the read location and offset properties. You could try using this function instead.

-- Chris
0 Kudos
Message 6 of 10
(5,524 Views)

Not much documentation about that function (DAQmxGetReadTotalSampPerChanAcquired), can you describe how you expect this to behave using a continuous read and allowing the buffer to be overwritten?

Ed

0 Kudos
Message 7 of 10
(5,524 Views)
DaytonaEd:

The Total Samples Per Channel Acquired value should be monotonically increasing, regardless of whether the buffer is overrun or not. Thus, given your setup, if this value is >= 6, then you can successfully read 6 values.

I don't have the C API installed, but a wrote a simple test in C#, and this appears to work as expected.

-- Chris
0 Kudos
Message 8 of 10
(5,502 Views)
That works, thanks for the suggestion because I wasn't aware of this property.  Another question - is there a way to know if the counter rolls over when using the inverse period method???  We are measuring a wide range of frequencies and as it slows to almost zero we get rollover but need a way to detect it.
 
Ed
0 Kudos
Message 9 of 10
(5,479 Views)
Hello Ed,
 
You can use DAQmxGetCITCReached to see if the terminal count has been reached. You should get an error if the frequency gets too low. To get a lower minimum frequency use a slower timebase. To set the timebase for a frequency measurement you would set the counter timebase using DAQmxSetCICtrTimebaseSrc and DAQmxSetCICtrTimebaseRate. Please let me know if you have any questions. Have a great day!
 
Sincerely,
Marni S.
0 Kudos
Message 10 of 10
(5,460 Views)