Seq context in multiple executions

[logatto]

Hi, I have to modify the values of some TS local variables from LV without passing directly the sequence context. I mean, I have a VI that is running stand alone, it is not called by TS. Then I should only use the TS APIs. Using these APIs I can access to the station global as you can see in the attached file. I am using a batch/parallel model, then I need to have the sequence context of each execution.

Anybody can help me?

I discovered a work around using the TS PostUImessage, but it is not working properly.

Thanks

[~jiggawax~]

So are you saying you can access the globals this way?  How will you know there is even a TS execution running?  You need a handle to it somehow. 

Honestly the best way is to use the UIMessages.  This is the proper way to access data in a sequence.  What issues are you having with the UIMessages?

Regards,

[j_dodek]

Hi,

I agree with jigg's best way.

But there is an other solution to modfiy your variables.

1.) Create a in your running executions a named TS-Queue which is

is acessible over the maschine.

2.) then put your current execution in it. Now you can access this on all processes on your maschine !!

3.) Open the TS Engine in your vi .

4.) Open the queue in your vi. (well you have to now the name)

5.) Access the execution in the Queue.

Here is link and also an example to this crazy stuff.

http://forums.ni.com/ni/board/message?board.id=330&message.id=18737&query.id=164454#M18737

Hope this helps and was not too confusing

Juergen

--just click on the star button a see what happens -- 

[logatto]

Basically, I have not really understand  yet how Sequence context works. I use in this way: Process Models create new executions. At the beginnig of each entry points I sent a UImsg to LV. LV gets the SequenceContext and store it in shift register. When I need SeqContext I get it from the shift register and I use it, but I have an error; something related to the variable that does not exist. Unfortunately today I cannot do any try.

Is this the correct approach?

Each execution has its own sequence context and no more? I mean, sequence context is only related to the execution or also to the sequence that is running (i.e. if an execution call dynamically some different subsequence, the sequence context is the same. Isn't?)

Does it change continuously during the execution?

And for Parallel threads of the same execution?

Queues ara a solution, I know, but I would like go deeper with sequence context.

Thanks.

[j_dodek]

Hi Logatto,

Here is a screenshot from the TS-Help:

Sequence Context
A sequence context is an object in the TestStand API that represents the execution state of a sequence. For each active sequence, TestStand maintains a sequence context you can use to access all the objects, variables, and properties that relate to the execution of the sequence

That means a Batch/Paralell Model contains one or more Executions. A Running Execution can Contain one more Threads. Each Threat contains
sequences in a stack (SubSequenceCalls)--> Every Sequnence has one Context

Hope this helps

Juergen

--just click on the star button a see what happens -- 

[logatto]

Ok, then each running sequence or subsequence has its own sequence context. Another import issue is that each sequence context changes during the execution. Then store the Seq context into a shift register (or global) seems to be senseless, becouse when you need it, it has been already changed. Then using the UImessage is not the solution. Am I wrong?

All these "sequence context" should be in a stack. Then the unique solution could be accessing to this stack. Is it possible to do it using TS APIs? It should be possible using the "Execution Classes" but I was not able to do it yet.

Any ideas?

Thanks.

[Norbert_B]

If you are asking this question because you want to use UIMessages, please consider this:

UIMessages are created by the engine and are used to pass data to the user interface of your TestStand application.

So the "flow" is TestStand => UI. From that aspect, you have no need to keep the SequenceContext within your UI since you can pass it each time you send an UIMessage.

hope this helps,

Norbert 

[dug9000]

logatto,

What exactly are you trying to do? I'm not sure that sequence context's are really the right thing for you to be using. It's unsafe to access the sequence context from a separate thread while the execution is still running. The reason is that the sequence context changes as the execution runs and thus there are inherent race conditions in accessing the data if you are not accessing it from the execution's thread itself. If you just want to share data with or synchronize with the executions then there is likely a better way. Please explain what you are trying to do and perhaps I can suggest some alternatives.

-Doug

Message Edited by dug9000 on 01-26-2009 10:30 AM

[logatto]

I am developing in LV an Operator Interface for TS. The machine has a mix between parallel and batch model. The machine has 4 groups working in parallel and each group has 4 DUTs in batch. I have no problem with communication from TS => LV. Basically, I use "station Global" to display some station information. I use UImessage to synchronize and to send and display some data (i.e. like serial number, ..)..I also use UImessage to store the sequence context into a shift register with the problem I described in my previous post. Some problem with communication in opposite way from LV => TS. I use "station global" to store some data without any problem. I also use the queue to enqueue commands into the "DialogRequestQueue". Till now I can do it but using the sequence context. I am not sure yet I need the sequence context, I am still investigating. Definitely I need the sequence context for the TS_SetPropertyValue. TS_SetPropertyValue is not essential I could find a work-around. I would use it to set same local variables inside the parallel/batch executions (i.e. like the Parameters.TestSocket.ContinueTesting.That's more or less a quick vision about what I am doing. 

Thanks all.

[dug9000]

You can get the station globals directly from the engine (i.e. Engine.Globals). You don't need to use TS_SetPropertyValue. That is meant for VIs that are called from a sequence. You can use the TestStand PropertyObject API directly on the Globals object you get from the engine (TS_SetPropertyValue just uses this underneath - I think you can open the SetPropertyValue VI to see how it's implemented if you'd like).

In general you shouldn't be accessing a sequence context from a different thread than the one that owns it (i.e. the one running in the execution) because you have no way of knowing/synchronizing whether or not it's still in use or active. Sequence contexts represent a particular sequence call on the callstack, once the sequence is done executing much of the information in them is cleared. There are ways you could synchronize that information for example you could add steps to the process model sequence to tell the UI to save and free them. There are many ways such steps could communicate with the UI (e.g. synchronous UI Messages, queues, LabVIEW specific shared data and synchronization, etc.). But if you do so, it would probably be better to pass just the data you need to the UI, not the whole sequence context. Why do you need to set Parameters.TestSocket.ContinueTesting from your UI directly? Isn't this normally set in the process model? Perhaps you could remove the need for having the sequence contexts in the UI by returning this information back to the process model and let the process model set ContinueTesting. That's probably closer to how the model works by default too.

Hope this information is helpful. Let me know if you need more details.

-Doug