Open different Workspace files with VeriStand API

[NotSureJoe]

Hello, I have a question about using VeriStand API in LabVIEW. LabView is able to open a specific VS project; now I want to tell VS it has to open the same project file with a different Workspace file (.nivsscreen) similar like the dialog below, but with the API:

The reason I want to do this is because I want to open different Workspace files depending on the connected hardware.

Is there an API-function to do this?

Thanks, Michael

[joshe]

I'm a little confused on what you are trying to do.  Using Labview you can launch a Veristand System Def file that will load it to the RT system, and then use other API's to read and write data from the host to the RT.  I used Labview to build my own Man-Machine Interface (MMI) to the RT system on the host using the Veristand API's since the VS workspace was so ugly to use.  If you are using the Veristand workspace for your MMI, it is probably just as easy to build a new project with the type of workspace you want for each hardware piece you are connecting.  You can then load the correct VS project based on the hardware connected.

[NotSureJoe]

Hi joshe,

thanks for your reply. We have a Software on top of Veristand which reads and writes data from host to RT, as you said. We don't want to replace the SysDef file on the RT every time we change the connected hardware (the PXI-system isn't changed), because the time it takes deploying the sysdef file every time is too long. I just want to tell Veristand to quickly switch the Workspace to show appropriate controls and indicators for the connected hardware.

I discovered the possibility to edit the .nivsproj file (which is just a XML file) and replace the path to the Workspace file (.nivsscreen). The next time I open the project the new Workspace is loaded. But this solution would require to edit the XML file with Labview, which is possible but a little awkward. Besides it would be bad style..

Another possibility would be the usage of the built in Screens of the Workspace. But then I have again the problem to tell the VS Workspace through the API which screen it should show (without selecting it manually in the drop down menu).

I hope I've put the idea across and would appreciate any comments.

[ClaudioH]

Hi KleisBert,

Allow-me to give another option: use the API to connect a LV app to VS.

Doing this your VS project may stay untouched and you change your LV app to remap as you wish.

Cheers,

[Jarrod_S. · Accepted solution]

There is not an API to directly change the workspace screen file or instruct the workspace at run-time to load a particular screen.

I can think of one way you could accomplish what you want, namely leaving the system definition deployed but programmatically selecting different workspaces to display via the API. It is a little roundabout, and there are some cosmetic oddities that I'll mention below, but it's probably worth a look. I'm attaching an example below you can play with.

The main idea is to create one system definition file, but then create multiple separate VeriStand project files that all link to this same system definition. You can do this in the Create New Project dialog by selecting on the System Definition tab to use an existing system definition instead of creating a new one. For each project you create, edit the corresponding workspace screens file to have whatever display you like.

Once you have done that, use the Execution>>Workspace VIs to programmatically deploy the system definition file. It is important you do this instead of deploying the system definition file through the project, as I'll explain below. Then you can leverage the Project Execution API VIs to programmically load and close projects, as well as launch and close the workspace for that project. To show a particular Workspace, simply close the current project (if any is open) and load the project associated with that workspace.Then instruct that project to open its workspace window.

The key thing to note here is that if a project loads and it detects that the VeriStand Gateway is already connected to its linked system definition, it will simply adopt that open connection. Furthermore, if the project closes, it will NOT undeploy this Gateway system definition connection, because it didn't deploy it in the first place.

Check out the example below. Just unzip all the files to the same folder and open Workspace Automator.vi. Make sure VeriStand is open before running this VI.

Known issues: When you switch workspaces in this example, you are actually closing one project and opening another. As such, the Getting Started Window might show briefly.

[NotSureJoe]

Thank you very much, Jarrod.

That's a working solution for us and much better than editing the XML code. It's a little annoying to see the Start Screen when you switch the workspace but as you said, these are just cosmetic oddities.

Wouldn't the possibility to switch the Workspace Screens via API be a nice addition in VeriStand 2012?

Kind regards,

Michael

[Jarrod_S.]

Would it be enough in your opinion to be able to send an API command to switch the screen being shown, and not necessarily the entire screens file?

[NotSureJoe]

Hi Jarrod,

at the moment it looks like we have to switch between different System Definition Files from case to case. So switching the screens via API wouldn't be that useful for us. We're more interested in disabling the display of the VS start screen on startup and its popup between switching different project files.

Regards,

Michael

[joshe]

This was given to me by an NI SE.  I have not used it personally, but it may help with your issue.  There also use to be a way to customize the VS start screen, but I can't seem to find anything about doing that now.

[Jarrod_S.]

The VeriStand Gateway is the automation server for most of the execution API commands. It does not include any user interface components such as the Project, Workspace, or Getting Started Window. As such, if you launch the Gateway directly in your own custom application, you do get headless access to communicating with targets and deploying system definitions, but you can't access the Workspace.