eCLA Summit 2018 Quick Highlights

European CLA Summit in Madrid

I had the pleasure of being able to attend the European CLA Summit last week in Madrid. It was my first time at the European Summit. Just like the Americas summit, it was kind of like drinking from a fire hose. The quantity and quality of the information presented was very high. There were plenty of great presentations. I took something away from every single presentation that I was able to attend. However there were a few that stood out to me.

“Modular Design Deep Dive” by Steve Watts

Steve is just a great presenter. He is very animated and energetic. If you haven’t seen one of his presentations, it is worth it for the entertainment value alone. Obviously the content is also fantastic. When I think of Steve, I think of a phrase that I learned while studying martial arts: “The better you understand the basics, the more advanced you are.” While Steve’s presentation style maybe be somewhat flashy, his programming style is not. He doesn’t use the latest frameworks, LVOOP, or other shiny tools. But he does have a great grasp on the basics. His presentation was all about Coupling and Cohesion. To a software engineer those are probably pretty basic concepts. However since most of us LabVIEW developers are not software engineers, Steve did a very good job of breaking it down and making it very accessible. My key takeaway was “Here are the general rules and ideas. Sometimes you have to make tradeoffs. When you do, just make sure it is a conscious decision and that you understand the implications.”

“Efficient Actor Framework Development” by Allen Smith

Allen gave a very technical presentation on the Actor Framework. If you use the actor framework, I highly recommend you watch it, because it will definitely change the way you do a few things. The presentation was basically about doing more with less. The one big tip I took away was to use a Self-Addressed message instead of an abstract message, when you needed to send a simple trigger message (ie. no data) to the caller. It requires fewer messages.

“UI Design” by Jorge Vasiliadis

Jorge just did a very brief demo of a UI that he had built. It was easily one of the most impressive LabVIEW UIs I have seen. He didn’t get into too much of the details about how he built it other than that he uses subpanels and moves them around. Just watch the video, when it comes out and you will be impressed. He mentioned he might do a follow-on presentation where he would talk more about the implementation, so keep your eyes open for that.

“LabVIEW Teambased development” by Paul Morris

I always go to these NI events wanting to learn all the technical stuff: the latest frameworks and toolkits, etc. However lately I have been coming to the realization that what I really value are the process and business management presentations. I found Paul’s presentation probably one of the most useful, in that afterwards I had a big list of action items. Paul talked about how as their team grew they realized that they needed to work a lot on their process. He outlined how they brought Fab in as a consultant and showed some of the processes they came up with as a result of that. I really liked a diagram he had that showed a gitflow type model with icons depicting at what stage various unit tests and vi analyzer tests were run. I thought that was a good way to visualize things.

“Team-based Development” by Chris Roebuck

Chris’ presentation has some very good content, but the real reason to watch it is for the entertainment value. It will have you rolling on the ground laughing as he identifies various labview developer personalities. You will recognize all of them, in fact you probably work with some of them. In all seriousness, Chris’ presentation provided some good insight into managing difficult developers and trying to get them to work together as a team.

“Guide to Scripting” by Fabiola de la Cueva

Just like Steve, Fab is a very energetic presenter. Her presentation was filled with links to all kinds of tips and tricks for scripting. If you want to learn scripting, it is all there. She also did a few slides on calculating ROI, which could be very useful.

OOP and Interfaces

I would be remiss if I didn’t mention something about OOP and Interfaces. There was a lot of interesting discussion at the conference on that topic. Those of you at the Americas CLA summit may remember Stephens presentation on vims and how you can use them to implement static interfaces. Steven gave a repeat of that presentation (with a lot more detail). But the most interesting part was Andrei Zagadorni’s presentation. He had come up with a very good implementation of dynamic interfaces using very basic LabVIEW classes and library features.

Andrei solved almost the entire problem, except for one little thing: dependency. In Andrei’s original idea his interface class was dependent on all the other classes that implemented the interface, which obviously poses some problems. Luckily Stephen was super-enthusiastic about this whole idea and he talked Andrei into having a seperate brainstorming session after the conference. A bunch of us sat down and discussed various options and ideas and came up with a pretty good solution. It relies on the call-by-reference node. There were some questions about its performance with regards to data copies. Stephen was going to look into that and get back to us. If that works out,then Andrei and Stephen will have found a way to implement dynamic interfaces in LabVIEW, which is very exciting.

