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


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.


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.


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 –

Actor-Oriented Design in LabVIEW –


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.


In order to get a copy of AVM, go to 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.


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


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.


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.


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.


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.



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.



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.


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.


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



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.



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


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. 





Easy VPN

VPN stands for Virtual Private Network.  Why would you need one?  Well, let's backtrack to my previous post.  My previous post was about how to setup a development server.  It works great when I connect to it over my home LAN.  Your home LAN, or local area network consists of all the computers/devices connected to your router (wired and wirelessly).  However the next obvious question is how do I connect to it from outside my home LAN?  For example while I'm on a customers site.  A VPN allows me to connect to any computer (or virtual server) on my home LAN from anywhere with internet connectivity.

In this blog post, I'm going to talk about how to setup a simple VPN connection to your home network.  It will utilize a program called OpenVPN, and we will run it on a virtual appliance using turnkey linux (see previous blogpost for more information about turnkey).  They are an amazing resource and their free appliances typically work very well.  However I have found that sometimes they can be a little tricky to set up (at least to get them to function the way I want them to function).  That is why I'm writing this blogpost, in part to document what I am doing and in part so that others may benefit. 

Networking Overview

First we need to review networking.  If you are already an expert, you can jump ahead. This is a very brief (and rudimentary) overview.  It's obviously slightly more complicated than what I'm laying out here, so if you want to know more, a quick google search should produce more than enough information.  As you may know every computer has an IP address.  It's kind of like a mailing address.  It tells other computers where to deliver messages to it.  There are basically 2 types, global addresses and local addresses. Think of it this way:  A global address is like a street address for an apartment building, while a local address would be the apartment number within the building.  In terms of your local LAN, your router has a global IP address and all your devices are given a local address by your router. 

So when a local device wants to communicate with the outside world, it sends a message through the router which sends it to the correct global IP address (all your, etc URLS get translated into an IP address).   The global IP address then sends a response to the global IP address of your router (it doesn't know anything about the local IP address system).  The router then routes the response to the correct local device.  The router is acting as a gateway connecting your inner local network to the greater internet.

When a local computer talks to another local computer, it sends a message through the router, which sees that it is destined for a local address and forwards it to the correct local device.  The same thing happens to the return message.

DNS and Dynamic DNS

DNS stands for Dynamic Name Service.  If you recall above I mentioned that URLS like get translated into an IP address.  DNS servers are what do that translation.  A DNS server contains a lookup table that links each Fully Qualified Domain Name into an IP Address.  That way you don't have to remember the IP address for google, facebook, twitter, or whatever your favorite site is.

The first step in accessing your home network from the outside world using a VPN or any method is to know it's IP address (ie. the global IP address of your router).  One way to figure this out is by typing "What is my IP address?" into google.  Unfortunately for most home internet services, the global IP address of your router is not fixed.  Your ISP randomly assigns your router an IP address and that can change over time.  So one way of dealing with this problem is to use a dynamic DNS service.  It keeps track of the changing IP address for you and gives you a URL that you can use that will always point to your routers global IP.  I personally use duckdns, but there are other services out there.  Often a router comes with pre-installed Dynamic DNS support – check your routers documentation.  Dynamic DNS works by running a script on a machine inside your network which detects your routers global IP address and sends an update to the Dynamic DNS service.

Port forwarding

Using a VPN is a great way to access your network, but its not the only way.  There is a method called port forwarding.  Remember that external devices only know the IP address of the router.  For example say I want to access my server, whose local IP is  If I type that into my web browser, whatever router I'm connected to will recognize that as a local IP address (10.x.x.x and 192.168.x.x are reserved for local addresses), and will forward it on the local network only.  If I'm inside my home LAN, then all is well, but if I'm outside, then I'm not going to be talking to my server, but rather the local device (if it exists) with that local IP address.

Portforwarding is a way to use your router's global IP address to access a service on one of your local computers.  First we need to address the subject of ports.  A Port is like a mailbox slot.  Every IP address has a whole bunch of numbered ports attached to it.  Different services on the computer listen for messages on different ports.  For example, http uses port 80, https uses port 443, ssh uses port 22, etc.  Portforwarding is setup on your router (see for directions for your specific router) and says that whenever the router recieves a message from the outside world on a certain port to forward it to a specified computer on your internal network.  So to send a message to a server on my internal network on port 22, I just send it to my router on port 22 (using the router's global IP address) and if port forwarding is set up correctly, it will arrive at my internal server on port 22.

