LabVIEW Development Best Practices Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

Object Oriented Design Patterns Technical Manual and Exercises

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.

7-20-2011 11-42-58 PM.png

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

  1. Requires LabVIEW 2012 or later
  2. Download and install the VI Package Manager (VIPM) from here
  3. Run the configuration file with VIPM
  4. Click 'Create Project' from the Getting Started Window

Related Content

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Comments
Member Wire_Warrior
Member

Is it possible to get a copy of the "UI Framework (PC-QSM)" project VIs that are referenced in the demo script? 

Wire Warrior

Behold the power of LabVIEW as my army of Roomba minions streaks across the floor!
Active Participant Elijah_K
Active Participant

It has been added now

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member franco.atzeni@terna.it
Member

Hi Elijah,

Your examples are very interesting.

I'm new with pattern LVOOP develoment technic and just for study I would like to

ask if is it possible have the UML description about UI Plugin Framework

Solution.

Thanks a lot

Franco

Active Participant Elijah_K
Active Participant

Sure thing.  I just added a power point to the document containing four UML slides.  The first two were made in power point and are simple but clear illustrations.  The last two were generated automatically in StarUML directly from the example code.

Let me know what you think.

Eli

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Active Participant D60
Active Participant

Hi!

Could you post the attached examples in LV09? Thank you!

---
+++ In God we believe, in Trance we Trust +++
[Hungary]
Member Wulfi
Member

It's all for LV11. It would be grate if you can post a verison vor 2010, because thats the newest not beta version...

Active Participant Elijah_K
Active Participant

Versions created in 2010 can be found here (document revision 14)

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member B.Settles
Member

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.

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Member tstahl
Member

There is a post in the ideas exchange for a long-term support version of LabVIEW. It is located at: http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/4814/page/1

Tim

Active Participant Elijah_K
Active Participant

I understand where you're all coming from on this matter, and I know that there are several threads on this topic.  We are listening, and we have gone to great lengths to improve the transportability of code between versions.  As an example, if you open the 'Save for Previous' dialog in LabVIEW 2011, you'll see that you can save for 2010, 8.6, 8.5, 8.2 and even 8.0.  This has been the case for the last several releases.  Where this breaks down is if you use functionality in a new version that is not available in a previous release, but LabVIEW will do its best to adapt the code for the older version or notify you of any conflicts.

At the risk of sounding like someone in marketing, a large part of the unique value we provide our users is the fact that they can leverage the latest technologies and hardware platforms in LabVIEW.  This is largely made possible by our annual release cadence.  In addition, it allows us to respond to feedback and ideas from users quickly - both 2011 and 2010 feature over a dozen user-submitted features from ni.com/ideas. 

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member B.Settles
Member

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

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Member ANDRES_VANEGAS
Member

Best Regards, could post examples in LabVIEW 2009

Member Jamey
Member

I just tried to use the link provided by ElijahK above to get a version of this for 2010 and it brought my straight back to this page where it says at the top "Version 17" not 14.

If you can resolve that it would be great!

Member doyles
Member

If you click on the "search" spyglass next to "VERSION 17" at the top, it will bring you to a revision comparison page.  You can select any version of this page to compare.  The code wasn't added until version 15 and when I downloaded the code it was still 2011.  I was in the session at NI Week that covers this and they stated they are still working on getting a 2010 version.  They "hope to have that out in a couple weeks".

Member drval
Member

I get tired of continually HAVING to ask this question:

Is there a version of this that does NOT require OpenG?

I really think there is an ENORMOUS problem in demo code being offered by NI and the code necessitating OpenG. I highly respect Jim Kring et al but I do NOT have ANY OpenG tools on my system and I do not want them on my system -- only NI code.

At the very least it would be good to mention this on the page pointing to downloads as well as in the presentations and hands on sessions during NI Week 2011.

So long rant shortened: Now what do I do? In other words, how can I remove all the OpenG calls and still preserve functionality?

Active Participant Elijah_K
Active Participant

To remove the OpenG libraries would require that I then re-write identical functionality myself, which defeats the purpose of reuse libraries.  As with all software environments, their is a tremendous value placed on the ability to reuse code and libraries in order to save time and leverage the experience of other people in the community.

