SequenceContext in NewExecution

[Madottati]

we start x times the same seqeunce parallel. The sequence has a VI, which has a sequence context input.

The question is, if we modify some Parameters or Locals inside this VI (using the SequenceContext), does this apply always the instance of the sequence, from which the VI has been called?

It seems not to be the case. We see the modified variables in instance 2, where changed them in the instance 3 of the seqeunce.

[dug9000]

The sequence context is associated with the current run of that sequence so, yes, every copy of that sequence running in parallel, as well as recursive calls within a single thread, should get a different sequence context. There are some cases in which variables are shared, so perhaps you are hitting such a case, if you provide more details, such as where the variables you care about are located (i.e. Locals, StationGlobals, FileGlobals, etc.) we might be able to help.

-Doug

[Madottati]

Hi Doug,

you are right, I watched the seqeunce context for all the 4 executions, they are 4 different references. I would refine my question to be able to get the right answer.

In TS, I start 4 times the same seqeunce in new execution. The sequence file contains the VI, where I have the problem. I pass the sequence context to it, and start another new executions, where I write parameter values in the new executing sequence. The following screenshot shows how I write these parameters. And I think I know, what the problem is. The 4 new executions, which are running parallel are in the same seqeunce file. That is why the resulted reference to the seqeunce file (from the first property node) is not unique. I still don't know how to write the parameters into the right sequence (file). How to identify, which execution it is?

[Norbert_B]

Instead of modifying parameter values directly by using the TS API within the LV code, you should make sure that the properties are using local or file global variables in the expression.

The advantage is that the locals and file globals are by default separated to each execution.

For file globals, you can change this behavior in the SequenceFile Properties by selecting "All Executions Share the Same File Globals" instead of the defaulted "Separate File Globals For Each Execution".

So essentially, the LV code only sets new values for local/file global variables in "its" calling SequenceContext.

Norbert

[dug9000]

---

@Madottati wrote:

Hi Doug,

you are right, I watched the seqeunce context for all the 4 executions, they are 4 different references. I would refine my question to be able to get the right answer.

In TS, I start 4 times the same seqeunce in new execution. The sequence file contains the VI, where I have the problem. I pass the sequence context to it, and start another new executions, where I write parameter values in the new executing sequence. The following screenshot shows how I write these parameters. And I think I know, what the problem is. The 4 new executions, which are running parallel are in the same seqeunce file. That is why the resulted reference to the seqeunce file (from the first property node) is not unique. I still don't know how to write the parameters into the right sequence (file). How to identify, which execution it is?

---

What are you trying to do? What do you mean by parameter values? I don't think you mean sequence parameters because that's not the way sequence parameters are generally used. You should not generally be accessing the SequenceFile property of the sequence context. That is the edit-time copy of the sequence file, you are editing the sequence file if you do that. If you were writing a sequence that edits the sequence file, then accessing the SequenceFile property would make sense, but that does not sound like what you are trying to do. Please explain what you are trying to do without any assumptions about how it should be done, and I might be able to suggest a better way.

Is this the sequence context for the current thread or one that is running asynchronously? If it is for the current thread you can access the runtime copy of the sequence using the Sequence property of the sequencecontext, but I'm not sure if that's even really the best approach because I'm not sure what you are trying to do. If you are just trying to pass parameters, then you should just pass them when calling the sequence in a new thread or execution. There is a way to pass parameters directly, no need to use any sequence contexts (or even any APIs really, you could just use sequence call steps in a root level sequence).

-Doug

[Madottati]

Hi Doug,

I run this VI 4 times parallel, and the VI should start seqeunces (always from the same seqeunce file) according to a seqeunce list from a test configuration file. The solution with the screenshot works fine if I run the VI only once, otherwise with parallel executions it goes in chaos. As you wrote, the SequenceFile property should not be used in run time. I was not aware in that. I use this solution since 4 years without problems. The problem came now at the new challenge, as I have to run seqeunces parallel.

To answer your other question, yes it is the seqeunce context of the current thread on the screenshot. Now I know, it is wrong what I have done.

In the meanwhile I have found the right way. It is passing a property object as variant to the sequenceArgsParam input of the Engine.NewExecution method.

[dug9000]

---

@Madottati wrote:

Hi Doug,

I run this VI 4 times parallel, and the VI should start seqeunces (always from the same seqeunce file) according to a seqeunce list from a test configuration file. The solution with the screenshot works fine if I run the VI only once, otherwise with parallel executions it goes in chaos. As you wrote, the SequenceFile property should not be used in run time. I was not aware in that. I use this solution since 4 years without problems. The problem came now at the new challenge, as I have to run seqeunces parallel.

To answer your other question, yes it is the seqeunce context of the current thread on the screenshot. Now I know, it is wrong what I have done.

In the meanwhile I have found the right way. It is passing a property object as variant to the sequenceArgsParam input of the Engine.NewExecution method.

---

Yes, passing the argument as an actual parameter to the sequence using the sequenceArgs is a better way to go. You can use the SequenceFile property of the SequenceContext to specify the file for NewExecution. What I was warning against is that you should not be modifying it (unless you are really trying to edit the file). At runtime, copies of the sequences are made before they are run and all of the modifications generally happen on the copy (Some step properties are shared, but for variables it is generally true that when you are operating on them at runtime you are operating on a runtime copy).

Hope this helps clarify things,

-Doug