Why VPN and not port forwarding?

Portforwarding has a few disadvantages:

  1. Overhead. You have to open a port for each service you want to access from outside, this is a tedious task. Everytime you add a new service, you have to remember to forward the ports.  And if you decide to stop using  it, then you have to remember to go back and remove it from the port forwarding list, so the port is not sitting there open, which could compromise security.
  2. Less Security.  The more ports you have open, the more chances for an attacker to compromise your systems.  A port is basically a way for attackers to send malicious messages and data into your local network.
  3. Port conflicts.  You can only forward a port to one specific computer on your local network, so if you want to have 2 webservers running, then you have to force one to run on a different port

In Contrast, with VPN:

  1. Single Port.  You are only required to open up a single port for the VPN connection, and you are only required to do this once.  When you add a new service, there is no need to forward another port.
  2. More Secure.  There is only 1 port and all VPN traffic is encrypted, so it is much harder for attackers to break in.  Also VPN lets you encrypt normal internet traffic when it is routed through your VPN.  This lets you browse the internet at the local coffee shop without worrying about people sniffing your internet traffic.
  3. Access to all services.  Once you are connected to the VPN, it is as if your laptop is plugged directly into your router.  You can access any service normally available on your home LAN.

Avoiding IP conflicts

We are almost ready to setup a VPN, but there is one more topic that needs addressed and that is IP address conflicts.  When a computer connects to your router, the router assigns it an IP address (a local address).  Every computer on your LAN has a unique IP address.  Your router has a limited pool of IP address to assign.  The same way, when your laptop connects to a VPN, the VPN assigns it an IP address from a pool of IP addresses.  But it also has an IP address for the local network that is connected to at the coffeeshop or at your client's site or wherever you happen to be accessing the internet from.  All of the other computers on that network also have a local IP address.  All of these IP address pools need to be seperate, so there is no possibility for confusion.

For example, on most routers the preconfigured IP pool is 192.168.0.x.  The routers local address is usually  So if you want to talk to your router to configure it, if you are on the local network, you type into your browser to connect to it.  So you go to a coffee shop and connect to its wireless network and then connect to the VPN.  What happens when you type in  That depends on the coffee shops router.  If it's local IP address is, now you have a conflict.  You computer doesn't know which one to connect to.

You can't control how the coffee shops router is configured.  There is always a possibility for conflict, but there is an easy way to make it much less likely.  Change your router's (and your VPN) preconfigured IP pool to something else other than the defaults.  The most common local addresses are 192.168.0.x and 10.0.0.x, so pick something else.  Look at your routers documentation on how to do this.  For the VPN, you get to pick the IP pool during the openvpn setup. The setup routine automatically generates a random IP pool, which you can change if you wish.

First Step Dynamic DNS

As mentioned above, the first step to accessing your home network via VPN is to set up a dynamic dns service.  I use duckdns, but there are others.  Some routers have built in dynamic dns support, so check your router's documentation.  You will need your FQDN (Fully Qualified Domain Name) for setting up the server.  It will show up in the authentication certificates we are going to generate.

Setting up the server

In order to connect to your vpn, you must have a  VPN server setup inside your home LAN.  See the previous blogpost for more information on TurnKey Linux and virtual appliances.  Download the turnkey virtual openvpn appliance and open it in VirtualBox.  Go through the configuration.  Enter your FQDN from your dynamic DNS service when asked.  Use the randomly generated IP pool or use your own.  Set a static IP address for your server.  Do the updates, and reboot.

Setting up Timezone