Thank you

Thanks to all of the presenters. You all did wonderfully. Thanks to all of the attendees for some excellent conversations. Thanks to chair
Pascal Heinen and cochair James McNally, and everyone at NI for organizing. Thanks for Jeff Kodosky for his visionary presentations on what he sees as the potential future of LabVIEW.

2018 European CLA Summit in 2 weeks

The European CLA summit will be taking place in 2 weeks in Madrid.  I was luckily enough to be selected to be a speaker.  Here is a brief teaser of what I am going to talk about.

The software engineering book I should have read 10 years ago

I recently just finished reading "A Software Engineering Approach to LabVIEW" by Jon Conway and Steve Watts.  The whole time I was reading it, I couldn't help but thinking: "I wish I would have read this 10 years ago.  It would have saved me a lot of trouble."

Background

I started using LabVIEW back in 2007.  I had just graduated from college with an electrical engineering degree.  I knew a little about programming in general (mostly C and pascal), but certainly knew nothing about LabVIEW and even less about software engineering.  When I first started working in LabVIEW, I was thrown to the wolves.  I inherited a very large well-established project that would have benefited from some software engineering.  Over the next several year I continually beat my head against the wall while learning (mostly the hard way) many of the basics outlined in Steve's and Jon's book.

"A Software Engineering Approach to LabVIEW" was written back in 2004, so it was definitely around when I started using LabVIEW, but unfortunately I didn't know about it.  In fact I didn't learn about it all until NI Week 2017.  I saw Steve give a presentation at NI Week and I thought "Wow this guy knows his stuff".  I mentioned something to one of my friends and he brought up the fact that Steve had written a book. I thought "Oh I'll have to check that out." 

When I first looked it up, the first thing I noticed was that it was over 12 years old and that the reference code was written in LabVIEW 6.  Anyone who has used LabVIEW 6 knows that a lot has changed since then.  I started using LabVIEW 6 but pretty quickly graduated to LabVIEW 8.0  and the project, and soon after that libraries and classes.  I was somewhat skeptical as to how useful/relevant it would be.  What really changed my mind as far as getting the book, was reading a review by Fabiola de la Cueva back in 2012 where she asserted it was still relevant.  I thought I would give it a try.

 Review

First I must say I was wrong.  The code samples in the book may be dated but they are not outdated.  That is to say that it is very obvious they were written in LabVIEW 6, however those same vi's would likely function if written in the latest version of LabVIEW.  I must warn you thought, that if you tried that you might get laughed at as being too "old school".  Since Steve and Jon wrote those examples a lot has changed. The newer versions of LabVIEW provide much easier ways to accomplish a lot of thier ideas.

The key to getting the most out of the book is to look past the implementation of a lot of the code and focus on the principles.  Coupling, cohesion and information hiding are just as valuable today as they were 12 years ago.  You can easily take them and see how they apply to the Actor Framework or the DQMH or some of the other frameworks and design patterns. 

The thing I took most out of it was Chapter 7: Software Engineering Essentials.  It talks a lot about process and documentation.  It talks about development models, requirements gathering, quoting, test specs, etc.  All very useful things that I had somehow managed to get by so far without really diving into too deeply.  I'm more what Steve might refer to as a "techno sheep":

"Techno Sheep" was a term learned from a project manager; he used it to describe the difficulty in getting his programmers to stick to the core programs on the project when all they wanted to do was wander around munching on the interesting bits.

I always found solving technical problems to be much more interesting than paperwork, but Steve makes a very good case as to why the paperwork is necessary.  He also does a great job at breaking things down to their simplest level, so that we don't drown in paperwork, but rather end up with just the right amount to guide ourselves through the project and around any pitfalls.

