Monday, November 27, 2017

Learning a new Language: LabVIEW

Every once in a while we have the opportunity to learn a programming language. With each new language comes the challenges of learning new "vocabulary" as well as the various things that make each language unique. As with any new language, habits from our "native" language carry over. For example as someone who learned to program in Java and C++, leaving types off variables is still hard in Python!

LabVIEW, unlike most programming languages is a visual language, much like drawing a circuit diagram. Each component is wired to the next, but instead of electricity you pass data. While at large this is very intuitive, LabVIEW has a few of its own quirks.

Clusters are one of the unique quirks in LabVIEW. The need for them stems from the pass by value nature of LabVIEW. Imagine if you needed a wire for every small piece of data that you were going to use in your program! Clusters are a way to bundle this data all onto a single wire, greatly simplifying the visual complexity of your code. However, this often comes at the cost of readability because in general the user can't easily see what a cluster contains. As a newcomer, sometimes a cluster feels like a cheap way to avoid using classes and class private data. 

One thing that still blows my mind as a new LabVIEW developer is how easy it is to implement parallel code. In text based languages parallel code can be a pain to write and debug. In LabVIEW it is as simple as dropping two separate pieces of code in the same vi. No allocating of threads or trying to figure out where to place a barrier/mutex etc... LabVIEW does most of this behind the scenes, just drop two loops (or two of anything) wire them to what you need an let the compiler take care of the rest!

Tab Completion → QuickDrop 
Most IDEs for text-based languages supply the user with some form of tab completion to speed up development times. Some IDEs go as far as providing a list of suitable choices for the user to select. Since LabVIEW isn't a text-based language, traditional tab completion doesn't really have a place in LabVIEW. In my eyes, QuickDrop is essentially LabVIEW's tab completion. It lets the user preform a text search all of the available functions/components and drop those components into their block diagram. One of the features that I like about QuickDrop is the ability to write your own plugin that, instead of dropping in new code, modifies the existing code you have already placed.

Because of LabVIEW's visual nature I personally feel like code written by other developers is easier to digest and understand than most text based languages. LabVIEW also interacts seamlessly with countless pieces of hardware, which is something that you can't say about most other languages. These are just a few reasons why LabVIEW is a great language to have in your arsenal. National Instruments has great tools to learn LabVIEW that can be found at The Core modules (Core 1 and Core 2) are interactive and provide a great overview of LabVIEW especially to someone who has some prior experience with other programming languages. Upon completion make sure you schedule and take the CLAD and become a certified LabVIEW associate developer!

Friday, November 17, 2017

How I Saved My Client over $200k with 15 Minutes of LabVIEW Code

"Sorting this material by hand will take two guys about six months and cost us around $60,000," said my client.

Someone on the production line had installed the wrong component leading to one dimension being off enough to be unusable, and 3 million parts had gone through before they realized the problem.  Even though only 1 in 22 parts were bad, the whole batch was tainted and headed for scrap unless the good parts could be sorted and verified.   At 7 cents per part, that added up to around $200k.

"So we want you to modify your image analysis code to measure for this defect and see if there is enough separation to accurately reject the bad parts," he continued.

Luckily the images we were already taking were the right angle and the analysis code similar in nature to what we needed.  Five minutes of coding later, I was ready to try it out, thanks to modular code and a good architecture.  Below are the results.  Above the black line are good parts, below are the bad.

Five more minutes of code had the bad parts being kicked out of the system.  They ran the system overnight and made it through 400,000 parts during that shift.  Spot testing showed no bad parts passing and very few false rejects.

"This works so well, we want you to roll it out to the other production lines permanently so we can pick up this same common problem before parts get through next time," he said the next day.

Another five minutes of code, and I started installing the update on the first new line.  Except the change wasn't working as well on this line.  One of the 22 stations was showing a measurement way out of spec from the others.  Then realization hit.

"Um, it looks like one of the stations on this line has the same problem," I quickly informed the line manager.

They shut it down, and sure enough, same wrong component.  Luckily the rest of the lines were problem free.

"You just saved us a ton of money," my client gratefully commented.  "And two guys a very boring six months," I replied.

