NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Pass thisContext reference to executable???

Solved!
Go to solution

hello

 

is there a way to pass the reference "ThisContext" from TS to LV application? I tried to convert the reference to string in TS and then pass via arguments to my executable without success. Even if the reference address is correct the reference in my executable is seen like an empty reference. I'm not able to use it?

maybe VI server will allow me to do that?

 

i need to do it exactly this way. I have my labview applicaiton called from the TS Custom menu and I need to read some properties/methods of TS API within my executable. It works perfrect with the LV sources application but not with the executable.

 

thanks 

regards 

maszup

0 Kudos
Message 1 of 15
(6,096 Views)

I wanted this same thing recently but I couldn't find a solution.  The reason I wanted it was so that I could refresh the search directories so users wouldn't have to restart TestStand.  However, I had to end up wrapping my executable into a sequence file and having the sequence file do all the engine stuff in steps.

 

You can always create a new engine inside of your executable as well to get to the API.

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 2 of 15
(6,087 Views)

You can use a TestStand Queue or Notification to pass references between processes. A TestStand Queue or Notification with a name begining with an '*' character is global to the machine. You can create the TestStand engine in the other process, call GetSyncManager("*mysyncobj") on it and then use the sync manager API to get a reference to the queue or notification and get the reference from that. The sync manager API is a bit tricky to use, but it is documented in the TestStand help file. If you try this and run into problems getting it working let me know.

 

One thing to be aware of though is accessing a sequence context from a thread other than the one it refers to can lead to race conditions. You are better off passing exactly the variables you want to access into the queue or notification instead.

 

Hope this helps,

-Doug

Message 3 of 15
(6,080 Views)
Solution
Accepted by topic author maszup

Hi

 

In this tread there is an example dealing with engine and queues

(thanks to Doug !)

http://forums.ni.com/t5/NI-TestStand/Marshalling-the-IEngine-object/m-p/666852

Unless it is written in C# but the TS-API calls are same than in LV

 

Regards

juergen

 

--Signature--
Sessions NI-Week 2017 2016
Feedback or kudos are welcome
Message 4 of 15
(6,068 Views)

thanks a lot for you tips. indeed notification or queue are able to pass the ThisContext reference from TS to my executable. I attached simple example how to use TS notification in LV:

undefined

 

Doug, what kind of rise conditions are you talking about? I need to have this reference since i use lot of methods/properties in my software. Passing all these elementes sepertely in both ways would cost me too much time. But when I pass this reference to my executable and then in the executable I can access TS API easily. 

Download All
0 Kudos
Message 5 of 15
(6,065 Views)

Race conditions with accessing the sequence context can occur because the PropertyObject API is not threadsafe with respect to structural changes (i.e. inserting/remove child properties and array elements). During the normal course of execution the sequence context for a thread is constantly having properties added and removed from it. This happens synchronously with respect to the thread that is executing, but if another thread is trying to access the sequence context subproperties while the thread using it is executing, it could lead to unexpected problems such as errors and crashes. It is better to explicitly pass the exact variables you want to access to the asynchronously running thread, thus avoiding the cases of accessing propertyobjects undergoing structural changes in another thread. Another alternative is to synchronize the access to the sequence context in the asynchronous thread using synchronization step types or primitives, but that is probably more work.

 

What exactly are you trying to get from the sequence context? Perhaps I can suggest specifically what you can do to avoid the race conditions and still be able to do what you want.

 

-Doug

0 Kudos
Message 6 of 15
(6,050 Views)

In my executable application I use TS reference mostly in following purposes:

- read user & group logged in in TS

- open/close sequence file in TS

- read sequence file details (steps names, step "skip" status, step module input names & values, step variables names & values)

- write sequence file step values (step module input values, step variables values, step "skip" status) 

 

My executable is running from withing TS customized menu (via sequence step -> CallExecutable).

0 Kudos
Message 7 of 15
(6,032 Views)

@maszup wrote:

In my executable application I use TS reference mostly in following purposes:

1. - read user & group logged in in TS

2. - open/close sequence file in TS

3. - read sequence file details (steps names, step "skip" status, step module input names & values, step variables names & values)

4. - write sequence file step values (step module input values, step variables values, step "skip" status) 

 

My executable is running from withing TS customized menu (via sequence step -> CallExecutable).



I've numbered the bullets above to make it easier to respond to them.

 

1. From the StationGlobals correct?

2. Using the Engine correct?

3. Are you accessing the running copy of the sequence while it's running, or do you mean you are reading a completely different sequence file you opened using the engine?

4. Are you modifying the running copy of the sequence while it's running, or do you mean you are editing a completely different sequence file you opened using the engine?

 

If all you need is the engine, you can pass just the engine reference via the queue/notification. 1 & 2 can definitely be done with just the engine reference. For 3 & 4 it depends on what files you are talking about.

 

-Doug

0 Kudos
Message 8 of 15
(6,024 Views)

1. using the Engine.UserFile and Engine.CurrentUser

2. using the Engine indeed 

3. values are read from not running sequence and previously open using Engine

4. values are written to not running sequence too 

 

One thing i forgot to mention. I need to know what sequence file is open in TS in the moment I run my executable from the menu. The only way I know is following (by calling the RunState.InitialSelection.SelectedFile.Path😞

undefined 

For this I need to have TS context reference. But now I see i could pass this name using a notification and then pass also only the Engine instead of full context. But in the other hand I wouldn't like to limit my software, which is still being developed, probably I will need more.  

 

Is it really a big difference if I pass the Engine or Context reference. In my executable I use mainly the Engine so it's the same if I extract it every time from the Context? Do you think it is better to pass the Engine only?

 

Thanks for your involvement.

 

0 Kudos
Message 9 of 15
(6,019 Views)

Because of threadsafety issues with structural changes to PropertyObjects, it is safer to pass just the engine and file path that you need. These threadsafety issues might be addressed in a future version of TestStand, but for now I highly recommend you not try to access the sequence context for an execution in any thread other than the one executing the sequence that the sequence context is for. Doing so can lead to random errors or crashes.

 

One thing you could do to more future proof your design is build a container with all of the things you will need as subproperties and pass that to the other process. Then you can always add more properties to the container if needed in the future.

 

-Doug

0 Kudos
Message 10 of 15
(6,004 Views)