The biggest complaint I saw about the book on Amazon was the image quality.  I didnt' think it was that bad.  Apparently Steve is well aware of it though, because when I sent him an email telling him I had bought his book, he immediately sent me digital copies of all the images.  My only complaint  (and it is a minor one) is that I didn't have access to the code examples.  It made it kind of hard to follow some of the last chapter where he goes into some of the details of the implemenation.  The website listed on the back of the book was down.  I'm sure if I would have reached out to Steve, he probably would have sent me a copy seeing as he was so responsive with the images.  I didn't bother because I was more interested in the principles in the book than the implementation.  I don't plan on writing any code in LabVIEW 6.0 any time soon.

Lastly I must say that the book is actually a pleasure to read.  I read it in 2 or 3 sittings.  It flows really well.  If you have ever heard Steve speak you will quickly realize that he has a great sense of humor and doesn't take things too seriously.  That definitely shows through in the book.

Conclusion

If you do software engineering in LabVIEW you should buy a copy of this book.  It is a few years old, but still very relevant.

NI Classes on Object Oriented Programming and Actor Framework

For those of you who want to take your programming to the next level, there are 2 classes coming ot Denver (actually the NI training facility in Louisville.) 

 

One is an introduction to LVOOP – LabVIEW Object Oriented Programming. It talks about how to apply Object-Oriented techniques to LabVIEW applications using native LabVIEW classes.  It talks about the basics of OOP, such as encapsulation and inheritance and discusses several common design patterns.

The Actor Framework (AF) is a way of managing multiple parallel processes. It is OOP based and has a definied messaging structure.  It is a great class and if you are thinking about using the Actor Framework, I highly recommend it.  Learning the AF by yourself is quite hard, the class helps a lot.

 

Here are the links for registration and pricing information:

Object-Oriented Design and Programming in LabVIEW – http://sine.ni.com/tacs/app/offering/p/s/ebiz/lang/en/ol/en/oc/us/id/1837037/

Actor-Oriented Design in LabVIEW – http://sine.ni.com/tacs/app/offering/p/s/ebiz/lang/en/ol/en/oc/us/id/1837038/

 

National Instruments is coming to Denver.

National Instruments is coming to Denver next week.  They are hositng 2 events at the Renaissance Boulder Flatiron Hotel in BroomField CO.  On Tuesday October 31st they are hosting the Denver CLD Summit and on Wednesday November 1st they are hosting NI Developer Days.

CLD Summit

The CLD summit is an annual event sponsored by NI.  It is a local gathering of certified LabVIEW Professionals.   It is required to be a Certified LabVIEW Developer or Architect to attend.  This year I am co-hosting the event along with Matt Richardson.  We've pulled together a nice lineup of presentations including cybersecurity, object-oriented programming, group development including using source code control, and several other topics.  

NI Developer Dfays

NI Developer days has a much broader audience. It is geared towards anyone who uses NI products in any capacity.   It is an annual single day conference that NI brings to various cities every year.  The idea is to reach out to customers who could not make it to their annual NI Week conference down in Austin.  It is part salepitch/marketing and part skills development.  It usually features some discussion on all the new features that have been introduced to LabVIEW in the latest release and highlights some of the new hardware coming out.  The rest of the day is spent on various presentations ranging from business related topics like "Calculating the ROI for an automated test system" to hardware topics like "How to select the correct D/A or D/A card"  to software topics like "How to choose a framework for your next software project" (which happens to be the topic of a presentation I am giving at the Developer Days this year).

Why go?

If you are Certified LabVIEW Developer or Architect, going to the CLD summit is a no-brainer.  The discussion is very high level and you are guaranteed to learn something to help improve your programming.  The Developer Days Conference is very good if you missed NI week and want to learn about the latest and greatest HW and SW.  Depending on the particular presentations you can also learn some valuable skills.  Both events are great for networking.  And did I mention that both are FREE?   So if you can get a day off of work to go check it out, there really is no excuse.

 

 

Introducing Automatic Version Manager (AVM) for LabVIEW

Automatic Version Manager (AVM) for LabVIEW

