Programatically Launching Veristand Workspace Tool inside of a sub-panel

[MPCC]

I am attempting to launch a Veristand Workspace Tool programatically and have it reside in a sub-panel.

Here's what I have done:

1. Attempted to use the Veristand Launch Workspace Tool VI.

Result: I was able to launch the Tool independantly. I couldn't find a way to add it to the sub-panel.

2. Attempted to open the Tool ref and open it in the sub-panel

Result: The tool launched but was disconnected from the Veristand Workspace.

3. I am attempting to populate the necessary controls in the tool programatically THEN launch it in a sub-panel.

Of the optional controls, this particular tool is using these:

NIVS.System Definition Root

NIVS.Project File Path

NIVS.INI File Path

NIVS.Workspace Event

NIVS.Gateway IP Address

I am populating the following:

NIVS.Project File Path <--- An actual path to the project file on the local computer. (Not on the RT chassis. I'm unsure of this)

NIVS.INI File Path <-- An actual path to the Veristand INI File on the Local Computer (Not the RT)

NIVS.Gateway IP Address <-- "localhost" string

I am unsure of where to get the

NIVS.System Definition Root and NIVS.Workspace Event

It is my understanding that the System Definition Root is a .net Ref and the Workspace Event is an Event.

Can I get these from Veristand through an API and feed them to the VI?

OR

Am I going about this all wrong?

Thanks!

- Mike Cornwall

[Jesse_D]

Hi Mike, 

I can replicate your behavior with the subpanels except for the disconnected behavior. Does one of the built in tools replicate the disconnected behavior? I am double checking with R&D about the exact behaviour of the of subpanel approach but I suspect the answer will be to use the .net APIs instead of a custom tool.

I don't know of a way to get access to the WorkSpace Event. However, the event refers to the project shutting down, not the workspace. You may be able to get the functionality you need from the Session Undeploy event. If not I think we will be able to access the event but I don't know if it is documented.

The NIVS.System Definition Root is a part of the NIVS System Storage API. If you know the name of the root node you can getaccess to it by the route below. Alternately you may be able to get the node name and guid out of the tool you currently have. 

[MPCC]

Well, I'm actually using Wineman Technology's INERTIA plugin and I'm trying to launch the PID tool in the sub-panel.

I'm working internally with WTI to find a solution as well but the initial hang-up that we have is getting those items that are auto-populated by INERTIA.

I'll try to use some built-in tools and see what happens.

[Jesse_D]

Hi Mike, 

I thought the Inertia custom device has channels for the inputs and outputs, although I don't have it installed at the moment to check this. If this is the case it will be much easier just to re-create the PID control panel in labview. An example .net reference is given in C:\Program Files\National Instruments\LabVIEW 2011\examples\NI Veristand\API\Execution API\Deploy and Read Channels

Is this an option for you? 

[Jesse_D]

Hi Mike, 

Did you find a resolution for this or do I need to keep following up with R&D to get an answer? 

[MPCC]

Jesse,

I did not find resolution to this. I checked the IO on the INERTIA custom device to be sure but it's nothing that appears usable to me. Everything is controlled through the added procedural steps or through the PID Configuration Tool.

I still can't get the PID Configuration Tool to launch inside the sub-panel.

Thanks!

[Jesse_D]

Hi Mike, 

Sorry to hear that. I discussed this with the veristand PSE, the conclusion we came to is that it will be better for you to develop something not using a subpanel approach. 

The base problem is that veristand is running in an Application Instance separate from your labview project. A sub panel for a given instance of a VI can only be opened in one Application Instance. Additionally, events and queues all exist within one application instance. I think in this case a communication system will need to be setup between the workspace tool and an external labview program to make sure the events and queues are registered correctly. 

There have been many discussions on communicating between projects. One of the more interesting ones is here. Between being able to launch a workspace tool from an external labview program and being able to communicate with that tool I think you will be able to build the solution. Will this architecture work for you?