How to stop an async activex call made to a VI?

[RavensFan]

Rolf,

Is it actually reading 1000 samples inside the loop?

I thought that since the # of samples is unwired on the read, the default is -1, which means read all available samples.  So how many samples are available is determined by how long the rest of the code takes to run based on 1000 samples/second.  Since the major part of that code is the Write to Measurement File, that is what is controlling the loop rate and how long it takes for the iteration to finish and get back around to read the stop button.

Yashwant,

You say the  VI doesn't stop immediately?  How long is it actually taking from when you hit the stop button to when it stops?

Since that Write to Measurement File is an Express VI, it tends to be slower in operation then a similar program made with the basic File I/O functions.  It is opening and closing the file on every iteration.  All of that takes time and makes the loop run a bit longer than it needs to.  This is where producer/consumer comes in handy.  The data can be put into a queue where another loop reads the queue and does the file I/O.  Open the file before the loop, only write the data inside the loop, close the file after the loop.

Also, the Stop DAQ task still has to run after the while loop as stopped.  I'm not sure how long that takes.

[rolfk]

---

Ravens Fan wrote:

Rolf,

Is it actually reading 1000 samples inside the loop?

I thought that since the # of samples is unwired on the read, the default is -1, which means read all available samples.  So how many samples are available is determined by how long the rest of the code takes to run based on 1000 samples/second.  Since the major part of that code is the Write to Measurement File, that is what is controlling the loop rate and how long it takes for the iteration to finish and get back around to read the stop button.

---

My memory may be shaddy a bit about DAQmx and I don't usually program DAQ in such a way but I believe it will indeed use 1000 samples per read and this would be the major delay. It's half as bad as it used to be due to the avoidence of an extra execution of the DAQ read and File write cycle when the button is pressed.

Rolf Kalbermatter

[Yashwant]

---

@Ravens Fan wrote:

Yashwant,

You say the  VI doesn't stop immediately?  How long is it actually taking from when you hit the stop button to when it stops?

Since that Write to Measurement File is an Express VI, it tends to be slower in operation then a similar program made with the basic File I/O functions.  It is opening and closing the file on every iteration.  All of that takes time and makes the loop run a bit longer than it needs to.  This is where producer/consumer comes in handy.  The data can be put into a queue where another loop reads the queue and does the file I/O.  Open the file before the loop, only write the data inside the loop, close the file after the loop.

Also, the Stop DAQ task still has to run after the while loop as stopped.  I'm not sure how long that takes.

---

 Yes, the VI doesn't stop immediately. The VI with DAQ assistant would take a second sometimes to stop. I had modified this VI according to Rolfk's suggestions to add a case structure for the stop button. Then I created another VI based on the PNG that rolfk had posted. That seems slower and takes more than a second to stop.

My understanding is that the reason why it takes time to stop is because the DAQ assistant or the VI collects the 1000 samples for a second, then writes to the measurement file. Now when we try to stop after the DAQ VI has already started collecting, it completes that iteration by collecting the data for a second and then evaluates the stop boolean value. This results in a delay of atmost 1 second to stop.

 For the above reason, I'm hesitant to use the producer/consumer idea that you suggested since I feel it's not going to help it stop immediately.

[Yashwant]

---

rolfk wrote:

Well you never will get immediate stop. The currently running data acquisition has to return which with the settings you have will take up to one second. I will typically be a bit less than that but it can take up to one second. If you want that to be less you will have to read less than the 1000 samples inside the loop that the DAQ Read will do by default (the number of samples you pass to the "samples per channels"input of the DAQmx Timing (Sample Clock).vi determines how many samples the DAQ Read will return by default.

Rolf Kalbermatter

---

Rolfk, your suggestion of putting a case structure for the "stop" button reduced it to a second atmost for the VI to stop. However, I was able to do this with the DAQ assistant itself and without copying the DAQ assistant VI to my VI. Please see my attached PNG.

But yes, I want to reduce it to less than second, preferably within some 100 millisec. But at the same time, I want to collect exactly 1000 samples/second. I don't understand how I can achieve this. I tried using the timed loop structure with one sample on demand from the DAQ assistant, but it doesn't seem to work.

[Yashwant]

oops, didn't attach my PNG in my previous message.

[rolfk · Accepted solution]

You will need to get smarter inside your loop. Instead of reading the default number of samples inside the loop, you will read a specific number of samples each time, for instance 100 (of course since you want this to react in 100ms of less you will take the sample rate and divide that by 10 to get the actual value).

You can then write those samples to disk directly even if they are not 100 samples. The sample rate determines how many samples per second will be acquired (and therefore saved) not the number of samples you read per iteration. You can go as low in the number of samples per iteration as you wantbutthe DAQms Read VI and even more so the Write to Measurement File do have some overhead for each time they are called and at some point LabVIEW will not be able to execute them all in one iteration, without the DAQ buffer filling up. Once the DAQ buffer is full, LabVIEW will return an error in DAQmx Read to that effect, and your data acquisition gets interrupted.

If you want to have exactly 1s of samples in every block of data in your data file you will have to aggregate those smaller blocks inside the loop. So you will add the read data to a shift register inside the acquisition loop the 1st until n-1 th time, only writing the entire data to disk every n-th time.

It's all fairly simple program logic, but yes once you want to do something that the magic assistents do not foresee out of the box for, you do have to do some programming even in LabVIEW 

Rolf Kalbermatter

[Yashwant]

---

rolfk wrote:

You will need to get smarter inside your loop. Instead of reading the default number of samples inside the loop, you will read a specific number of samples each time, for instance 100 (of course since you want this to react in 100ms of less you will take the sample rate and divide that by 10 to get the actual value).

You can then write those samples to disk directly even if they are not 100 samples. The sample rate determines how many samples per second will be acquired (and therefore saved) not the number of samples you read per iteration. You can go as low in the number of samples per iteration as you wantbutthe DAQms Read VI and even more so the Write to Measurement File do have some overhead for each time they are called and at some point LabVIEW will not be able to execute them all in one iteration, without the DAQ buffer filling up. Once the DAQ buffer is full, LabVIEW will return an error in DAQmx Read to that effect, and your data acquisition gets interrupted.

Rolf Kalbermatter

---

I guess I should have seen this myself. I was getting confused between the sampling rate and the number of samples that I can read in the while  loop. Now things are working fine. Please see my attached VI.

Many thanks for all of your help.