LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does my VI perform differently when called by Teststand instead of being ran standalone?

I have written a VI to set a scope channel up to look for a trigger on channel 1.  I have the timeout set for 10 seconds.
 
I then have a VI that sends a communication signal out on a bus.  Channel 1 of my scope is tied to this bus.  I want to setup my scope to start looking for the trigger and then whlie it is waiting for the trigger i want to send this command out on the bus and capture it with the scope.
 
I have successfuly done this and everything works fine when running LabVIEW standalone, but when i use this subvi inside of a teststand test, it does not perform the same.  It no longer lets me do two VI's simoultaniously.  The Scope VI will hog all of the execution time for the entire 10 seconds and will not release until the timeout is expired.  It is not until then that my message is then written.   I can obviously see this happening when i use highlight execution.  If i am instand alone mode i can see it execute the scope vi and then i can see the wires light up and go all the way to the communcation VI.... As soon as the communication Vi executes the scope vi returns the waveform........However when stepped through after being called by test stand i can see the execution flow into the scope Vi and then just sit there and hog all  the time until it is done with its timeout...........then and only then will it execute my communication VI.  I have attached an image for assistance.   Has anyone ever seen this before?  Or does anyone know a better way to achieve what i am wanting to do.
 
Thanks in advance,
Jason Davis
Test Engineer
0 Kudos
Message 1 of 6
(3,212 Views)
Page B6 of the Using LabVIEW with TestStand manual talks about using a thread other than the user interface. I would stick the wait and write message in another vi and execute it in a different thread. Also, I try running it without the vis open.

I have had LabVIEW stuff running in parallel with TestStand and LabVIEW stuff. Try executing the sequence with the LabVIEW operator interface instead of the sequence editor.

What version of LV and TS are you running?
0 Kudos
Message 2 of 6
(3,192 Views)

I am using LabVIEW 8.0 and Teststand 3.5

 

I will look into splitting it up in TestStand like you said.  Right now it is just in one "numeric limit test" for test stand.  I can split them up in test stand like you said and have the scope set up first and then tell test stand not to wait...But then after i send the communication signal, i will need to wait until the scope test is done before i move any further..


Example:     Do step 1, then dont wait and just go ahead and do step 2, but then before doing step 3 i must wait until step 1 is finished.   I havent looked into that yet, but does that sound possible?

 


Thanks,
Jason Davis

0 Kudos
Message 3 of 6
(3,177 Views)
Running the sequence with the LabVIEW simple Operator Interface causes the same results as running it in test stand.   It just sits there until the 10 second timeout runs out before it executes the "write communication" VI.  Its so odd though because it works perfectly if just open up the VI in LabVIEW and run it by it self.............  I have also tried making a copy of the VI.... Then running my test stand and putting a breakpoint right before that VI is called... I then run the copy of the VI with LabVIEW and it works fine as well.........
 
Thanks for the help,
Jason
0 Kudos
Message 4 of 6
(3,173 Views)
Jason,

Did you find a solution with the suggestion provided here?

http://forums.ni.com/ni/board/message?board.id=330&message.id=9511

Using the synchronization steps and splitting your calls into separate threads should fix the problem.  However, please let us know if you are still running into issues.

Thanks,

Tyler Tigue
Applications Engineer
National Instruments
0 Kudos
Message 5 of 6
(3,159 Views)
Thanks guys.  This helped a lot.
 
I made one VI with a 2 second delay wired into a 'write comm'.  I then made another VI that just sets up a trigger and watches for the signal. 
 
I then made two steps in teststand.  One step calls a sequence that runs in a new thread that does not wait for execution to end (this is the 2second delay -> write com vi), and the other step is called right after that and it is the step that uses the scope.
 
This seemed to work just fine!
 
Thanks for the help!
 
Jason Davis
0 Kudos
Message 6 of 6
(3,139 Views)