dynamic user data in execution context

[LuI]

Hi,

I need to call to an USB-driver-DLL via LV7 in parallel running excutions (modified parallel process model with several test sockets).
I get a DevHdl after opening the driver from every instance (execution).
Is there an elegant solution to keep this handle in the context of every execution? I dislike the idea of keeping an array of handles in a station global and access it with the test socket index or to maintain a chain of parameters 'handle' throughout all the sequence files involved in that calls.
Any ideas?

Greetings from Germany!
--
Uwe

[Scott_Richardson]

Uwe -
I assume that the only tests that will access the handle are the VIs. If this is so, you could create some VIs that can store and retrieve the handles with an execution using an input name that you use to associate with the handle. These VIs would require a handle to the Execution, the name and either an in or out handle wire. The VIs could persist the handle under the property object that Execution.RunTimeVariables returns.

Scott Richardson

[LuI]

Scott,

thx for your answer.
I had done a similar solution using a reentrant daemon.VI that is started with the test socket index as its reference and is controlled with notifiers.
Works quite OK, but every once in a while LV is simply going away from memory (from one second to the next, after some times of successfull actions, just gone. No error messages, no memory leaks before, no debug messages from the DLL - nothing) when using this solution. And reentrant daemons are hard to debug - I had asked a Q on this objective in Info-LabVIEW recently.
BTW, the DLL in question works reliably when operated directly and only from within LAbVIEW in a test.vi for hours.

I have seen a statement in the TS help that gave me the impression that one can create something li
ke dynamic variables associated with an execution. This would make everything so straight and simple...

--
Uwe Frenz

[Scott_Richardson]

Uwe -
When I here someone saying they want to create dynamic variables associated with an execution in TestStand, I believe they are talking about using subproperties under Execution.RunTimeVariables. I cannot think of any better way to do it within TestStand.

As to why your VI calls appear to crash quietly when using this DLL and TestStand, I have no ideas. The first path to debug this would be to attach a debugger like MSVC to the process that goes away to see what might be going on. Minimally you should be able to catch the exception that is causing it to crash, see what type of exception it is, and to see the minimal stack trace to see where the crash is occurring. Sometimes this type of information can lead you to the next level of de
bugging. If you have source for the DLL, then you can possibly see more details if the crash occurs inside the DLL source code.

Scott Richardson

[LuI]

Scott,

you may be right - but I had no idea on what phrases I had to search for.
Now that I have tried this it looks like those 'subproperties' can only be accessed from outside TS, can't they?
I have found a statement 'What are Thread.runtimevariables?' on http://digital.ni.com..., that said, I had to use the GetVal__() and SetVal__() API methods in order to access those. Trying to put those in a sequence statement causes a runtime error -17320: unknown function.
Is there any way of accessing those props from within TS? Or have I to use external code to do so?

TIA and Greetings from Germany!
--
Uwe

[Scott_Richardson]

Uwe -
You are correct in that the GetVal and SetVal methods are not currently available to you to use in expressions and there is no equivalent expression function that allows you to create a variable that does not already exist.

If you wish to add runtime variables you must gain access to the property object that the RunTimeVariables method returns from either an Execution or Thread object.

You can invoke TestStand API calls from code modules or you can just use an Action step that uses the ActiveX Adapter. TestStand process models and users in general do this all the time so that an external code module does not have to be created to simple stuff like this.

Scott Richardson