Determining Sample Rate

[Nathan-P]

Vijay,

"One more question: Will I run into errors (especially with timing and no available samples and so forth) if I am reading ALL samples from buffer as they are being loaded into buffer? GIven my 2 jpegs, would you think that would work?"

I'm not sure how you are transitioning from your "initilize daq" to "read daq" states. I'm going to assume that you call the init case and then the read case for each 2000 samples that you request.  For example: initilize, read, initialize, read, initialize, read, etc.  

If your configuration settings don't change between each read, then if you move the niScope Initiate.vi from the end of the init case into the beginning of the read case, then you would only need to call the initilize daq case when you need to make a change.  For example, you would do: initilize, read, read, read, etc.  

When you call niscope Initiate.vi, the digitizer will acquire 2000 samples, and then transistion back into the idle state, NOT sampling.  When you call fetch, these 2000 samples will transfer from the hardware to LabVIEW.  If for some reason, all 2000 samples have not yet been acquired, the Fetch VI will wait until they are all ready, and then return them to you.  

In summary, you likely will not cause buffer overflows, and Fetch will handle the case if there are not enough samples ready.  You will likely not run into errors.

[Nathan-P]

Until now, I have reccomended acquiring your data as records.  It sounds like you want to acquire data just like our DAQmx products, where it is always sampling from when you call start until you call end.  Is this what you actually want, and then read all the data off in chunks?  

If this is how you actually want to write your code, then there is an example that will work this way.  Look at the example "niScope EX Fetch Forever.vi"

That example shows how to setup an niscope acquisition that will behave like a daq, since it seems that is what you really want.  In that example, each time you call fetch, it will grab the next 2000 samples, with no deadtime in between, and will run until you press the stop button.  

One warning I have is that if you don't call fetch fast enough, then the data in the onboard memory buffer will overflow, and cause errors.  This is avoided with the record acquistion case.  I would reccomend that you place the fetch VI in a loop without your processing code, and then send the data to another parallel loop to process the data using a queue.  That should minimize any timing issues you might find.

I hope this helps.

[TooEagerToLearn]

---

@Nathan-P wrote:

Vijay,

"One more question: Will I run into errors (especially with timing and no available samples and so forth) if I am reading ALL samples from buffer as they are being loaded into buffer? GIven my 2 jpegs, would you think that would work?"

I'm not sure how you are transitioning from your "initilize daq" to "read daq" states. I'm going to assume that you call the init case and then the read case for each 2000 samples that you request.  For example: initilize, read, initialize, read, initialize, read, etc.  

No, that is not how it is setup. It is "initialize" then read, read read read........ until stop ("readdaq" is queued in in the "readdaq" case_)

If your configuration settings don't change between each read, then if you move the niScope Initiate.vi from the end of the init case into the beginning of the read case, then you would only need to call the initilize daq case when you need to make a change.  For example, you would do: initilize, read, read, read, etc.  

This is how it is setup. "readdaq" constantly reads with 10ms intervals.

When you call niscope Initiate.vi, the digitizer will acquire 2000 samples, and then transistion back into the idle state, NOT sampling.  When you call fetch, these 2000 samples will transfer from the hardware to LabVIEW.  If for some reason, all 2000 samples have not yet been acquired, the Fetch VI will wait until they are all ready, and then return them to you.  

Does this mean, I have to move the "Initiate vi" to "readdaq" case before the Fetch functions? I assume I don't need multiple initiates for 2 channels.

In summary, you likely will not cause buffer overflows, and Fetch will handle the case if there are not enough samples ready.  You will likely not run into errors.

---

[TooEagerToLearn]

You hit the nail on the head. I want it to work exactly like daqmx products. I will look at those examples now that the numbers are squared away and I get the concepts. THanks!

FYI, I may not have shown the loop around the case structure in the jpegs. My bad. It is implemented in "Producer-Consumer" architecture. So initializedaq runs ONE time just like "Fetch Forever vi" and readdaq keeps running until it ends.

[Nathan-P]

Ok, then the example  "niScope EX Fetch Forever.vi" will be perfect for you.  The code outside the loop is the configuration/init code, and the code inside the loop should go into your read daq state.  

If you run into errors like "requested samples overwritten" or "hardware buffer overflow", then you will need to fetch the data faster from the onboard circular buffer. (ie more often or bigger chunks.)

I hope this helps.

Nathan

[TooEagerToLearn]

Would this change the minimum record length? Or can it still be 2000 and "numSamples" in loop be 2000 as well? 2000 numSamples is what I need. Goes back to my original question. What would be "minimum record length" in a FETCH FOREVER like setup.

Or would minimum record length has to be very very large....?

[Nathan-P]

minimum record length doesn't matter for the Fetch Forever setup.  Just leave it unwired.

[TooEagerToLearn]

Hi Nathan,

I have received more requirements regarding the measurement of AC Voltage and Current signals.  Our customer said that my using RMS.vi, I will have to be precise about obtaining a collection of NEAR TO EXACT FULL WAVE CYCLES (No partial waves), Otherwise, our power measurement will not be correct.

How do I know if I am measuring FULL WAVE CYCLES? Any thoughts? I  don't know where to begin. Thanks!

V

[Nathan-P]

Hi Vijay,
Since you can't know before you fetch data if you will recieve full wave cycles or not, you will need to do some post-processing (after fetch), and extract out of the fetched data, only full wave cycles, to pass onto your RMS.vi.  

I'm going to assume that the amplitude of the waves change over time, so the best way to get full cycles, is to determine where the zero crossings on the waveform are, and then between two zero crossings, take that array subset, and process it.  Any points you don't use at the end of the array, you could append at the beginning of the next fetch data, so you don't lose samples.  Then continue with finding the next level crossings, etc.

This is just one way.  If you need help implementing LabVIEW code, I would reccomend posting your questions into the LabVIEW forums.

Regards,

Nathan

[TooEagerToLearn]

Thanks! BTW, the Fetch Forever vi wasn't working when I implemented that into my code. SO, I replaced Fetch with READ.vi and it works. Don't know why?