Would you like Endigit to help your company save tons of money through better efficiency and product quality?  Contact us for a free consultation.

Monday, November 13, 2017

Using LabVIEW's diff tool with SourceTree

Our team is using BitBucket for source code control and the SourceTree app for Windows to interface with our repositories. We've had a couple of small hurdles getting SourceTree to integrate with the LabVIEW diff tool, but here's a solution that's worked for us. (Credit to Paul Lotz on Atlassian's forum,

First, download these scripts and place them in a local folder:

For this example, I'm assuming you'll put them in the folder:

C:\Users\User Name\AppData\Local\Programs\GIT\bin\

Next, open the options for SourceTree, and go to Tools > Options:

For the diff command, change from "System Default" to custom and enter:

C:/Users/User Name/AppData/Local/Programs/GIT/bin/

And for arguments:

\"$REMOTE\" \"$LOCAL\"

For the merge command, use:

C:/Users/User Name/AppData/Local/Programs/GIT/bin/

And for arguments:

\"$REMOTE\" \"$LOCAL\"

If you'd like for us to help get your LabVIEW team set up with SourceTree, please let us know by contacting us.

Tuesday, November 7, 2017

Welcome Blake to Endigit!

Endigit is excited to announce that Blake Ewton has joined us as an Associate Systems Engineer.  Blake has been employed at Hill Air Force Base doing LabVIEW programming for automated test equipment.  Blake will be an excellent addition to our team in meeting your expectations of world class LabVIEW development for automated test and data acquisition systems.

We got to recycle most of our fancy sign from welcoming Jake!

Friday, October 6, 2017

How Good Communication Makes an Awesome Product

Here is a quick story about some software that became awesome due in a large part to good communication. Our client, AccuPower Solutions, records HD video at 120 frames per second from multiple cameras and force data from a force plate while people jump on it. The data can then be used to draw force arrows on the video and  help coaches characterize athletic performance. AccuPower can take the forces and determine velocities and power at different parts of the jump, compare left and right leg forces and velocities to see where athletes might be compensating for injuries, and measure fatigue over time as athletes make repeated jumps. It has been used in places like the NHL Combine to measure Athletes jumping abilities. There are also plenty of physical therapy applications. And to be honest, there is something just magical when you stand on the force plate as you look at the live video image that includes the force arrows and data and watch how things shift as you move around. Don’t tell the AccuPower guys this, but while I had the force plates set up at my house during development my kids were jumping on them all the time! “Dad, can we do the cool jumping thing again with the arrows?”
The project was super fun. However, I want to tell you about how our communication with AccuPower really made the project work. The ideas here loosely follow the ideas of Agile Software Development, which lean heavily on repeated formal scheduled meetings with clients, but in a less formal way.

To start, we put our feature list into a Google spreadsheet. The list contained the following information for each feature/task/issue:
  1. Status
    1. In this column we had the following options: Do Now/Do Soon/Test/Waiting/Future/Done.
    2. The features were colored and sorted based upon the status.
  2. Owner
    1. Which Endigit employee was assigned the feature, but also, which employee of our client was tasked with testing and reviewing the feature.
  3. Title
    1. Something short and descriptive to remind us what the task is.
  4. Description/Summary
    1. A detailed description of the feature or task or bug.
  5. Notes/Waiting on
    1. What needs to happen next
  6. Hourly Estimate
    1. While a chunk of this project was fixed bid, the majority was hourly and this column gave the client a good idea of how long a given task would take. As the client added new features or changed things around, this column gave us a location to let them know how the changes would affect the budget and schedule.
As features were implemented, we would do a new build, drop the new build in our client’s Dropbox folder and they would check out the new feature. At times, this iterative process happened as often as 4-5 times a day.

Our development often looked like this: “Hey Pete, I just uploaded another build, check it out when you’ve got a moment” and when Pete had a moment he would check out the features list to see what had changed, run the exe and respond with “Excellent! I like how that turned out and it works great!” or “Um… that is not what I had pictured, let’s grab the team and do a quick conference call to get everybody on the same page”. This method of communication worked extremely well in this situation but only because of our relationship with the client and our client’s history in working with software developers. There is certainly something to be said about only delivering code that has been highly tested and functioning perfectly. However, for this client, getting stuff working quickly was key and they had no qualms about doing some of the testing for us while we got started on the next feature.

