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!

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


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.

Tuesday, August 29, 2017

The Evolution of a LabVIEW Developer

I made and gave this presentation for the Utah LabVIEW Developer Education Day.  Let me know what you think or if you have any questions.

Friday, August 18, 2017

Dining Philosophers in LabVIEW

History
As I program in LabVIEW I am surprised by the number of times small bits of code cause large problems.  For example, I was working with a large system that communicated with many instruments.  I made some changes, tried running the code, and the program locked up! My gut reaction was to blame the LabVIEW development environment or a driver, but in the end I discovered the code I changed caused the hang.

Dining Philosophers
I did finally find what was causing the hang, but it took a long time.  The hang was caused by two resources that were used by two different pieces of code (see the Wikipedia’s Dining Philosopher article for a good explanation of this).  Both pieces of code had one of the resources, but neither would relinquish the resource because they were waiting for the second resource.
This can be shown in LabVIEW with the following code:

So Don't do That
The above example is simple enough to be trivially avoided.  However, it can get more subtle.  Consider a non-Reentrant SubVI; a second caller to the subVI will block until the subVI finishes on the first caller.  This allows the same hang to occur with a subVI and a queue as shown below.  Note that there is a second queue shown which is not causing the hang, but is needed for the subVI to be called twice: 


Still Want to Use References?
The code I had written was fixed easily.   The code had started before Data Value References (DVRs) existed in LabVIEW, so it used a Queue with a single element as a referenced resource.  I made a change to the data dependency so that the Dequeue would happen later and not block the other code from executing.   The experience did make me a little more cautious, and I’m on a quest to find out how to avoid these mistakes in the future.  Here’s what I’ve got so far:
·         Use a message-based architecture to avoid sharing resources:  I know many are successful with message-based architectures like the actor framework.  I cringe at doing this myself.  It works, but it is trading one set of problems for another.
·         Use the “In Place Element Structure” instead of Queues for references.  The In Place Element Structure groups the data value read in the same structure as the data value write.  This means that the read won’t happen until all the inputs to the structure are ready.  The Dequeue function in the example above happens before all the inputs are ready for the Enqueue function, and that allows the hang to occur.
·         Consider setting VI executions to reentrant.  When creating a new VI, the default is non-reentrant.  If a VI is non-reentrant, it is a resource that must be shared and it may block.
·          Be especially wary of code that must wait for multiple resources to be available.  For such code, see the “Dining Philosophers” link for ways to address the lockup issue.

The Good News
References are an intuitive way to program, and they are used frequently in LabVIEW.  Consider all the references in LabVIEW:
  • ·         Synchronization VIs: DVRs, Queues, Notifiers, etc.
  • ·         VI Server: VI References, Control References, etc.
  • ·         Driver APIs: DAQ Tasks, VISA Resources, FPGA References, etc.
  • ·         Computer Resources: File References, TCP Refnum, etc.
  • ·         Many, many others
You will use many references as you program in LabVIEW.  You may even start to use references in your APIs as I do.  If you have advice or a story about references locking up code, I’d love to hear it!  



Friday, August 11, 2017

Vote for Best Face on endigit.com

Endigit is having a competition on who has the best fun face on our website.  Go to the About page on our website and mouse over the pictures.  Then come back here and comment on the face you like the most.  Whoever gets the most votes gets a $50 Amazon gift card!

While you are on the website, you might as well look around and go to the Contact Endigit page and tell us how we can help you.

Monday, July 31, 2017

Even More Life Changing Mouse Buttons

I recently wrote a post on how to change your life by changing a mouse button.  My life has been vastly improved since I added a delete button to my mouse.  My hair is growing thicker and fuller, my eyesight has improved, my lawn is greener, and I can delete things so much faster than before.  My life has been great, but I still felt like something was missing.

Easy access Delete
As a refresher, we at Endigit all use the Logitech M570 wireless trackball mouse.  With that mouse you can change the button settings.  I have assigned the forward button to be the delete button.  I rarely used the Forward button and often need to delete things.  This saves me from moving my hand from the mouse to the keyboard to hit the delete key.  Notice that I have the Back button still set as the Back task.  I use this often when navigating Windows Explorer and on the Interwebs.


Introducing: Quicker Quick Drop
I don't use the back button ever in LabVIEW though.  That makes that button worthless to me when developing software in LabVIEW.  I thought about it and talked about it with the other Endigiters and we thought it would be great to add ctrl-space for even quicker quick drop.  Now instead of wasting so much energy moving my pinkie finger all the way down the the control button and pushing space, I can gently press a mouse button and have quick drop open.  Take that Carpal Tunnel!



