Download
1 / 8
80 likes | 127 Views
At a recent North West LabVIEW User Group, I presented my experiences of managing large LabVIEW applications. I covered how to help keep your LabVIEW projects organised and manageable, using a series of tools within LabVIEW.
E N D
0 1 5 1 5 5 8 0 8 1 0 Navigate to... Managing Large LabVIEW Applications with LabVIEW Projects Posted by Martin on September 5, 2017 // 1 Comment At a recent North West LabVIEW User Group, I presented my experiences of managing large LabVIEW applications. I covered how to help keep your LabVIEW projects organised and manageable, using a series of tools within LabVIEW. Firstly, let me answer the question of what the challenges are that developers are facing when creating large applications. Also, how are these are different to smaller applications? With a small application, there is typically a limited set of inputs, outputs and logic within the program. This can be managed by a single developer, in a simple structure like a state machine or event driven structure. As the scope of an application grows the inputs, outputs and state logic grows making it more difficult to manage. A key problem is that adding or modifying one part of the program, will affect multiple other areas. At this stage a modular, well-structured application is needed. Also useful are some tools to build this application. Luckily LabVIEW has some great tools that can be of use here, the first of which is the LabVIEW Project: LabVIEW PROJECTS Subscribe To Newsletter
Since LabVIEW 8.2, LabVIEW Projects (.lvproj) are required to build executable applications. National Instruments encourage you to do much more with projects. They recommend that you use projects throughout your development process, to handle source code, devices and support files. I find a few tricks with projects really help me to keep track of: Empty Projects: When I am developing, I have a project for my main application. I like to create empty projects occasionally, to check dependencies within libraries and classes. When I have a fully populated project with many VI’s, libraries and classes, it’s difficult to view what the dependencies are between code modules, within the project. But, if you create a new empty project and drag in your library or class, you can immediately see it’s dependencies. An empty LabVIEW Project can be used to quickly identify dependencies The image above shows a before and after view of a class ‘Scan Part.lvclass’. I wanted to ensure that Scan Part.lvclass had no dependencies on other code within my project. So, I copied it into an empty project and used the dependency view. I then went about removing all vi’s within the class that were causing dependencies, until the dependency view was empty except for vi.lib. This was important in this instance, as I
wanted to create a packed library from the class that I could use across multiple projects. This technique is also useful when making reusable code from existing source code. Moving VIs with the Projects ‘File View’: I came across this feature completely by accident. If you press Ctrl + E when you are in the LabVIEW project, you will change from the Item View to the ‘Files View’. This shows how your source code is located on disk, rather than how it is grouped in LabVIEW libraries, folders or classes. This is interesting, but the real benefit of this view is for moving and renaming multiple LabVIEW VI’s, libraries and classes. The LabVIEW Project Files View is essential for moving multiple files on disk simultaneously Before I started using the Files View, renaming classes was a risky challenge that I ended up avoiding doing. This was due to many corrupted references within the class. Renaming and moving LabVIEW files, is much quicker and easier
if you use the project Files View. This lets you select multiple files all at once and move them on disk. For example, in the screenshot above I can rename Scan Part.lvclass. I can then select the class and all vi methods within the class, to move to another folder on disk all at once. As well as being much quicker, this helps LabVIEW to understand that the class name has changed, as well as the location of the method vi’s. You can move multiple files simply by selecting a group of flies, right clicking and selecting ‘Move on Disk’. Named Projects: We now use multiple named LabVIEW projects during our development phase, for a few reasons. When developing, using Real Time targets like CompactRIO or PXI, we often create a Virtual Machine. This simulates the Real-Time target before we have the actual hardware. Named Projects allow you to run your source code under different conditions easily. Using a dedicated project that contains the VM target is useful because we also use libraries. A library will become locked if it is open under multiple targets at the same time.
All the code modules within the projects are identical – there is no duplicate code. The multiple projects just allows us to easily run the code under different targets. This is also useful when combined with the Conditional Disable structure. We often have a series of conditions for Virtual Machines and simulated hardware. By having these in different projects, you can run the same code under different conditions, then easily run builds in your main project, with real hardware enabled. Project Hyperlinks: This is a small but very useful, feature of LabVIEW projects – you can add hyperlinks to the project. Hyperlinks in a project can help you to remember that essential forum post where you found technical advice. This feature really comes into its own when you are doing online research. It can solve a bug or tackle a new feature. We often have links to online forums or blog posts, that have outlined a solution to a specific problem. By posting the link within the project next to the code that we have implemented, it reminds us what the solution was based on and why those decisions were made. SUMMARY These tips and tricks for using LabVIEW projects, help our development team to create better solutions for our clients every day.
This is the first blog post in a series about managing large LabVIEW applications. I will cover Libraries, Sub VIs, Polymorphic Vis and distributing code with VI Packages and Packed Project Libraries, in follow-up posts. In the meantime take a look at our LabVIEW development and consulting services. One Comment Leave a Comment Danny Thomson //October 3, 2017 at 2:55 pm Thanks for this been meaning to read it for a while. I like the idea of different project with the same code, it make Conditional Disables in a project work better I feel. Also your use of hyperlinks appeals to me Reply Leave a Reply Name * Mail (will not be published) * Website
Submit To search type and hit enter Recent Posts Northern Automotive Alliance Business Awards AMRC Factory 2050 Visit Communicating with Smart Tools LabVIEW Sub VI Design Metis Automation Joins The Northern Automotive Alliance LabVIEW Libraries Managing Large LabVIEW Applications with LabVIEW Projects Transformation of the Automotive Industry by Connected Manufacturing Categories Automotive Connected Manufacturing Datalogging Embedded LabVIEW Tips Mass Customization NI Days North West LabVIEW User Group Software Design Uncategorized Copyright © 2017 Metis Automation Connected Manufacturing & LabVIEW Solutions
