A Challenge to NI: Use your Application Builder

Posted on Tuesday 27 May 2008

I'd like to challenge developers at NI to find more ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes.

One of the major pain points in my day-to-day use of LabVIEW (which I love) is building stand-alone applications. I suspect that the reason this is so painful for me is that (in addition to my use cases being fairly advanced) most of the developers at NI who are on the LabVIEW development team probably don't build applications using LabVIEW -- they are not eating their own dog food.

For example, LVOOP (native LabVIEW Object Oriented Programming) dynamic method overriding requires VIs of the same name, but it is impossible to store two VIs of the same name inside an EXE? How could this feature conflict possibly happen?  I suspect that nobody actually tried to build an application that used LVOOP until well after the feature was implemented.  What's even crazier is that NI was working on this feature for many years, before it was released.

As time goes by, more people within NI are developing code in LabVIEW on a daily basis. However, I'll bet that most of them never actually use the application builder to build stand-alone applications, since most LabVIEW code is shipped in source form and never gets "built" -- it's just one big, monolithic reuse library.

So, I'd like to challenge developers at NI to find ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes. It will make a huge difference to your customers.

I'll have you know that I'm committed to eating my own dog food, too.  At JKI, we work very hard to use our own products in a variety of ways:
  • EasyXML is being used inside VI Package Manager (and other JKI products and projects), for reading and writing XML files.
  • VI Package Manager (VIPM) is used to install EasyXML, as well as manage the LabVIEW configuration needed to develop and build EasyXML (and every other JKI product and project).
I'm only telling you this, because I'm committed to practicing what I preach.  And, we're working on a new version of VIPM that is going to take this concept to a whole new level -- more on that, later.

I should close by saying that I know some of the people who work on the LabVIEW application builder and LVOOP and they are all very nice/smart people who are very competent LabVIEW developers and software designers.  The only problem is that they are probably not eating their own dog food.  NI has stated that they are committed to this, so I want to make sure that this is one area they do not neglect :)

15 Comments for 'A Challenge to NI: Use your Application Builder'

  1.  
    Justin Goeres
    May 27, 2008 | 5:15 am
     

    I recall an NI engineer at NIWeek a couple years ago describing the sound of “several dozen foreheads simultaneously hitting their desks” when it was discovered that override VIs would have to be stored outside the EXE.

    Also, I raised a similar question (“Honestly, how may developers inside NI use the App Builder, and what do they use it for?”) at my local NI Dev Day a few weeks ago. I got an answer along the lines of, “We’re using it more and more every day.” I don’t remember it exactly, because it was really more of an accusation than a question to begin with, and the true answer is clearly, “Not enough.”

  2.  
    Ben
    May 27, 2008 | 12:51 pm
     

    Good points Jim!

    That reminds me a war story from back in the day…

    Ken Olsen (owner and founder of Digital Equipment Corp.) gathered all of his top managers togther and demanded that they assemble a computer system using only the instructions available when they were shipped.

    It was not very long until the hardware got much easier to work with.

    Ben

  3.  
    Mikael
    May 27, 2008 | 3:17 pm
     

    Hi
    I hope NI will abandon the LLB structure they are using in the exe-file or at least add folder support in the a LLB, this will make it possible to store everything inside the exe-file.
    One other painful thing I have is that a quite large application, with lot of classes and lvlibs, it takes me more then 30 minutes to build an executable and during that time I can’t use my computer for something else, since LabVIEW uses all my resources.
    Cheers,
    Mikael

  4.  
    May 27, 2008 | 3:48 pm
     

    Justin: Regarding, “foreheads simultaneously hitting their desks”, that sounds a lot like what happened when I found out :)

    Ben: Yes, these concepts are timeless. Thanks for sharing that story. I’m looking forward to sharing some stories about about how we’re eating our own dog food at JKI, soon.

    Mikael: It’s too bad you can’t use that 30 minutes to catch up on LAVA. Actually, I’ve worked on an application that takes 15 hours to build! And, it took much longer than that before we did some build optimization (removing some type definitions that were inside the class data cluster). Our solution to the long build time was to have a dedicated build machine with quad (4) core 2 duo processors. But still, this is very impractical — we can’t wait 15 hours to know if a build was successful.

  5.  
    Tom Eilers
    May 28, 2008 | 12:04 am
     

    It is not only that LVOOP things won’t work if you build an application. Also a lot of Properties won’t work any more after you build an application and that changes with every Labview version. And the superstar of all the vi’s that won’t work is the Current Path VI that never was good.

  6.  
    Ton Plomp
    May 28, 2008 | 4:16 am
     

    And that’s why we love OpenG, Tom see here.

    On the builder issue, what happens during those 15 hours? That are a lot of computations.

    Ton

  7.  
    Mikael
    May 28, 2008 | 3:25 pm
     

    Jim,
    15 Hours, it would be good if you could use a cluster server like this one:
    http://helmer.sfe.se/
    Cheers,
    Mikael

  8.  
    June 3, 2008 | 8:31 am
     

    Jim:

    Interesting point, for years I have maintained the belief that NI doesn’t hire enough from industry, since they typically hire right out of college. People that haven’t practiced, seldom preach an accurate message.

    Do you think this hiring practice could be one of the root causes? Just curious about your opinion.

  9.  
    June 3, 2008 | 9:04 am
     

    Matt: Yes, you’re probably right. NI typically doesn’t pay for experience engineers — they prefer to hire right out of college and have them develop their experience within NI. This is what makes eating their own dog food so important. It would probably benefit NI greatly to hire outside people who are very skilled users of NI’s tools, however, these individuals are, at the same time, both (1) expensive to hire and (2) have an enormous value to NI, when left “out in the wild”, where they directly purchase NI’s products or facilitate the purchase of NI’s products through integration services.

  10.  
    June 6, 2008 | 8:21 am
     

    Interesting point Jim. I wouldn’t have thought about how hiring an engineer from the industry might remove a customer. Valid and certainly an eye opening perspective. Thanks!

  11.  
    June 6, 2008 | 10:05 am
     

    Matt: Another interesting thought is that an engineer who is highly skilled in using NI products might be more valuable to NI when they are working for a large company vs. an NI alliance partner. The reason being that they can more effectively evangelize NI products within that large organization and they probably have a big stack of purchase orders ;)

  12.  
    Ritesh
    January 13, 2009 | 11:37 am
     

    Hi Jim,
    could you pls tell me which software do you use to build stand alone applications which you code in LabVIEW ?

    Thanks

  13.  
    January 13, 2009 | 11:57 am
     

    Ritesh: I use both NI’s application builder and OpenG Builder (the “ogrsc_builder” package available for download using VIPM).

  14.  
    Ritesh
    January 14, 2009 | 12:09 am
     

    Hi Jim,
    Thanks alot for your quick reply. I have already laid my hands on the NI’s application builder, but didn’t like it much. I’ll surely try the OpenG Builder.

    I have installed VIPM(not the professional) on my PC. i want to know if i could make my own packages of VIs and add them to my palette using VIPM. Is it Possible?

  15.  
    January 14, 2009 | 3:28 am
     

    Ritesh: Yes, you can build packages with VIPM. Check out the Package Building Guide, here: jkisoft.com/vipm/guide. There are some limitations in the Community Edition that are not present in the Professional Edition. There is a comparison of features, here: jkisoft.com/vipm/compare/.

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 1123 access attempts in the last 7 days.