But wait there's more!
The middle mouse button is really useful for opening links in new tabs online, or opening a new instance of applications, but again, worthless to me in LabVIEW.  Another common task is cleaning up wires.  Clean Up Wire is normally the top option when you right-click on a wire so it is quick and easy.  However, I have modified my right-click menu so that Create Constant, Control, and Indicator are at the top.  (That is another great time saver.)  So I had to right-click and choose the 4th option down.

That is just too much work for me.  I started selecting the wire and then hitting ctrl-u to clean it up.  That was nice, except the U button is way on the right side of the keyboard.  I have to move my pinkie down to the Control button and then stretch way out to get the U key with my index finger.  That is exhausting!  Why not map the middle mouse button to ctrl-u to save me so much energy?  Unfortunately, the middle button cannot be configured for application specific behavior.  Luckily, AutoHotkey.com came to the rescue!  With AutoHotkey you can set specific keys to run scripts.  I have an AutoHotkey script that looks at the middle mouse button.  When it is pressed it checks if I am using LabVIEW.  If I am then it clicks and sends ctrl-u.  If I am not using LabVIEW it sends the normal middle click.  BOOM!  Now I have block diagram clean-up, and wire clean up with a quick easy push of the button.



What is next?
I have been thinking of other things that I can do to maximize my mouse and keyboard.  I think the next thing I am going to figure out is using the mouse buttons to copy and paste.  I am going to see if I can have ctrl modifier to have the Forward and Back buttons be copy and paste.

What ideas for mouse shortcuts do you want?
Comment your ideas on what you would like to have simplified with your mouse.  I would love to hear some new ideas.

Edit 8/10/2017:
Toggle between Front Panel and Block Diagram
I added so that when I press both the left and right mouse buttons at the same time it sends Ctrl-E to toggle between front panel and block diagram.



Monday, July 17, 2017

LabVIEW Queue for Loop Control; Elegant Hack or Abuse of the System?

After 10 years of LabVIEW development, I like to think of myself as fairly experienced. I’ve acquainted myself with a number of design patterns. When I encountered this, I assumed I was dealing with an event-based producer-consumer pattern.

Do you spot what’s wrong with this picture? Technically nothing, but it took me a minute to figure out what was really going on with that queue. That’s right, it’s not really a queue. It’s an elegant hack to control timing and shutdown of those parallel loops. My first reaction was, “this is wrong,” but the best I could do to justify that judgement was that this isn’t what queues are supposed to do. Problem 1: Readability. I didn’t understand what was going on as quickly as I would have with a more conventional use of a queue.
Weeks later, I was troubleshooting a problem with a similar implementation. Do you spot the problem here?

Kudos if you caught that the bottom “Status Loop” was gobbling up data intended for the Action loop. Someone took the pattern for timing and shutting down parallel loops and leveraged it to also carry data. Problem 2: Protection. There isn’t a guarantee that someone won’t mess with your queue.
Problem 3: When using this pattern, you must be sure to wire in a timeout value. Otherwise, your loop’s not gonna loop.
In the interest of continuous improvement, I thought we could add an improved version to our arsenal. One that solves all the problems. We call it Exitimer, and it’s just a class wrapped around the queue implementation.

Solution 1: With a little VI documentation, other developers understand what Exitimer’s being used for. It’s a timing and shutdown mechanism. They don’t even have to think about queues.
Solution 2: Because access scope to the queue is limited, nobody can try to misuse it to carry data.

Solution 3: Because the timing input is required and negative numbers are handled, there isn’t a risk of an infinite timeout.

Download the code from our website.  What do you think? Is this a pattern you've seen before? Elegant hack, or abuse of the system?

Friday, June 30, 2017

The Secret Combination to Unlocking AutomationDirect Stepper Motors in LabVIEW

I was working on a radiation leakage test system trying to control a STP-DRV-4850 motor designed to spin an array of D-tect sensors around a unit under test.  I was able to spin the motor using AutomationDirect's utility program, SureStep Pro and everything was looking good, until I tried to send the motor controller serial commands from LabVIEW.

After beating my head against the wall for the greater part of an hour, I finally turned to the Internets for wisdom.  I had exhausted all the usual serial communication suspects:

Read the manual?  Check.
COM port?  Check.
Baud rate?  Check, 9600.
Command format?  Check, working in SureStep Pro.
Reread the manual?  Check.
Termination on writes?  Check, carriage return.

No matter what I tried, I could not get this motor to turn.  I had talked with countless instruments over serial and considered myself an expert.  And now my customer was looking over my shoulder, expecting to see magic.