The required dependencies are all included in the VI Configuration file, which is attached above (direct link).  If you have VIPM installed, this will ensure that you have all of the correct libraries, which includes OpenG, as well as three others that I borrowed from our systems engineering group.  In all, the level of effort to remove these would be quite high.

I am curious, why are you so opposed to the use of libraries such as the OpenG libraries?

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member drval
Member

Eli,

There are several issues here.

First let me be perfectly clear.  I'm NOT opposed to re-use libraries.  They are, of course, important and highly useful.  However, third party unsupported (by NI) re-use libraries are problematic.  I've been building distro EXEs since v5 and whenever I have relied on third party libraries there has inevitably been a problem when the next version of LV was released.  So there is the general issue of real, deployed re-use of "re-use" libraries.  I'm a small programming staff (really me and a consultant at times) maintaining and extending an application with a 10 year history and I don't have the time, let alone energy, to keep up with those kinds of problem -- that can be avoided.

I think Jim Kring et al do a fabulous job.  I don't have a problem with the quality of what they have done and shepherded through.  But I've even been caught in the past with those kinds of problems induced by the use of OpenG: a version changes and it isn't kept up to speed with the latest LV release, etc, etc.  That WAS years ago but, once bitten twice shy -- it took months to work around that.

The bigger issue for me though is that the use of a third party add-on was not CLEARLY announced in the example: and it's an "official" NI example, displayed and taught from during NI Week.  At the VERY least the use of OpenG -- or any other third party library -- should be plainly and obviously documented.  I now have a lot of work to do to clean this up or I have to change a very long standing policy of my company and open up an enormous can of worms (potentially).  Yes, I know JKI and OpenG community do a very good job and it is several years now since the last problem I encountered, and, and, and; however, the point remains: now I've got to integrate special re-use libraries into some code (probably duplicating other code already in my project) in order to make use of this example.

And that brings us, in a roundabout way, to the last point.  Come on NI.  Wake up and smell the re-use libraries!  VIPM is now "part of" LV.  It's way past time to integrate the OpenG code when possible -- with permissions obtained and tested (by those at NI who are already using it on their own systems perhaps) -- and alter the licensing of those OpenG libraries as needed so that the code is transparent to registered LV users, with no restrictions.  Then I'd be happy.  Get t into vi.lib where it belongs and make it easy and seamless for all of us.

Active Participant Elijah_K
Active Participant

In my opinion, we shouldn't add every VI created by our users to vi.lib for the same reason Apple shouldn't own every app that is available in their iOS App Store.  In addition to the logistical problems and resource-intinsive task of owning and maintaining that much IP, it would erode at the value of our EcoSystem - their is tremendous value in the fact that LabVIEW users can leverage and reuse IP created by other users for engineering and scientific applications, and we want to encourage that.  That is why VI Package Manager is now integrated with LabVIEW 2011, to make it even easier for users to share and exchange their IP.  By fostering this EcoSystem, we can focus our efforts on building a platform that supports all the latest targets and technologies.

I understand that you've had some problems in the past with integrating and using these libraries across multiple LabVIEW versions, but VIPM has really come a long way in the last five years.  I've been using it and the Open G libraries since 8.2 (six years ago), and I've always been impressed with smoothly I can upgrade my applications and migrate the dependencies to new versions.  As an example, I actually began writing the application in this document in LabVIEW 2009, and I've never run into any issues with the reuse libraries.

We've also built an internal team that is responsible for testing certified libraries (including the OpenG libraries) against future versions of LabVIEW to ensure that they will work.  The Open G libraries are certified as Silver Products, which you can read more about here.

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Knight of NI Knight of NI
Knight of NI

An from another side...

I have very tight requirements in the applications I develop. At times I have trouble getting LabVIEW installed without a very long song and dance. I can fight that battle since I can point back at NI if the Center for Desease Control (boy are they paranoid ever since the anthrax attack) goes down with an indication it came from my machine. The CDC would toss me with no hopes of return if I had to tell them "I used freeware".

Imagine if a Stuxnet virus was traced back to my code.

So my main point is that freeware is simply not an option for many of us and assuming we can all use it would be like assuming we are all on twitter or the like. I suspect NI does not intend LVOOP to be a game that can only be entered by passing through the OpenG door, but developing examples using OpenG stuff without an alternative makes the path a little longer for those that have to develop evrything themselves.

