Downloaded 42 times
Uploaded byDMC, Inc.
Tools for Managing your LabVIEW Source Code
The document discusses various tools and best practices for managing LabVIEW source code, including details on different file types such as VI files, LabVIEW projects, libraries, and packages. It emphasizes the importance of organization, dependency management, and the benefits of using the VI Package Manager for building and maintaining LabVIEW applications. Key concepts related to object-oriented programming in LabVIEW and tips for leveraging library management effectively are also highlighted.
More Related Content
Similar to Tools for Managing your LabVIEW Source Code
Tools for Managing your LabVIEW Source Code
- 1. Tools for Managingyour LabVIEW Source Code Jesse Batsche
- 2. Topics • What’s ina VI? • LabVIEW Projects (*.lvproj) • LabVIEW project libraries (*.lvlib) • LabVIEW Class Libraries (*.lvclass) • LabVIEW libraries (*.llb) • LabVIEW packed project libraries (*.lvlibp) • VI Package Manager (VIPM) • VI Package (*.vip) • VI Package Build (*.vipb) • VI Package Configuration (*.vipc)
- 3. What’s in aVI File? • Graphical G code • What you edit • Block Diagram • Front Panel • Compiled Code • What LabVIEW uses to run the VI • VI is a binary file format
- 4. Separating Compiled Code •When a VI is changed, LabVIEW recompiles all VI’s that call the changed VI • Separate compiled code from VIs, thereby creating source-only VIs, for the following reasons: • To simplify source control • To prepare VIs to be upgraded to a new version of LabVIEW • To improve load time for VIs *** • Compiled Code is stored in Compiled Object Cache
- 5. Separating Compiled Code •Mark Project Items to Separate Compiled Code
- 6. LabVIEW Projects (*.lvproj) •Important tool for managing project code • Configure multiple targets • Default = My Computer • Items vs Files Views • Virtual vs Auto-Populating Folders • Dependencies • Build Specifications
- 7. LabVIEW Projects (*.lvproj) •Project Conflicts and Resolution
- 8. Loading LabVIEW ProjectItems • Not every item in a project is loaded when you open a project • LabVIEW searches the locations of project items on disk to populate the project tree. LabVIEW then loads the following libraries, including the libraries under Dependencies, into memory: • Project libraries (.lvlib) • Packed project libraries (.lvlibp) • Class libraries (.lvclass) • XControls libraries (.xctl) • Statechart libraries (.lvsc)
- 9. Moving multiple fileson disk • Best way to smoothly move multiple files on disk is through Items view of LV Project • Ctrl/Shft to select multiple VI’s, or move entire folder • Allows LabVIEW to cleanly update dependencies • Best to do with all callers loaded into memory • Doesn’t necessarily get fully tracked by Source Control • Benefit of clean LabVIEW dependency updates generally outweighs this
- 10. LabVIEW Project Libraries(*.lvlib) • Collections of VIs, type definitions, shared variables, palette files, and other files, including other project libraries. • Use them to: • Organize a virtual, logical hierarchy of items • Name spacing to avoid potential VI name duplication • Access Scope control (Public, Private, Community) • Limit Editing Permission • A project library file does not contain the actual files it owns, unlike an LLB, which is a physical directory that contains VIs.
- 11. LabVIEW Project Libraries(*.lvlib) • Best Practice: Utilize access scope control properly • Create Private (and potentially public) folders at top level of library to differentiate, and configure access scope at the folder level
- 12. LabVIEW Class Libraries(.lvclass) • LabVIEW classes define data associated with an object, as well as the methods that define the actions you can perform on the data • Lvclass is similar to an lvlib, however: • lvclass contains the class private data control (a cluster ctl stored WITHIN the .lvclass file) • lvclass contains additional OO properties about the library and its members
- 13. LabVIEW Class Libraries(.lvclass) • LabVIEW Class Libraries provide the benefits of core Object Oriented Programming concepts • Encapsulation • Public • Community • Protected • Private • Inheritance • Data Abstraction • Polymorphism • Class vs Object (an instance of a class)
- 14. LabVIEW Class Libraries(.lvclass) • What is Object Oriented Programming? • What are the benefits? • Makes computer science best practices accessible to any user • Enables planning software using terms that match a feature specification • Easier to debug and maintain • Who should use LV OO? • Developing a large application, or one that will be maintained for a long time • Multiple developers working on the same VIs • Who should NOT use LV OO? • Express users developing simple VIs for quick measurements • Sometimes LV OO classes are overkill
- 15. LabVIEW Class Libraries(.lvclass) • This presentation does NOT cover LabVIEW Object Oriented programming • This video provides a great introduction to LV OO. It’s not short, but it’s worthwhile • http://www.ni.com/webcast/2703/en/ • After watching the above video, this white paper provides specific answers to certain technical questions: • http://www.ni.com/white-paper/3573/en/ • Another good reference on core LV OO concepts: • http://www.bloomy.com/support/blog/object-oriented-labview- inheritance-part-1-3-part-series
- 16. LabVIEW Library (*.llb) •A single file that acts as “zip archive” of multiple LabVIEW VIs • Generally used as a distribution tool, not a development tool • Advantages • You can use up to 255 characters to name your files • Easier transfer to other platforms (only one file) • Slightly reduce the file size of your project because LLBs are compressed to reduce disk space requirements • Mark VIs in an LLB as top-level so when you open the LLB, LabVIEW automatically opens all the top-level VIs in that LLB • LabVIEW stores many of its built-in VIs and examples in LLBs to ensure consistent storage locations on all platforms • Don’t make huge LLBs (impacts performance) • VI’s can be extracted from LLB later if needed • Generally… not the most useful these days • If in doubt, opt for lvlib
- 17. LabVIEW packed projectlibraries (*.lvlibp) • LabVIEW packed project libraries (PPL) are project libraries that package multiple files into a single file with a .lvlibp file extension • The top-level file of a packed library is a project library • All VIs in a PPL are pre-compiled • These VIs are only changed/updated when the PPL is built • Built specifically for one version of LV and one specific target • When you open a packed library, you see only the exported LabVIEW VIs • When you build a packed library, you can create it as a release build or a debug build
- 18. LabVIEW packed projectlibraries (*.lvlibp) • Benefits • When building an application, build time is shorter if portions of the stand-alone application are in packed libraries • Fewer files deploy when you deploy the VIs in a packed library • VIs that call exported VIs in a packed library can adapt to memory allocation changes so that you do not have to recompile the caller VIs
- 19. LabVIEW packed projectlibraries (*.lvlibp) • Considerations • Compatibility of Packed Project Libraries and Caller VIs • Extra management required when multiple targets are present • A little tricky if you have hierarchical dependencies of PPLs
- 20. LabVIEW packed projectlibraries (*.lvlibp) • Best Practices • Include only related VIs in a packed library • When you open a VI in a packed library, all VIs in the packed library load • After you create a project library in a LabVIEW project, create a separate LabVIEW project for the project library before you build the packed library.
- 21. VI Package Manager •VI Package Manager (VIPM) is a package management tool created by JKI that organizes and maintains packages within your LabVIEW environment • Various libraries and tools are supported for download via the LabVIEW Tools Network or the VI Package Network • Or, manage your own repository • Free version includes most useful features • Pro version for larger scale management
- 22. VI Package (*.vip) •A package is a file which contains all of the necessary components wrapped together along with the actual tool which is to be installed • The package provides information related to its destination, compatible LabVIEW versions etc. • Package files are saved in the *.VIP format.
- 23.
- 24. VI Package Buildspecification (*.vipb) • Make your own packages (available in VIPM free version) • Close parallel to LabVIEW application build spec • Various aspects of the build are defined: • Package properties/metadata (Name, company, author…) • Source directory/files included • Output directory • Destinations for package deployment (vi.lib, user.lib, etc.) • Source file settings • Advanced: • Install/versioning requirements • Dependency management tools • Licensing/activation tools
- 25. VI Package Configuration(*.vipc) • A VI package configuration contains a set of vi packages (of specific versions) • This complete set of packages can be deployed with one click (by VIPM free version) • Creating vipc file requires VIPM Pro
- 26. VIPM Summary: CoolFeatures/Benefits • Direct palette integration and quick drop integration • Automatic tool/project dependency scanning • Auto deploy dependencies for the package you want. • Automatic flagging of new available versions of tools • Quick VIPC deployment to recreate project environment • Easy migration to newer/older versions of packages • VI Package Repository (Pro Version) • Everyone connects their VIPM into company VIPM repository, so all published packages are listed and available • VIPCs allow all code to reside in the repo (good versioning) • Can automatically recreate project tool environment with one click • Streamline/encourage use of NI tools network/3rd party tools • Examples/Testers published alongside packages
Editor's Notes
- #4 By default, a VI contains two kinds of code: the graphical G code that you edit and a compiled version of this code that LabVIEW uses to run the VI. When you edit the G code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, which introduces unsaved changes to the calling VIs. Because VI’s are binary files, traditional diff/merge tools in common source control platforms do not work directly, like they do with text based languages.
- #5 When a VI Is changed, LabVIEW also automatically recompiles all VIs that call the changed VI, which introduces unsaved changes to the calling VIs. Because these unsaved changes complicate source control for VIs, LabVIEW allows you to separate compiled code from VIs. To simplify source control—If you separate compiled code from all files in a VI hierarchy or LabVIEW project, changes to one file do not produce unsaved changes elsewhere in the hierarchy or project. This behavior allows you to check out only the VIs you want to modify instead of all VIs that call the changed VI. To prepare VIs in source control to be upgraded to a new version of LabVIEW—You can upgrade source-only VIs to a new version of LabVIEW without checking out the VIs from source control. To improve load time for VIs—LabVIEW can load source-only VIs more quickly than regular VIs. To maximize this benefit, separate compiled code from all the files in a VI hierarchy or project. *** DMC has see mixed, and sometimes opposite results to this claim. Evaluate what works for your use case / code base. After you separate the compiled code from a VI, LabVIEW still compiles the VI when you modify subVIs. However, LabVIEW stores the recompiled version of the code in a compiled object cache rather than in the VI in source control. Because the VI in source control does not change, you no longer have to check the VI out of source control when you change subVIs. The object caches are located in the LabVIEW Data directory. You do not need to manually interact with the object cache. However, you might want to clear the object cache if you delete a large number of VIs in the previous list. LabVIEW does not automatically delete the associated compiled code when you delete these kinds of VIs. Do not separate compiled code from VIs that you intend to load or run using the LabVIEW Run-Time Engine. The Run-Time Engine cannot run these VIs because it has no access to the compiled object cache that stores the separate compiled code. If you intend for VI hierarchies that you check into source control to run on the Run-Time Engine, build a source distribution with the VIs.
- #6 Within a LabVIEW Project, go to Project >> Properties, and you can select whether to Separate Compiled Code for new project items You can also mark/unmark existing project items in batches
- #7 What is a LabVIEW Project? Projects in LabVIEW consist of VIs, files necessary for those VIs to run properly, and supplemental files such as documentation or related links. Use the Project Explorer window to manage projects in LabVIEW. In the Project Explorer window, you can use folders and libraries to group together items, and you can use a list of VI hierarchies called Dependencies to keep track of items a VI depends on. The Items page displays the project items as they exist in the project tree. The Files page displays the project items that have a corresponding file on disk. You can organize filenames and folders on this page. Project operations on the Files page both reflect and update the contents on disk. You can switch from one page to the other by right-clicking a folder or item under a target and selecting Show in Items View or Show in Files View from the shortcut menu. Project Contents Project root—Contains all other items in the Project Explorer window. This label on the project root includes the filename for the project. My Computer—Represents the local computer as a target in the project. Dependencies—Includes items that VIs under a target require, such as other VIs, shared libraries, and LabVIEW project libraries. Dependencies updates automatically when you add, remove, or save an item in the project. You cannot directly add files to or remove files from Dependencies. LabVIEW automatically tracks the hierarchy of every item you include in the project to ensure Dependencies includes files on which the item depends. Items that a VI calls dynamically do not appear under Dependencies. You must add these items under a target to manage them in a project. Build Specifications—Includes build configurations for source distributions and other types of builds available in LabVIEW toolkits and modules. If you have the LabVIEW Professional Development System or Application Builder installed, you can use Build Specifications to configure the following: Stand-alone applications Installers .NET interop assemblies Packed libraries Shared libraries Source distributions Web services Zip files When you add another target to the project, LabVIEW creates an additional item in the Project Explorer window to represent the target. Each target also includes Dependencies and Build Specifications. You can add files under each target. Disk vs Project organization (Virtual Folders vs Auto Populating Folders) Directories on disk do not match the project structure of virtual folders. After you add a directory on disk to a project in a virtual folder, LabVIEW does not update the folder in the project if you make changes to the directory on disk. Add a directory on disk to the project in an auto-populated folder to monitor and update changes on disk in the project. Use of Auto Populating Folders is generally good/recommended. Helps ensure disk org and project org stays aligned
- #8 The project can contain conflicts when two or more items with the same qualified name from different paths exist in the project. A yellow warning triangle appears on any conflicting items. Click the Resolve Conflicts button to view a summary of the project conflicts in the Resolve Project Conflicts dialog box. When the potion to "Use Selected Item" is grayed out for all choices, it basically means LabVIEW cannot cleanly resolve the conflict with any of the items. Generally, it means too much stuff is in memory right now, and less needs to be loaded at once to resolve the issue. Specifically, due to these Certain Conditions
- #9 Most Notably: Lvlibs load member libraries LabVIEW classes load Member VI’s, type definitions, and member libraries! Very different behavior than non-class or non-library code
- #11 What is a LabVIEW Project Library LabVIEW project libraries are collections of VIs, type definitions, shared variables, palette files, and other files, including other project libraries. When you create and save a new project library, LabVIEW creates a project library file (.lvlib), which includes the properties of the project library and the references to files that the project library owns. A project library file does not contain the actual files it owns, unlike an LLB, which is a physical directory that contains VIs. Files that a project library owns still appear individually on disk in the directories where you saved them. Benefits Name spacing to avoid potential VI name duplication Use project libraries to qualify the names of VIs and other LabVIEW files. LabVIEW identifies VIs by filename, so LabVIEW unintentionally might load and reference a VI because the VI has the same filename as another VI, a problem known as cross-linking. When a VI is part of a project library, LabVIEW qualifies the VI name with the project library name to avoid cross-linking. A qualified name includes the filename and the qualified name of the owning project library. Access Scope control (Public, Private, Community) Use project libraries to limit access to certain types of files. You can configure access to items and folders in a project library as public or private to prevent users from accessing certain items. When you set access for a folder as private, all VIs in that folder also have private access. Limit Editing Permission You can limit editing permission by locking or password-protecting project libraries. When you lock a project library, users cannot add or remove items and cannot view items that you set as private. When you assign a password to a project library, users cannot add or remove items or edit project library properties without a password. Users can open the Project Library Properties dialog box, but all dialog box components except protection options are disabled. Users must unlock the project library or enter a password to enable the dialog box components. To unlock the project library, right-click the project library and select Enter Password from the shortcut menu. Note: Adding password protection to a project library does not add password protection to the VIs it owns. You must assign password protection to individual VIs if you want to limit edits to the block diagrams and front panels.
- #12 Best practices Utilize access scope control properly Create Private (and potentially public) folders at top level of library to differentiate, and configure access scope at the folder level
- #13 What is a LabVIEW Class? You create user-defined data types in LabVIEW by creating LabVIEW classes. LabVIEW classes define data associated with an object, as well as the methods that define the actions you can perform on the data. The benefits of encapsulation and inheritance allow you to create modular code that is easy to change without affecting code throughout the application. In LabVIEW, the data of a class is private, which means only VIs that are members of the class can access the data. You define the data of the class in the private data control. When you create and save a LabVIEW class, LabVIEW creates a class library file (.lvclass) that defines a new data type. The class library file records the private data control and information about any member VIs you create, such as a list of the VIs and various properties of the VIs. The class library is similar to the project library (.lvlib). However, the class library defines a new data type. The private data control is a unique class library file that defines a cluster of data for the new data type and is the data on the class wire. LabVIEW does not save the private data control on disk. Instead, LabVIEW saves it inside the class library file. Saving the private data control inside the class library file allows LabVIEW to ensure that you never use the wrong private data with the class definition. What is Object Oriented Programming? In the broader programming/computer science world, Object-oriented programming is broadly considered to have demonstrated its superiority over procedural programming as an architecture choice in several programming languages. It encourages cleaner interfaces between sections of the code, it is easier to debug, and it scales better for large programming teams.
- #14 Encapsulation Each LabVIEW class consists of a cluster of data and methods to read and write to that cluster. The data of a LabVIEW class is always private or hidden from VIs that are not members of the class. To access the private data, you create methods, in the form of member VIs of the class, to perform functions on the private data of the class. Encapsulation is the consolidation of data and methods into a class where the data is accessible only through class member VIs. Encapsulation allows you to create modular blocks of code that you can easily update or change without affecting other sections of code within the application. While data of the class is always private, you can expose member VIs to the user in varying degrees. You can set the access scope of a method to the following options: Public—Any VI can call the member VI as a subVI. Community—Only VIs within the same class, friends of the class, or VIs within a friend library of the class can call the member VI. Community member VIs display a dark blue key glyph in the Project Explorer window. Protected—Only VIs within the same class or a descendant class can call the member VI. Protected member VIs display a dark yellow key glyph in the Project Explorer window. Private—Only VIs within the same class can call the member VI. Private member VIs display a red key glyph in the Project Explorer window. Not specified—This option appears only when you select a folder. The folder does not have access items specified. Access is public. By default, folders in a class do not have access specified, which means the folders are publicly accessible. Note If you specify access options for a folder, the access setting applies to all items in the folder and overrides access options for individual items in the folder. Inheritance Inheritance allows you to use an existing class as the starting point for a new class. If you create a new LabVIEW class and set it to inherit data and member VIs from another class, the new class can use the public and protected member VIs of the class from which it inherits. It also can add its own data and member VIs to increase its functionality. Data Abstraction: Abstraction is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics. Through the process of abstraction, a programmer hides all but the relevant data about an object in order to reduce complexity and increase efficiency. The resulting object itself can be referred to as an abstraction, meaning a named entity made up of selected attributes and behavior specific to a particular usage of the originating entity. In the process of abstraction, the programmer tries to ensure that the entity is named in a manner that will make sense and that it will have all the relevant aspects included and none of the extraneous ones. Information (Data) Hiding Data hiding is a software development technique specifically used in object-oriented programming (OOP) to hide internal object details (data members). Data hiding ensures exclusive data access to class members and protects object integrity by preventing unintended or intended changes. Because an object can only be associated with data in predefined classes or templates, the object can only "know" about the data it needs to know about. There is no possibility that someone maintaining the code may inadvertently point to or otherwise access the wrong data unintentionally. Thus, all data not required by an object can be said to be "hidden." Polymorphism Generally, the ability to appear in many forms. In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. More specifically, it is the ability to redefine methods for derived classes. For example, given a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the area method to it will return the correct results. Polymorphism is considered to be a requirement of any true object-oriented programming language (OOPL).
- #15 In the broader programming/computer science world, Object-oriented programming is broadly considered to have demonstrated its superiority over procedural programming as an architecture choice in several programming languages. It encourages cleaner interfaces between sections of the code, it is easier to debug, and it scales better for large programming teams. The idea behind object-oriented programming is that a computer program may be seen as comprising a collection of individual units, or objects, that act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility. A. What is the benefit to a brand new user of LabVIEW? 1. The strength of LabVIEW is that it makes the power of computer science accessible to non-programmers. LabVIEW object-oriented programming brings some of the most advanced programming techniques into the grasp of beginning users. OO requires more of a commitment to planning, and so is generally chosen only if the user is embarking on a large software effort. 2. OO provides a way of planning software using terms that match a feature specification. The description of the feature discusses about items that appear on the screen, or pieces of data that the feature will manipulate. With OO, you can write code that plans itself around those same terms: database objects, button objects, e-mail objects. B. What is the benefit to an experienced G programmer who does not practice OOP? 1. Easier to debug—More modular code allows you to narrow the list of VIs where a bug might be. 2. Easier maintenance—OO design leads to more structure, which helps developers to be more productive over time. Developers can easily identify areas where they want to add features, and are less likely to introduce errors into unrelated sections of code.
- #17 What is a LabVIEW library? A single file that acts as “zip archive” of multiple LabVIEW VIs When to use them? Generally used as a distribution tool, not a development tool You can use up to 255 characters to name your files. You can transfer an LLB to other platforms more easily than you can transfer multiple individual VIs. You also can ensure that the user receives all the files needed. You can slightly reduce the file size of your project because LLBs are compressed to reduce disk space requirements. You can mark VIs in an LLB as top-level so when you open the LLB, LabVIEW automatically opens all the top-level VIs in that LLB. Considerations Note LabVIEW stores many of its built-in VIs and examples in LLBs to ensure consistent storage locations on all platforms. If you use LLBs, consider dividing your application into multiple LLBs. Put the high-level VIs in one LLB and set up other LLBs to contain VIs separated by function. Saving changes to a VI in an LLB takes longer than saving changes to an individual VI because the operating system must write the changes to a larger file. Saving changes to a large LLB also can increase memory requirements and decrease performance. Try to limit the size of each LLB to approximately 1 MB. You can extract the source VI's from an LLB later if needed Generally not all that useful these days If in doubt, opt for an lvlib rather than an llb
- #18 What is a Packed Project Library? LabVIEW packed project libraries are project libraries that package multiple files into a single file with a .lvlibp file extension. The top-level file of a packed library is a project library. By default, the packed library has the same name as the top-level project library. All VIs in a PPL are pre-compiled These VIs are only changed/updated when the PPL is built Built specifically for one version of LV and one specific target When you open a packed library, you see only the exported LabVIEW VIs. Exported VIs are VIs in project libraries with a public access scope or VIs in LabVIEW classes with a public or protected access scope. Types of Builds When you build a packed library, you can create it as a release build or a debug build. A release build is the default build for a packed library. Create a packed library as a release build when you do not want to include block diagrams of the VIs in the library. If a VI is not a dialog box, you also can remove front panels on the Source File Settings page of the Packed Library Properties dialog box. Create a packed library as a debug build when you want to include block diagrams of the VIs. Use a debug build to debug issues in the packed library. Because you cannot save changes to VIs in an existing packed library, save the changes to the original VIs and then rebuild the packed library.
- #19 Benefits When you build a stand-alone application, build time is shorter if portions of the stand-alone application are in packed libraries. Because a packed library is a precompiled file, it does not need to compile when you build the stand-alone application, shortening build time. Because a packed library packages multiple files in a single file, fewer files deploy when you deploy the VIs in a packed library. VIs that call exported VIs in a packed library can adapt to memory allocation changes so that you do not have to recompile the caller VIs.
- #20 Compatibility of Packed Project Libraries and Caller VIs The following changes to a VI in a packed library require caller VIs to recompile: Changing the connector pane pattern. Changing the dynamic dispatch terminal on the connector pane. Changing an input terminal to an output terminal or an output terminal to an input terminal on the connector pane. Changing an optional input to required on the connector pane. Changing the data types of inputs or outputs on the connector pane. The packed library has the same properties as the top-level project library. Because you cannot modify a packed library without rebuilding, you cannot make changes to properties in the Project Library Properties dialog box. If a VI calls a packed library on one target and you open the VI on another target, when the VI calls the packed library, the library tries to open on the original target. LabVIEW includes dependencies of the top-level library in the packed library, but they do not export with the build and are not visible in the packed library. To export the dependencies of a packed library, place the dependencies in the top-level project library before building the packed library. If an exported VI has a connector pane with inputs or outputs of type definitions or classes, include the type definitions or classes in the top-level project library. Things can get tricky with hierarchical dependencies of PPLs Consider MGI Solution Explorer
- #21 Best Practices / Tips Include only related VIs in a packed library. When you open a VI in a packed library, all VIs in the packed library load. If you include non-related VIs, load time increases because more VIs need more time to load. After you create a project library in a LabVIEW project, create a separate LabVIEW project for the project library before you build the packed library. If you build the packed library in the same LabVIEW project where you create the project library and you replace the project library with the packed library, you cannot rebuild the packed library.
- #22 What is it? VI Package Manager (VIPM) is a package management tool that organizes and maintains packages within your LabVIEW environment It’s a tool for obtaining and configuring libraries and development tools You can also subscribe to shared repositories created with VIPM. Various third-party development libraries and tools are supported for download via the LabVIEW Tools Network or the VI Package Network These repositories are configured as built-in subscription channels within VIPM VIPM allows you to quickly access third-party networked code repositories and get them into your LabVIEW development environment quickly VIPM also helps you build your own reuse tools into packages which can be installed in LabVIEW. VIPM has configuration management features that help you configure your LabVIEW development environment for your current project. Created and managed by JKI Free version has majority of the useful features Pro version includes some nice additional features for larger scale package management
- #23 What are they? A package is a file which contains all of the necessary components wrapped together along with the actual tool which is to be installed. The package provides information related to its destination, compatible LabVIEW versions etc. Package files are saved in the *.VIP format.
- #25 VI Package Build (.vipb) What are they? Close parallel to LabVIEW application build spec Various aspects of the build are defined: Package properties/metadata (Name, company, author…) Source directory/files included Output directory Destinations for package deployment (vi.lib, user.lib, etc.) Source file settings Advanced: Install/versioning requirements Dependency management tools Licensing/activation tools