Since this is my first blog entry, I feel it’s only appropriate that I begin with a discussion about how to start developing a LabVIEW application. These days, it’s not uncommon for some of the more complex LabVIEW applications to span thousands of VIs, which can pose a number of challenges if not given proper thought. What many don’t realize is that they can simplify their life and perhaps keep more of their hair by knowing how to use some best-practices combined with some of the latest tools in LabVIEW.
And this is true for all applications, large and small – be it one developer or 50.
The nature of graphical programming offers scientists and engineers a clear advantage when it comes to reducing development time and rapidly prototyping complex systems that need to interface with hardware. However, as a result, many jump directly into writing code without really giving proper consideration to some of the more mundane practices. Is this you? Have you ever thought to yourself…
· “My files are so disorganized – I don’t even know if I’m working on the latest copy of my code!”
· “Oh no, someone else overwrote all my work with their changes – I just lost a week’s worth of work!”
· “I’m too scared to rename or move subVIs because LabVIEW will never find the right ones and I’ll have to re-link them all!”
· “I want to compare my latest changes with a previous version to examine exactly what the differences are!”
If you’re anything like me, you’d probably rather be coding in LabVIEW than thinking about any of these things, but I’ve seen too many developers paint themselves into a corner by ignoring some of these until the last possible second. This is not an exhaustive list, but for the sake of today’s entry, we’ll keep it simple.
For anyone reading this that comes from a Computer Science or Software Engineering background, you’ve probably already heard of SCM, or software configuration management. For those of you who have no idea what I’m talking about, this just refers to a combination of tools and practices that developers have been using for years to avoid some of these common problems. I’m going to discuss some of the tools that you can take advantage of in LabVIEW.
Perhaps the most fundamental and important tool for any and all LabVIEW developers is the Project Explorer. Those of you who have just recently transitioned from 7.1 or earlier may still be fighting adoption, but hear me out – this tool was designed to make your life easier – you just have to know how to use it.
The Project debuted with LabVIEW 8.0 to mixed reviews. For many who had grossly outgrown using their operating system’s file browser (ie: Windows Explorer or Finder) to manage all their files, the Project Explorer was a welcome relief and had a lot of potential. However, as with any completely new features, there was plenty of feedback and discussion on what could be improved.
Fast forward two years. LabVIEW 8.5 came out in August of 2007, and with it came a revamped version of the Project that incorporated much of the feedback we’d been hearing from you. It is this version and all the latest features that I’m going to be discussing in this entry.
This is a screenshot of a Project in LabVIEW 8.6 that happened to be open on my computer while writing this blog. It’s true – I code in LabVIEW for fun whenever I can, but I always use the Project and source code control (note the checkboxes). Friends don’t let friends code without the Project.
I have a golden rule that I preach to all LabVIEW developers who are just starting out with the Project: “Think of the Project Explorer as an opportunity to tell LabVIEW: ‘here are my files – this is what I intend to use in my application – nothing more, nothing less.’ By doing this, LabVIEW is smart enough to help you make informed decisions and manage your application.” To clarify, you can and should use the Project to manage all of your files – not just the VIs. Note that in my screenshot I have VIs, as well as PDfs, videos, DLLs, documents – anything and everything related to my application.
So what exactly can LabVIEW’s Project Explorer tell you if you use it correctly? It can show you your entire system – including all the hardware targets and build specifications your project uses. It can warn you when you’re potentially using the wrong subVI. It can tell you when moving or renaming a file will change a link from another caller. It can instantly tell you when you’ve added a new file on disk. It can tell you when someone else is modifying a file and help you track down the latest version of that file. It can show you, graphically, the differences between your revisions and the last changes someone else made (also known as ‘diffing’). The Project Explorer can even tell you if you’re breaking my golden rule (subVIs you haven’t yet added appear in a flat list under dependencies).
For those of you scratching your head at source code control (SCC), I’m referring generically to third party tools that are commonly used for large application management. They essentially serve as an intermediate layer between you and the centralized storage location for all your code. You, as a developer, communicate with SCC by telling it things like “I’m going to modify this VI.” Through this exchange of information, other developers can then be made aware of potential changes, which avoids overwriting work and helps the rest of your team know when changes were made and who made them. SCC is beneficial even for individuals who just need to keep track of all of their revisions. I myself keep a Perforce server on my laptop which I use to store and manage all of my side projects (Perforce is free for individual use – check it out at perforce.com).
Interested in learning about how to set up the Project Explorer to take advantage of all these features? You can find technical details on all the topics I’ve mentioned here and more on this wiki: Managing LabVIEW Application Development in the Project Explorer. This guide provides best-practices and technical how-to’s for using the Project, so be sure to check it out and let me know if you have any questions or feedback.