Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

CLAD DAQ question

Solved!
Go to solution
Highlighted

Q4.png

 

 

Hello everyone. I am new in the community. I was having trouble understanding the above vi.

Why do I get 2 rows ?

When I ran this vi , while loop count was 1. Then why did I get 2 rows? 

Thank you.

0 Kudos
Message 1 of 9
(1,272 Views)
Solution
Accepted by topic author mayur95

The way I see it is the first time the loop runs the "Elapsed Time" VI will return a false, but the DAQmx Read vi will wait for 5 samples (i.e. 5 seconds since the rate was set at 1Hz). The next loop the "Elapsed Time" VI will return true (i.e. we've been running longer than 4 seconds), but we'll still wait for 5 samples from the DAQ device. Since the output of the Read VI is indexed on the while loop boundary we will see two iterations with 5 samples each.

 

 

Message 2 of 9
(1,257 Views)
Solution
Accepted by topic author mayur95

@mayur95 wrote:

 

When I ran this vi , while loop count was 1. Then why did I get 2 rows?


Remember that the loop iteration counter starts at 0.  So a count of 1 means you iterated 2 times.  Therefore, 2 rows.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 3 of 9
(1,252 Views)
Solution
Accepted by topic author mayur95

There's a little tidbit I wanted to emphasize.  The first call to Elapsed Time will result in an auto-reset behavior and consider that instant as t=0.  It will run in parallel to DAQmx Read and finish pretty much instantly while DAQmx Read has to wait around 5 seconds for its samples.  The next iteration starts about 5 seconds later and that's the reason Elapsed Time will return a True (at least 4 seconds have passed) and terminate the loop.

 

Even if you sequenced the functions in the loop so that DAQmx Read was called first, waited a full 5 seconds, and *then* you called Elapsed Time, it would *still* return a False on the first call.  It wouldn't set t=0 to be the beginning of the loop iteration, it would still be the instant that Elapsed Time first executed.

 

 

-Kevin P

Message 4 of 9
(1,244 Views)

Thanks for the reply.

So , in all this vi should take almost 10 sec to complete , right?

0 Kudos
Message 5 of 9
(1,210 Views)
Solution
Accepted by topic author mayur95

mayur95 wrote:

So , in all this vi should take almost 10 sec to complete , right?


It will take at least 10 seconds.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 6 of 9
(1,206 Views)

Thank you Sir.

0 Kudos
Message 7 of 9
(1,195 Views)

This algorithm is not robust as you keep playing with the rate and number of samples per channel it fails to make sense. Please have a look at the attached file, if rate is set at 5 as I should have 6 rows then ?

 

The first run makes a valid result, now try playing with the user inputs. As you see the algorithm failing to be consistent. 

 

It's as if its failing to reset....well anyone could give it a try !

0 Kudos
Message 8 of 9
(250 Views)

@cobbPP wrote:

if rate is set at 5 as I should have 6 rows then ?


It is looking for 4 seconds to have passed since the first loop iteration began.  If you are running at 5 Samples/second, then each loop iteration should be 1 second ( (5 Samples) / (5 Samples/second) = 1 second).  Assuming everything is ideal, you will have read elapsed times of {0, 1, 2, 3, 4}, which will give you 5 rows.  Of course, you have weird software timing in the mix as well, which could add some time.  Probably not enough to mess this up though.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 9 of 9
(241 Views)