Calling Main and Extra Pages of Custom Device(s) from LabVIEW

[DaHelmut]

Hi,

I am currently evaluating VeriStand (VeriStand 2011) and its control from LabVIEW using .NET APIs.

I am trying to use LabVIEW to add and configure custom devices for a given system definition file.

For that I am using a subpanel, the same way it is done in the System Explorer.

It is almost working.

I only get errors from VIs that are dynamically called from the Custom Devices API. These VI's are part of an lvlib which is called "Custom Devices Storage.lvlib".

I can't find this lvlib on my Computer. So, I guess, this error is normal. The only way to get rid of this error would be to load this lvlib in memory, but how ?

An example of a dynamically loaded VI from the Custom Device API :

If I can't configure a Custom Device inside my own Human Man Interface, there is no way I use VeriStand in the future. I don't wan't an operator or an administrator to open the System Explorer and change anything else than Custom Devices that may change in several of our test benches.

Is there a way to do that or should I throw VeriStand to the trashcan ?

Thanks in advance for your answer(s).

Regards,

[DaHelmut]

Hi,

My project files are attached if you need to test something...

Regards,

[HoussamK]

Hi DaHelmut,

the easier option is to use a path control to enter the entire path.

When a path control is wired to Open VI Reference, it is not necessary to have the VI already present in memory. Because the full path is already specified in the path control, Open VI Reference loads the VI into memory and returns the reference to it.

[HoussamK]

in your case :

the easier option is to use a path constant to enter the entire path

[DaHelmut]

Hi,

Thanks for your answer...but I think you do not understand what my problem is...

The example VI is part of the VeriStand API. I should not modify any of those VIs.

The example VI is dynamically lauching another VI that is part of the Custom Devices Storage library. 

As I have seen on the forum this library is internal to VeriStand, and seems to be included in System Explorer.exe, thus it is in memory only for System Explorer.exe

So I guess this is not possible to use the configuration page of a Custom Device outside of the System Explorer ?

Have you checked and tried to launch the VIs I posted ?

Regards,

[DaHelmut]

My goal is to have access to the configuration page(s) of any custom devices in a LabVIEW application, and not only in the System Explorer.

[HoussamK]

If you want to build the custom device directly into an executable, replacing all the Custom Device API calls with Custom Device Offline API calls will also fix the problem.

VIs can be found in the following library:
<LabVIEW>\vi.lib\NI Veristand\Custom Device Offline API\Custom Device Offline API.lvlib

[DaHelmut]

Hi hsm78,

I think there is a misunderstanding...

I don't want to build a custom device directly into an executable.

I want to be able to configure the custom devices section of my system definition file in my OWN application : I want to re-create the same functionnalities of the system explorer : adding / editing / deleting ANY custom devices BUT in MY OWN APPLICATION.

If I am not the developer (for example if I bought a Custom Device on ni.com) how would I change the API calls if I do not have access to the source code ? That's why, I am testing my sample application with the PID controller custom device.

As I said before :

My goal is to have access to the configuration page(s) of ANY custom devices in my OWN LabVIEW application, and not only in the System Explorer.

Thanks in advance for your answer(s).

Regards,

[DaHelmut]

up

[Pie566942.0]

Hi Da Helmut,

The VeriStand execution target is defined by the System Definition (an XML file).  The System Definition includes the configuration of all custom devices.  When the System Definition is deployed, it configures the VeriStand Engine according to the System Definition.  You cannot remove the System Definition from VeriStand.  Maybe you already know that.  System Explorer is little more than an interface (GUI) for configuring the System Definition.  System Explorer also provides resources and hooks to items (items are code, i.e. software, i.e. plug-ins) so they can act like native VeriStand code.  You can remove the System Explorer from VeriStand.  Maybe you already know that.  What you may be missing is unless plugins are loaded within VeriStand's context, they don't have immediate access to the resources and hooks that allow them to act like native VeriStand code.  As with most plug-ins, without the right framework, the plug-ins won't work.

To limit the configurations your users can make, I can think of a few options.

• Make a normal, System Definition compatible custom device that does everything you need it to do.  Then build an API for that custom device.  Then write a LabVIEW application that "looks" like the custom device, but calls the .NET System Definition API and your custom device API.
• Make a normal, System Definition compatible custom device...  Let the operator configure it in System Explorer.  Then create an Action VI that parses the System Definition XML, retains the custom device configuration, and reverts the rest of the file before deploying it.
• Ask NI if there's a key you can put into the System Definition XML to protect sections from modification.  There are keys that protect against deletion and renaming, so maybe there's a key to protect against modification.

Best,

Steve K