LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it bad to use cont' sampling?

Solved!
Go to solution

I trying to structure an application that needs to take a 300 samples from different DAQ channels during a short period of time. This process is made in a of statemachine (loop+case).

Can I start a continuous sampling (1kHz) of the analogue channels and let it run? When I need data I take it from the buffer.

I place the chain of DAQmx blocks outside the statemachine. 

The alternative is to start a finitive sample of DAQ channel(s) in a specific state. This is the way I done it before. Now I want to try another way. 

 

Sorry about the bad english.

 

 

0 Kudos
Message 1 of 5
(1,280 Views)
Solution
Accepted by TakeANap

If you really want to take 300 samples at 1 kHz at certain points in the execution of your code (say at the beginning of the State called "Acquire 300 samples"), I'd definitely recommend writing a sub-VI that does a finite acquisition of 300 samples (which, at 1 kHz, will take 0.3 seconds).  If you have, say, 10 A/D Channels you want to sample, you could make the Channel an input parameter for this sub-VI ("Acquire 300 samples from Channel 4").

 

The advantage of doing this is you now have samples synchronized to the time you asked to acquire the samples.  If you are acquiring samples continuously, your ability to know when the sampling started will be much more complicated.  To illustrate, suppose you decide to continuously sample 1000 samples at 1 kHz.  Every second you'll get 1000 samples.  So now (at 1.25 seconds), you say "I want 300 samples".  Sorry, the A/D is busy continuously sampling -- you'll need to wait 0.75 seconds until it is done, then extract your 300 samples from the 1000 it gives to you (but where do you start to look for them?).

 

It seems unusual to me that you are taking 300 samples at odd times from multiple A/D channels.  Why?  Why aren't you recording continuously from, say, 10 channels at 1 kHz and making a scrolling display of the data as they are acquired?  What are you hoping to see?  [Note that it is difficult to "see" signals that change at 1 kHz, but you can do something like display every 20th point to slow the display down as though you sampled at 50 Hz and look for trends].

 

Bob Schor

0 Kudos
Message 2 of 5
(1,264 Views)

Since you say you want to "try another way" than using a finite sampling task in a specific state, look over here for an alternative based on continuous sampling and occasional queries.

 

What's illustrated there is a way to read the "most recent sample from the past".  But you can mix and match past and future samples by choosing different values for "Offset" and "# samples to read".

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 5
(1,254 Views)

@Bob_Schor wrote:

If you really want to take 300 samples at 1 kHz at certain points in the execution of your code (say at the beginning of the State called "Acquire 300 samples"), I'd definitely recommend writing a sub-VI that does a finite acquisition of 300 samples (which, at 1 kHz, will take 0.3 seconds).  If you have, say, 10 A/D Channels you want to sample, you could make the Channel an input parameter for this sub-VI ("Acquire 300 samples from Channel 4").

 

The advantage of doing this is you now have samples synchronized to the time you asked to acquire the samples.  If you are acquiring samples continuously, your ability to know when the sampling started will be much more complicated.  To illustrate, suppose you decide to continuously sample 1000 samples at 1 kHz.  Every second you'll get 1000 samples.  So now (at 1.25 seconds), you say "I want 300 samples".  Sorry, the A/D is busy continuously sampling -- you'll need to wait 0.75 seconds until it is done, then extract your 300 samples from the 1000 it gives to you (but where do you start to look for them?).

 

It seems unusual to me that you are taking 300 samples at odd times from multiple A/D channels.  Why?  Why aren't you recording continuously from, say, 10 channels at 1 kHz and making a scrolling display of the data as they are acquired?  What are you hoping to see?  [Note that it is difficult to "see" signals that change at 1 kHz, but you can do something like display every 20th point to slow the display down as though you sampled at 50 Hz and look for trends].

 

Bob Schor


btw, it is a finaltest I'm making. I measure voltages and currents. I activate some module and measure a voltage during 0.1 sec (100 samples) or sometimes currents during 0.3 sec and making a average of the samples and compare it with limits. The whole test would be over in 10 sec. 

You are right about the sync. Your argument is undoubtedly true. I don't really know when the data where collected. I think I use the old and safe method. A sub-VI with Inputs: start/end channel. Output: array + time of start. I'm using DAQmx Read with automatic start. No problems with that one. The goal is to get the job done. Not to show a nice technical solution.
Why I talking about cont' sampling is because I don't really know how the sampling engine works in the DAQ. Without knowing, I think DAQ would be used more correctly if it is allowed to work continuously. In this case it doesn't matter. No huge amount of data and no high speed.


0 Kudos
Message 4 of 5
(1,203 Views)

Kevin, the solution you showed is interesting and it is a way I imagined it can be done. I'll test it. However, in this project, it is better to be safe than sorry.

 

 

0 Kudos
Message 5 of 5
(1,200 Views)