NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Teststand thread communication

Hi All

 

I use teststand and labview 2012 for development.

 

I have 10 Vi’s that was created on the same achitecture basis. Each vi has two parrallele loops. One for the User interface (Front Pannel) and one to process front pannel actions. Communication between the two threads are handled with qeues.

 

I want to use these Vi’s in test stand each running in a thread of it’s own. This will enable me to have all VI’s running at the same time. I can start each VI in it’s own thread in Teststand this is not a problem.

 

The problem is how do I communicate with these individual VI’s from test stand after I have started them? I need to interact with the VI’s to be able to close them, set outputs and aquire data for result processing.

 

What is the best way of communicating with them from test stand? (Qeues, Teststand local variables)

0 Kudos
Message 1 of 7
(4,567 Views)

Personally I think it's best to pass in the Sequence Context and use the TestStand VIs to get and set properties.

 

Look at the AccessingPropertiesUsingAPI example in the TestStand Examples folder.  Specifically the UsingLabVIEW one.

 

Also there are some VIs you can poll that will tell you if TestStand was terminated or not.

 

Hope this helps,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 7
(4,557 Views)

When running any code module for a non-finite amount of time it's recommended that you use the Termination status monitor (VIs for this are on the TestStand palette) as well as setting the thread as ExternallySuspended (an API on the thread object, there might also be a wrapper vi in the TestStand palette). Using these VIs/APIs ensures that a user can pause and terminate an execution even while your VIs are running in a separate thread in that execution.

 

That said, there is probably no reason why you can't continue to use labview queues to communicate between the vis. You could also potentially use TestStand queues (they have an API to them), but if you only need to access the queues from labview then using labview queues is likely simpler.

 

Hope this helps,

-Doug

0 Kudos
Message 3 of 7
(4,550 Views)

Thank you guys for responding.

 

I expected the answer about useing the local variables, I am quite sure that it will work.

 

I tried the Teststand Qeues but coulds net get them to connect to my Labview qeues then I created enqeue and deqeue vi's. You tell the vi what qeue you want to acess and the data to enque etc, this worked as long as I used only one thread. As soon as I started a second vi thread the first vi qeue would not be accessable any more. I saw in the labview craete qeue vi help that qeues do not work accros aplications. So I asumme that this is why it is not working.

 

So for now it looks like I will have to go with the teststand local variables and an update to all my VI's to be able to access the teststand local variables.

 

May be there is some more opinions out there re this topic.

0 Kudos
Message 4 of 7
(4,547 Views)

Hi,

 

I would look at the TestStand Synchronization Object palette, THere are ques, notifiers, etc.The is a way to create ques in TestStand and read those ques in LabVIEW using property nodes for TestSTand ques,. TestStand ques come from this service called Synchronization Manager. You can also pass references of different Local variables around.

0 Kudos
Message 5 of 7
(4,534 Views)

@TheForce wrote:

Thank you guys for responding.

 

I expected the answer about useing the local variables, I am quite sure that it will work.

 

I tried the Teststand Qeues but coulds net get them to connect to my Labview qeues then I created enqeue and deqeue vi's. You tell the vi what qeue you want to acess and the data to enque etc, this worked as long as I used only one thread. As soon as I started a second vi thread the first vi qeue would not be accessable any more. I saw in the labview craete qeue vi help that qeues do not work accros aplications. So I asumme that this is why it is not working.

 

So for now it looks like I will have to go with the teststand local variables and an update to all my VI's to be able to access the teststand local variables.

 

May be there is some more opinions out there re this topic.


TestStand threads are not separate applications, you should be able to use the same LabVIEW queue from multiple threads. Perhaps you need to pass the queue handle from one thread to the other somehow though. I'm not a LabVIEW expert so I'm not that familiar with how LabVIEW queues work.

 

-Doug

Message 6 of 7
(4,519 Views)

Hi,

 

I once had a bug where LabVIEW VIs in an execution were unable to share a LabVIEW Que. The cause was, the step that created the que and enqued had the LabVIEW Project field empty. The step that dequed had the LabVIEW project filled in. Therefore the two code modules were running in different LabVIEW contexts and were not able to "see" each other.

 

This is probably not your problem, but you are describing the same symptom.

 

I agree with this, "you should be able to use the same LabVIEW queue from multiple threads." You should try it with named ques, and by passing the LabVIEW que reference around.

 

cc

0 Kudos
Message 7 of 7
(4,517 Views)