Developer Center Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand / VeriStand Add-Ons Licensing?

Is there a recommended method/recipe to create a licensed add-on for TestStand / VeriStand? 

Assume the computer where the add-on will be installed will not have LabVIEW installed, does that rule out Standard Mode licensing? 

Without LabVIEW installed on the target machine can we use VIPM for distrabution?

Any pointers anyone can provide, or a best practices for add-ons that do not directly integrate with LabVIEW on deployment machines that do not have LabVIEW installed would be appreciated?

Thanks!

-ben

0 Kudos
Message 1 of 4
(5,336 Views)

Hey there Ben,

 

One option is to use the Third Party Licensing and Activation Toolkit API and implement 'Deployment Licensing', as executing custom device code in VeriStand is analogous to using TPLAT to add licensing to a LabVIEW-built EXE where code is executing in the LabVIEW Run-Time Engine. The following list provides a rundown on what to consider:

 

The first link provides an overview of how to use the API, but there's an additional step in NIVS to disable a custom device when deploying through use of 'ActionOnCompile' and in the 'ActionOnLoad'...    For the ActionOnLoad you can report an error easy enough through the Custom Device API, reported to the user in the System Definition.   With the ActionOnDeploy action you set a flag to disable custom device execution when a license is invalid.  Also note, when deploying the code to NIVS you will need to include all of the dependencies from vi.lib (including the licensing DLLs) in a \VeriStand\vi.lib\ folder...

 

Of course, other licensing options are out there and can be baked into your code in a number of ways and the custom actions used to manage deployment of a custom device.

 

This does rule out use of Standard Mode licensing as it is intended only for the toolkit/edit-time licensing use case for the LabVIEW Development environment.  Without LabVIEW installed on a target machine there really is no point of having VIPM as it installs into and compiles for LabVIEW versions and it will spit out an error when no LabVIEW version is present.

 

I recommend building an installer when the add-on is not dependent on the LabVIEW environement and can install into its own \Program Files\ directory.

 

 

 

 

Message 2 of 4
(4,256 Views)

Thanks for the response!  I am well down this path, and it is working well with a VeriStand custom device driver, quick follow up questions:

 

1. ActionOnDeploy - As far as I can tell this isn't implemented yet, are the following two links out of date?

 

Asking for Action on deploy and a provided work around

https://forums.ni.com/t5/NI-VeriStand-Add-Ons-Documents/NI-VeriStand-ActionVIs/ta-p/3494427

 

Idea Exchange for Additional Actions

http://forums.ni.com/t5/Additional-NI-Software-Idea/Veristand-Include-Additional-Action-VIs/idi-p/23...

 

2. NI-Managed SOLO Server - going down this path, using the activation API, would we be eligable to use the NI-Managed SOLO Server or are we on our own to host our own server? 

0 Kudos
Message 3 of 4
(4,256 Views)

1. Good question, I am not sure.  I've not played with this action in a few releases but I do recall it wasn't working like I expected in 2011 or 2012.  It is worth testing and I recommend following up with Ryan in that thread to see if it has been fixed/updated. 

2. With the NI-Managed SOLO account we are only able to provide this approach for the Standard Mode licensing model based upon our agreement with Concept Software, but I recommend following up with the folks at CS to see if choosing the NI Managed SOLO Server is acceptable as long as you sell through the LabVIEW Tools Network...

0 Kudos
Message 4 of 4
(4,256 Views)