03-06-2013 02:23 AM
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)
03-06-2013 08:14 AM
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,
03-06-2013 09:41 AM
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
03-06-2013 10:02 AM
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.
03-06-2013 11:36 PM
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.
03-07-2013 10:34 AM
@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
03-07-2013 11:28 AM
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