This video is a  demo of some software I wrote called Automatic Version Manager for LabVIEW.  AVM is a solution for dealing with multiple versions of LabVIEW installed on the same computer.  If you have ever used multiple versions of LabVIEW on the same computer, you have likely run into some issues.  Continue reading for more information about AVM.   After watching the video and reading this post, if you like what you see, you can go here to get a copy of AVM. 

What is the problem with the default LabVIEW Behavior?

The issues stem from the way LabVIEW sets file assosiactions with Windows.  When you double click on a LabVIEW file (vi, ctl, lvproj, lvclass, lvlib, etc) in the Windows Explorer, Windows uses the last version of LabVIEW that was opened in order to open the file.  If the last version of LabVIEW that was opened is not the same as the version of the vi that you are trying to open, there are 2 possbible cases.

Attempting to Open a file with an older version of LabVIEW

The first case is more of an annoyance than anything. In the first case, the file version is newer than the last version of LabVIEW that was opened.  For example, the last version of LabVIEW opened was 2015 and you double click on a vi last saved in 2016.  In this case, the vi will fail to open and LabVIEW will notify you.  It's kind of frustrating because LabVIEW knows what the version of the file is.  LabVIEW tells you.  But it cannot open it with the appropriate version.  That is just annoying and kills your productivity, but it's easy to recover.  Once you close the newer version of LabVIEW, simply open the correct version of LabVIEW and then double click the file, or open it from within the correct version of LabVIEW itself.

Opening a file with a newer version of LabVIEW

When you try to open a file with a newer version of LabVIEW the results are a little less pleasing.  LabVIEW tries to be helpful. It will open the new vi in the newer version of LabVIEW. This isn't necessarily a bad thing.  My biggest issue is that is does not tell you that you opened it in a newer version.  Combine that with the fact that the IDES for 2012-2016 look very similar and it can cause some serious problems. A simple dialog box here would solve a lot of problems. 

An Example

So imagine this scenario:  A colleague asks you to lookover something for him.  You are working in LabVIEW 2015.  First, you save what you were doing and close LabVIEW. Then, you check out the source code for your colleague's project (You should be using source code control.  If you are not – do yourself a favor and start now.)  You're not thinking clearly, or you don't remember what version of LabVIEW it was written in so you just double click on the project file.  Maybe you even say to yourself, "I don't care because I'm not going to change anything.  I just want to look at it."   Let's say this project was written in a previous version of LabVIEW, say 2014.  LabVIEW trying to be helpful, gladly opens it in LabVIEW 2015 and doesn't think to warn you.

Once you open the code, you look at his code and immediately find the problem.  After making a few quick changes, you save the one or two vis that need changed. When you exit LabVIEW, LabVIEW prompts you to save a whole bunch of stuff, but that is normal since some stuff likely recompiled.  Since you know that you saved what you changed, so you don't save all.  Once LAbVIEW exits, you check the couple vis you changed back in. Now, thinking you are done, you tell your colleague that you fixed it and checked it in.

Suddenly, your colleague calls, saying  the code  is broken and it won't even load.  "What happened?"  You ask incredulously.  "I only changed 2 or 3 vis."  LabVIEW was trying to help you, but unfortunately in this case, it caused more problems.  You did only chang 1 or 2 vis.  Unfortunately, you happened to edit them in a newer version of LabVIEW and when you saved them, you saved them in the newer version.  Therefore when your colleague goes to open his project file (which you didn't save, so it is still in LabVIEW 2014), the project opens, but it complains that it can't open the vis that you edited. 

Now you are left with 2 choices for fixing the problem.  Of course you can take your new edited 2015 vis and backsave them.  However that creates all kinds of problems, particularly if the edited vis called up subvis.  Those subvis have to be loaded and saved in 2015 and then backsaved as well.   Once integrated with the rest of the code this will cause crosslinking problems.  The easier option is to just roll everything back in source code control and redo your changes making sure that this time you are in 2014.  If it's just 1 or 2 changes, then no big deal. If you changed a lot, it can be a real pain. 

Again I will note:  A simple dialog box from LabVIEW notifying you that it is upgrading the vi to the new vewer version of LabVIEW would avoid all these problems.

There is a better way

