Tuesday, February 20, 2018

Taking Control of Instruments With LabVIEW

If you have ever thought "Man, I am so sick of pushing these buttons on this instrument I could punch someone!", or your instrument is strategically placed on the opposite side of the lab from your computer, then you are in luck. The everyday mundane tasks of using instrumentation for your projects is inevitable. Sometimes it requires pushing buttons every hour or so, and sometimes it requires pushing those buttons 30+ times a minute. In short, doing this for days on end can lead to mental breakdown. Science proves it.

A very common and complex instrument to deal with is a spectrum analyzer.

These instruments are packed with so many modes, buttons, and screens that it is hard to keep track of where you are, and what you are actually trying to measure. What is even worse is having to take the same measurement over and over again on different frequencies, which requires even more button pushing! I dare say you spend 85% of the measurement time setting up the instrument, connecting cables, and fumbling around the menus, and 15% of the measurement time actually taking your data measurement. There is a ton of lost time in doing this, and even more dangerous is the pent up anger that builds.

This is where LabVIEW can help. LabVIEW Drivers can be created to control this instrument. And if you are lucky, there might already be LabVIEW drivers someone else created out there that you can utilize. But the big question is, where do you start? The very first place I look for these LabVIEW drivers when I get a new instrument handed to me is www.ni.com/idnet. This site has a wide variety of LabVIEW instrument drivers available to download for free. In a perfect world, every instrument you look for will already have LabVIEW drivers already created. But chances are you will have an instrument that you cannot find any LabVIEW drivers. Let us know, and we can write you some LabVIEW drivers! We have done this for several instruments already. Just for the sake of this blog post, I went and found the LabVIEW drivers for a Keysight N9030B spectrum analyzer. I downloaded the project and have over 350 already made LabVIEW driver commands for the spectrum analyzer.

So LabVIEW driver development is already done, check that one off the list. Now that I have the LabVIEW drivers, what do I do with them? You can simply create a VI by placing the LabVIEW driver calls, and wire them together. Here is an example of how to use the LabVIEW driver calls.

Here is a simple VI I created to control the spectrum analyzer. Here is the order of the LabVIEW driver calls: Initialize, set to Swept SA, set center frequency and span, set a marker, do a peak search, change mode to Channel Power, take a channel power measurement, and finally close the communication. In the amount of time that you read that, I could have probably run this VI four different times. No joke. Now imagine how much you could accomplish in a day by making a simple VI like this one! Now imagine if you made more and more of these VIs, incorporated switching, and made a graphical user interface. You could have yourself an automated test, without ever having to push buttons, connect/disconnect cables, fumble through menus. Life would be great, wouldn't it?! This is the power of LabVIEW and controlling your instruments.

Don't have time to do all of that, or completely feel overwhelmed? Let us know! We can help by making the automated test for you! This is where Endigit excels.

I'm sure there are still a lot of questions about controlling instruments, and we are going to have this be a series of instrument control posts. We will dive deeper in some of these subjects.  Comment below if you have any requests for blog posts about instrument control, or anything else, for that matter, that you want to read a blog about!

Tuesday, January 23, 2018

Welcome Brian and Jon to Endigit!

Endigit is happy to announce the hiring of two new employees, Brian Denkers and Jon Terry.

Brian Denkers is a Certified LabVIEW Architect and Certified TestStand Architect.  He is joining as a Systems Engineer most recently employed at L-3 Technologies in Salt Lake City.

Jon Terry joins as a Systems Engineer Intern.  He is finishing up a masters degree in mechanical engineering at Brigham Young University.  

Also, Jake Hansen has transitioned from intern to former intern as Associate Systems Engineer.

Endigit is still growing so let us know if you are interested in joining us!

Sorry no cheesy banner in this picture.

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 ni.com/self-based-training. 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, https://community.atlassian.com/t5/Questions/SourceTree-external-diff-path-issue-on-Windows/qaq-p/394740)

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/_LVCompareWrapper.sh

And for arguments:

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

For the merge command, use:

C:/Users/User Name/AppData/Local/Programs/GIT/bin/_LVMergeWrapper.sh

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!