Packed Project Library Shared With OI?

[LVB]

I have an application which needs to share some resources/instruments with TestStand steps.  The requirements require the application to communicate with these resources/instruments with or without the TestStand Engine running.

I understand that the suggested approach is to ONLY place instrumentation code in a test sequence.  However, what is the best approach if the application requirements dictate the resource/instrument must be shared?

• Can a packed project library be shared with the operator interface?
• Is a source distribution the only option?

[Beau_H]

Hey LVB,

Is it possible to get a more detailed explanation of what you are trying to do? What Language are you using? It is possible in TestStand to run the test Sequence in a independent execution as long as it has the references to the source files. One thing you will have to be aware of is Reserved resources if you have 1 instrument that is being used by another program and TestStand tries to access that instrument, TestStand will throw a Resourced Reserved error. You mentioned that you need the program to sometimes run even if TestStand is not running, will these programs ever be running at the same time?

[LVB]

> What Language are you using?

• LabVIEW

> Is it possible to get a more detailed explanation of what you are trying to do?

• Read and write from instruments in both my Code Modules and my Operator Interface
• Implement Diagnostic Panels without requiring the TestStand Engine
• When the TestStand engine is not running, I would like to read and write from the instruments in debug panels on the operator interface.
• Implement Status Panels without requiring the TestStand Engine
• During a TestStand Sequence, I only wish to read from the instruments in the operator interface (IO status panels).
• Implement a few high-speed timed loop state machines within LabVIEW.  These loops must start running as soon as the application is launched and for the lifetime of the application.  I would like to share the state/data of these loops with TestStand and allow a command/response interface.

> It is possible in TestStand to run the test Sequence in a independent execution as long as it has the references to the source files.

• What if I want to start a VI that talks with an instrument.  Why can't I open a serial port in the OI and pass the session to the TestStand API?
• Why is is "better" to call a Code Module VI in a new execution vs just calling the VI from the Operator Interface?  For example, if I want to display the "status panel" of a digital input card...

> You mentioned that you need the program to sometimes run even if TestStand is not running, will these programs ever be running at the same time?

• There will only be a single application that launches the TestStand Engine.
• The idea is that the program utilizes the TestStand engine to run automated tests.  I would like to allow the OI to read the current values (status panels) while TestStand both reads and writes.

Additional Questions

• I would like to understand how TestStand executes LabVIEW VIs differently with the Development and Run-Time adapters.
• If I run a TestStand sequence with the LabVIEW Development System Adapter, from my Operator Interface (OI) I can call code modules and vice versa.  This will work for VIs within the context "Main Application Instance" (no project).
• When I deploy this system using the LabVIEW Run-Time Engine with a built "Operator Interface" EXE, it seems they may run in different "Contexts".

• Why is the separation between User/Operator Interface and Code Modules required?
• The TestStand Reference Manual states "Do not use instrumentation code in user interfaces".  Why?
• If I change the Preferred Execution System in the LabVIEW VI (that is running in the OI) settings to "standard" is this ok?

I hope this detailed response explains my goals adequately.  Thanks for your assistance.

[Beau_H · Accepted solution]

Hey LVB,

Thanks for the information. Based on what I think you are trying to do you should be able to do what you seeking. The reason that the manuals say not to use the instrumentation code with the UI is preserve modularity, it is not recommended that you add specific instrumentation interfacing to the LabVIEW TestStand OI as this will make the OI instrument specific. And as long the OI .exe is running your instrumentation processes will be running, and until your operator actually selects Test UUT or Single Pass(or whatever TestStand entry point you choose) the TestStand API will be just waiting. This example I think shows what you are looking at doing https://decibel.ni.com/content/docs/DOC-21047.

Hope this Helps.

[LVB]

Thanks for the response and example.  This is very useful information.