Those of us that do not have the luxury of using freeware still have a need to stay current with the latest and greatest educational oppertunities.

Just my 2 cents,

Ben

Proven Zealot Proven Zealot
Proven Zealot

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
SimonH
NI Employee

Ben you bring up a good point with regards to the applications you develop having to have accountability you can't obtain by using open source/freeware code you found on the internet.

I'm normally just a lurker in this group but I feel like there is an underlying frustration here that I would like to better understand.  Is merely installing the OpenG libraries on your system a problem?  Examples we (Eli, myself, other NI employees) post on the community or present at NIWeek do not go through the same testing process as code that ships with LabVIEW.  In that sense it is the same as the OpenG code -- it's (hopefully valuable) freeware that you use at your own risk, to aid your own understanding or experience, or as part of a system that you verify the operation of.  Everything is open source to the point where you can see exactly how a given function was implemented.

Put another way -- you shouldn't (and I know you wouldn't) be using any part of the example verbatim without verifying it works for your application. 

Is the problem with the OpenG code that you have to install it separately?  Are there licensing issues that make it difficult to download even for educational purposes?  Do you have policies about putting things into user.lib or vi.lib/addons that can't be used in final products?

We want to make examples that help and if the way we're doing so isn't helping we would like to address that.  We also want to balance that with our own efficiency and desire to advance best practices and we believe using the latest version of LabVIEW and taking advantage of well-written, freely available, re-use libraries help us do that and represent a good best practice for those for whom it makes sense.

Regards,

Simon Hogg

Knight of NI Knight of NI
Knight of NI

Good points Rolf!

Thank you for the feedback.

I have done what you suggested, download to an issolated looked and learned.

I am not dishonoring OpenG in any way. Plese don't take my post as anything along those lines. I also realize that my situationis probably unique. My intent was and is to undersore the proevious post.

There is also another factor that comes into play and that is the nature of "Design Patterns" which are supposed to be ready made solutions to well defined situations. For those that can't use OpenG, these design patterns are not available.

Plese feel free to jump on me! Maybe you will give me the info I need to see this a different way.

Attempting to humbly share my point of view, your brother in wire,

Ben

Knight of NI Knight of NI
Knight of NI

I would like to publicly appologize for everything I have said in this thread. My intent was to help and not insult anyone or anything. I will trouble you no more.

Ben

Member MattWhitlock
Member

Don't think you have anything to apologize for Ben, you expressed an issue that many people face. I think that LabVIEW users are not quite as prone to flame wars as other programmers, so please continue to share your perspective.

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.

From a management and software engineering perspective, I have huge issues with VIPM as the only acceptable means of software distribution. For packaged software (EXEs/plugins) and non-critical software, VIPM is great. For libraries to be used in mission-critical or long life-time applications, I don't like to use anything from user.lib. If I need to go back 10 years from now to tweak an application or make a bug fix, I have to have the exact same reuse library available. Unless it’s addressed by VIPM (haven’t looked into it closely enough), we could be facing a DLL hell like situation with these reuse libraries.

While not appropriate for all users/situations, I like to have the reuse library in the project directory structure and under version control. This makes it very easy to share code without sending someone off to install a bunch of non-standard palette items. It makes using virtual machines, multiple computers, distributed development teams, off-the-grid code sharing, etc. much easier. The tradeoff is that it takes more thought to keep the reuse libraries current, so it’s not a perfect answer.

I think that there are probably enough users with various issues with OpenG or any non-standard libraries that it merits some thought by NI on whether they should use it in code they hand out. I’d prefer to see OpenG not used in example code from NI, but if it must be used, please just put the relevant VIs in the project directory structure.

BTW, I think it's great for NI to be putting out so much useful information, and even if it's not perfect, please keep it coming.

Matt

Member justin.goeres Member
Member

MattWhitlock wrote:

                       


From a management and software engineering perspective, I have huge issues with VIPM as the only acceptable means of software distribution. For packaged software (EXEs/plugins) and non-critical software, VIPM is great. For libraries to be used in mission-critical or long life-time applications, I don't like to use anything from user.lib. If I need to go back 10 years from now to tweak an application or make a bug fix, I have to have the exact same reuse library available. Unless it’s addressed by VIPM (haven’t looked into it closely enough), we could be facing a DLL hell like situation with these reuse libraries.