The first few Google hits covered the usual issues (see above) and I began to despair.  After resorting to the second page of hits (who goes there?) I hit gold with an obscure post on the NI forums from 2011.  Apparently lmtis (Jim) had run into the same problem and went to the effort of hooking up a USB bus monitor.

When AutomationDirect's utility, SureStep Pro, connects serially to motors, it first sends an "HR" command.  I quickly tried it, and sure enough, everything started working.

I'm still not sure what "HR" stands for, but it is the "open sesame" of the STP-DRV world.  And after six years it still hasn't made it into the manual (SCL Commands for STP-DRV-4850 and STP-DRV-80100 Step Motor Drives).


Friday, June 2, 2017

2017 World's Fastest LabVIEW Programmer - Endigit 1st and 2nd Places!

Last week at NIWeek, National Instruments held the World's Fastest LabVIEW Programmer competition.  With Robert Mortensen being the 2016 champion, Endigit was hoping to make an impact again this year.

In the first round of competition, competitors complete three programming challenges in as little time as possible.  The competition open to anyone attending NIWeek and runs in the LabVIEW zone on the Expo floor.  

Bryan Heslop from Endigit was the winner of the floor competition.  With the fastest time on the floor, Bryan went against Sung Jin KIM from South Korea.  Sung Jin won the event at NIDays in China and is Asia's Fastest LabVIEW Programmer.

In the final rounds both competitors are given programming challenges and race to complete them.  The first to win 2 challenges wins and advances.  Bryan and Sung Jin went head to head in the semifinals.  There was some fast programming and Bryan came out on top winning 2-1.


The finals featured two Endigit employees, Robert Mortensen and Bryan Heslop!  In an attempt to intimidate, Robert reminded Bryan that he had taken second place more times than Bryan had been to NIWeek, and was the reigning champion.  In awe of Robert's superiority, Bryan felt extreme nervousness because it was only his first time competing.


Robert used his programming wizardry to defeat Bryan 2-1 and retain his title as World's Fastest LabVIEW Programmer.

Congratulations to Robert and Bryan from Endigit and Sung Jin from South Korea for being the fastest LabVIEW programmers in the world!

Endigit is happy to help you with your LabVIEW programming needs.  Contact us for help with your projects.

Friday, March 31, 2017

Fisnar Glue Application Robot.

We recently had a customer come to us with a request to program a Fisnar I&J7100 robot.  We did not have any experience with this robot, but told them that if they couldn't find someone to help then we could learn it.  Endigit's best feature is our ability to learn and solve new challenges.  Bryan had experience with programming and running CNC machines so he volunteered to take this on.
Here is the resulting robot in action.


We were able to save the customer time and money by taking this project on.  They were able to stay focused on their core competency by having us take care of this for them.  Let us know if there is anything your business needs.  We are great learners and problem solvers.

Tuesday, March 14, 2017

Change a Mouse Button, Change Your Life

I like being efficient. I don't like doing unnecessary things.  I figure out the fastest route to drive everywhere I go.  I even tie my shoes differently to save myself two seconds.  If you have talked to me in person then it is very likely you have heard me go on about minimizing my wallet.  I don't like wasting time or energy.  At Endigit, we are proud of our efficiency and ability to complete things quickly. One way we do this is by being effective in our key strokes and mouse clicks.

One trick that will save you a lot of time in the long run is to map the delete key to an accessory button on your mouse.  With a delete button mapped, you no longer need to move your hand from the mouse (or move your left hand over) to press the delete key on the keyboard.  You can simply select it with the mouse and hit the newly mapped delete button.  Each click saves me around 1 second.  While one second by itself is not much, imagine if you are deleting 60 things a day.  You just bought back one minute of your life that would have been sucked away!  Count Rugen would be furious!

Everyone at Endigit uses the Logitech M570 trackball mouse.  Logitech has instructions for customizing the buttons for their products.



Effective use of movement and time are part of what helps Endigit provide faster software development.  It is part of how Robert won the World's Fastest LabVIEW Programmer at NIWeek 2016!  I think mapping the delete button is the only thing Robert changed to advance from taking 2nd place for several years in a row.  Now instead of not being a winner, Robert is a champion.  Imagine what a faster delete key can do for you.



What are your favorite time saving tips and tricks?

Monday, March 6, 2017

Welcome to the new Endigit.com!

We are making some big changes at Endigit.com!  The new web page is designed to make finding useful information easier.  It also highlights our capabilities more to show what Endigit is capable of.

Endigit is a premier LabVIEW development company.  We do LabVIEW integration work for customers across many industries.

With the update to the website it will be easier for Endigit to share with you what we are working on and share cool things that may be helpful to you.  Be sure to subscribe to the blog for the latest updates.