LabVIEW Development Best Practices Documents
This session will explore how popular software design patterns (ie: Command Pattern and Factory Pattern) can be applied in LabVIEW to develop complex applications that require scalability, extensibility and maintainability. Specifically, we will cover the use of a factory pattern to dynamically load and run plugins within a framework and the use of the command pattern to extend the functionality of a typical queued message handler / state machine. These concepts will be combined to illustrate an example of a object-oriented hardware abstraction layer in LabVIEW.
Summary
This technical manual demonstrates some of the most important object-oriented design patterns and how they can be used in LabVIEW to improve the scalability and maintainability of an application. A functionally equivalent version of the application that was built using a classic producer consumer queued message handler (PC-QSM) pattern is also provided in order to relate the example to a well-known LabVIEW approach. This application also demonstrates how proper architecture can enable a highly modular application that enables multiple people to work on separate components without impacting or breaking un-related components. This modularity is made possible by the fact that several dependencies are dynamically loaded at run-time, including the plugins and the images. In addition, the menu interface was designed separate of this application and is another independent resource.
Revision History
- 10/12 - New version of manual and demos released for LabVIEW 2012. One installer places everything in the 'Create Project' dialog.
- 7/11 - Updated for NIWeek 2011
- 3/11 - Updated for Developer Days 2011
Setup Instructions
- Requires LabVIEW 2012 or later
- Download and install the VI Package Manager (VIPM) from here
- Run the configuration file with VIPM
- Click 'Create Project' from the Getting Started Window
Related Content
I think Wulfi's comment points to a larger problem that I'm sure has been pointed out many times.
NI's marketing strategy of producing a new version of LabVIEW every year while concurrently working three versions in the background may be great for NI, but it sucks for the users that can't upgrade their software every year for a plethora of reasons, code maintenance and money being the big two.
Now I know that even compilers for other languages go through changes and can sometimes be incompatible from one to the next, but I don't think the compilers go through major revisions every year. (feel free to correct me if I'm wrong). So, will NI please look at making a compiler that can span a couple releases or some other solution that helps its user base while still dangling the carrot of must have new features every year.
I understand the benefit of the yearly releases and I appreciate that NI continues to innovate for the user. I also appreciate the save for previsous versions, but my point was really for being able to view examples and code from new versions of LabVIEW in older versions. I understand that some of the code isn't backwards compatible, but that would be limited to newer features that are still being refined and would only be a subset. I just want to be able to look at the code without requesting the person who posted the time to take additional time to post 3 different versions of the same code so everyone could view it. The code wouldn't even have to be executable. Just being able to see the code and then possibly code it my current version of LabVIEW would be enough.
Hmmmm...maybe I'll post an idea on the exchange for a LabVIEW Code Viewer plug-in that would allow you to view code but not run or edit the code (images of the front and block diagrams with embedded links to documentation maybe). The viewer would work for several versions of LabVIEW (maybe 3 or 4 major releases).
Update: Looks like the idea is there, but the proposal was intended for code reviews and allowing people without LabVIEW to see code. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-Viewer/idc-p/1645222
Sorry Ben but you make a somewhat roundabout explanation that doesn't fully work. You talk about educational opportunities. And about the code you have to provide as final product. Why would they even be remotely linked? For applications with such stringent requirements you surely aren't just taking an NI example and install it on that computer.
So where is the problem of having an isolated installation where you can install various software that you would not be allowed to use in production quality applications, so you can load this example and review it for your educational opportunity?
And your knive cuts on two sides too. Not everyone has the ability to install the newest and greatest LabVIEW versions that comes with a framework of library functions that doesn't even exist yet, to replace those OpenG functions. Would you want this library to be posted in LabVIEW 2012 because it might have the officially redeveloped and sanctioned NI replacments for those OpenG functions?
While you and a few others take issue with the fact that this example uses OpenG functions, others take issue that an example is only available in the latest LabVIEW version, and again others that it requires an expensive addon to be installed. So everybody gets now and then in a situation where he has to find a solution himself.
But reasoning that because your work situation doesn't allow OpenG to be installed for production type applications, it is also not allowing you to review the example for educational purposes simply doesn't work. Those should be and are entirely different things.
OpenG is not even Freeware, but Open Source. As such you could do whatever is needed to assess, certify, control, check, etc. the functions to be fine. Something you can't say about many NI functions. You just blindly have to believe that NI did it right and if they didn't and your mission critical project blows up you can't even get back at them as they exclude any liability anyhow.
And open source is in many ways the latest and greatest in educational opportunites.
OmarMussa wrote: Note that the unit tests predate both JKI VI Tester and the NI Unit Test Framework, so the tests themselves are just VIs that have a pass/fail status. Hopefully this helps anyone who cares about the quality of OpenG code (both developers including OpenG in their source and developers receiving code that depends on OpenG).
...and there are plans to migrate OpenG unit testing to a more robust strategy in the near future.
Ben, by all means, this was not meant as an attack against you, and I see no need for you to apologize. But I felt your post was connecting two things together that should not be connected at all anyways and I wanted to point that out.
The other part was more directed to the earlier post, that whatever NI does, there will be always some people who feel not happy about a particular way, the things are done. Use of OpenG could be one of those issues, although I believe it's mostly a policy issue, as you need to validate and possibly certify every piece of your application anyhow before you can release it to the factory floor. Use of specific LabVIEW features that only work in particular versions, or expensive addon toolkits are other issues for other people.
We also work with customers who are in regulated industries. But that would not mean that we can't install and look at software on our own development machines that would not meet the specific requirements of those applications. We simply can't include it in their applications!
LVOOP has majored and should be possible to be used now, but to be honest, if it's not necessary I still won't do it for such applications, as I have learned to work with the possibilities of earlier LabVIEW versions, and if something internal to LabVIEW breaks I can usually find a quicker solution in such situations than in a LVOOP application. And things can and have broken in the past quite a few times, and LVOOP still has a higher chance for that.
MattWhitlock wrote:
I have customers that explicitly state that no open source software be used as part of their contract T's & C's. Although this is example code, we all know that a lot of code gets used as-is (sort of the whole point of doing example code) without enough thought as to the consequences.I like OpenG and the people who've contributed to and maintained it. But, I think NI using it in public examples is a bit of an issue from a teaching standpoint. For those of us who teach others (UG's, training, etc), it is a pain or even unacceptable to have to go out and download packages (VIPM, OpenG, AMC, etc) other than what is included in LabVIEW natively. i.e. If it's not native LV, I won't promote it. I don’t think OpenG should be included with LabVIEW, but surely there is a better option.
Businesses buy LabVIEW from NI in part because they can hold NI accountable (or beg for help) if something goes wrong. There is perceived business risk (IP, legal, liability or other) associated with using non-NI libraries. Whether the risk is real or imaginary is up for debate, but for some businesses it's a deal-breaker.
I don't really understand the issues about using Open Source software versus openly available example programs! The first is often unit tested and whatever, the second many times just thrown together to show a concept as some sort of proof of concept. Why could you include the second (worse even "verbatim" as you hint) when you can't do the same with the Open Source??
And how will you hold NI accountable when your mission critical system blows up? They refuse all liabilities to the maximum extend the law allows, which is basically never more than the purchase price of the product and often much less.
MattWhitlock wrote:Thanks for clearing that up for me, it sounds like you've done a good work-around on the versioning issue. But VIPC isn't the way most people end up with OpenG. I'll look into it again for my reuse libraries, but VIPM is still a separate package for my customers to install so it's not ideal for me.
That's a fair point, but I'd suggest that once you standardize on including a VIPC file with the source of every project you do, it quickly becomes a very easy part of your workflow. That's certainly been our experience at JKI.
It's true that VIPM is a separate tool to install next to LabVIEW, but the installation process itself is pretty quick and painless, and you only have to do it once per machine. Given that the process of installing LabVIEW itself takes so long, adding VIPM to that isn't a huge deal. Again, my experience is that the inconvenience of installing VIPM is far outweighed by the benefit of getting exactly the right libraries installed in just a couple clicks.
(All this discussion of shipping VIPM with LabVIEW is also very interesting in its own right, and I hope lots of NI people are reading this thread 
.)
Right - once the vipc is part of your standard development process, you'll never look back. The benefits of have having avipc per project are huge, and far outweigh any other process I've seen.
This thread has kinda been hijacked - I suggest we continue the discussion on this parallel thread: http://lavag.org/topic/14732-why-is-openg-installed-to-the-userlib/
If you want to be able to change the number of menu buttons via the uiframework.ini, you need to modify the Sliding Menu XControl, this feature was not implemented in the original version. You can get the code from here as well as see two videos explaining the changes done. Once you have the changes you will need to modify "UI Initialize.vi" to set the number of buttons and te space between buttons as shown below:
Hi Eli,
Great demo!
It took me a few tries to figure out how to get things working. Somehow I ended up linked to older versions of this document at first and didn't have all of the correct files. Then I found the correct version of the document, installed the .vipc file, used the Create New Project dialog and found the new template ready to go. The documentation is even already bundled into the project file. Awesome.
....now I just need to figure out how it all works.
Hello Experts!
First of all, thank you very much for this interactive demo. This framework is pretty useful but I have some question regarding this solution:
- What do you recommend to use for large systems: This solution or Actor Framework?
- Could you give me some explanation about this error handling method? Pros & Cons? I have never seen similar error handlig tool like that.
