NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Vi performs differently in teststand than when it is ran standalone? Why is this?

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,314 Views)

Hi,

You will need to setup your step for the scope to be performed in a seperate thread or execution, and also not to wait for it to complete. That way your next step of sending you data out on the bus will be performed.

If you are using TS3.1 or above then you can set the actual labview step type up to do this. If you are using an early version, you will have to place you scope vi is a seperate sequence. Then call this using a SequenceCall adapter, you can set the SequenceCall to be performed in a seperate thread or executions.

There are some examples in the TestStand folder for parallel executions.

you may find some useful examples here

http://zone.ni.com/devzone/devzone.nsf/webcategories/F255EBD2FF79B055862567B3006BE376

Regards

Ray Farmer

Regards
Ray Farmer
0 Kudos
Message 2 of 6
(3,298 Views)

Hi, Ray Farmer

I work with TestStand3.5 and LabVIEW 8.0

I have a question that relates to similiar problem ->

After transferring of my 'vi' to executible file(build)  due to running my sequence from TS3.5 LabVIEW Operator Interface-> LabVIEW Run-Time Engine & without LabVIEW installed.

I execute my compiled_vi.exe with 'calling to Executible' and i see that i lost the return values from it to tha next step in sequence but before in Development System mode was ok. (in other words i did not get the return values  from my compiled_vi.exe to next step 😞  )

1. Why i lost the return values ?

2. How can i run my 'vi' without builidng an executive file in Run-Time Engine mode?

Message Edited by Yuri_IL on 05-28-2006 10:30 AM

Thank you & Best Regards

*I use LabVIEW 2018 & TestStand 2021 versions
0 Kudos
Message 3 of 6
(3,196 Views)
Hi,
 
What are you expecting as the return values?
 
You dont need to turn your VI's into an executable. Set the LabVIEW adapter to use either the Labview runtime engine or the ActiveX Server, and this could be the Labview Operator Interface or the LabviewRuntimeServer.
 
Hope this helps
Regards
Ray Farmer
Regards
Ray Farmer
0 Kudos
Message 4 of 6
(3,186 Views)

Just want to remind that at my Development station i has LabVIEW 8.0 & TestStand 3.5 and at my target station only TestStand for Operator interface runnings.

 

1. 'Expected values' - SORRY, i did not express myself well -> Before 'built/compiled' version of my VI it changed the value of defined(by myself)  two Station Globals, but 'built' version of my VI does not change those Station globals. I do not understand why it happend...

    Why after building the VI finished to change my Station Globals?

2. 'You dont need to turn your VI's into an executable' - At my deploument station I have only TestStand and i have not installed

    LabVIEW, so i can not use the Development System mode, I must use or LabVIEW RunTime engine  or  Other Executible->TestStandLVRTS

  I tried to use it but i got such problems:

    a. when i used LabVIEW RunTime mode engine It wrote that i should use 'built/compiled' version of VI (executible version only), because it can not run source (not built/complied vi) 😞

    b. when i tried to use TestStandVRTS (to stay with original, not built version of VI) i got strange errors (files are attached)

 what can you say regards all of it?

*I test some VI file that was written in LabVIEW 6.1 at TestStandVRTS but I got that error(attached files) again 😞

The questions are

a.       Why TestStandVRTS wrote that the server built with LabVIEW 6.1 ?  That means that we can run ‘vi’ in that mode(TestStandLVRTS)  with only LabVIEW 6.1 and down? LabVIEW 8 does not support?

b.      Why it did not run ‘vi’ that was written in LabVIEW 6.1,e.g. i got the same error as for vi that was written in LabVIEW 8.0?

c.       If I understand correctly, we have a difference between configuring adapters/engines in TS3.0 and TS3.5 ?

Message Edited by Yuri_IL on 05-29-2006 03:31 AM

Thank you & Best Regards

*I use LabVIEW 2018 & TestStand 2021 versions
Download All
0 Kudos
Message 5 of 6
(3,183 Views)

The issue was solved.

In a short form:

1. I did not installed the LV8.0 RTS at target station

2. I did not deploy in a right form all the files (must to use installer and deployement manager)

After aplying the 1 & 2 the issue was solved...If someone will want to know in a more detailed form please ask and i will answer.

Thank you & Best Regards

*I use LabVIEW 2018 & TestStand 2021 versions
0 Kudos
Message 6 of 6
(3,170 Views)