While not 100% required, this step can save you a lot of headaches.  The reason this causes headaches is the next step which involves generating authentication certicates.  If you generate them with the default timezone, UTC, at say 5pm, then the certificates will be valid at 5pm local time.  this is because when the clients check the timestamp, they don't the timezone into account. The should, but they don't.  So if you skip this step, then your certs won't be valid for several hours.

From the commandline on your server, type in date and you will see that the timezone is set to UTC.  Use   dpkg-reconfigure tzdata to bring up a dialog which lets you chose the correct timezone.

Creating Keys

If you go to https://openvpnserverip it will bring a webpage that looks like the one shown below.  Click on the Quick reference tab and it will show you some common commands including the command to generate a client cert, which we are going to do now. Make a note of the command.


Now, go to the command line.   You can quickly do this by switching back to the control panel tab and clicking on the WebShell Icon.  Use the command openvpn-addclient client-name client-email.  Give the client a unique name.  For example Sam-iphone.  Then replace client e-mail with an e-mail address to associate with the cert.  Hit enter and it will generate the appropriate certs.  If it asks you about signing and commiting, say yes.   The necessary files will show up in /etc/openvpn/easy-rsa/keys  It will also create a file named client-name.ovpn  This .ovpn file is what you need to then copy onto each client.  It contains all the information necessary for the client to connect to the server.  Guard this file carefully.  Anyone who has access to this file, has access to your VPN and through that to your entire network.  Be warned.  Repeat this process to generate one key for each client.  You can repeat this process and add more at any time in the future.

Installing clients

Now you must go install the openvpn client software on each client.  In my case, I had a Windows 10 laptop and an iphone. For the iphone, go to the app store and for Windows 10 you can just download the client from the openvpn website.

Moving Keys to clients

So we need to be careful with the keys (ie. the .ovpn files).  I used winscp to transfer the files from the server to my laptop.  From there I moved the .ovpn file for my laptop to the C:\Program Files\OpenVPN\config\ directory.  For my iphone I used iTunes to transfer the file.  Another option is to use the command line and generate a website with a QR code link.  Type the server's ip into your internet browser and then click on the quick reference tab for details.  This command provides the html link.  Open that in a browser and then use a QR scanner on your iphone.  The QR code will provide the download link.  However it uses the FQDN, and we haven't set up port forwarding yet.  So if your iphone is on your LAN, just change out the FQDN for the local IP addres and it should work.  Once it downloads, it should automatically open in the openvpn app.

Port Forwarding

We are getting closer, but not quite done yet.  In order to access our VPN server to setup our VPN from outside our LAN, we need to set up port forwarding.  Again, go to and look up directions for your specific router.  We need to forward 1194 to the local IP address for your OpenVPN server.

Adding access to other computers on your home LAN

Right now, you could connect to your VPN.  Everything is set up to connect your laptop or remote device to the openvpn server running inside your local LAN.  However, you will not be able to access any other computers inside your LAN yet. There are 2 more steps to enable that.  Right now you have 2 seperate networks.  You have the VPN network and the LAN network.  You need to enable them to talk to each other.

On the openvpn server, pull up the command line. Use nano to edit the /etc/openvpn/server.conf file.  Add a line at the bottom push "route" .  Where is your local network.  For example if your local IP pool was 10.5.4.x, then you would put  It should always end in 0.  This makes your VPN client (your remote laptop) aware that the LAN pool of IP addresses exist.  Save the file and the restart the openvpn server using /etc/init.d/openvpn restart.

That will get message from your remote machine to your LAN.  But now you need to configure your router to return messages.  This will depend on your router.  You basically want to direct any traffic to the VPN subnet to the VPN server (but using its gateway address on the VPN) Sorry I can't be of more help, but if you've made it this far you can probably figure it out with a little help from google. 


All that's left now is testing.  If you did everything correctly, it should all work.  You should be able to use the client to connect to the VPN and you should be able to access all your LAN devices using their local IP address.  The clients usually give pretty good diagnostic information.  You can add a line to the server.conf file on the server to create a logfile there.  Add log pathtologfile .  Make sure to create the file first using touch and then restart the openvpn server using init.d