In order to avoid all these issues, I designed some software that sits between Windows Explorer and LabVIEW, called AVM.  When installed, AVM injects itself into the launching process.  Instead of Windows associating vi, ctl, lvrpoj, lvlib, lvclass, etc with LabVIEW, these are now associated with AVM.  Now, when you double click on them in the Windows Explorer, Windows will open them, not with LabVIEW, but with AVM.  AVM then looks at the version of the file and the versions of LabVIEW that you have installed on your computer and makes an intelligent choice.  If it can, AVM opens the vi in the correct version.  If it can't, it doesn't automatically upgrade them.  AVM will prompt you for what to do.  Now LabVIEW will no longer be able to automatically upgrade your vi's for you without notifying you. You have to manually do it, by intentionally opening a vi in a newer version of LabVIEW.

Get AVM

In order to get a copy of AVM, go to http://automatedenver.com/automatic-version-manager/ and fill out the form there.  You will be e-mailed a link to download the installer.

Graphics Design for LabVIEW: Tips and Tricks

Graphic design should be important to anyone who designs and sells software.  The look and appearance of your final product makes an impact on what your users think of your software.  You want it to look professional.  Unfortunately, especially if you are an engineer turned LabVIEW programmer like me, you may not have a lot artistics skills and may not know a lot about graphic design.  It's ok. I've been there. Fortunately designing graphics for a LabVIEW application is not terribly hard.  If you are smart enough to code in LabVIEW, you can figure this stuff out.  You just need pointed in the write direction.  I am by no means a graphic designer, but making use of a couple free tools I've been able to design some really nice user interfaces in LabVIEW.

My main goal in designing graphics for aLabVIEW application is to make the program look like it was not written in LabVIEW.  I know you've all seen plenty of programs, where you look at it and you just immediately know it has been written in LabVIEW.  And let's face it, LabVIEW is UGLY! There is a whole lot that goes into UI design.  There's control layout, use of subpanels, resizable UIs, designing for touch screen devices, and a whole lot more topics  I suggest you research all those, but I'm going to talk today about some of the more basic concepts.  We are going to take a step back and look at just the graphics side of things.

Step 1 – Color Scheme

When desiging graphics for a LabVIEW application, the first place I usually start is with a color scheme.  I generally start with the customers logo.  Generally I want to feature their logo in the finished product.  Since it is going to be there, I might as well use that as a starting point and design the color scheme around that.  Logos are generally pretty simple color-wise.  Typically they might have 2-3 colors.  I like to take those colors and throw them into Adobe Colorwheel.  If you don't like Adobe, there are plenty others.  Just google "Colorwheel".  It takes a little playing around with, but you should come up with a set  of 5 or so colors.  There are several different color rules to use.  Just google them if you want more info.

After I pick my colors, I make up something like the graphic below.  I like to have a single graphic with a swatch of each color and then write the RGB values for each underneath them.  I'll either have this open on the screen or printed out in front of me as I'm working. Having it on the screen is nice because I can use the color picker.

Step 2 – Custom Controls

Typically I take this color scheme and then assign certain colors to certain things.   For example, with the colorset above, I used the dark blue as a background color with white text.  I used the 2 yellow shades for LEDs.  I used the grey for backgrounds on controls and indicators with either white or bark blue text.  Generally I would create a custom controls folder in my project and play around with the color pallette until I got some controls I liked.  Then when desiging my frontpanels, I would just right click and goto "Select File.." and browse to my folder full of custom controls.  Or maybe drag them out of the project window.  Just play around and see what catches your eye.  Remember a lot of this is artistic and subjective.  Pretty much anything looks better than the traditional LabVIEW look. I try to put together a sample like below.

Step 3 – Custom Drawings.

