LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

I use Labview 8.6 to collect  hand movement data of monkeys. Because some graphics is needed, I make use Visual C# express edition to program the graphics and call the VI's using ActiveX from my C# code. I use three VI's in all, two of which I call synchronously (I wait for the call to complete). But the third VI has to be called asynchronously so that I can continue doing my work in C#. This VI fetches accelerometer data via DAQ and dumps to a LV measurement file in a while loop.


I start the async call by doing VI.run(true) where true indicates that I don't want to wait for the call. Now when a trial is over (monkey gets some visual cue, then does work and successfully completes), I have to stop collecting the data. I have one of two ways to stop the VI.

 

1) Do an abort using vi.abort(), but this results in some residue data collected by DAQ not being written to measurement file.

 

2) Set the Stop button in the VI to false via VI.SetControlValue(). In this case, the VI doesn't stop immediately, it takes a LONG (1.5 to 2.5 sec) time to halt. I tested that it takes a long time to stop by running the VI using Labview without using C#.

 

Note that once I stop my VI, in the lvm file I want to write "trial ended" from C# to differentiate data between successive trials. I don't want to create new lvm file for each trial (there will be some 300 of them), so I append data to the same file. In case of 2), I don't have a VI.isRunning() to see if it has stopped running. I can sleep() in my C# code for a second or two and then append "trial ended" to lvm file but all this is happening real time and I don't want to sleep that long.

 

Now my problem is that both the options don't seem good to me. Is there a better way that someone can suggest? And why does it take so long for the VI to halt if I use 2)? Is there something I can do about it? Thanks in advance.

 

0 Kudos
Message 1 of 17
(4,534 Views)

Since LV is taking longer than you want to stop even if you don't involve the ActiveX calls, first you'll have to figure out why your code is taking longer than desired even in native LabVIEW and fix it there.  It sounds like your File writing routines are taking too long.  Are you constant opening and closing the file in a loop?

 

Instead of stopped and restarting your LabVIEW VI, perhaps you can set up a TCP/IP communication scheme between your C# program and your LabVIEW VI and have it send commands to tell LabVIEW when to add  Trial Ended to the data file.  Basically set up a Producer/Consumer architecture where your C# program is the producer generating commands and your LabVIEW VI is the consumer monitoring the TCP/IP port and acting on any commands it gets.

0 Kudos
Message 2 of 17
(4,523 Views)

You most probablly poll the stop boolean in the acquisition loop and have a a DAQ Read that reads in enough samples to have to wait for about 1 seconds or more. Without some data dependancy forced the normal action in a particular LabVIEW sub-diagram is to read first all controls and then execute the rest of your sub-diagram. So the boolean is read and is false and then the data acquistion (which takes about 1 second to execute because it has to wait for data) is executed. Somewhere in between the boolean toggles to true. Next iteration the boolean is again evaluated AND the data acqusition is again executed and now the loop stops.

 

There are several solutions:

 

1) make the Data Acquistion interval faster. This will cut down on the wait time after the boolean toggled but you can't make it to small because as smaller as it gets as bigger gets the overhead of executing the loop and calling into the DAQ driver to retrieve a new buffer of data.

 

2) introduce some data dependency. You can either wrap the entire rest of the loop in a case that gets only executed when the boolean does not indicate stop or you can put the boolean into a single frame sequence structure and wire some output from the DAQ Read to that structure boundary.

 

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 3 of 17
(4,511 Views)

Thank you both for your replies. Was doing some programming, so got busy and couldn't reply back.

 

I guess rolfk's reply is more in line with what I want. Basically I want my VI to stop quickly when I ask it to stop. I have attached my VI. I don't understand how to make use of either of your suggestions, rolfk.

 

1) I have the DAQ assitant through which I'm collecting continuous samples at 1K Hz since I want 1000 samples / sec. I don't understand how I can reduce 1KHz and still collect 1000 samples per second.

 

2) Can I get a quick PNG image of the VI that you are talking about?

 

 

0 Kudos
Message 4 of 17
(4,472 Views)

Ah, didn't read Ravens Fan's reply properly.

 

@Ravens Fan

 

The first paragraph makes perfect sense to me. I don't think I'm opening and closing the file within the loop. I have attached the VI in my earlier reply, please have a look at it.

 

Your suggestion of setting up TCIP/IP port seems a bit roundabout. The project is in a mature stage and I don't want to make too many changes to C# code about how it communicates with the VI. Also, I want to stop collecting the data after a trial is over until another one begins. So I'm hesitant to go with this solution.

0 Kudos
Message 5 of 17
(4,468 Views)

Ohhh well, DAQ Assistent!!!! I can't really come up with a proper way using the DAQ Assistent! The DAQ Assistent is nice for a quick data acquistion but it does not allow customizing the actual execution of the code. What I would do instead is converting the entire DAQ assistent into a normal VI, put the initialization outside of the loop, the Read Data inside the loop in the false case of a case structure whose selector is connected to your stop boolean, the Write TDMS in the same false case and at the end outside the loop the clear task.

 

You basically right click on the DAQ Assistant VI and select Open Frontpanel, acknowledge the prompt you get and from the subVI that then gets created you copy the various components into your Get Accelerator Data.vi.

 

GetAccelerometerData.PNG

 

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 6 of 17
(4,456 Views)
Thank you rolfk. I'm going to try this VI out.
0 Kudos
Message 7 of 17
(4,417 Views)

Rolfk,

 

Please see my attached VI. I guess I've done exactly what you told me. Still I find that neither Abort nor Stop (using Stop button) stops the VI immediately :(. Let me know if I'm doing something wrong somewhere.

0 Kudos
Message 8 of 17
(4,355 Views)
Hi, please see my previous message on this thread. Clicked on the "reply" button in my message instead of yours. So I'm concerned that you didn't get an alert and hence this message.
0 Kudos
Message 9 of 17
(4,354 Views)

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

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 10 of 17
(4,349 Views)