Development Server Setup

Software Developers often use a development server which runs version control and bug tracking software. Version control systems, such as Subversion, keep copies of each iteration of the source code. This allows developers to roll back changes if need be to fix bugs or broken code. Bug tracking software, such as Bugzilla, allows developers to input bugs and feature requests. Then these tasks are assigned to specific developers and the progress can be tracked. The Development Server acts like a central toolbox that the developers and project managers have access to.  If you are developing code and you are not using version control or bugtracking software, you should be.  As you'll see in the post there is a free and easy way to setup a development server to provide these services.


For several years I did software development work for a large company. One nice thing about working in such a large company is that the company set up and maintained a Subversion (SVN) server and a Bugzilla server, which I was able to use and I didn't really have to worry too much about setting up or maintaining the servers.

So when I started my own company, one of my first tasks was to build a development server of my own. This was a little outside my realm of expertise. By formal education I am an electrical engineer. By on the job training I became an expert in LabVIEW, but I was not (at least at the beginning of this project) very knowledgeable about servers and how to set them up. Now, I needed a development server that would meet my needs but be easy for me to setup and maintain.


The goal of this post is to highlight the solution that I used for my development server. It took me a little while to find a good solution and fine-tune it for my needs. I want to document that solution so that perhaps others can benefit. I will only be hitting the highlights. While this is not necessarily a step-by-step guide, if you are technically inclined and know how to use google, it should be pretty easy to repeat to get your own development server up and running. If you are already familiar with linux and apache web server, you could probably do it in an afternoon. If not, plan for a few days.


My key requirements for a development server were that it needed to

  • Be cheap – In the case of my final solution I found a free solution.
  • Be easy to setup – I didn't want to spend too much time learning linux commands and doing tons of setup and configuration.
  • Include both version control and bug tracking – My final solution includes both SVN and Redmine
  • Not require special hardware – I was able to run my solution on an old MacBook I had laying around.
  • Be reasonably secure – My solution uses https to encode network traffic.

TurnKey Linux

While doing some research I stumbled upon TurnKey Linux . They offer a variety of standalone servers, which they call appliances. Each of these appliances is basically a very lightweight linux server (based off of Debian linux) with either a single program or suite of programs designed to work together, already installed and preconfigured. All of the software is open-source, so it is free. It promised to provide a free ready to use development server right out of the box, which really appealed to me.

TurnKey offers a whole variety of appliances. There are several issue tracking and version control offerings. For my development server, I chose to use an appliance that included both Redmine, for bug tracking, and SVN, for version control. Both are free. And they can be integrated together, such that specific changes in the source code can be tied to a specific bug or feature request.


TurnKey has several options for how to deploy their appliances. The option I chose was to download a virtual machine image and run that using VirtualBox .  This would let me use an old MacBook I had laying around as my Development Server. Other options include: running it on bare metal, or running it on a cloud server, such as those offered by Amazon. VirtualBox is free to download and runs on most OS. The appliance itself doesn't require a lot of RAM or processor speed since it is a very lightweight linux distribution.  It should run on just about any old computer you have laying around.

Getting started

In my case, the first step to setting up my development server, was to download and install a copy of Virtual Box from their website. Then I downloaded the Virtual Machine Image from TurnKey. Double clicking on the Virtual Machine image will load it in Virtual Box. Next, a dialog comes up asking about some settings for CPU cores, RAM, virtual harddrive size, etc. You can change them if you want, but the defaults worked fine for me.

Initial setup

Once the virtual machine is loaded in virtualbox, you can just double click to run it. Soon the OS will load. Then you will be prompted to set some passwords for the root account, redmine admin, MySQL access, etc. Use strong passwords and write them down somewhere for now. Next it asks about TKLBAM which is an automatic backup service to Amazon cloud. Use it if you want. You can also configure it later. Then it will ask about applying updates. I suggest you do so you have the latest security patches. After that, it may reboot. When all is said and done, your development server is now up and running. You should end up with a screen like the following:


Web shell and Webmin

Once you get to the above screen, you can select quit and get to a Linux prompt. However you can just minimize the Virtualbox window and move to a web browser. Before moving on, make sure to write down the IP address and ports shown. Now, you can do the rest of the setup for your development server over the network. TurnKey comes with 2 powerful tools for network configuration built in, Web Shell and Webmin (and it also comes with ssh if you wish to use it). Web Shell gives you a shell interface through a web browser, and Webmin provides a GUI interface through a web-browser. Both are very powerful and very useful.


The first thing I would suggest is simply typing the local IP address of your development server into a webbrowser using https. You will get an SSL cert error, because the cert is self-signed. For now just add it as an exception. You can fix that later if you want to. The browser should come up with a redmine window similar to below. The next thing is to login to the webmin accounts and webshell accounts just to make sure they work and to see what is there. You should see something similar to below.

RedmineWebmin InterfaceWeb Shell

Setting up svn for http access

If you look at the svn documentation there are several ways to access the repository. This appliance comes with svn configured for svn:// protocol access. If you want to simply use that, you can skip the next couple sections. I prefer https access. It's secure and https goes through most firewalls. Turnkey does not come with a webmin module installed for svn, so you'll have to configure that using the Web Shell or ssh. To begin setting up svn web access plug the Web Shell address of your development server into a webbrowser and login as root.

Apache Basics

Turnkey already has apache and the apache svn modules installed, so you just have to do a few things to get http (and https) access set up. I suggest you look at the SVN documentation and the Apache webserver documentation. Particularly pay attention to the location of the apache config files on Debian (TurnKey is based on the Debian flavor of linux). The config file locations are different and if you follow the normal instructions you find on the web, it will mess you up.

Apache Setup

The first thing is to use nano to edit /etc/apache2/mods-available/dav_svn.conf All of the entries you need are already there, they are just commented out. Uncomment them and you should be good. The file is well documented and it should be obvious which lines need to be uncommented. Next, make sure the paths are right. The repository is at /srv/repos/svn. Before moving on, note the location of the password file. Next, save dav_svn.conf. Then load the dav_svn module using "a2enmod dav_svn" and restart apache using "/etc/init.d/apache2 restart"

Setting up SVN passwords

This step depends on if you used the Require valid-user option in the dav_svn.conf file.  If so, now you need to use the htpasswd utility to create the password file pointed to in dav_svn.conf If you don't know how to use that utility, just google it. It's pretty straightforward.


Next, you need to change the permission and ownership of the /srv/repos/svn directory and subdirectories to the user running apache. In the case of Debian, this is www-data. First use "chown -R www-data:www-data /srv/repos/svn" to change the ownership. Then use "chmod -R 755 /srv/repos/svn" to change the permissions.  The -R is for recursive.


One nice thing about this configuration of turnkey is that ssl will automatically work with svn once it is configured as above. To force ssl, I went into /etc/apache2/sites-available/redmine.conf and added a location directive with SSLRequireSSL. <Location /> SSLRequireSSL </Location> This requires using https instead of http to access redmine and svn.  In order for it to take effect you have to force appache to reload the config files using "/etc/init.d/apache2 force-reload".   Now, if you use http, you will get a forbidden error.

Testing and Troubleshooting

Now, to test everything, go to a web browser and type in "https://serverip/svn/helloworld" Conveniently Helloworld is a preloaded svn repository. Once you enter your username and password, you should be able to browse it. If not, check the apache log files located at /var/log/apache2. I ran into a few problems and the logs (and google) were very helpful.

The last test is to connect to the development server from the machine where you write your code. Use your favorite svn client (I like tortoisesvn), or the command line client to check out the helloworld repository. Make sure you can edit files and check them back in.

Next Steps

The next step is to create a new SVN repository. If you don't know how to do this, just google it. Be careful with permissions, you may have to reset them after you create it. Then add a new project in Redmine and you are ready to go. The best part is that SVN, Redmine, Apache webserver, and the Linux shell are all well documented on the web. Soon you should have you development server up and running.