Matt,

I think I can address some of these points.  If I'm off the mark or something isn't clear, we can continue the discussion here, offline, or in the JKI forums -- I'm happy to tackle these kinds of issues.

First, VIPM is by no means the "only acceptable means of software distribution."  It's just what NI (and Eli) have chosen for this design pattern.  VIPM happens to be a really good way to distribute toolkits and add-ons, and because of that NI has chosen to use it, but there are plenty of other ways to distribute LabVIEW code, both in general and in this community.

Second, regarding having to "go back 10 years from now,"  VIPM covers precisely this use case, and Eli is doing the exact "right thing" in this example. VIPM users like Eli can create VI Package Configuration (VIPC) files that contain the exact libraries (at the exact versions) used for development on a per-project basis. You can commit this VIPC file to source code control with your project so you can literally recreate the exact same library layout any time in the future by simply "applying" the configuration.  Omar wrote a blog post about this a while back that explains this a bit better.

I'm particularly interested in what you mean by "DLL hell" since that's a problem we've designed VIPM and VIPC files specifically to alleviate. If there's an angle on it where it doesn't serve your needs, I really want to find out more about your use case.

Member MattWhitlock
Member

Hi Justin,

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.

I wish NI would have just purchased VIPM from you guys, it would have prevented of the issues I've run into with it.  They've purchased software and packaged it as their own before, and it wasn't even high quality like VIPM... ahem, Database Connectivity Toolkit...

My issues with this particular example remain though with respect to teaching, T's & C's issues, etc.

Thanks,
Matt

Member Omar_Mussa
Member

drval wrote:

I've even been caught in the past with those kinds of problems induced by the use of OpenG: a version changes and it isn't kept up to speed with the latest LV release, etc, etc.  That WAS years ago but, once bitten twice shy -- it took months to work around that.

Just to point out a couple of OpenG feature that are highly overlooked:

  1. The source code is available, so it is possible to test OpenG libraries during the LabVIEW beta periods and prevent bugs from LabVIEW upgrades from getting their way into the OpenG libraries.
  2. OpenG library functions are all unit tested and the unit tests are also open source, so it is possible for anyone to both test and improve the quality of OpenG libraries by running/creating unit tests.  The unit tests for OpenG have been one of the primary mechanisms for ensuring that the quality of OpenG code is really high.   For example, the unit tests for the OpenG array library can be found here: http://opengtoolkit.svn.sourceforge.net/viewvc/opengtoolkit/trunk/array/tests/?sortby=date

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).

Active Participant crelf Active Participant
Active Participant
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.





Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Proven Zealot Proven Zealot
Proven Zealot

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Proven Zealot Proven Zealot
Proven Zealot

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Member justin.goeres Member
Member


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 .)

Member MattWhitlock
Member

Smiley Happy I think that NI should have made VIPM part of LV 2009, and paid JKI well for it. it would have made a number of these issues moot.  There's still, time though, 2012 is just around the corner.

Member MattWhitlock
Member

Rolfk,

I agree that the limitation against open source is misguided, but that doesn't actually matter. When a contract says no open source, there's no way around it. They're trying to say no crappy code, but that's not legally enforceable.

Although I wouldn't use example code verbatim, too many people do. I believe that we, as experts and LabVIEW advocates, have to be conscientious about putting example code out there it WILL get uses as-is.

As for holding NI accountable, there are lots of options there. Legal action is not what I'm talking about.

Matt

Active Participant crelf Active Participant
Active Participant

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.





Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
SimonH
NI Employee

Ben,

No need to apologize.  I hadn't seen Rolf's post before posting so my post was a little redundant.  My intent was not to jump on you or defend a certain approach, I was trying to probe to get a better understanding so I can accurately represent the needs of the community when we are making decisions.

