Need help understanding how to license development and target machines during development/debug

[Rudders]

I would like to get a better understanding of how the licensing of a LabVIEW Full Development System is intended to be used in conjunction with the application builder and deployment on multiple target systems.  For example, this the following scenario:

• I am a developer and have LabVIEW Full Development System licensed and installed on my laptop to do software development.  However I have multiple target systems which consist of  industrial PC's with PCI-e data acquisition cards etc
• Each target system is functionally different and requires it's own specific software.  So for me to test and debug my application on each of the target systems I would also need to install the LabVIEW Full Development System.
• Once my applications are finished they would be deployed using the application builder so that my end customer does not have access to source code.

My questions are as follows:

1. In a scenario such as above how is the licensing of the LabVIEW Full Development System intended to work?  Would I have to keep moving my license from my laptop to the target system I am working on?  How easy is this if the target systems are not connected to the internet? 
2. Or does NI expect me to buy multiple development licenses, one for each target system even though the target system will only ship to the customer with executable from the application builder?
3. Is there something I am missing??

Any advice would be gratefully appreciated.

Paul

[Akiel]

As far I understand, (If your unsure i would contact NI to make sure alls good). You can install the runtime licenses on the target machine as required but you would need a license per developement computer. But if you have any questions contact your NI rep, they are often very helpful

TD 

[bonesjackson]

I'm a bit new to LabVIEW, but it is my understanding that you could purchase a LabVIEW Development System Debug License (some info here), which basically enables, on the deployment computer, all of the functionality you have with LabVIEW on the development computer. The caveat here is that the License Agreement states the you absolutely cannot use the Debug License to license LV for development puropses (because the debug license is quite cheap compared to the cost of the actual development licenses). It can only be used to license LV for debugging.

I believe the standard LV development licenses come with a "Home License" so that engineers can bring their work home, without having to take their development computer out of the office. You could potentially temporarily license the deployment computer you wish to work on with the home license. Then once debug is complete and your application has been built to an executable, remove the home license. I am NOT 100% sure this is acceptable with NI's license agreement. It would be great if an NI engineer chimed in on this.

Also, I'm not quite sure where you can find the LabVIEW Development System Debug License in the online store. I can never find it when I am browsing around. I think NI could really beef up their documentation in regards to debug licensing; much of it seems a bit unclear.

This is all my general understanding from reading some of NI's documentation. If I am wrong, someone please correct me. The learning process never ends with LabVIEW 😄

[MarkMoss]

If your development system license is a named-user license, then you're allowed to install it on up to three computers + a home computer.  Beyond these three, you'd need to buy additional development or debug/deployment licenses to cover the additional systems.  What we do here is to assign one of the developer's three development system licenses to the target computer when we need to debug on the target.  This is made easier for us since we have a VLA which allows us to centrally manage which developers are licensed to run LabVIEW on which computers.

In additional I would suggest that you work towards minimizing the frequency with which you need to debug on the target computer.  There are quite a few things we do here to help accomplish this.  Obviously some of these are much easier to do with a system built from scratch than when working with a legacy system.

1. Use LVOOP classes for the hardware interfaces.  This makes it easy to implement a dummy class which generates valid data.  Generally the dummy class simply overrides the setup/configuration/write methods to be NOP's and the read methods to return valid, but fake, data.

2. Use a plug-in architecture for your program so that you don't have to rebuild the entire EXE to deploy modifications to the test stand.  In some cases, essentially the entire program may be a plug-in which is simply loaded and run by the top-level EXE.  Combine this with good source control, it can be very easy to deploy modifications to the target (i.e.. commit on development machine, check-out/update on target machine).

3. Make the program as configurable as possible.  The more the user can configure the software to meet their needs, the less you'll need to modify the software itself.

4. Implement a debug dialog in your program which will display live data and state information.  This will allow you to find a number of problems without even going into the program's block diagram.  If you use events to communicate between different parts of your program, it's very easy to add a dialog which catches and generates these same events for debugging.

Mark Moss

Electrical Validation Engineer
GHSP

[nathand]

Along with these tips, remember it's possible to debug a compiled application remotely.  You need to enable debugging when you build, and set the appropriate flag in the INI file (if you don't use a custom INI file then this will be done for you when you enable debugging in the build).  Then you can connect to the remote application using your development system, no need to install the development environment on the target.  This is slower than debugging locally, and I've seen some crashes, but it can be helpful.

Also, the NI license manager makes it easy to activate and deactivate licenses.  Since the license allows a named user to install on up to three systems, I think you can install the development system on a target machine, do your debugging on it, then deactivate the license before shipping (or releasing) to the user to free up that activation, so long as you're the only one actually doing development work.

[Rudders]

Thanks for all your replies.  I was not aware of the remote debug capability, I will have somebody look into this.

After a lot of dicussion with our local NI rep the only real solution for us is the debug and deployment licenses so this is how we will be moving forward.

Paul