optimize labview VI

[Yashwant]

Though I have worked with Labview for some time now, I have just written basic Labview VI's (So I'm a newbie!). I call them from my C# code using ActiveX. I have this one VI which takes a long time to stop and since the code is time critical, I want the VI to stop immediately.

Kindly refer to my attached VI. I stop the VI using the "STOP" button I've created. Though ABORT stops the VI immediately, I don't want to use it since some DAQ data doesn't get written to the measurement file. Please give me suggestions on how I can make the VI to stop quickly. I'd like to collect 1000 samples/sec from the DAQ.

[cirrusio]

Yashwant -

It is not entirely clear what you are trying to do.  But, if you set this up not using the DAQmx assistant, you might get the behavior you are seeking by setting the number to read (using the VI DAQmx Read) to -1.  This allows the loop to run as fast as the structures in the diagram will allow it.  However, this will result in you acquiring number of samples (at the rateyou specify) each loop execution.  That is, if the Write to Measurement File function takes on 20 ms one time and 100 ms another, you would get about 20 samples in one loop cycle and 100 in the other.  If you are trying to acquire a fixed number (i.e. 1000 samples) the loop would wait (within the timeout specified for the read) at the read until all samples are acquired - for 1000, 1 s; for 100, 0.1 s.  Anyway, let me know if this is clear.

Cheers, Matt

[Yashwant · Accepted solution]

mtat76,

Thanks for your reply. I had opened another thread earlier regarding a similar problem. The solution for that helped solve this one.

[cirrusio]

Can you post the link to that thread?

[Yashwant]

sure,

Here it is :

http://forums.ni.com/ni/board/message?board.id=170&thread.id=437572

Thread topic : How to stop an async activex call made to a VI?

[altenbach]

A VI that needs user interaction should never be set to time-critical priority. Updating and reading the controls and indicators has very low priority in such a scenario.

Then you waste a lot of resources pumping everything through express VIs.

Do lowlevel DAQ and stream to a binary file using lowlevel functions and keep the file open during the execution of the loop. This would be much more efficient than running an inefficient program at redline as you currently do.

Why do you use time-critical at all? Do you experience performance problems?

Message Edited by altenbach on 09-15-2009 02:26 PM

[Yashwant]

Altenbach,

Please see my previous reply in the thread. I've given a link to another thread where I've explained my environment. 

> Do lowlevel DAQ and stream to a binary file using lowlevel functions and keep the file open during the execution of the loop. This would be much more efficient > than running an inefficient program at redline as you currently do.

Yep, I've removed the DAQ assistant and I guess I'm doing low level DAQ operations now. Please see the other thread. I've attached my VI there. But I'm using "Write to measurement file" VI and don't think I keep the file open during the loop execution. But this doesn't affect the performance much.

> Why do you use time-critical at all? Do you experience performance problems?

My environment is such that monkeys do a task using the touch screen while I capture their hand movement using accelerometer. The task is repeated and each one is a trial. It's time-critical since I don't want the monkeys to wait in between trials while I stop and start collecting the accelerometer data. In other words, when I ask the accelerometer data collecting VI to start or stop, it should do so immediately.

[altenbach]

---

Yashwant wrote:

My environment is such that monkeys do a task using the touch screen while I capture their hand movement using accelerometer. The task is repeated and each one is a trial. It's time-critical since I don't want the monkeys to wait in between trials while I stop and start collecting the accelerometer data. In other words, when I ask the accelerometer data collecting VI to start or stop, it should do so immediately.

---

You simply need to esure that the subVI is called at the right time. This is a matter of program design, not some priority setting. Setting time-critical priority is irrelevant and NOT the solution here. There a very few (very few!!!) cases where time-critical priority is useful. 

Have you even compared with normal priority?? 😄

[Cory_K]

Your designing your program so easy a monkey can use it?
Funny... I find myself doing the same thing usually.

Or at least I try to.

[Yashwant]

---

altenbach wrote:

---

Yashwant wrote:

My environment is such that monkeys do a task using the touch screen while I capture their hand movement using accelerometer. The task is repeated and each one is a trial. It's time-critical since I don't want the monkeys to wait in between trials while I stop and start collecting the accelerometer data. In other words, when I ask the accelerometer data collecting VI to start or stop, it should do so immediately.

---

You simply need to esure that the subVI is called at the right time. This is a matter of program design, not some priority setting. Setting time-critical priority is irrelevant and NOT the solution here. There a very few (very few!!!) cases where time-critical priority is useful. 

Have you even compared with normal priority?? 😄

---

Oops, I didn't know I was using the time critical priority setting. I opened my VI and saw that the execution priority in VI properties has been set to "time critical". I guess I was trying different settings some time back and forgot to change it back to normal priority. I have changed it now and I don't think it is changing the performance in any way. Thanks for pointing this out. I hadn't read your previous message properly. Sorry about that :). 

Also, I don't have any subVI's that I've written. All my VI's do very basic tasks and my C# code is the driving code which simply calls the VI's when needed.