I spend more time in meetings than programming these days so I love open, honest discussions like these.  So please, trouble us as much as you care to (because it's no trouble to us)!

~Simon

Member SamoraJ Member
Member

Hi all,

I have posted an idea about shipping VIPM-functionlity with LabVIEW.

/MArcus

Active Participant crelf Active Participant
Active Participant

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/





Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant FabiolaDelaCueva Active Participant
Active Participant

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:

UI Initialize.png

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Member Electromecha
Member

ElijahK,

This document is awesome!!  I've been following all your versions.  This looks to me like it should become the Advanced LVOOP Course.

Thanks for all your hard work and apparent dedication to simple and sexy code.  OO is the way to go!

+Steve

Active Participant Elijah_K
Active Participant

Thanks!

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Active Participant Elijah_K
Active Participant

By the way, for those of you who are interested in taking your OO skills to a level beyond this example, I strongly recommend learning about the Actor Framework, which provides an elegant mechanism for sending messages between independently running actors.  Their is a learning curve, but it is an extremely powerful framework that addresses a lot of common challenges facing large applications.  My personal favorte illustration of this is the Angry Eagles code, but I'm a little biased ;-)

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member Sjef Koopmans
Member

For some reason i can't find the folder: 'UI Plugin Framework Solution' where the file 'UI Plugin Solution.lvproj' should be.

I'm doing something wrong but don't know what.

Active Participant Elijah_K
Active Participant

Did you download this link: https://decibel.ni.com/content/servlet/JiveServlet/download/15014-18-31897/UI%20Framework%20Solution... and extract the contents of the zip folder?  Be sure to follow the setup instructions up above

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Member Paolo_Squillari
Member

I'm having the same SjefKoopmans' problem. I downloaded all material and followed the setup instruction, but all projects have some missing files. It seems that some folder has been moved (eg. Plugin libraries).

Some ideas?

Thanks,

p.

Active Participant Evan
Active Participant

Can we get this code in LabVIEW 2010?

I know you have tried to answer that before but revision 14 that you suggested has no code, and revision 15 is already 2011.  Then to re-iterate some of the comments from before.  Can you plainly and clearly document the software requirements for the various examples and presentations?  I downloaded everything started going through the presentations, got excited, and now I am sitting here with no ability to actually look at the VIs.  It would have been nice to know from the get go it was newer code.

Active Participant pallen
Active Participant

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.  

---------------------
Patrick Allen: FunctionalityUnlimited.ca
Active Participant D60
Active Participant

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.

ErrorHandler.png

---
+++ In God we believe, in Trance we Trust +++
[Hungary]
Active Participant Elijah_K
Active Participant

The command pattern is actually a concept upon which the Actor Framework is built (if you go deep within actor.vi, you'll see essentially the same pattern).  The Actor Framework combines this concept with more sophisticated management of running processes and communication between them.  If you were to build a 'large applicaiton' off of this simple illustration, you'd find yourself having to wrestle with many of the same challenges and problems that the Actor Framework has already solved for you.  Take a look at this example for an illustration of the AF in a fairly large application: https://decibel.ni.com/content/docs/DOC-21441

As for the error handling - this is just a cheap and easy solution.  I'm merely capturing the error and sending it to the Desktop Execution Trace Toolkit.  Most real applications are going to require something more sophisticated, as they may want to take an action (ie: retry, stop, ignore) as a result of specific error codes.

Elijah Kerry
Principal Product Manager, Platform Software
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Proven Zealot
Proven Zealot

D60 wrote:

- What do you recommend to use for large systems: This solution or Actor Framework?


                   

The command pattern is something that can play out at many levels of your architecture in various forms. The Actor Framework solves one particular version of the command pattern that occurs between independent modules. Patterns are called patterns because they recur in lots of forms and there is no one-true-final implementation that you should use. You memorize the *pattern*, not the particular syntax or implementation. That way you can create your own command systems in whatever case you encounter, as needed. In other words, just because you're using the AF in an application does not mean you might not need to write your own APIs that use a command pattern for other parts of your code, and just because you need the command pattern does not mean you should use the AF in all instances.

Member NI-hilator
Member

Any tips on keeping the various plugins loaded instead of swapping them out? Obvious things that come to mind are not unloading when loading a new, ensuring all unload when stopping, determine where/how their front panels will be displayed - a tab control with a new tab for each plugin would make it simple.  I also want a central logging so would be adding a producer-consumer pattern with multiple producers. The goal is a "slow speed" (1 to10 seconds intervals) monitoring/logging app with dynamic (runtime) selection of plugins. Would I be better to start with a different design pattern or framework? Thanks in advance for any insights!

Contributors