The next thing I look at is custom drawings.  Custom drawings might be for icons for boolean buttons (there are a lot available out there, look through some collections on google before you commit to drawing your own).  They are also useful to add graphics to your program.  For example a drawing of a pump or motor.  A really interesting thing to do is to generate some animation by using some animated gifs (google it – there's lots of ways to do it) or perhaps a simple picture ring that you programatically control – that may be a seperate post later.  For now though let's go over the basics of how you design a graphic and import it into LabVIEW.  Before you go reach for trusty old Microsoft paint, there is a better solution. 

I really like a program called Inkscape.  It is basically a free opensource equivalent of Adobe Illustrator.  It can be complicated to use, but if you just keep it to simple shapes, it is not too bad.  There are some good tutorials online.  The nice thing about inkscape that it creates graphics in vector form.  This means they scale very well.  Unfortunately LabVIEW accepts graphics in raster form. (if you don't know the difference, google it). That's ok, we can export an inkscape image using the "File > Export png image" command.   See screen shot below.

The next problem is that we need to know what size we want.  This is easily solved.  There is a free program called "A Ruler for Windows".  It is a pixel based ruler that you can move around your screen.  See screen shot below.

Once we've exported the .png file, we need to get it into LabVIEW.  For just graphics on the screen, we can drag the .png file from Windows Explorer and drop it onto the front panel.  You can also drag it into picture rings.  Booleans are a little trickier.  It depends on what you want to do.  If you want a specific graphic for true and a different one for false, then do the following: Copy one of the images to the clipboard and then in the control editor, you can right click on the boolean and select "import image from clipboard'.  That replaces the entire button with your graphic (be sure to select which state you want that graphic to represent – ie. True/False).  Repeat for the other state. This presentation goes over it well.  Another option is to take the Silver buttons and replace the image on those.  Here is link to a discussion about how to do that.

Step 4 – Generating windows icons.

A last little step I like to do is to generate an icon for my executable.  I like to design mine in inkscape, as the normal LabVIEW in the executable builder, leaves a lot to be desired.  My favorite program for doing that is Online Icon Converter.  Another fancy trick is to associate files with your .exe using the registry and give them your own fancy icons (maybe that will also be another post later).

 

 

Creating CHM Help Files

Help Files

If you are not creating help files for your applications, you should seriously consider it.  How many times have you written an application and then one of the users comes to ask you how to do perform some task in the software?  When I was writing software for lab testing equipment, I got those types of questions a lot.  Most of my projects were simple test rigs for the guy down the hall.  There was barely enough in the budget to get the software to work correctly, yet alone money for documentation. In those days it worked,  because I was right down the hall,and it was easy for him to walk over and ask questions.   Unfortunately times have changed.

As more and more people began using my software I got tired of answering the same repetitive questions.  Also, as I progressed as a software engineer I looked for ways to improve the quality of my software.  Adding a a well-put together help file became a way to avoid spending precious time answering basic questions and it also became a way to make my software look more professional. 

My last blog post was about Innosetup.  If you want to see what a good help file looks like, check out their help files…

Microsoft Compiled Help

For years the standard in help documentation has been the Microsoft Compiled Help format (chm).  If you have used a computer any time in the past ten years, you have problably used a chm file.   A chm is a single file that combines a bunch of html content with a table of contents and an index.  It all displays in a window as seen below.

screenshot

KEL CHM Creator

At first I was kind of intimidated by creating chm files, but once I found the right tools, I realized that it can be very easy.  The KEL CHM creator is a very nice GUI for creating CHM files.  It makes compiling the .chm file very easy.  The first step is to download the Microsoft HTML Help Workshop.  The next step is to get the KEL CHM Creator from here

Getting Started

Open the KEL CHM Creator.  Click on the compiler tab and make sure it points to the hhc.exe that got installed with the Microsoft HTML Help Workshop (see graphic below). 

screenshot

Next click on File>New CHM Project…   Select the folder where all of your html content is located and click ok.  This will fill in some of the fields on the compiler tab and create the support files necessary to compile everything.  It adds 3 files to your folder, as seen below.  The .hhp file is what you would click on to open the project in the KEL editor.  The others are just support files needed by the Microsoft compiler.

screenshot

Adding Content

NOTE: The KEL CHM creator does not create the .html content.  It just simply tells the compiler how to compile it all.  You will need to create the .html yourself using your favorite .html editor.  I happen to like atom.

Once you have your KEL project setup and your html files created, it's time to add them to the project.  Right Clicking on the TOC pane in the editor will allow you to Add Nodes.  In the resulting dialog box simply select the .html files you want to add.

screenshot

Organizing Content

Once you have added a bunch of html files to your project, it's time to organize them.  You can drop and drop them to arrange the order.  Dragging one page onto another nests it.  You can also add blank node, which act like folders, by right clicking.  See the example below.

screenshot

Creating an Index

The next step is to create an index.   I like to do this step last before I compile.  Before building the index, it is a good idea to add some tags to your .html files.  Inside your header tags, add <meta name='Keywords' content='My Content/'> tag and that will add 'My Content' to the index and link it to that particular html file.  Once that is done, go to the Index pane and right click.  Select "Add Index from HTML Keywords…"  (see below).  This will create your index.

 screenshot

Compiling

You are almost ready to compile.  First navigate to the Window Display tab and set the window title and the default topic.  Next click on the Build CHM Button (see image below.) This will compile the chm file and give you a results window where it reports any errors and allows you to view the compiled CHM file.  Now you are done.

screenshot

Conclusion

CHM files are a great way to provide guidance to your users. The KEL CHM Creator makes them fairly easy to create.  The fact that they are html lets you embed all kinds of graphics and links to external documents and websites.  If you are not planning on making one for you next project, you should.

Alternative to LabVIEW’s Installer Builder

Most people who develop software in LabVIEW are familiar with the installer build process from within LabVIEW.  If you haven't built an installer from within LabVIEW, it is similar to building an executable.  The first step is to build your executable.  Next you right click on Build Specifications in the project explorer window and select New>Installer.  That will bring up the Installer Builder window shown below.

LabVIEW Installer Builder

Next select the desired executable under source files and edit any other relevant settings.  The idea is that while the executable build script creates your executable, building the installer packages the executable along with any support files and creates a directory structure similar to what is shown below.

Output of LabVIEW Installer Builder

Running setup.exe will then install your program, which means it will put the executable and support files in the correct locations and add any registry settings and shortcuts that you may want. Then you can take the whole folder and zip it up and send it off to customers.

What I do like about the LabVIEW installer

Before I talk about what I don't like about the LabVIEW Installer Builder, let me talk about what I do like about it.  I like that it is integrated with LabVIEW.  There are no external programs to manage.  I can do my entire workflow from within LabVIEW.  I like the graphical user interface.   It is very intuitive and similar to the executable builder, so it seems very familiar.  I particularly like the GUI for editing registry values.  I like the fact that it makes it easy to install the LabVIEW Run-Time Engine as well as any relevant NI drivers (which it will find for you). It will even let you install a MAX Configuration file.

Why use an alternative?

My main issue with the LabVIEW Installer can be seen in the folder contents above.  The results are not lightweight.  After running the installer build scritp, it creates a whole set of files and folders that need to be zipped up and sent off.  Also, it's not obvious from the image above, but the overall size is quite large.  For a recent project the size was over 288 MB for a project with only about 25 vis.  If you want to distribute your installer over internet, the size can be a big deal.

Innosetup

Due to the size issue, I started looking at other tools.  After some research I settled on Innosetup. It's a free tool that allows you to create your own installer.  It has similar capabilities to the LabVIEW installer, however some of the LabVIEW/National Instruments features are not there, such as easily including the Run-Time Engine, NI drivers, or MAX configuration.  The main difference is that it is script based in nature.  Therefore, being a LabVIEW programmer instead of a text-based programmer,  I found it a little bit harder to use.  However it does have a very well-written help file.  Below is a screenshot.

Innosetup

The biggest thing I like about Innosetup is the results.  As shown below, my 288MB LabVIEW generated installer package was reduced to a single 2.5MB executable file.  In my case, that was worth the extra hassle. 

Output of Innosetup

 

Summary

So my point in this blogpost was to get the word out to other LabVIEW developers that there are alternatives to the LabVIEW Installer Builder.  When I found Innosetup I found several others (WIX being another popular one).  There are some tradeoffs to think about before using a different installer builder.

Here are some of the advantages I see to the NI builder:

  • Simplify your workflow – do all your work in LabVIEW
  • Nice familiar GUI interface
  • Easy to include NI drivers and RunTime Engine
  • Ability to Load Max Configuration files

Here are some of the advantages of using a 3rd party tool:

  • Size of final installer
  • More control – not limited to options presented in LabVIEWs built in GUI.
  • Script based – so potentially easier to automate.

Hopefully you all found this useful.

 

 

 

 

 

Denver CLD Summit

CLD Summit 2016

I recently had the privilege of presenting at the Denver Certified LabVIEW Developer Summit or CLD Summit for short.  It's sort of a "meeting of the minds" of some of the highly skilled LabVIEW developers in Denver.  It is one of the perks of being a certified LabVIEW Professional.  If you are not certified, I highly recommend that you look into getting certified.  Being certified gives you the ability to attend the CLD Summit, which has a lot of benefits, and certification is also a good feather to put in your cap.  If you are certified and didn't attend the CLD Summit, I highly recommend you make some time to attend in the future.  I always learn a ton at these events and they are almost always well worth the time invested.  I find it's always good to spend time in the company of people who are smarter than you.

Presentations

Overview

The CLD summit is organized by NI, and they usually provide a few presentations, but most of the content is provided by the local community.  Each presentation is generally about an hour long.  I had a teaching commitment in the morning so I missed the first couple presentations, but the couple that I saw were very good. 

Google Repo tool

The first presentation I caught was a presentation on using the Google repo tool to manage multiple git repositiories.  It was very interesting.  The presenter's product line required various different modules and depending on the specific product, it might require a specific revision of a module, which might vary from one specific product to the next.  Basically each module in was given its own git repository and then the Google tool kept track of a manifest file for each product that said: "For this particular product pull this specific revision of this module from this location."  You could peg a module at a specific revision or you could set it to get the latest.  I thought it was rather slick.  It was also a rather different way of thinking about the problem.  When the presenters were introducing their problem my mind had immediately jumped to using VI Package manager, but their solution seemed a little more flexible.

You're doing it Wrong

After that, Matt Richardson, who organized the summit, gave a great presentation entitled "You're doing it wrong".  He was basically poking fun at himself.  It was about an ongoing project he is working on and some of the issues he's been running into.  It was a lot of project management type dos and don'ts.  It also talked about webservices, Actor Framework and some other technologies and their pros and cons.  What I took out of it was don't fall victim to the magpie syndrome, where you constantly are trying to use the latest and greatest shiny thing, but make sure that the tool fits the problem.  Another major point I took out of it was to avoid fixed bids.  All in all it was a very useful presentation.  Matt is a very bright guy and very good at challenging the status quo and challenging people's thinking.

Virtual Machines

The next presentation was a roundtable on the use of virtual machines.  It was interesting to see the different opinions.  Various people used different Virtual Machine managers such as Virtual Box or VMware.  The opinion seemed to lean towards VMware as the better choice.  It also seemed like most people were making a single "virgin" image and then making copies of that for each specific application.   It also seemed like most people were carrying these around with them on USB 3.0 harddrives.  There was some discussion of running the VMs on a server and then remote desktopping into them, but it seemed like no one was really doing that.

My Presentation

After lunch, I gave a presentation on a toolkit that I have been developing for managing multiple versions of LabVIEW on a single computer.  There is a beta program available if anyone is interested.   You can find it on my website under the "Tips, Tricks, and FREE stuff" menu, or you can use the following link:  bit.ly/LVMBeta.  That was only a small part of my presentation.  Most of my presentation was on how to take a tool that you may have built that is rough around the edges and polish it and turn it into a product you can either sell or give away.  There's lots of good information in the presentation on building installers, graphics, and other tips.  The graphics slide is probably my favorite and points to a lot of free tools.  Here is a link to my presentation, so you can check it out yourself.

Followup

In writing my presentation for the CLD Summit and developing this LabVIEW version managing tool, I have learned a whole lot and it has sparked some great ideas for future posts.  Look for some more coming soon and make sure you keep your eyes open for details on next years CLD Summit. 

Sam

 

 

 

Top