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

Parallelism:
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!