NI VeriStand Add-Ons Documents

Daniel_E · ‎02-22-2013

Overview

NI VeriStand has a .NET API (http://zone.ni.com/reference/en-XX/help/372846D-01/vsnetapis/api_hierarchy/) which allows you to programmatically create and configure a system definition. This API is powerful but complex to use. The simple system definition api is a LabVIEW wrapper on a subset of the .NET API to make use simpler.

The result is a user.lib palette that has one polymorphic VI.

The supported functions are:

Create Sysdef

Save Sysdef

Add Target

Add Chassis

Add DAQ

Add FPGA

Add CAN

Add Formula

Add Average

Add Acceleration

Add Maximum

Add Minimum

Add Peak and Valley

Add Conditional

Add Alarm Folder

Add Alarm

Add Alias Folder

Add Alias

Add User Channel Folder

Add User Channel

Add Model

Add Custom Device

Add System Mappings

Not Supported

Add LIN

Add Flexray

Add Shared Memory

Add Procedure

Anything else not listed above

Instructions for Use

An example is included with the API that should be the starting point for the user in the examples folder named Basic Example.vi The front panel cluster is already set with default values and will show the user how to format various inputs.

Another example named Script from Excel.vi is also included. This is for the case when the user keeps their hardware definition in an Excel file. The user could make changes to the Excel file and use this API to re-script the VeriStand system definition. Note: you will need Excel 2007 installed to run this second example.

Installation

The code is attached below. Download the code and extract the .zip file to your <LabVIEW>\user.lib folder. If LabVIEW is open, restart LabVIEW.

Requirements to Run or Modify

The code requires LabVIEW 2011 and VeriStand 2011 or newer. Make sure to match LabVIEW version to VeriStand version (both 2011 or both 2012, etc). If you want to run the Script from Excel.vi, you will need Microsoft Excel 2007.

Each function has the same basic structure. The Base Node Path is used to search and find the appropriate place in the system definition file. As an example, if Base Node Path is set to "Targets/Controller/User Channels", the search function will return the refnum to the User Channels section underneath the target named Controller.

The returned refnum is generic so it has to be type casted to the expected refnum. In the above example, that means type casting to NationalInstruments.VeriStand.SystemDefinitionAPI.UserChannels.

From this refnum, you use the various methods and properties to add your functionality. Again, in the example, this method is called AddNewUserChannel.

This functionality will require inputs, which you add to the Settings control. For user channels, you need Name, Description, Units, and Default Value. Make sure to make the Settings control a type definition specific to your new function (ie. User Channel Settings).

To aid in creating new functions, a template VI has been provided in <user.lib>\Simple SysDef\_Templates\New Add Function.vit. Create a new VI from this template as opposed to editing the template directly. Change the .NET reference to the expected class and add the necessary functionality. Make the Settings cluster a type definition specific to the new function. Add the necessary inputs to the cluster.

Release Notes

<1.0.0>

Initial Release

Known Issues

Certain VeriStand Functions have not been wrapped. These are:

Add LIN

Add Flexray

Add Shared Memory

Add Procedure

Anything else not listed above

Support and Contact

This add-on is provided as open-source software. If it does not meet your exact specification, you are encouraged to modify the source code to meet your needs. It is not officially supported by National Instruments.

National Instruments does not support this code or guarantee its quality in any way. THIS EXAMPLE PROGRAM IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

joshe · ‎03-11-2013

Hi Daniel_E, Thanks for putting this together. I am still trying to understand how this is working, but you might be able to point me in the right direction. I have a Sys Def already created and configured, I now have to add 100+ User Channels to add to it. I have the channel names in Excel, and would like to be able to load the file and add the User Channesl and Folders. Can I do this with this code? How? I would love to do the same for Reflective Memory, but it doesn't look like that is implemented yet. I am trying to understand this so I could modify your code to be able to implement the Ref Mem channels.

Thanks,

Josh E

Daniel_E · ‎03-12-2013

Hey Josh,

You will want to open the existing system definition as opposed to create a new one. This is a different function than above. However, once the system definition is open, you can use the rest of the API to add your user channels. Here is a quick example of what that would look like:

Note that you will have to write a VI that reads/parses the Excel file and puts the information in the expected format (cluster) for adding a User Channel. Also note that I used the default name for a controller (targets/controller/user channels). If your controller name is different, you will need to change the path.

As for reflective memory, I have not added that function yet. I will update the documentation above on how to add functionality to the API. Give me a day on that one. That said, the one comment I would make is that I believe if you have the reflective memory already added to the system definition, you can just reference the channels you want to share across the targets and they automatically get mapped. For example, if you wanted to do a calculated channel that included a local channel and a channel on another target, just build the calculated channel normally by browsing to the channels (ie. localch+remotech=calcch). If the reflective memory is in the system definition, the channel on the other target will automatically get mapped. As you are working from an existing system definition, it might be easier to just add the reflective memory to that existing sysdef. That is all theory as I have never tried it so let me know if I am incorrect on any of this.

Thanks!

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

Chuck_81 · ‎03-19-2013

Hi Daniel,

I'm trying to add aliases to a sysdef. I'm running this code

that runs ok in LV 2011 SP1 but returns a .NET exception (error code 1172) in 2012.

Any idea on how to solve this error? Are you aware of it?

Regards

Fabio

Fabio M.
NI
Principal Engineer

Daniel_E · ‎03-21-2013

Hey Fabio,

I did some testing and you are correct. It turns out that it is a bug in the .NET API (the stuff I sit on top of). I will file a report with R&D so they can fix the issue. I will see if I can come up with a work around.

Thanks!

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

Daniel_E · ‎03-21-2013

Hey Fabio,

I updated the API for 2012 and added the workaround for the alias issue. Please let me know if the new version fixes your issue (It did in my test).

Thanks!

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

StephenB · ‎03-21-2013

weird. you can't even construct an alias object with a path string without error 1172. I changed my code to use the other method of adding an alias by reference to the channel (instead of path string) and did the reference lookup myself. that works

Stephen B

StephenB · ‎03-21-2013

Thanks Dan!

what CAR # for the issue?

Stephen B

Daniel_E · ‎03-21-2013

CAR - Corrective Action Request - #398626

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

Chuck_81 · ‎03-22-2013

yes, the workaround works now. Only one thing: you cannot creata aliases with an empty LinkedChannelPath. This should not be a common use case, anyway you could do it in 2011.

Thanks fro the help guys,

Fabio M.
NI
Principal Engineer

GuilhermeCorrea · ‎05-09-2013

Hi Daniel,

How can I use this API to include a custom device to the system definition file.

I've tried to run the basic example, but it requires to select the Pre and Post Initialization VIs. Which files are these?

Regards,

Guilherme

Guilherme Correa

Daniel_E · ‎05-13-2013

Hey,

Good question! The first thing to note is that VeriStand doesn't provide any custom device system definition API methods or properties out of box. The only real method available is add. Add takes in a reference to your custom device. The developer of the custom device is responsible for creating a system definition API for the custom device. So, this feature only works if the custom device you are trying to use already has a system definition API created for it. I have no idea what different people are going to do in their custom device API. So, I allow you to run a LabVIEW VI before and after (pre and post) you add the custom device to the system definition. Those VIs can be anything but need to output the reference to the custom device so that I can add it to the system definition. The Pre and Post Initialization VI Settings are again a generic way to allow you to pass whatever you want into your custom VIs. If you want to see a custom device system definition API, you can look at the J1939 add-on.

I hope this helps!

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

bmorison · ‎11-22-2013

Any idea how this setup will work with 2013 LabVIEW and Veristand?

Daniel_E · ‎11-22-2013

I am not sure. I should have an update to the code by the end of the year if you can wait that long. I recently found some issues with adding aliases and CAN information in later versions of VeriStand so the update will fix those plus add support for 2013.

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

bmorison · ‎11-22-2013

Ok, thanks. We are using some similar code on a project I am on and are running into some issues with some of the low level calls. One section in particular appears to be pretty close to your setup for adding calculated channels by formula, we are getting a .NET exception there on the 'Formula' constructor node about an object reference not set to an object. Not sure yet if its a VeriStand/LabVIEW issue or if it is a machine/Windows issue. If we end up finding a solution or figuring out the issue on our end I'll pass it along.

Daniel_E · ‎11-22-2013

Sounds good. I do seem to remember having similar issues but it had to do with the order I added things to the system definition, searching from the right place in the reference hierachy, etc. I don't remember the specifics as this was a year ago and I got past it. Hopefully, it spurs ideas.

Daniel Eaton
National Instruments
Systems Engineering
Embedded and Industrial Control

daufdi13 · ‎04-24-2014

Daniel,

Any update for LabView/VeriStand 2013?

I tried to open your 2012 code in 2013 and it didn't seem to migrate very well.

I have a bunch of missing links and the 'Simple SysDef API_Poly.vi' seems locked so I am unable to fix what is broken.

If you are not planning on upgrading to 2013, can you please post code that I can edit?

Thanks,

Dan

StephenB · ‎04-24-2014

Dan, you might need to force the assemblies that the library is linked to be the ones for NIVS 2013. You can do this by placing an XML file next to your labview project named <project name>.lvproj.config and/or by placing an XML file next to your LabVIEW.exe named LabVIEW.exe.config.

I would attach the XML file here but you cannot do so in comments so I'm pasing the contents.

I'm giving two, one for NIVS 2013 and one for NIVS 2013 SP1 (which is available for download now).

NIVS 2013:

<?xml version ="1.0"?>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

NIVS 2013 SP1:

<?xml version ="1.0"?>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

<!-- Assembly versions can be redirected in application,

publisher policy, or machine configuration files. -->

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

Stephen B

KLSsuperstar · ‎11-04-2014

The add folder API seems to be not functionnal. I'm not able to pass an alias folder BaseNode ref to an AliasFolder Class.

See : http://forums.ni.com/t5/NI-VeriStand/BaseNode-ref-to-Alias-Folder-Class/td-p/3042357

Best regards,
Ulysse

Nicopsa · ‎05-10-2016

Hi !

I use the VI with an Excel, that include all of Hardware setting. That works pretty good but i have some question. First of all, why did this create some Aliases ? Is it possible to delete, because we don't use them ?

Second question, when I had my hardware, I do'nt understand how to get the port (port0, port1 ...) with the Digital I/O... any idea ?

Thanks a lot !

NI VeriStand Add-Ons Documents

VeriStand Simple System Definition API

Overview

Instructions for Use

Installation

Requirements to Run or Modify

Release Notes

Known Issues

Support and Contact