Communication is key. It can make or break a software project. For this project, where the client was able and open to having almost daily communication, surprises were kept to a minimum and the software lives up to its truly awesome potential!

Wednesday, October 4, 2017

Welcome Jake to Endigit!

Endigit is happy to introduce Jake Hansen as an Intern Systems Engineer.  Jake studied applied physics at BYU.  We are excited to work with him!  We made a banner and had a little party to celebrate our continued growth.

Friday, September 8, 2017

Hourly or Fixed Bid?

At Endigit, our services come in two flavors: hourly and fixed bid. Many factors contribute to deciding which flavor to choose.  This article is designed to discuss the benefits of each option in order to help decide which will work best for you.


Hourly work is set up such that Endigit charges a fixed hourly rate for whatever time is spent working for you.  The reins are entirely in your hands.  You can specify how much or how little work to do at a time, when to check in, and when to stop.  For larger projects, we can provide an estimate on how many hours it will take and keep you up to date on whether we are on track to meet that target.

We generally invoice on a monthly basis, but can adapt to whatever schedule or amounts you need.  We'll often have clients set up a PO for a certain number of hours, say 100, then we'll work on whatever they need our help on, at their direction, until those hours run out.  Other clients need to keep each invoice under a certain amount.

Our hourly rates vary based on experience and expertise.  An engineer with a higher rate should ideally be able to complete a project faster than an engineer with a lower rate, with the overall cost coming out about the same.  However, certain types of projects, such as embedded work using LabVIEW RT and FPGA, require higher end programming.

Hourly work is best when requirements are not very well defined, or when we are functioning as consultants, working alongside internal engineers to complete a project together.

Benefits of Hourly Work
  • Doesn’t require up front specifications
  • Endigit can help design what you need
  • Supplemental to existing engineers and project managers
  • Easy to control when and where efforts are applied

Fixed Bid

Fixed bid work is more like a contract between you and Endigit.  You define exactly what you want and Endigit provides an exact cost.  You pay Endigit that exact amount, on whatever schedule is set up (half up front/half on completion, according to milestones, etc.)  If it takes Endigit longer or costs more for us to meet those requirements, you don't pay any extra.

Fixed bid work lends itself well to projects that are clearly defined.  Because of this, you know exactly how much the finished product will cost and Endigit has a clear idea of when we are done.  Fixed bids often include hardware and installation costs in addition to software development.  Fixed bids make planning and budgeting much easier on you, but require that you fully specify what you want.  

What happens if, during the development process, you find additional features or added scope you want done?  No problem.  We can either add those items to a list of features to implement as hourly work after the fixed bid, or we can increase the fixed bid amount to account for them.  

Fixed bids also work well when comparing contractors.  Once the project is fully specified, you can have multiple companies bid on the work, potentially lowering your cost for getting the work done.

Benefits of Fixed Bid Work
  • Can budget entire project up front
  • Great when you have solid specifications
  • Easy to compare multiple bidders
  • Often lower cost in the end

Combining Hourly and Fixed Bid

It is often the case that clients need help defining requirements.  Endigit takes a two step approach to this situation: we help you write the specifications for the project on an hourly basis, then provide a fixed bid for completing those requirements.

Other clients begin with a fixed bid on their first project or phase of a project with Endigit, allowing them to gage their comfort with how fast we can accomplish tasks.  Once they have a feel for the quality of work we can do in a timely manner, they switch to hourly work.

Which Do I Choose?

Another perspective on these two routes is through the lens of risk.  Who owns the risk?  Hourly work puts more risk on you that the project will take more hours than estimated.  Fixed bid work puts more risk on Endigit that the project will overrun the budget.

Hourly or fixed bid, jumping into a project with a new contractor is a risky endeavor.  Do your homework, get some references, and talk to other customers to find out how their experience has been.

Some projects and situations lend themselves to hourly work and some to fixed bid.  Either way, Endigit will provide efficient, quality work to help meet your needs.  We would be happy to discuss these issues with you and how they apply to your situation.  Feel free to contact us by phone or email, or through our contact page.