Are you excited about NIWeek? Here at VI Shots, we definitely are and to prepare you for what's to come. I assembled 3 session speakers for you to talk about their sessions and what to expect. I also go through a run-down of some sessions that I recommend. There are also some activities that are not part of the official schedule which we talk about as well.

You can watch the video below or listen to the audio above. To get notified of future VI Shots Live episodes, please join the mailing list at vishots.com/subscribe.

What to do and see at NIWeek 2014

Link to session scheduler. You can search the scheduler for the titles below or by speaker.

Recommended Sessions:

• Tips and Tricks for Highly Productive Programming in LabVIEW
  • Darren Nattinger
• LabVIEW Champions Live: From Specification to Design
  • Christopher Relf
  • Rebecca Linton
  • Christopher Roebuck
  • Justin Goeres
  • Michael Aivaliotis (me)!
  • Tim Robinson
• LabVIEW Hacker: Hacking the Real World
  • Sam Kristoff
• LabVIEW OOP: Computer Science for the G Programmer
  • Stephen Loftus-Mercer
• Implementing Gang of Four Design Patterns in LabVIEW
  • Yves Lemay
  • Joseph Des Rosier
• Creating Highly Innovative User Interfaces With LabVIEW
  • Samuli Bergstrom
• Hands-On: Code Review Best Practices
  • Nancy Hollenback
  • Brian Powell
• How to Create Truly Reliable LabVIEW Real-Time Applications
  • David Staab
• Save Time and Money With Unit Testing
  • Fabiola De la Cueva
• Standard and Nonstandard Inter-Thread Communication
  • Piotr MAJ
• How to Eat the Elephant: Turning Ideas Into Architecture
  • Jon McBee
• Going Large: Tools, Tips, and Tricks for Developing Large Applications as a Large Team
  • Christopher Roebuck
• Featherweight: Sustainable Application Architectures for LabVIEW
  • Jack Dunaway

Unofficial Events:

• LAVA BBQ
• Meetup at the Gingerman on Sun Aug 3 8pm (301 Lavaca St, Austin)

NI recently announced a small form factor instrument that packs a punch called VirtualBench. I interviewed Chris Delvizis, a Senior Product Manager at National Instruments about this new hardware. Aside from containing several instruments essential to a typical benchtop lab setup. It also works right out of the box with built-in software for the PC that loads when you plug in the USB cable. The NI VirtualBench iPad app is now available. Click the player above to listen to this weeks podcast episode, where we break down what VirtualBench is and if it's the right hardware for you.

Functionality:

• Mixed-Signal Oscilloscope
• Digital Multimeter
• Function Generator
• Programmable DC Power Supply
• Digital I/O

Joel Shapiro, Leader of Emerging Markets Marketing at NI, said, “Many entrepreneurs, engineers and scientists don’t always have easy access to the instruments they need. Due to the excellent functionality, affordability and portability of VirtualBench, every engineer can immediately be equipped with the tools they require to bring their ideas to life and take it to market.” “We are building on what NI does best, which is our software-based approach to test and measurement,” said Chad Chesney, Director of Data Acquisition Marketing at NI. “VirtualBench’s software user experience is more intuitive, creating efficiencies that go above and beyond simply having these five devices in a single device.”

Links to content mentioned:

• Official Site for NI VirtualBench
• NI VirtualBench Spec Sheet (pdf)
• iPad App

The Actor Framework, is a LabVIEW framework that has a growing following. It allows you to build powerful applications that can contain asynchronous processes and allow them to communicate in a more robust manner. Jack Dunaway and I talk with Allen Smith, Dr. James Powell and Dave Snyder about what exactly is the Actor Framework and how they've been using it in their work.

You can watch the video below or listen to the audio above. To get notified of future VI Shots Live episodes, please join the mailing list.

Links to content mentioned:

• Actor Framework Community

How do you support your LabVIEW applications remotely? Have you found the right tools and methods that make your job easier? In this episode of VI Shots Live, we look at some of the benefits and pitfalls of remote collaboration and support. Jack Dunaway and I talk with Fabiola De La Cueva and Justin Goeres on the topic of being a remote developer.

You can watch the video below or listen to the audio above. Listen to the end of the audio recording for a funny behind the scenes moment from the podcast version. To get notified of future VI Shots episodes, please join the mailing list at vishots.com/subscribe.

Links to tools I recommend:

Collaboration Tools

• Google Hangouts – This is a collaboration tool that I use to record VI Shots Live.
• JoinMe – Lightweight meeting tool. Also has a web interface.
• GoToMeeting – Highly recommended meeting tool. They also have GoToWebinar, which I've used many times for webinars.
• Skype – Audio & Video over the Web. This is the main tool I use here at VI Shots for my interviews.

Remote Control & Support

• TeamViewer – Powerful remote control software. This is expensive but it allows for unlimited hosts with one client.
• LogMeIn – Remote Control software. This is a lower cost but you pay depending on the number of computers you control.

Waterloo labs is at it again with another creative project that merges LabVIEW, NI hardware and the maker mind-set. How about standing in front of 3 paintball guns as they automatically “draw” an outline of you? How about if the software controlling them was written by an NI intern? It turns out, this system is pretty smart and fun. Check out the video below and then listen to the interview above I gave with Hunter Smith who mentored several members of Waterloo Labs throughout this project.

In the interview we discuss in detail the hardware and software used and developed. Hunter also talks to some of the challenges encountered.

Links to Content mentioned:

• Waterloo Labs Paintball Picasso
• NI MyRIO
• TechShop

I'd like to thank everyone for the positive feedback on our first VI Shots live, both in personal emails and also on our Google+ page. We're back with a new live episode which was recorded on Feb. 26, 2014. You can listen to the podcast version of the show above or watch the embedded video below.

Are you looking for a LabVIEW consultant for your next project? I'm a Certified LabVIEW Architect with over 20 years of experience in developing automation powered by LabVIEW. Contact me today for a free code review or project evaluation.

Our guests this episode:

David Thomson who's based in Colorado, is the founder of and systems Integrator at Original Code Consulting, which provides LabVIEW programming and system integration all the way from device drivers to complete systems. Dave is also a LabVIEW Champion since 2005.  Dave runs a user group meeting in Colorado, the Advanced LabVIEW Architects of the Rocky Mountains (ALARM).

Neil Pate is a Certified LabVIEW Architect (CLA) and Certified Professional Instructor (CPI). He’s a founder and systems development engineer at Premier G Solutions Limited in the United Kingdom. Neil is based in the United Kingdom. Neil is very active on LAVA: http://lavag.org/user/7375-neil/

Steen Schmidt is the founder of GPower in Denmark. Steen is a Certified LabVIEW Architect (CLA), a Certified TestStand Architect (CTA), and was recently nominated as LabVIEW Champion just this month, so congratulations, Steen!

We've all heard of the Agile Software development methodology; but how many of us are actually using these principles while developing LabVIEW code? My guest, John Sextro is an Agile coach and an expert in the field of Agile Software development. Listen to this episode of the VI Shots podcast where I ask John about the Manifesto for Agile Software Development, and we walk through the 12 principles behind the Agile manifesto. This conversation is just the beginning of an exploration of this topic. I'm planning on having John back on in the future to discuss Scrum, which is the leading agile development methodology.

I believe LabVIEW is by-design, a language that can thrive within an Agile development environment. You can quickly get software working and data displayed on a UI within a short time frame. I'd like to hear your feedback on this topic. Do use Agile? If not, then why not? Post you concerns and questions in the comments below and John will visit this post to answer your questions.

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

12 Principles behind the Agile Manifesto:

1. Our highest priority is to satisfy the customer through early and continuous deliver of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Links to content mentioned in this podcast episode:

• Contact John Sextro on Twitter
• Agile Evidence – John's website on Agile
• This Agile Life – John's podcast on Agile
• iOhYes Podcast

Our guests on our first episode were Christopher G. Relf, chief Architect at VI Engineering (a National Instruments Platinum Alliance Partner). He's also a CLA, CTD, CPI and a LabVIEW Champion. We also had Darren Nattinger, principal engineer, CLA and part of the LabVIEW R&D team at National Instruments.

• All of the shows can be found at vishots.com/live
• Google+ show page: Click on Q&A link in the video to view all the questions posted during the live event.

Using Subversion with LabVIEW is a challenge when it comes to some of the most popular free tools like Subversion (SVN). Eric Metzler from Viewpoint Systems took on the challenge of updating an older version of an internal company tool. The new free version of the TSVN tool won  the LabVIEW Tools Network Product of the Year award at NIWeek 2013. Eric talks with me about his journey through the LabVIEW world and his newfound passion for working on LabVIEW-based products.

Links to items mentioned in this episode:

• TSVN Toolkit from Viewpoint systems
• Subversion Source Code control
• CLA Summit
• VI Shots Live

Jack Dunaway from Wirebird Labs is on this episode where we discuss his Deploy product and what it takes to develop great software products. Jack also announces a new “framework” he will be releasing in 2014 called Featherweight.

Links to Content Mentioned:

• Deploy – LabVIEW Tools by Wirebird Labs
• Inspired –  Book by Marty Cagan
• VIPM Idea Exchange
• Wirebird Labs Idea Exchange

I hope you enjoy this interview as much as I did. Leave me a comment below and tell me what you think of this episode, or if you have any questions. You can support this podcast by subscribing on iTunes (for iOS) or giving us a rating and review in the platform of your choice.

Links to the topics mentioned:

• Nancy's presentation at NIWeek 2013 (pdf)
• Example Code for the above
• CLD Summit 2013
• NI LabVIEW Developer Days
• NI Days
• NI LabVIEW Certifications

I hope you enjoy this interview as much as I did. Leave me a comment below and tell me what you think of this episode, or if you have any questions. You can support this podcast by subscribing on iTunes (for iOS) or giving us a rating and review in the platform of your choice.

Links to the topics mentioned:

• Creating a Custom Bookmark Manager for LabVIEW
• Christina's Eyes on VIs Blog
• Rune

Here is the one opening quote that Fabiola used in our discussion. I highly recommend you listen to the entire episode.

Designing the Moment by Robert Hoekman Jr.
“Each moment has the potential to increase a user's confidence or destroy his trust in a product or a company, and each one is an important piece of the whole experience. Why? Because the task a person is attempting to complete at any
given moment is the most important task to that person, at that moment. It is our job to make sure nothing goes wrong. To make sure that moment is enjoyable and productive, and helps our user feel smart.”

Here is a summary of the five tips (more explanation in the podcast):

1. Improve the user experience. Starting all the way from the installer.
2. Make your application user configurable.
3. Don't use geek speak when the software interacts with the user.
4. Develop your code in a moduler, testable fashion
5. Use Source Code Control

Links to some content mentioned:

• Delacor – Fabiola's LabVIEW consulting company
• Fabiola's presentation at NIWeek
• Deploy Tool

Thomas has managed to create a valuable resource for anyone that wants to transition from a basic LabVIEW coder, to a professional LabVIEW programmer that can handle complicated software project requirements. He spreads proper coding techniques and best practices throughout the book. This is knowledge that would take someone years to master on their own. I highly recommend this book for any beginner to intermediate level user who wants to take their skills to the next level.

Links to content mentioned on this episode:

• How to become certified in LabVIEW
• Preparing for the CLA Summit
• Purchase this book – “Effective LabVIEW Programming”
• Leave Feedback and Subscribe to us on iTunes

Links to items mentioned in this podcast episode:

• Raima Database API for LabVIEW
• LabVIEW Tools Network
• Smart-grid control network by Localgrid

Links to Items mentioned in this podcast:

• Steve's Company SSDC ltd.
• Book: A Software Engineering Approach to LabVIEW
• Steve's Blog: Random Ramblings in LabVIEW Design

About the Panel

This is a rare video recording of a panel discussion which took place at the Americas CLA (Certified LabVIEW Architect) Summit on March 5th 2013. This was on the schedule for the summit, but was intended as a filler for that morning because some of the participants were taking their CLA re-certification exams. So we were treated to an hour of listening to some of the original members of the LabVIEW R&D team speak about what it was like in the early days with the release of LabVIEW 1.0 and then the re-write of LabVIEW 2.0.

Brian Powell, facilitated the discussion by posing some prepared questions and presenting some old photos of the team. Yes, Brian actually had hair back then! Then it was opened up to questions from the CLA attendees. As you listen to the stories about the “bowl and the lid” to describe their source code control check-in system, you get sucked into the excitement of not just the software development process, but the feeling of being part of a team of smart people that are working towards a common goal.

Here is a list that Brian put up on a slide that describes some of the lessons learned during the early years of LabVIEW development:

Lessons Learned:

• Have a vision and a passion – and share it!
• Individual ownership – team effort.
  • Set goals, evaluate, iterate – make something happen.
• Start from where you are.
• Optimism, persistence over long term.
  • Ooch approach.
• Excitement, confidence, success are contagious.
• Have Fun – “The Journey is the Reward”

Brian Powell, Duncan Hudson, Greg Mckaskle, Jeff Kodosky and Steve Rogers. Some of the original members of the LabVIEW R&D team.

This panel chat is not typical of the type of discussions going on at a CLA summit. However, Jeff Kodosky and a lot of other NI LabVIEW R&D folks were always on hand to engage in deep-dive discussions. The CLA summit lasted 3 days and took place in Austin. The summit also took place in Paris, France this year (The European location changes every year).

Becoming Certified

If you want to take your LabVIEW career to the next level. I definitely encourage you to get certified. If only to get a chance to come to the CLA summit every year. The summit is only for those that have reached the CLA level of certification in LabVIEW and is free to attend. The discussions are very lively and you get to really hash out a lot of ideas and techniques of LabVIEW development that help you improve your skills, while networking with like-minded engineers. More information on becoming a Certified LabVIEW Architect can be found on NI's website.

Just as in previous versions of the Robotic kit, National Instruments continues the collaboration with Lego in this new version. They're releasing a new programming environment for the EV3 which is improved and should make programming much easier than before.

Guests:

• Greg Mckaskle – Chief Software Architect for Labview (National Instruments, Austin)
• Nicole Richard – labview K – 8 Software group manager (National Instruments, Austin)
• Flemming Bundgaard – Electronics in product technology (Lego, Billund, Denmark)

Below you can see a video of the EV3 demo at NIWeek 2013. If you look at the programming environment demo, you will notice some great usability features. For example, you can see the configuration of each block without having to bring up any popup dialogs. Also, you might not notice it in the video, but at 8:10, David zooms out on the diagram to get a better view of the program. The audience breaks out in applause to which Ray Almgren responds with: “It's coming someday”. Obviously referring to the fact that you can't do zooming out in your code in LabVIEW. Many people have asked for this feature over the years and NI has yet to deliver on it.

In the podcast, I asked Greg Mckaskle if any of the enhancements delivered to the EV3 software development environment will transfer over to core LabVIEW. His response gave me some hope that we might see these down the road.

Links to more information:

• Buy Lego EV3 Education Edition
• Buy Lego EV3 Consumer Edition

In this podcast episode I chat with Grant Heimbach and Jonah Paul as we run through some of the top features in LabVIEW 2013 in addition to the new cRIO controller.

New LabVIEW 2013 Features:

• Productivity Enhancements
• LabVIEW Web Services
• LabVIEW FPGA Features
• LabVIEW Real Time Features
• All the New Features!
• What is the NI cRIO-9068 Software-Designed Controller?

Brian of course is well known as one of the original team members that helped bring LabVIEW 2.0 to market as a software engineer. His vast experience with working with LabVIEW teams shows in this interview, which is packed with wisdom. We discuss the following topics:

• Humility and why that's a good character to have.
• Why code reviews are essential and how to do them.
• The importance of clarity in your software
• Simple or Scaleable, are they conflicting requirements?

Visit LabVIEWJournal.com for more.

One of the benefits of being a CLA (Certified LabVIEW Architect), is that you get to go to the exclusive CLA summit. This is a yearly event held in Austin and Europe for the purpose of discussing topics and issues affecting LabVIEW developers today. Topics range from LabVIEW frameworks to source code control techniques. Best of all, admission is free with your membership.

One very enlightening presentation was given by Joe Silva from National Instruments. In it he discussed some basic UI design principles that can help improve your design right away. I interview Joe in this episode and we highlight some of the topics in his presentation. We also discuss some of the struggles LabVIEW developers face in developing good UI designs. – If you want to catch Joe presenting, you can see his session this year at NIWeek 2013

Joe had a list of recommended reading in his presentation. Here is the list:

• Universal Principles of Design
• Envisioning Information
• The design of everyday things

Links to content mentioned in this episode:

• Edward R. Tufte – Noted for his writings on information design and as a pioneer in the field of data visualization.
• The NIWeek Conference Podcast

NSA Powerpoint slides, before and after. Designed for better comprehension and data presentation:

In this episode, I interview Matthias Baudot from Studio Bods. He's started a new company that just announced a product on the LabVIEW Tools Network called BLT for LabVIEW.

From the LabVIEW Tools Network Description:

• License your own LabVIEW application in a few clicks – no coding required
• Automatically (and remotely) update your applications when you make changes in your LabVIEW code
• Automate the build process for your LabVIEW executables
• Get user activity reports and error logs so you can remotely debug your program
• Use BLT scripting to remotely execute actions on a deployed computer, e.g., update LabVIEW RT Engine
• Disable parts of your code with features definitions

Links to content mentioned in this episode:

• Studio Bods website
• BLT for LabVIEW demo video
• LabVIEW Tools Network

Here at VI Shots, one of my goals is to always be expanding my knowledge into LabVIEW and learning new software engineering techniques and ideas. To that goal, I try to bring people on the show that can teach me, and in turn you, something new. This episode of the VI Shots LabVIEW podcast is no exception.

We all have, at some point, developed a framework that allows us to create parallel processes and communicate with them. We've even given them cool pet names. We're pretty proud of our creations and excited about using them in our customer projects. However, things fall apart at some point, usually with a looming project deadline.

Stephen Mercer and Allen Smith from National Instruments join me to discuss some of these framework problems and the solution they have within the Actor Framework. The Actor Framework is a collection of VIs made available through the LabVIEW 2012 palette and as a Project Template. Should you be using it in your next customer project? Listen to the show, then dig into it and try it for yourself.

Links to content mentioned in this episode:

• Getting started with the Actor Framework
• Actor Framework community group

Links to content mentioned in this episode:

• Trew Marketing
• Smart Marketing for Engineers – Guide
• Seth Godin's Startup School

The LabSocket System enables LabVIEW applications to be monitored and controlled remotely using a web browser. The system operates without browser plug-ins, making it suitable for use with a wide range of desktop and mobile browsers. The system is easy to use and requires no knowledge of web programming languages such as HTML or JavaScript.

Listen to the interview to find out more about LabSockets and see if it can help extend your own LabVIEW app, and allow it to be controlled via a web browser interface.

• LabSockets Website
• Follow John Bergmans on Twitter
• Bergmans Mechatronics

In this podcast, I interview Grant Heimbach, the data dashboard product manager. We explore some of the capabilities offered by this new free mobile application and how it can help LabVIEW developers extend their reach into the mobile space.

Links to content mentioned in this episode:

• Mobile Technology for Measurement and Control
• Smartphones, Tablets, and Mobile Devices Community
• iTunes Store Page
• Google Play Store Page

Links to content mentioned in this episode:

• LabVIEWhacker.com website
• Some of the content:
  • AR Drone
  • MindShark
  • ez430-chronos
  • Kinect
• Science in the pub embedded video below:

Over the years, he’s transitioned to a radically different career as a director in the filmmaking industry. He’s had many short film successes, but recently he’s directed an independent feature film called Dragon Day. I had a very interesting discussion with Jeffrey on the challenges to producing an independent film and the balance between his engineering background and his new found passion. Also listen to find out about a special cameo appearance in the film, and it’s not who you might think.

Jeffrey is a fellow engineer that decided to pursue his creative filmmaking passion. He describes how he made that happen in the interview. However, he needs our help. Please visit the following link and contribute what you can so he can complete the post production process and get it released. There are only a few days left in the campaign.

http://www.indiegogo.com/dragonday

Excerpt from the films website:

When out-of-work techie Duke Evans and his family try to rebuild their lives in a remote mountain town, their own version of the American Dream is cut short as planes begin falling from the sky and all power, communications and transportation suddenly stops working. Caught in an unprecedented cyberattack that signifies the end of the U.S. as we know it, Duke and his family must use all their wits and the unlikely help of an illegal immigrant, to survive this frighteningly realistic scenario where water, food and time are running out.

Support the movie:

• Contribute to the movie
• Dragon Day Movie Website
• Dragon Day Facebook page

I invited Elijah Kerry, the senior product manager for LabVIEW, on the show so we can find out first-hand about all the new features of LabVIEW 2012. One of the most significant features, this year is the LabVIEW Templates and sample projects. I was a little skeptical of relying on NI to deliver quality sample projects that would meet my high expectations. Listen to the podcast to find out how good they really are.

I will be taking VI Shots to NIWeek 2012. You can see me at the technology theater on Tuesday at 4-5pm. I will be interviewing some past VI Shots guests and some new faces. More info here.

Here are links to items mentioned in this podcast episode:

• New features of LabVIEW 2012
• Large LabVIEW App Development Community Site
• Elijah's Blog
• Elijah's twitter
• VI Shots Live @ NIWeek 2012

I’m very excited today to bring you an interview I did last year at NIWeek 2011. I sat down with a group of engineering interns at National Instruments. Now these intern positions were not typical. Hunter Smith and Ben James who managed this group of students, gave them the flexibility to do whatever project they wanted, as long as it was extremely awesome. How’s that for some parameters to work within?

Top Row: Hunter Smith, Ben James, Humphrey Huang, Peter Gayler – Bottom Row: Dylan Caswell, Tim Lynch, Me. Fred Visser was also a manager for the group (not shown).

This group within NI is called Waterloo Labs, and I had a great time talking with them. It’s feels great to see so much excitement in engineering. Some of the projects that have come out of Waterloo Labs is an iPhone controlled vehicle, an Eyeball powered super mario game, a Kinect powered etch-a-scetch. One of the coolest projects so far, I think is something they go in great detail in this interview.

Here are links to items mentioned in this podcast episode:

• Waterloo Labs Youtube Channel
• Facebook Page
• Twitter

In addition to getting some insights into how they work and collaborate, they also made a huge announcement on the show of a new product they are really excited about unleashing onto the LabVIEW community. Take a listen to find out what it is.

*Keep listening after the closing title of the podcast and listen to some bonus content*

Here are links to items mentioned in this podcast episode:

• Sixclear website
• VI High Video Blog
• Sixclear on Twitter
• Sixclear on Facebook (go friend them)

Some Deadlines to be aware of:

• Dec 1st  9:00am CT: Challenge descriptions become available
• Dec 19th 9:00am CT: Submissions accepted & voting for User Interface Challenge begins
• January 11th 11:59pm CT: Deadline for submissions
• January 13th 5:00pm CT: Voting ends & winners announced

Here are links to items mentioned in this podcast episode:

• LabVIEW 2011 Winter Coding Challenge – Instructions

In this episode of the VI Shots podcast, I interview the three members of the recently formed Field Architects group at NI. Nancy Hollenback, Brian Powell and Charlie Knapp.

 From their blog:

We are a small, elite group of LabVIEW experts working in large accounts and helping engineers become more proficient in LabVIEW. We guide software architectures, develop technical leaders, and teach and encourage good software engineering.

Take a listen to this episode to gain some insight as to how this group of experts is expanding LabVIEW proficiency among large development teams by promoting good software engineering tools and practices.

Here are links to items mentioned in this podcast episode:

• LabVIEW Journal Blog – Blog of the NI Field Architects
• LabVIEW Large apps Community
• LabVIEW Unit Test Framework
• VI Tester
• LAVA

I've reached the 10th podcast episode! That's a big milestone for VI Shots.

Another big milestone is the 25th anniversary of LabVIEW and the release of LabVIEW 2011. To get the rundown of all the new features, I asked Jeffrey Philipps from National Instruments to join me in this podcast episode. Do you know why the new controls palette was named Silver? Listen to find out.

In addition to the new version of LabVIEW, we discuss the NIWeek 2011 keynotes and the “what's new in LabVIEW” session.

Here's a hit list of some of the cool new stuff:

• Improved Stability
• New Silver Controls Palette
• Improved Real-Time Deployment
• New Math and Signal Processing Functions
• Application Builder API
• Asynchronous Call by Reference
• Improved Create SubVI functionality
• Create Type Definition from Block Diagram
• Find Add-Ons link in the Getting Started window

There are a lot of things to see at NIWeek and we cover some of the technical sessions you can attend and how to get the most out of this year's technology conference if this is your first time or even if you've been there before.

I will be at NIWeek this year, so feel free to come up to me and say hello. Most of the time I will be hanging out at the JKI booth on the expo floor. I will also be attending the LAVA OpenG BBQ and will be on a discussion panel called We are the Champions (Tues. Aug 2, 2:15–3:15 p.m. – room 10C).

Here are more links to items mentioned in this podcast episode:

• LAVA OpenG Barbecue
• NIWeek 2011 Program Schedule – This is the complete conference program guide as a PDF. You can search the document by speaker or company name

In this episode of the VI Shots podcast I sit down with Terry Stratoudakis who is the CEO of Wall Street FPGA. A company that specializes in the acceleration of trading and financial analytics software using LabVIEW FPGA.

This is a new industry in general for LabVIEW and specifically LabVIEW FPGA. I was skeptical at first and a little confused. Where exactly are FPGAs used here? No worries, Terry explains it all to us. By the end of the interview, I was all fired up to find other untapped industries where I could use LabVIEW FPGA.

There is a lot of information packed in this podcast episode so you might want to listen to it more than once.

PS: Terry will be at NIWeek this year giving an unrelated presentation (TS3261-The Missing Link – 8/3/11 1:00 PM – Rm: 10C). So track him down if you're there.

Here are more links to items mentioned in this podcast episode:

• Wall Street FPGA LinkedIn Group
• LabVIEW in Finance ni.com Community Group
• Follow Wall Street FPGA on Twitter

I mention in the interview that I was having problems getting LabVIEW to communicate with the arduino under Mac OS. Since then I have resolved my issue. It turns out I was using the wrong port. The VISA serial port listings under Mac are not very descriptive and what I thought was the USB port was actually the Bluetooth.

I've recorded a detailed video tutorial on how to get started with the toolkit which you can find here.

Here are links to items mentioned in this podcast episode:

• Community Support home for the LabVIEW Interface for Arduino
• Download the toolkit from the LabVIEW Tools Network
• Cool Projects built with the toolkit on the NI Arduino Blog

In this video tutorial, I give an overview of what the Arduino hardware is and how the LabVIEW Interface for Arduino (LIFA) works. I demonstrate a simple program I wrote that scrolls 12 LEDs with a variable speed similar to a Larson Scanner.

Download Code Used in this Tutorial: (LabVIEW 2010)

There are many Arduino boards out there. A complete listing of all of them can be found here. More information about the Arduino can be found on the Arduino project website.

Overview

The Arduino, is a programmable micro controller board that has several analog inputs and digital IO lines. The Arduino language is text based and is used to create embedded programs which you download to the board.

Step by Step Startup Guide

Here is a step by step process to get up and running with Arduino and LabVIEW:

1. Purchase an Arduino board and accessories. You can find them at many locations. Here's the best place to buy:
   • Awesome deal – get the Arduino+LabVIEW Bundle for only $55.
   • Purchase a USB A-Male to B-Male Cable
   • You will also need a 9V 1A Power Adapter
2. Make sure you have LabVIEW 2009 or newer installed. The VIs that are included in the LIFA are saved in LV 2009, so this is the version of LV that you must have to be able to use the LIFA. If you do not have this version of LabVIEW, you can download a 30day evaluation of it from ni.com/trylabview
3. Install NI-VISA Drivers. To LabVIEW, the arduino appears as a serial instrument device. To communicate with serial instruments in LabVIEW, you need to have the latest version of the NI-VISA driver. You can get the latest NI-VISA drivers here. Make sure to select the latest Windows or Mac versions.
4. Install the Arduino IDE and drivers for Windows. You can download them from the Arduino website here.
   • Step-by-step instructions for setting up the Arduino software on Windows can be found here.
   • For Mac look here. Mac does not need drivers but you still need the IDE environment.
5. Install the LIFA. The LIFA is available as a VI package through the LabVIEW Tools Network. You must first install VIPM. Once VIPM is installed, click on this link to get and install the LIFA under LabVIEW 2009+.
6. Upload the sketch ‘LIFA_Base.pde' to the Arduino. The LIFA comes with a sketch program that must be uploaded to the Arduino before you can use the VIs to communicate with it. You must use the Arduino IDE software (which you installed in step 4) to do this. I show how to do this in the video tutorial – above. The sketch is located at:
   • C:Program FilesNational InstrumentsLabVIEW 2010vi.libLabVIEW Interface for ArduinoFirmwareLVIFA_BaseLVIFA_Base.pde
7. Start Playing. For support, join the Arduino LabVIEW community at ni.com/arduino

In this episode of the VI Shots LabVIEW podcast I chat with Crystal Drumheller from W.L.Gore and Associates in Flagstaff Arizona and Justin Goeres from JKI. Before Crystal worked for her current employer, she worked for National Instruments. That's where she got the LabVIEW bug and hasn't looked back.

Both Crystal and Justin mentor FIRST Robotics teams and they both participated with their teams in the FIRST championship in St. Louis, Missouri this past April. Have you ever wondered about being a mentor for a local FIRST robotics team? Listen to this podcast to find out first hand from these mentors.

Also, listen to find out how Justin ended up with a bloody head wound during the championship.

Here are links to items mentioned in this podcast episode:

• Crystal's Team 2486
• Justin's Team 3459
• Find a local FIRST team to mentor

Peter wrote some awesome code that scans through the NI Community site and returns all the documents available from various categories and groups. Take a listen to see how the code he wrote led to an opportunity for a spin-off product which Peter is working on releasing to the LabVIEW Tools Network.

Here are links to items mentioned in this podcast episode:

• Peter's winning entry
• Windows Baloon Prompt using .NET Constuctors
• LabVIEW IP Spark

As we've learned back in VISV Episode 003. When building executables that use dynamic VIs, you must make sure to specify the dynamic VI name in the ‘always include' section of the LabVIEW Application Builder specification. Not doing this will cause problems that manifest themselves as a LabVIEW application that won't be able to load your dynamic VI and will either raise various errors or cause the application to fail completely. It depends on how critical your dynamic VI is to the overall application.

Making special considerations for dynamic VIs during the build process is an extra step you have to do which can lead to a point of failure. If you create a new dynamic VI in your code then you must remember to update the build spec. Even with the best intentions, this step can still be missed.

Sometimes you are not in control of the build process. For example, your code may be distributed as a toolkit that others use to build their own applications. Informing end users of your code to include the dynamic VIs is a challenge.

In this video tutorial, I will show you a simple way to avoid these problems by following two simple code modifications.

Download Code Used in this Tutorial: (LabVIEW 2009)

*Update*

In the video, you'll see me use the path from the VI path property wired into the Open VI Reference function. It's slightly more efficient to use the VI Name property and wire that instead. Since the VI's already in memory. Using the VI name should work just fine.

In this episode of the VI Shots LabVIEW podcast, I have Darren Nattinger of National Instruments back to chat about his favorite feature of LabVIEW – Quickdrop. Darren is not new to this podcast. I had him on the show back in episode 002 where he gave us some interesting insight to his background and his unique role at NI.

Did you know that Quickdrop was written using LabVIEW? It's true, which would makes sense since Darren programs exclusively in G. There are also several other interesting and useful tips Darren lays down in this episode, including ways on how to make using quickdrop even faster with Quickdrop shortcuts.

Something that was discussed in the show are Quickdrop plugins. Since 2009, there are a few plugins that ship with LabVIEW. My favorite is the one that moves control labels on the diagram from above to the sides using <ctrl + T>.

Here are the links to items mentioned in this episode:

• Quickdrop Overview
• Quickdrop Enthusiasts Community
• Quickdrop ini tokens

In this video tutorial, I share with you a technique that I use, when I want to be selective of how LabVIEW child classes load into memory. Specifically, by using the Factory pattern, I can dynamically load a class into memory and create an instance of a child class on-demand.

It's important to note that LabVIEW loads classes into memory automatically whenever class objects are used in VIs.

To demonstrate these concepts, I am using a code example from VISV 002. Take a look at that video if you want a more in-depth walkthrough of the code. Here, I attack the problem of how to limit loading of classes to only the ones you need for your current application run.

Download Code Used in this Tutorial: (LabVIEW 2009)

I ask Justin about how he got his start in LabVIEW and how he almost became a PLC programmer! We also find out what Popcorn, Twitter and LabVIEW have in common.

Here are links to items mentioned in this podcast episode:

• CLA Community on ni.com
• LAVA Discussion on Justin's Event Structure bug (video).
• Popcorn Tweets video
• JKI State Machine

As always, discussion is encouraged. Please leave a comment on our site or send an email to feedback@vishots.com

Show Transcription:

Michael: Hello everyone and welcome to this episode of VI Shots. My name is Michael Aivaliotis and this is the podcast devoted to the world of LabVIEW. With each episode, I bring you interviews, discussions, and share with you ideas for how you can take your LabVIEW development to the next level.

Well thank you all for joining me for this third episode of the VI Shots podcast. Today, I bring you an interview I did with Justin Goeres, who is a senior engineer and product marketing manager at JKI. But before we get into interview, I'd like to play for you an audio clip I recorded a few weeks ago at the National Instruments CLA Summit, which took place in Austin, Texas between March 7^th and 8^th. I was there with Justin attending this awesome event. Justin did a presentation where he shared how JKI does interprocess communication. So I’m playing this clip actually directly from my iPhone. This is actually an interesting, a cool idea I don’t know if anyone has thought about this but you can actually use the voice memo feature on your phone and just use that for recording audio at any conference or seminar you may attend. So a little bit of background, Justin had been battling some technical issues with the event structure and when I’ll interview Justin, he’ll go into more details about this. This is just right before Justin discovers at the CLA summit that why he’s having this problem and it’s actually someone from the audience that points that out. So let’s take a listen.

Justin: What this means or one other aspect of this is public events are inherently one to many, right? You can generate the event but anybody can register for those events, anybody can register for that event. And as I think it should be clear, the process VI doesn’t know who these guys are or how many of them they are or if they exist at all. One cool feature of the LabVIEW user event backend system is that basically when you pass that cluster of user event refnums into a user event registration node and then hook that into an event structure, any event refnums that don’t have a corresponding case in the user event are basically de-allocated in the background. So you can attach that wire for all of the event refnums and ones you don’t use, don’t create bloat or leaks or process overhead because they’re just not generated like magic.

Steen: You just have to understand that they reset the timeout.

Justin: They do what?

Steen: They reset the timeout you know even though they are not handling the instruction.

Justin: Is that why my event structure isn't timing out? They do? Say it again? Okay. What Steven suggested is that if you have an event structure that’s registered for, sorry, if you have a cluster of (we’ll do it with two) with two user events wired into an event structure and the event structure has a case to handle one of them but not the other. And then somewhere else, something else generates the other event, the one you’re not registered for that won’t be handled here but he’s saying it will reset the timeout counter on that user event.

Stephen Mercer: Yes

Stephen Mercer: Why did you register it for then? You’ve said register for it.

Justin: Oh my god. In all honesty, that might be my problem. Okay let’s move on anyway.

Stephen Mercer: What other behavior would you want, given that you did say register to hear about it?

Fabiola: But you’re not using it.

Justin: Actually I’ll tell you why I do. I do that because I thought, and have thought, that it was an awesome feature of LabVIEW that I could just only create a frame for the things I wanted to receive and that I thought something really cool was happening. Actually furthermore, I would suggest that that is a really hard behavior for me to figure out because all I have is an event structure in my code with a timeout value attached to it, but never times-out and I have no way of inspecting the State queue to find out what’s happening.

Michael: Okay so having played that I introduce to you Justin. Hello Justin.

Justin: Hey Michael.

Michael: So I hope you heard all that.

Justin: I did hear all that. I remember it as though it were two weeks ago and that’s why everyone should come to the CLA summit. Everyone who’s a CLA.

Michael: Case closed.

Justin: Case closed. That was a watershed moment in my LabVIEW career right there. It was a whole series of dominoes that fell just with that offhand comment that someone else made that just clicked.

Michael: I’d like to mention just for the record that it was Steen Schmidt from CIM Industrial System that was in the audience.

Justin: Yeah I called him Steven but I misread his name tag. Sorry Steen.

Michael: Basically Steen was nonchalantly you know just laying back and say yeah you can do that but you just have to understand that they reset the timeout and you’re like what?.

Justin: And now I do understand.

Michael: And then after that you know a whole slew of discussion ensued which it goes on and on and on, but actually that night and the next day as well.

Justin: Yeah it actually turned into a very interesting discussion that got into sort of language semantics and how the core of LabVIEW works and all kind of neat stuff and it turned out to be a pretty cool discussion on LAVA too. I no longer have an opinion on it. I’ve recused myself from what is right or wrong. I just wanted to have proper expectations.

Michael: I guess this is a good advertising for the CLA summit and I mean I guess you got a lot out of it.

Justin: I absolutely got a lot out of it. I wasted more hours dealing with that bug prior to the summit almost than I spent in the summit in its entirety. I lost a lot of, there was a lot of head scratching and several new dents in my forehead from hitting it on the desk dealing with that, but the CLA summit took care of it.

Michael: So you presented basically how JKI does interprocess communication. Can you I guess wrap that up in a nutshell as to what does entails?

Justin: Sure. The theme of the CLA summit this year was interprocess communication and the motivation for that was basically that we’re all CLAs and we all have these different templates that we’ve all developed for communicating information back and forth in a highly parallel, modular, large applications that we develop.

JKI has a set of templates. I didn’t develop them. They’ve sort of grown organically within the organization over the last several years for doing this and our design is based almost entirely on custom user events that are you know handled in the event structure and we use some neat aspect of the user event handling subsystem in LabVIEW to sort of wrap it all up in a nice API and pass information back and forth. And we think it’s a fairly unique design and so I was doing a presentation in the CLA summit about how JKI solves the interprocess communication problem. Other people use queues you know you could use local or global variables, you could use functional globals. There’s a thousand different ways to solve this problem. Ours uses user events so I was sort of presenting that to the community of CLAs.

Michael: The whole interprocess framework is based on the fact that you bundle into the event registration, several events but actually you’re not necessarily creating event cases for all those events and only for the ones you need, and therefore that’s what sort of brought out this bug, this issue.

Justin: Yeah exactly. There are lot of neat thing you can do. A lot of people have not experimented with user events and sort of the way to register for events now it works can be a little tricky and confusing. But it turns out that you can create you know custom user events using the create new user event reference primitive or whatever it’s called. And you can bundle those together and then wire the entire bundle into an event registration node so that you don’t have to wire in you know five or 10 or 30 individual event refnums. You can just wire in the whole bundle. We thought at JKI that that was a cool sort of shorthand way to get a lot of functionality in a small amount of code but it ended up having this consequence that we didn’t realize. But many people didn’t realize and we we’re among them.

Michael: Personally, I actually made the statement later coming back to JKI that you know I would even forego going to NIWeek if I could just go to CLA summit.

Justin: It was pretty valuable and it was fun because the thing about NIWeek is it’s so big and there are so many people there that you only get to see sort of online maybe in the forums or in the forum communities, LAVA and the NI forums, and things like that. But you only get to see them you know for two or three days a year in Austin in August and it’s so hectic and the crowds are so big and there’s so many presentations to go to.

One neat advantage of the CLA summit, I didn’t go last year, this is my first summit that I’ve gone to. One huge advantage is that it’s sort of slower and the crowd is a lot smaller.There are only maybe 50 people there, 50 CLAs, and maybe 10 or 15 NI people involved, but it was a lot slower and smaller and so there was a lot more opportunity to sort of connect with people; both personally and in a technical way.

Michael: You actually put a post on the JKI blog about this called “five reasons you shouldn’t miss the CLA summit next year”. I pulled it up here. It says other CLAs will explain LabVIEW bugs to you.

Justin: Bugs is in ironic quotes. Well that refers to the surprise event structure, non timeout issue. In the blog post there’s actually a link to the LAVA discussion. My initial take on it in the moment was it was a bug which is a reaction I would still stand by because the behavior clearly violated what I think were pretty reasonable expectations that I have developed but the way LabVIEW works is a language, but after a lot more discussion and some more explanations from different NI engineers, I’ve sort of tempered my opinion on that and so now I just put bugs in quotes because that was how it felt like to me at first.

Michael: Number two on your list you have NI will ask you what you think.

Justin: Yeah this one was one aspect of the summit that I really didn’t expect that was really cool. And I say in the blog post it’s no secret that sometimes CLAs feel like NI doesn’t get it with respect to advance developers and I don’t mean that as a dig at NI but the fact is that anyone out there who is a CLA or even a CLD and maybe some people who aren’t certified at all. Sometimes it’s hard to feel like the feedback or criticisms you have about LabVIEW or about NI’s products gets to the right people all the time and without taking the position or whether or not that’s true. I can tell you that at the CLA summit there were a lot of really interested LabVIEW R&D and LabVIEW product marketing, LabVIEW product management and even executive level individuals who where there specifically because they valued what’s going on and they wanted to get feedback. And that was a really cool thing to see.

Michael: Well I guess i’m going to jump to number five because it’s kind of related. You might get to give a presentation to Dr.T and Jeff K.

Justin: Yeah. Another extraordinarily surprising thing was that Dr. Truchard and Jeff Kodosky both spent a lot of time at the CLA summit and I was not surprised to see them show up but I was surprised that they spent as much time as they did and I had a nice conversation with Dr. T about some NI marketing data and market research that they’ve done and I did not get the chance to talk to Jeff. I don’t know if he sat in in my presentation. I don’t know what his opinion on the bug would be. In fact, he probably wasn’t there or we would’ve asked him. But in general, they were really there a lot of the time and it was really cool to see them engaging the CLA community like that.

Michael: Just so people who don’t know Dr. T is, he is president and CEO and co-founder of National Instruments and Jeff K has the title of being the father of LabVIEW because he basically invented LabVIEW which gives us our jobs, 9-5 jobs.

Justin: Gives us a podcast.

Michael: And the podcast. Let’s see going through your list, number three, you confirm that you’re not an idiot.

Justin: One common thing that I think everyone will relate to as a serious software developer is that you spend a lot of your life feeling like you’re not very good at what you do because the problems you’re solving are sort of by definition hard. If they weren’t hard, there will already be a library or you know a VI package or something out there to solve them already or your organization would already have a reuse library for them.

And so the fact that your job is hard just means that you’re solving hard problems and one of the really cool aspects of the CLA summit was that we were there to talk about this sort of very canonical issue of interprocess communication. I have two loops or three loops, or 10 loops. How do I pass information between them? It was really interesting to see all these other you know talented, very skilled people with very deep background in software engineering and LabVIEW and all kinds of disciplines, all struggling with exactly the same problems and solving them in very different ways. It sort of reflect their particular needs in whatever the work they do day to day is but it’s sort of edifying to see that because that means when I’m sitting at my desk banging my head on it because my event structure isn’t timing out. I’m probably not the only person in the world that’s confronting this issue and there isn’t sort of a cook book recipe to go to. It’s just that interprocess communication is kind of tricky and as a sort of ecosystem you know all the LabVIEW developers in the world haven’t settled on a good solution to it yet and so it’s nice to see that that other people struggle.

Michael: Finally, you have you’ll get to talk to people you normally only see.

Justin: This gets to what I mentioned earlier about the CLA summit being sort of a smaller, more intimate place. My little heading there is not perhaps the most clever thing I’ve ever written but what I wanted draw attention to was at NIWeek you say all these people and maybe you end up Facebook friends with them or you say let’s connect on Linkedin or you use your little Bump app on your iPhone to exchange mobile phone numbers so you can text each other snarchy comments during the NI week keynotes.

Michael: It’s that a sneak peek to what’s going on in NI week?

Justin: That’s completely hypothetical and I made it up. I have no further comment on the advice of my lawyer. But you know the CLA summit was really cool because I actually got to sit down with some of these CLAs that you normally meet in passing or maybe you know have a beer with at NI week but you don’t get to sit down and have a really technical talk, and it was nice to do that.

Michael: It seemed like even after the presentations were over, people just kept talking about the topics of the presentation and other architectural issues as well.

Justin: Exactly.

Michael: Is that you clicking over there?

Justin: Sorry that’s me. I had to let the cat out of the closet if you heard banging in the background in the last few minutes. In fact, go ahead and put this in the podcast. If you heard banging around in the background for the last couple of minutes, it’s because my cat was trapped in my office closet.

Michael: How far back does your career with LabVIEW go? When did you actually get started and how did you get started?

Justin: I got started with LabVIEW the same way a lot of people do I’ve found, which is that someone handed me with a box with the LabVIEW logo on it and said here figure this out.

Michael: You’ve been listening to Ben’s podcast.

Justin: I’ve had and actually that really resonated with me. Ben if you’re listening, you and I have sort of similar stories that way. I was in graduate school at Iowa State in the Mechatronics and Robotics laboratory there ran by Dr. Greg Luecke. I was actually I teaching assistant for a brand new and I think I have this right, I forget if it was this course or a different but I think it was this one; a brand new mechatronics course that they were rolling out. This would have been fall of either 1998 or 1999 and I was tapped to teach this lab and I was like okay that sounds good you know. What do I have to do? And it was something we were doing for the first time so the lab syllabus was pretty sketchy and not really complete. And we’re going to be doing some data acquisition and control, probably built some PID loops I don’t know write some numbers to a file or something. What are we going to do that with? Well he handed, as I remember he literally handed me the LabVIEW 4 box and said we’re using this and I said what’s this? He said something with the effect of I don’t know but I guess you’re going to have to figure it out.

Ben described in his podcast interview described a stack of you know 25 3 1/2 inch floppies, I actually don’t remember that. Maybe it was already in all of the machines because one of the techs had done it. I forget, but be that as it may, it was either a LabVIEW 4 or 4.1. I had to teach a lab course in it so one of the lab managers who apparently have done a little bit of LaBVIEW and so was sort of known as the guy who knew how to make the wires sat me down for a couple hours and sort of walk me through how to build a VI. I don’t remember a single specific thing that he taught me, nor do I exactly remember what we used LabVIEW for in the class; although, I remember working with some students who didn’t understand the while loop very well so I remembered teaching someone about that.

Michael: The fact that it always iterates at least once.

Justin: Yeah they probably. It might have been that. They probably had their indicators outside the loop or something and then we’re wondering why they didn’t update you know classic problems like that. And so I bumbled and muddled and stumbled through this class and came out of graduate school with a background in control theory. I thought I was going to be a PLC programmer and ended up getting a job with a company in California and later became a National Instruments alliance company that was doing custom automation system for the semiconductor industry particularly gas delivery. The plan was for me to become a PLC programmer but they had a LabVIEW project that needed to be worked on.

Michael: Ouch, PLCs!

Justin: I think all is well and ends well you know. So they hired me because I had a line at the bottom of my resume that said well I have a resume that said PLC, control theory, automation something. By the way LabVIEW, it was down there, it was in a paragraph with like computing proficiencies and it was like Microsoft Office and Math Lab, and Mathematica and Lotus notes and whatever I thought was, whatever program that I had touched that you stuff in your resume in grad school. And one of those was LabVIEW because I had touched LabVIEW at some point so that me an expert as far as someone reading my resume knew. And so they hired me to sort of clean up on this LabVIEW project that they we’re in the middle of and then maybe transition into PLC development and that was followed by another LabVIEW project and another LabVIEW project and another and after a little while, we just gave up looking for PLC projects and became a LabVIEW company. That’s how I ended up doing LabVIEW profesionally in an alliance company after that I consulted independently for a while and now I work for JKI.

Michael: You and I crossed paths as well along the way. This was before you started working for JKI and this is kind of how I met you. The fact that you were working on a project and you had to actually leave the company and do something else and then instead of leaving the customer hanging, you decided to do this transition with the project would be handed to JKI. When we did the handoff meeting, actually I wasn’t there to be fair it was Jim and Philippe from our company so and I guess they were doing the interview and understanding how the code works and they were several questions about you know where’s documentation in the code? What’s your exact response to that?

Justin: I have to say this specific moment that Philippe likes to bring up and anybody who goes to NI week can ask either of us for this story because we both like telling it but I don’t remember it exactly how everyone else does. But what I’m accused of saying is that I don’t comment my code because I think I write it so well that it documents itself. It’s something along those lines and what it amount to basically was I used Unbundle By Name and therefore I don’t need to comment my code. I honestly if I remembered saying that I would admit it, I may have said it. I don’t specifically remember it but that was pretty terrible code to be perfectly honest. Looking back now, that was pretty terrible code and actually maybe this would resonate with people too. That was a very long project. It was a situation which happens to a lot of developers, not just in LabVIEW. But where I was really thrown in over my head and had to make this, had to build this giant, not giant, but very large application, did automated testing of semiconductor gas delivery panels from scratch, and it was by far the largest application I’ve ever done. I was thrown into the deep end all by myself and I had no mentors or anything to sort of give me an architecture. And so you could see if you knew where to look in the code, you could see the evolution of my programming as I sort of dealt with a larger and larger problems like when the project first started I was in that phase of life when I was like in love with global variables and then at some point I discovered that I could build functional globals and so then I stopped using; so part of the program used globals and then a whole other part used functional globals. And then at some point, I discovered references.

Michael: Control references.

Justin: Control references. And so I started rather than using controls and indicators for everything, I started basically doing everything by reference and Michael you’ve seen the code I mean you could attest, I did everything by reference.

Michael: Why not?

Justin: Yeah exactly. Because it’s the classic you know wow this is a very pretty good hammer now everything looks like a nail. There were some other evolutions that took place too, I forget what they were but I used to have four or five phases in my head.

Michael: Well the interesting one was when you had control references inside of functional globals. That was kind of cool.

Justin: Did I do that? I don’t even remember that one.

Michael: I don’t know. I guess it was kind of to reuse the references or something.

Justin: Yeah I’m sure it was clever at that time and I’m sure it solved some local problems.

Michael: But in all honesty, I have to give you credit that that was a pretty complicated application for someone who’s new to LabVIEW because I believe at that time that was kind of, you were still learning and I mean you were still growing as a LabVIEW developer.

Justin: That was my second, no that was my third major project as a LabVIEW developer and it was by far the largest like major is kind of in quotes. It was probably the first truly major project. Everyone's got skeletons in their closet.

Michael: Yeah and that’s the one. But I mean it turned out fine. I mean there’s been some refactoring over the years but just to understand the enormity of the project. It’s just so enormous that we can’t get rid of your old code.

Justin: Exactly. We still haven’t refactored it all the way.

Michael: I know you worked on somehow combining LabVIEW and popcorn with Twitter and I know that sound kind of strange but considering that you created a video that went viral.

Justin: I did. I’m one of those people that has enjoyed 15 minutes of at least minor internet fame in my lifetime. This is a year ago now. A friend of mine and I here in North Carolina discovered an online contest from a gourmet popcorn company in Wisconsin and they were running this contest. Show us your most creative way to pop America’s favorite snack being popcorn and so the way the contest work was you’re supposed to make a video of some creative way to pop popcorn and post it on their Facebook page. And then whoever’s video got the most likes over the course of the contest would win popcorn, right? So my buddy Dave and I were skyping each other and we’re like how are you going to win this and we came up with this idea to pop popcorn using Twitter. Long story short, over the course of really about two days because I was on travel for work and we had trouble getting our schedules linked up and there wasn’t much time to finish the contest. We built a lego, mindstorms-powered robot that ran on LabVIEW and it listens on Twitter for tweets that have the word popcorn in them and everytime it discovers one it pops, it dispenses a little bit of popcorn into an air popper and when the popper’s full, it turns on the air and it pops popcorn. We thought this was pretty cool. We made a little video of it, threw it up on their Facebook page and we ended up winning the contest, which was kind of neat. Not only did we win the contest, the video got picked up by Mashable, one of the big social media networking sites, who else did it get picked up by? Mashable and Engadget. It got picked up by Engadget both on Superbowl Sunday actually. From there it went really big, tweets everywhere with the word popcorn in them. We didn’t do a million views. I think we did over 25,000, which is no slouch. The popcorn company saw a several percent increase in their sales that month that they’d attributed to the video. NI ended up inviting me to setup the machine on the floor at NIWeek in 2010 and to do a presentation about how I built it and how we made it a success and all that. So that was a really cool experience and it sort of continues to this day. People ask me about it. I’m sort of the popcorn guy.

Michael: Yeah so the cool thing about that is it kind of combined several different elements in one. For example, there’s sort of NXT mindstorm element of it. There also the fact that you’re using the JKI State Machine, which is promoting you know one of our toolkits. So there’s Twitter which is another anything with the word Twitter in it is really popular. So you combined all those things into one was I think kind of cool and helps sort of promote JKI and yourself and LabVIEW and a whole bunch of other things.

Justin: Right. It was a good illustration and this is something that I talk about in the presentation I do about it of really the benefit of being active and involved in online communities, for instance, the Twitter code that I used, I didn’t write it, I stole that off LAVA. Someone had posted an example there which was actually an evolution of an example posted on the NI forums by Christian Lowe and so I was able to incorporate that code into my program and within just minutes have the Twitter part working and then because I have the mindstorm set laying around which I won at NIWeek a few years ago, I knew that I’d be able to use that as motor controller and I absolutely i had absolute confidence that I’d be able to control that from LabVIEW so I have these things in my head right away and I knew that I could stitch them together. But the reason I knew that is sort of because I hang out in the forums and talk to people and read threads. So I knew a little bit about mindstorms event though I’m not a professional mindstorms guy and I knew that there were some Twitter codes out there and I knew I had the JKI State Machine templates, which you know it’s a coincidence that I happen to work for JKI. That could have been anybody’s state machine template and so we were able to stitch together really quickly. Make the video, upload it, and sort of get the word out to our friends on Twitter and LAVA and the NI forums, you know e-mail all our parents and grandparents and aunts and uncles and make them go vote for it. And really sort of stoked this network very quickly, which then is part of sort of the larger point that I like to make about how to use social media but more importantly how to sort of build potential in social media so that you can activate it when you need to if that doesn’t sound too exploitive.

Michael: You can call upon the masses.

Justin: Yeah exactly. You can marshall your personal army to go click a like button for you. You know VI Shots probably has that power, right? If you told people to go like something, you know you could probably move the needle.

Michael: Yeah. I don’t know if we have power yet. We have some followers. You know speaking of the JKI State Machine which you know you spoke of that you use it for the popcorn tweets. Why do you think that’s so useful?

Justin: The risk of making this sound of a commercial from JKI, I think quite the JKI State Machine has resonated with people is basically because there is a lack of good templates available sort of in the community for LabVIEW. But I think the thing that really resonates is that it’s a pretty good template. It’s very easy to use. It takes a couple approaches to things like using strings to drive the state machine rather than enums that are a little bit against the grain in terms of how things are traditionally done but turns out to have a lot of good advantages. And I guess I would say that it succeeds because it’s easy for people to try it out. It’s sort of seductive, once you start using it, you’ll find that it actually is kind of fun and easy to use and on top of that it’s free so you know you can feel free to spend you own time inventing your own wheel or you can just use ours for free.

Michael: I think that’s it for this interview. Justin I’d like to thank you for stopping by and visiting our VI Shots studios or actually you’re not in the studios.

Justin: I’m in my office in my home in Cary, North Carolina.

Michael: Again thank you Justin for visiting.

Justin: It has been my pleasure. Thank you.

Part 1 of this video can be found here. It's highly recommended that you watch part 1 before watching this video.

This is part 2 of a 2-part video series where we go into more advanced topics related to using dynamic VIs as parallel asynchronous processes in LabVIEW. Topics covered in this video:

• Using queues to send data to a dynamic process VI
• Using queues to receive data from a process VI
• Using named queues
• Using reentrant VIs as process VIs

Download Code used in this tutorial: (LabVIEW 8.2)

Do you have any questions? Is there something you want to know about in more detail? Leave a comment below, or send your questions to feedback@vishots.com

This is part 1 of a 2-part video series where we go into detail on how to use dynamic VIs as parallel asynchronous processes in LabVIEW. Topics covered in this video:

• Differences between static vs dynamic VIs
• How to build an executable with dynamic VIs
• How to call a dynamic VI
• How to use the Run VI method
• How to pass data to a dynamic VI

Download Code used in this tutorial: (LabVIEW 8.2)

Do you have any questions? Is there something you want to know about in more detail? Leave a comment below, or send your questions to feedback@vishots.com

*Update*

I have gotten an excellent question in the comments in response to this video. It's regarding how to close an idle dynamic VI front panel after it has been aborted. I created a short video response with a possible solution. Check it out here.

The basic idea is that you can check if the front panel is open (FP.Open property) after abort, and if it is, execute the FP.Open property set to False. However there is a caveat to this solution as I describe in the video.

You can find Darren posting on his blog, or writing up a weekly nugget. Here are some other links mentioned in this episode:

• Include LabVIEW Version Number in Application Icon (LabVIEW Feature Suggestion)
• Diagram Cleanup Feedback Group
• Darren's Weekly Nugget 02/08/2010 (16×16 glyphs that ship with LabVIEW)

Show Transcription:

Michael: Hello everyone and welcome to another episode of VIShots. My name is Michael Aivaliotis and this is the podcast devoted to the world of LabVIEW. With each episode I bring you interviews, discussions and share with you ideas for how you can take your LabVIEW development to the next level.

Well, thank you for joining me today for the second episode of the VIShots podcast. Coming up in the show we have an interview that I did with Darren Nattinger of National Instruments. He discusses some of the tips and tricks that he uses to speed up LabVIEW code development. If that interest you then please stick around. But first of all before we get into that I'd like to thank all the listeners so far to this podcast. It's been a difficult start because I wasn't sure if there were any listeners out there. But if you are out there and you like what you're hearing, please leave a comment on the VIShots website for this show. Or even if you don't like what you hear, I want to hear that too.

If you'd like to send an e-mail directly to myself you can send it to feedback@vishots.com. I also like to thank the people who participated on our Facebook page and made the page one of their liked pages. I like to thank you for that. As of this post, we have 107 likes which is just great. Also, since the first episode aired I have put up two LabVIEW tutorials videos which are also available on the VIShots site.

One of the video shows you how to separate compiled code from your VIs. This is a new feature in LabVIEW 2010 and how you can use this effectively to improve your source code control integration with LabVIEW. The other tutorial talks about how to do hardware emulation using LabVIEW classes. This is something that I use almost every day in my projects, so hopefully this will help you in your development.

For those of you that want to listen to the podcast through your iPod or some other electronic device. I like to let you know that the VI Shots podcast are now available on iTunes. You can do go on to iTunes and do a search for VIShots and that should come right up. We’re also available on the Zune podcast network if you have a Zune device. We're also Blackberry users have an application that accesses podcast and we're actually registered on there as well. If you have the Blackberry podcasting application you should be able to find VI Shots on there as well.

One last thing before we get into the interview, I like to apologize for the audio quality especially on my end of the microphone for the interview that you're about to hear. There is some static on my side and that's definitely something I'm working on eliminating for future episodes. If you are annoyed by the static, I apologize and it will be eliminated moving forward.

Having said that, let's get into the interview. So on our show today we have Darren Nattinger from National Instruments. He's a Senior Software Engineer and a Certified LabVIEW Architect. It's actually an honour to have Darren on the show because he's probably one of the fastest LabVIEW programmers I know. He has pretty fast fingers and also I believe Darren you've proven this in a competition at National Instruments at NIWeek correct?

Darren: Yes, for three years in a row I've won the LabVIEW Coding Challenge actually.

Michael: This is not an official tournament type challenge, but it's something that National Instruments puts on every NIWeek. I think you've been the winner every year. You're famous for pushing sort of the productivity and development speed in LabVIEW. You're pretty adamant about coding fast and you've come up with a couple of tips and tricks that you use yourself to be able to code faster. Could you go through some of those with us?

Darren: Sure, so at this year’s NIWeek 2010, I gave a presentation outlining a lot of the daily features and tips that I use programming in LabVIEW. Just things that I use every single day, multiple times a day that I think really helped contribute to increasing my programming speed.

One of those obviously is QuickDrop everybody knows that's my baby in LabVIEW. I believe I've mentioned four in that presentation. QuickDrop was the first, another one is the Auto Tool. I'm a very big fan of letting the Auto Tool choose the right tool for me as I think it's much faster than tabbing between tools manually. Another feature that I use on a daily basis is the New Icon Editor in LabVIEW. In addition to some usability enhancements that it has, like being able to create text based icons very quickly.

One of the things that I really like to use in conjunction with the Icon Editor is most of my VIs in my projects are in libraries and classes. Since my libraries and classes all have a pre-defined banner on the icon of those libraries and classes. When I create new VIs, I already got a banner all I have to do is go in and edit the text and the icon that I need to change. A new VIs icon takes maybe two or three seconds for me to create just because of having those things in place.

Michael: Some people might not know this, the new LabVIEW Icon Editor, do you remember when that was introduced?

Darren: It was in 2009.

Michael: So that has a feature a new feature with layers. How do you use exactly, do you create your own templates, sort of predefined layers?

Darren: When you program — when you use libraries or classes, when you set up an icon for that library, that's the default layer for your icon. So whenever you create a new VI under that library, the library layer has already been applied to that icon. If you're just creating a text based icon for your VI, the library layer is already there and typically that's a banner. Then I just fill in the lines of text on the Icon Text Tab and Icon Editor and then I'm done. I don't have to touch any of the layering stuff because that library has already been applied.

Michael: You also mentioned the Auto Tool — can you explain a little bit more about what you like about the Auto Tool?

Darren: The Auto Tool's actually been around for a long time. Out of the features that I've discussed in NIWeek presentation that was probably the oldest feature. It's been around since LabVIEW 6.1 and I actually learned LabVIEW in version 5.0.

I programmed in multiple versions without the Auto Tool. When it came out the selling point for it was basically the tools that you need to tab through when you're manually tabbing through tools. The operate tool, the positioning tool, the wiring tool, the whole draw of the Auto Tools that as you mouse over certain regions of the diagram that would figure out for you, which one of those tools you wanted to use.

Unfortunately, when the feature first came out, it wasn't very good at guessing. I mean it guessed right some of the time, but certainly not all the time. But I noticed that with each LabVIEW released 7.0, 7.1, 8.0 whatever heuristics we use under the hood to make those decisions got better and better. Now I think it's perfect, I mean the selections that it makes are exactly what I know and what I'm expecting. As a result, my left hand is free to do QuickDrop or control E, control N, just all the keyboard shortcuts that I use without ever having to go over the Tab key to switch between tools.

Michael: Yeah, one thing I find, well I kind of use to it by now, but as a new user using the Auto Tool I think one of the difficulties is on the front panel or sometimes on the diagram, but just selecting an object and moving it. Is a little bit of a challenge because you have to actually position your mouse cursor or mouse pointer I should say, right at the border of the control, right? Because if you push it — if you move it to the inside of the control then it become sort of either text entry or button press or whatever. But if you want to move it like grab it and move it, then you actually have to put it right at the border to select. Select is a little bit of a challenge sometimes.

Darren: I agree for a new user I could definitely see that being an issue. Let's see, I think 6.1 came out about eight years ago and I've been using the Auto Tool ever since then. So I'd know what you are talking about, but my hands are just naturally good to those locations that I know for positioning in particular, to get the Auto Tool to pick the right thing.

Michael: Right, another thing we could mention as well was if you want to select something, you can also sort of click and drag around it. Create like a dotted box and then you will just grab the control as well that way.

Darren: Yes. Oh! One of the things I just thought of to mention about the Auto Tool is when you are having those difficulties, there's a tools option setting that locks the Auto Tool. I actually had that disabled, because on the rare occasion where I do want to manually tab to another tool I don't want LabVIEW to prevent me from doing so.

I have the Auto Tool locked turned off and alt tab tool I need every once in a while. There's a keyboard shortcuts that's if you have tabbed away from the Auto Tool if you press Shift + Tab it will switch back to the Auto Tool. I just wanted to mention that real quick. We do have an out whenever we occasionally do need to move away from using the Auto Tool.

Michael: So what other tips do you have for speeding up your development?

Darren: During my NI Week presentation, as I mentioned there were four essentials that I talked about. Just things that I use every day, the Auto Tool, the New Icon Editor, QuickDrop and then the  other one is Block Diagram Clean-up. That's one that I guess could be viewed a little more controversially, if there was such a thing as controversial LabVIEW topics.

I, for a very long time here in LabVIEW R&D, I guess it's still that way. I really haven't transferred ownership of this, but I actually own the LabVIEW Style Guide that ships in the LabVIEW documentations. For many years, people knew me as the Style Guy. I guess now they know me as the fast programming guy. I've always advocated clean diagrams.

Unfortunately, with my focus moving more towards the speed of LabVIEW development in recent years I noticed that diagram arrangement was a huge bottle neck in my programming. I would spend half of my time writing the code and then another half of my time cleaning it up. I decided to — I guess a little over a year ago, I decided that I was just going to use diagram clean up for everything and see what happens.

I've observed over the past year that there are some VIs that I still naturally arrange myself. Those tend to be VIs that are top level architecture type VIs, like my main state machine or my main cued message handler. I will make sure to arrange those diagrams myself because one of the keys to understanding a top level architecture VI like that is the arrangement of the diagram itself. I don't want diagram clean up just go on crazy on one of those VIs, so I'll still arrange those myself.

I've also noticed the diagrams that have a whole a lot of nesting. Lots of case structures and loops, diagram clean-up tends to explode those diagrams. I tend to not use it on those sub-diagrams as well. The vast majority of the VIs I write fit on one screen, they are internal type VIs that are use within the application that I'm working on. For those Vis, Block Diagram Clean-Up doesn't do a perfect job, but it does a good enough job. I think it does a good enough job that the diagram is still understandable. We made some improvements in LabVIEW 2009 and 2010 in terms of the positioning of comments on the diagram. In LabVIEW 8.6, all comments will just be moved off into one corner, which is basically made the feature useless, because you would document your code and then the documentation will be wiped away somewhere. In 2009 and 2010, we try to preserve that positioning, it's not perfect but it's pretty good. I think its good enough.

Michael: Also in 2010, those are new feature added, but one which I really like is sort of putting comments on wires.

Darren: Yes

Michael: That goes together with the diagram clean-up very well, I think.

Darren: Yes, it does. Yeah commenting your wires, being labelling nodes I think is a good trick. If you've got a section of codes that sort of revolves around a single node or a single structure. Assigning a label to that and using that as your comment is good, because that positioning will always be preserved. Ultimately, I'd say in my current project that I'm working on which has a code base of hundreds of VIs I'd say that probably 90 to 95% of those VIs I've just use diagram clean-up on. I've arrange the other ones myself. It’s just a huge time saver even if it’s not perfect.

Michael: I use diagram clean-up a lot, too. I agree with you it's good in those scenarios. I use state machines a lot and it’s difficult to use it on a state machine. There are some improvements that can be done and we could suggest some.

One thing it kind of annoys me is the way it bends some certain types of wires, like let say you're doing a bundle by name. Let’s say you want to put a constant somewhere and you want to do like a bundle by name from the constant. Then it actually position the constant way out in the middle of nowhere, instead of like right next to the bundle by name for example. It tries to0 strictly too conserve the left to right and then it sacrifices sort of creates a lot of bends in the wires, and puts things away in the middle of nowhere when it could just be place like right next to the object for example.

Darren: I agree. I actually created a group on ni.com/community site called Diagram Clean-up feedback. It's basically place for us to post screen shots, before and after screen shots. Let the developers that work on that feature knows about situations where diagram clean-up is making decisions that it seems like should be much easier to make a better decision.

I'll recommend that you post. I've posted multiple screen shots on there. I'd recommend you post some of yours. Maybe other listeners listening to our discussion here could go there as well. If you just go to ni.com/community and search for a group called diagram clean-up feedback. That's a place where we can post that type of feedback to the diagram clean-up team.

Michael: Great and also in the show notes on the web I’ll put a link to that as well.

Darren: Cool! Yeah, those were my four essentials. Things that I do every day, using the Auto Tool, using Diagram Clean-up, the New Icon Editor and QuickDrop.

Michael: You program in LabVIEW, correct?

Darren: Yes

Michael: Do you do a lot of C development there?

Darren: I have never written a text based program in my life, except for like Pascal in high school.

Michael: You're basically…you're one of us (laughs)?

Darren: Yes I am. I'm one of you I just happen to receive my pay checks from the Nationalist Instruments Corporation.

Michael: Is there…I was always curious about this. Is there sort of the LabVIEW people that you program in G and sort of a C people and like do you guys mingle, and do you have lunch together or do you have like sit in a separate tables and stuff like that?

Darren: Yes, it's nothing like that. I would say that in LabVIEW indeed there's a small member of us that do this type of G programming. I'd say the majority of people are working more on the source code itself. That's actually one of the really, really cool things about having the job that I do. Is that, as suppose to someone maybe in your position where you would need to talk to AEs, have cars filed, try to get those bugs and those features implemented from outside these walls, I can actually just walk over to someone’s desk and discuss with them things that I need to change. That's one of the really just wonderful things about working where I do.

Yeah, but as far as working together, mingling together, of course we do. I mean there are a lot of the C developers in LabVIEW who actually write G features as well.

One good example would be Christina [Rogers], she wrote the “Getting Started Window” which is all in G, but she also owns many of the core source code features as well, so that's and…Then you've got situations like I know you know about this and hope a lot of your listeners too, but Steven Mercer and I worked together to try to get the community to vote up the create sub-VI improvements idea on the idea exchange. Hopefully, we're going to see something along those lines implemented in LabVIEW 2011. But the plan that he and I have for that feature involves some changes to the LabVIEW source code, to allow for a VI to be called to actually perform the create SubVI operation. We've got some C work and G work going together into this one feature.

Yeah, there's definitely lots of inter-mingling and in the case of some features that actually working together on both components of the product, so that we can get stuff implemented.

Michael: When was the first time you sort of experienced LabVIEW and either heard about it or touched it, or worked with it, when was the first time that you did that?

Darren: The very first time was in undergraduate work that I did in college. I went to the University of Texas in Austin, got a Mechanical Engineering degree actually. In one of our Labs, we were taking some temperature measurements and pressure measurements with a very, very old Mac computer that was running LabVIEW three something or four something.

It was actually a pretty bad first experience just because that…and I don't even think it was LabVIEW’s fault. They had such terrible computers in this Lab. It's just terribly old and beat up that I don't think any software would have worked on that computer much less LabVIEW. I didn't really do any programming of it then that was just using pre-written VIs for the Lab. My first experience programming was actually in my first week of employment here at National Instruments. Because I started as an AE and all the AEs get LabVIEW training in their first week. That was my first experience. I actually the first program I wrote, there's this card game that I really like to play called Set. I wrote a LabVIEW version of Set during LabVIEW basics one training. That was my first experience and it was LabVIEW 5.01 was the version that we used at that time.

Michael: Well, that's interesting that the first program would be a game (laughing), considering that I believe that you are an avid gamer.

Darren: I do play a lot of board games, and card games, and video games and yes just about any games I can get my hands on.

Michael: Do you think that some of your experience from gaming, being very fast. I know you're a good guitar hero player (laughs) and that of everything kind of influenced you to speed up your LabVIEW development as well?

Darren: Yeah, I mean there are a lot of games that I like. Like chess, but a lot of people are much better than me at because they can do that really deep critical thinking that I'm not so good at, as I am the speed type games.

The game I just describe to you Set, the card game that I wrote a LabVIEW version for, it’s a very fast pace speed oriented game. Yeah, just over the years in LabVIEW you have noticed that there's things that could make me program faster. Things that are bottle-necking me. Back in LabVIEW 8.5 I'd noticed that the palettes were big bottle neck and that's why I prototyped QuickDrop. After that I noticed that arranging my diagram was a bottle neck, so I started using a diagram clean-up. I guess it really has been the focus of my LabVIEW programming here over the past couple of years, is just how fast I can get things done. Following the process, of course, I never neglect to write my specification documents or create my auto test for my features. The actual programming of the feature I try to make. I try to find how fast I can get it done, just because LabVIEW is such an intuitive environment. That I think you and I talked about this one time it comes down to those little repetitive tasks. Those things that you have to do, they're part of your programming that it seems like there's ways to make them faster.

Michael: Is there something that's on your mind right now, that it's kind of a bottle neck that you wish that could be fixed or some way improve in the future?

Darren: We're working on that create sub-VI thing that improvements to that, that's definitely a big one. Not much is coming to mind, I've got some ideas up there. One of which is (laughs) this one is not necessary a lacking feature, but one of the limits to QuickDrop is that it has to load the whole palette set. Loading the whole palette set can often take a long time.

Actually I have an idea up there. It's for us to find a way to eliminate that initial delay for loading the palette set. Another one of my ideas, not really a speed based idea. I know you guys are just like me you all will do develop them in multiple lively versions. The fact that all the icons of all my LabVIEWs look exactly the same on my Window's taskbar is really annoying. That's another one of my ideas, that's probably the one that I've submitted that has the highest number of votes is putting a little version of the number on the LabVIEW icon in the taskbar. I think that would just…not necessary speed me up, but reduce my frustration when I've got four-five LabVIEWs running. And I have to go guess which one is LabVIEW 2009, which one is LabVIEW 8.2 et cetera.

Michael: Do you do that often? Do you have like multiple LabVIEW versions up?

Darren: Yeah actually I do, I mean we LabVIEW 2010 came out in August. The project I'm currently working on, we didn't switch to the 2010 code based until a month, six weeks afterwards. I was still doing 2009 development for that project. But then for all the little LabVIEW features that I own, and I do own a lot of little features in LabVIEW. The fix bugs on that and stuff I would want to use the latest release version which is 2010. I would be using 2010 for those type of bug fixes and then 2009 for my main development. Yes, so that's certainly does happen.

Michael: I know you also have a regular feature somewhere on the ni.com forums which is “Darren's Weekly Nugget”. Can you explain exactly what that is?

Darren: Yes, so every Monday, hopefully, occasionally I don't get 'til Tuesday, but every Monday I just post some tip on the NI forums, just some little titbits of information that I come across in LabVIEW, that I think would be helpful to users.

Whenever there's a new LabVIEW release I like to talk about new features in LabVIEW that I think are going to be helpful.

I started doing the Weekly Nuggets back in 2006 and I did them for a whole year. Then in 2007, I started to take a break because it's actually hard to come up with a brand new tip to discuss once a week for a whole year. I did occasional Nuggets in 2007 and 2008.

In 2009, I was asked to start up the Weekly Nuggets again. For 2009 and all of 2010, I've been doing them weekly. Looks like I have written 152 Nuggets over the past I guess four or five years. Yeah, the ones I've have been writing lately have had to do with LabVIEW 2010 features that I think were really cool. If any of your listeners want to see links to every single one of those 152 nuggets I've ever written. All you have to do is go to ni.com/community and search for Darren's Nuggets. The first link that comes up is a page that has a link to every single Nugget that I have ever written.

Michael: Cool! Can you tell us maybe pick one of those Nuggets?

Darren: Sure! One of the ones I wrote, this one really surprise me, I wrote this one back in February. It has the second highest rating, in terms of number of kudos that it received on the forums. Has the second highest rating of any Nugget that I've ever written. This is Darren's Weekly Nugget from February 8, 2010.

On that webpage I just mentioned, you could just scroll down and click the link for that. Basically, I mentioned in that Nugget that there is a folder under the LabVIEW directory that contains a huge collection of 16 x 16 images that are frequently used within dialogues. Like pictures of folders, pictures of VIs, lots of file icons, icons for things you might see in the project Window. Like a little My Computer icon or a little FPGA target icon.

Little images of those, for those icons– there's dozens of them in this one folder. I just mentioned that in a Nugget because I figured well I use pictures that are in there once in a while so many other people might want to use those, too. I was just amazed how many people thought that was just the best tip they'd ever heard of. That's one kind of interesting to talk about.

Michael: Okay, well I guess I just learned something too, because I wasn't aware of that (laughs). Yeah, I mean I don't follow your Nuggets on a weekly basis. I might have missed a few. That was definitely the one I've missed. It’s showing icon– actually these are used in the project as well, right? The project dialogue?

Darren: Yes, the Project Windows uses those exact glyphs. Yeah, there's actually multiple ways to sort of be notified about my Nuggets. One way is to subscribe to the feed for this page itself whenever changes are made to it. Better way I think is that I have a blog on the NI Community site, but all it is, is links to the nuggets so every week that blog is updated with the link to that Week's Nugget. I think most people subscribe to my Nuggets that way. You just set up an RSS feed for that blog on NI Community site.

Michael: Thank you again for coming on the show. I think we're going to have you back in the future.

Darren: Excellent! Thanks for having me.

Michael: We'll have maybe a special Darren's Nuggets segment of the show (laughs).

Darren: That sounds great!

Michael: Well, Thank you very much and also just before you leave. Can you tell us what your blog web URL is so people can visit that?

Darren: Yes, I have a blog called LabVIEW Artisan and on that blog it’s not really so much a Nugget type material as it is. It gets more abstract discussion about LabVIEW features or LabVIEW sort of musing on LabVIEW programming. It's not really in specific tips or anything. That blog is labviewartisan.blogspot.com.

Michael: Well, thank you and that's it.

Darren: Thanks!

When writing a LabVIEW application that communicates with hardware. There are times when you need to have the code functional even though you don’t actually have the hardware in-hand. This could be because of time constraints. For example, parallel software development must happen while the instrument is being shipped or back-ordered. Or you’re presenting the software at a trade-show and you need a working demo without having to carry all the hardware around. In any case, you have to figure out a way to develop your application and work around this problem.

By designing your software around the use of LabVIEW classes, you can easily include hardware emulation capabilities from the start. In this video, I share a way that you can use LabVIEW classes to help you solve this problem.

Download: Code used in this tutorial (LabVIEW 2009)

Do you have any questions? Is there something you want to know about in more detail? Leave a comment below, or send your questions to feedback@vishots.com

By default, LabVIEW stores compiled code together with the VI file. This is something transparent to us and we don't pay much attention to it. However, this can cause problems which appear when editing your VI. Sometimes when we edit a single VI, we notice that a number of other VIs require saving. Even though we haven't changed them directly. This is especially painful when trying to keep things in order with source code control.

In this video tutorial, I go through the new feature in LabVIEW 2010 which allows you to separate compiled code from your VIs. This allows you to avoid the problem of propagating changes.

Download: Code used in this tutorial (LabVIEW 2010)

Have you started using this new feature? Let me know in the comments.

*Update*

I have some additional information that I learned after making this video. Thanks to Danny for commenting which prompted me to do some more research:

• Any diagram that contains a ExpressVI or a Statechart VI cannot separate source and object code due to how LabVIEW embeds those subVIs inside their caller. Also a PolyVI can't be marked, because it doesn't really have a diagram (although an instance of a PolyVI can be).
• The term now used to describe a VI that does not have its compiled code separated, is: “uni-file”
• At the end of the video, I describe a caveat. To clarify this a bit more. What this basically means is that in order to do dynamic loading of VIs from the LabVIEW Run-Time engine, (as is the case in built executables which call VIs) you must not separate compiled code from VIs. In other words, you must create uni-files.
• In the video, I show how to turn this on for a VI or even the contents of a Project file, but there is a way to enable this feature by default so that any and all new VIs are saved as “source-only” VIs.  This can be done using an ini token: SourceOnlyEnvironment=True. As with any “secret” ini token, it's not supported and it's considered experimental.  One side affect to be wary of is that you cannot create a normal “uni-file” with this setting enabled (the VI Property setting is ignored), which is required for dynamically loaded VIs.

In this (our first!) episode of the VI Shots podcast, we chat with Ben Zimmer of Enable training and Consulting.

We discuss how he started using LabVIEW and how he’s built a growing business around providing training materials. He also talks about his interesting journey as a mentor to FIRST robotics teams and how that has crossed paths with his business interests. We also get some tips on the best way to learn LabVIEW.

Show Transcription:

Michael: Hello everyone and welcome to this episode of VI Shots. My name is Michael Aivaliotis and this podcast is devoted to the world of LabVIEW. With each episode, I'll bring you interviews, discussions and share with you ideas for how you can take your LabVIEW development to the next level. In this first episode of VI Shots, I invited Ben Zimmer of Enable Training and Consulting to discuss how he started using LabVIEW and how he's built a growing business around providing training materials. He also talks about his interesting journey as a mentor to FIRST Robotics teams and how that has crossed paths with his business interests.  Ben, welcome to VI Shots podcast.

Ben: Thank you for having me on, Michael.

Michael: I'd like to start by asking you how long have you’ve been working with LabVIEW and perhaps take us through your career journey.

Ben: I've been a LabVIEW programmer since 1994 and that's so long that I actually forget what version it is. I know everyone wears that like a badge of honor. It was definitely pre undo, probably version four. I have basically just been a LabVIEW programmer for my entire professional career which has been a very interesting path which took me through a few different jobs, a few different industries and ultimately, had me settling in the path which brought me to create and found Enable Training and Consulting in 2006. The path which brought me to ultimately founding that company was kind of reflected in some of the troubles that were starting to be prevalent in the automation industry, particularly in automotive. At the time, I was working for a great company called Meikle Automation in Kitchener, Ontario. Actually, with one of your former colleagues, he was someone who hired me away from my previous job.

Michael: I think it's okay to mention his name.

Ben: It is? Okay. He's not going to hunt either of us down. Actually, Meikle Automation is no longer called Meikle Automation. That was Dean Mills and I remember Dean was a customer of mine. He was a beta tester for a product that I was releasing at obviously the previous company I was working for. Long story short, it was a very customized rs232 ethernet adapter for a device that this company was manufacturing.

I was working as a reliability engineer so I was doing awful lot of LabVIEW programming, testing, data analysis, that kind of stuff.  Dean being a beta tester for us, he found lots and lots of problems with our codes and really interesting problems and this was back in 2000, 2001-ish.

I remember at one point, going to visit Dean at Meikle Automation and seeing what they are working on which was some very, very high end PC based test equipment, back then, doing serious integration with robotics and photonics and instrumentation with very, very high rates of data collection and very, very high accuracies. It was not an easy problem to solve. Certainly there was no, to speak of no real time tools from National Instruments, no hardware, software and I remember seeing what Dean was working on and saying to my boss, “see what you can do with LabVIEW?”. Dean told me later, that was the moment he decided to try and hire me. My career’s been like that. It's been a lot of, hey, “see what you can do with LabVIEW” and taking it to the next step.

Starting to work with Dean and the rest of the team at Meikle Automation was a tremendously challenging, technically challenging, and really rewarding part of my career. I think I was there for about four years and we did a lot of things that were typically quite difficult to do in LabVIEW particularly then such as doing PC based control of 16 simultaneous pulses, collecting data at 10KHz operating  independently and again, this is with no real time hardware or software. Finding some of these black art approaches to collecting data in one place and dealing with it somewhere else in your LabVIEW code all on one computer which at that time was a Pentium 4, 1 GB, 1.6 GB, something like that.

Michael: Do you remember the precise moment or exactly the first time you ever were exposed to LabVIEW?

Ben: Absolutely. I was in my second year of university. I got a summer job which was partial scholarship/partial employment where you work at an industrial employer and you're partially sponsored by the government to do so. On my desk was dropped, over 25 3 ½ inch floppy disk which had this LabVIEW logo on the front of them. I was told essentially, “the guy before you made me buy this. Figure it out.” The next step was to sequentially insert 25 or so 3 ½ inch floppies onto a Windows 3.1 machine and solve this “LabVIEW thing” as it was referred to many times over the course of that summer and start writing software to control some very specialized instruments that this company was making. These were fiber-optic interferometers and for a long story short, it was a lot of DAQ and a lot of really weird signal analysis.

Michael: Was this back in '94?

Ben: Yes. This is '94. Now that you know, you can calculate backwards and see how old I am when I got my first degree. I think the best lesson I ever got in signal analysis was that summer. It wasn't a helpful lesson but it was a very motivating one. My boss who was a very successful small business owner, he was a brilliant scientist-engineer and he was a tinkerer. He had been making these instrumentation, these fiber-optic instrumentation devices for years and years and years. He would hang a scope on a signal, look at it on the scope and this is on a real scope, not part of this LabVIEW thing, point at some feature that popped up when he did something which quite often involved standing on your left foot and jumping while rotating, while rubbing your head and very, very hard to generate and just saying, “hey, I saw that with my eye, you dig it out in software”.

I had to learn to do that and I didn't have any training. I was a second year student with a little bit of math. I had never done any programming. I was using this LabVIEW thing to do what he says, “I can see this with my eyes so you do it with the software”. I learned to do that. I don't think I got a better lesson in Calculus, a better lesson in things like differential equations, a better lesson in Statistics than having to figure them out for yourself while clicking around on these palettes and trying to find out what the heck function is going to allow me to see that thing which I see with my eye. It was very cool.

I think that experience is probably the best definition I can give on why LabVIEW is such a powerful tool. Because here I was a kid, with no programming training, trying to solve a problem. I had some good problem solving skills and some good analytical skills and I was able given just those barebones tools to write software that I just simply couldn't have done if I was given C or Basic or Excel. That was the moment where I realized that programming should be problem solving. Later on, in third and fourth year, when I took some more programming courses and it became all about dimensioning arrays and handles and pointers and all this stuff, I found myself quite often scratching my head saying, I just want to solve a problem.

Michael: When we last left your journey through LabVIEW, it was at Meikle Automation. How did that transition from Meikle, and then was there somewhere in between or did you decide, let's the start a company here?

Ben: It's been of an interesting story. It involves you, Michael, because I think as I describe that job at Meikle and the work we were doing and the work they continued to do after I left, it was really cutting edge, really challenging. I talked about some of the high level things that it achieved but behind all that was some really, really big code. When I left, it was well over 2,500 VIs and I'm sure it continues to grow but some very, very flexible code, lot of embedded intellectual property. I'm not going to say anymore. You can probably find out all that you want by Googling the Meikle Automation software suite.

My problem was never with technical side. My problem was with the business side was that really automation at that time and a lot of our customers at that time were automotive. It was very competitive, very, very difficult environment. I worked a lot of hours and realized that that wasn't really the path I wanted to follow, ironically, because I’m not working as many hours as I was then. One of the things that I realized and very much most of the business relationships with your clients were a bit adversarial because there were such little profit margins and the automotive industry was in the process of really tanking. That's a long answer to a short fact that I just needed to move on to something where I felt the relationship with my clients is a little different. I had an opportunity to go teach at a college in Toronto because someone I knew who was teaching a class there was moving to California.

Michael: That would be me.

Ben: That would have been you. I saw that as a great opportunity to change the past pretty drastically. I took a 70% pay cut to go teach. What was interesting was, the reason I was able to do that actually is it's more than just a LabVIEW class, because of the background I had and the other teaching experience I had and the Master's degree that I got somewhere along the way. I was able to drop in as a part time faculty and teach more than just a LabVIEW course. I was there teaching digital electronics, analog electronics, analog digital interfacing, digital logic, a lot of fun stuff like that. They had a need for that so I came in as a part time teacher and doing more than just the LabVIEW class.

Michael: When I was doing the LabVIEW class, one thing that was really rewarding was to see the students learning LabVIEW and making the connection between the physical property that they want to measure and the data on the screen and sort of merging that up. I always found you could see the light bulb go off in their heads say, oh, okay.

Ben: For sure. It's very much the case in colleges and universities that even amongst the lab work that they do, very often there's a disconnect for the students between what they're told to do in their lab and what they're doing in their theory and what they're doing in their lab reports and any view of how this is applicable in the real world. When you are measuring a temperature and you are dropping that thermistor into frozen water that you just run outside to get snow and put it in a styrofoam cup. That drives the point home quite well. I was pleased because I got to say, hey, I can see that with my eye. You dig it out with software. It was that to turn that around.

To come back around to how that led to starting my company, all the professors went on strike three weeks later. Here I was taking a big pay cut, taking a drastic change. We actually moved a little closer to Toronto from where we were living, very close to Kitchener and then we were on strike which I found quite entertaining. That gave me an opportunity to chase up some of the contacts that I had made over the many years and follow up on doing some side programming. Actually, ironically enough, one of my large clients at that time and the one which … the work was enough for me just fractionally creating a company rather than just doing it and getting a check for it. The other position you vacated when you went to … wow, Michael, I didn't realize how much I owed my career to you.

Michael: Is there a theme going on here?

Ben: This is really funny. I hadn't thought about this since so long and here I am thinking, I wonder what’re going to talk about in this podcast and I didn't realize it's really just about us the whole time. Having picked up a couple of clients and doing enough work to justify actually creating a company, I became a LabVIEW consultant and a LabVIEW contract programmer and certainly I had been doing that for a long time.

Anyways, and strangely enough the work that I was doing, not strangely enough, not at all surprisingly, the really high end work that we were doing at Mickle prepared me really, really well for facing any problem and being able to walk in there in any situation and say, yes, I’ve done something similar to that. I understand where the pitfalls would be there and be able to really carefully assess the risk in various projects.

The other benefit was, towards the last year and a half or so that I was at Meikle, I was able to do a lot of quoting and a lot of project management. I had honed those skills. I was under someone else's payroll which is always a nice way to get started as a consultant because certainly quoting, and anyone who started off their business in this kind of industry will probably agree with this that one bad quote will kill you. Quoting was something that I was very pleased that I had the skills to be able to do it and that allowed me to be busy and somewhat profitable.

Michael: It seems from what I see on your website that you do a lot of basic LabVIEW training. You're still focused in the education side of things as far as LabVIEW is concerned.

Ben: Oh, for sure. It was no accident that we named the company Enable Training and Consulting. It was my goal right from the start, frankly to avoid the kind of business relationships I saw within the automotive industry as an example and really didn't want to get into that kind of situation where you're on a floor trying to get signed off or you get a call at two o'clock in the morning on a Sunday because a line has stopped making parts.

I made a vow to myself and to my wife that that wasn't going to be my life anymore. My goal was really fundamentally to help people learn LabVIEW and provide programming services, to always provide source code which was the goal from the beginning. I think it's probably still 100% true on our projects to always provide source code, to try as a very high level mission statement, to try and leave the customer self-sufficient so they never have to call me again. Ironically enough, that always meant that they called me again but it was for the next project.

I spent a lot of time training people, doing LabVIEW training sessions for people who needed an in-house trainer in various situations for whatever reason they did not want to or could not physically get to one of the LabVIEW basics, one. Two, intermediate course stream, they wanted something very tailored and did several of those.

At the same time, had very many situations and client relationships where I would be sitting beside the engineer who essentially was my customer, teaching him or her LabVIEW and also writing their software at the same time. I found myself explaining state machines and producer-consumer loops and tight desks and clusters, explaining that stuff over and over and over again and kind of had the realization that the value ad that I was providing wasn't necessarily in giving that training life. It was really in providing the mentorship and the personalization and wrapping what all those lessons were around their project needs. It was a very natural progression to take the teaching skills and the educational background I had, take the LabVIEW experience I have, take the LabVIEW teaching experience I have and just wrap it all up and create some self-paced online training.

Michael: Yes. You've created another website which I guess is somehow connected to your main site called LVMastery.com?

Ben: That's right. LVMastery.com was the site we launched at the beginning of 2008 which essentially has three full courses approximately one week of learning time for each of them. It's about three weeks worth of training on there. Starting at absolutely zero LabVIEW understanding and ending up on what I think are the fundamental structures to make you able to create easily debuggable, easily scalable modular codes. Things like state machines and multiple loop, parallel loop architectures and producer-consumer templates and all those things, since 2008, have started to be much more widely included in the various training products that are out there but I took it upon myself to create a curriculum which hold the way I thought and the way I learned LabVIEW and the way I wanted the people who were working with me or who were learning from scratch to learn LabVIEW.

Michael: You've expanded that actually, you have quite a bit of content, do you have like FRC, Mastery?

Ben: Yes.

Michael: Can you explain the other material?

Ben: Yes, sure, absolutely. LV Mastery turned into a whole bunch of course material. The path which led to some of these other stuff really all centers around FIRST Robotics, as I’m sure many of the people who are listening to this know that FIRST Robotics is a robotics competition aimed at high school kids which recently, that was two seasons ago, became very much centered around national instruments hardware and software. What happened was, as a part of ..–

Michael: Part of it is the cRIO, right?

Ben: Yes, exactly, there's a cRIO at the heart and LabVIEW is used to program it although there are other programming options for teams if they wish. They can use Java, they can use C++. Of course, LabVIEW is the best choice for a whole bunch of reasons. I can say that with a straight face because I do believe it.

What happened was with the LV Mastery course, the website that we created, part of that was bunch of continuing and free videos. We had a video blog section on that site. It's still there, called the tip jar. On the tip jar, we would create a 15- to 20-minute video tutorial. The goal was to do it every couple of weeks but as time went on, the pace of it changed and got refocused. Here I had a website I had experience creating, video-based training material and FIRST Robotics starts out. There's a brand new control system which is the cRIO and there's a brand new software platform which is LabVIEW, brand new for all these teams and there are thousands of teams across North America.

I heard about this at NIWeek of course. I thought, wow, that’s so cool, and dug up, found a team relatively local where I could be a mentor. I advised everybody, just a little aside here, it sales pitch from which I served to gain nothing. Go to usfirst.org, click on FRC and then click on Get Involved and become a mentor for an FRC team because it’s awesome.

Anyway, the FRC team that I found and hooked up with, they were terrified of this new control system because they just barely got the last … actually, they did quite did well the previous year but they’ve got this new complete system so they can’t reuse their code. Every team is in the same situation. Because I hooked up with them and I got to play with the control system that they got, I was able to bring it home for the weekend and basically make everything move, understand the framework because you don’t just get a blank VI you start with. There is a very specific framework which you’re obligated by the rules to stay within which is actually very important and a good thing.

I was able to figure how to make this thing go. I was able to get the team started. Yes, this is great. I had a situation where I got to go with a couple of the local National Instruments sales rep to meet with a whole bunch of teachers and mentors for FIRST Robotics in Toronto. The NI sales reps who had a real disadvantage because they thought they were just there to do a regular, getting started three-hour LabVIEW thing and you had this room full of teachers who all about their robot kids saying, “Hey, how do I make this thing work?” because I was there and I had just played with it, I offered to do an ad hoc little session and showed them how to get one of them working because one of the teams had their robot there.

That was a very successful, completely off the cuff two-hour session. I was asked to come back and do that for a whole bunch more students and teachers. We videotaped it. Because I had the mechanism upon lvmastery.com to put that up on the tip jar, we did so. It just kind of went from there that we continued to make videos, video tutorials for FIRST Robotics, for FRC and throw them up on the tip jar.

Michael: Those FRC videos actually are totally free right?

Ben: That’s correct. 100% free and they always were and they always will be. It’s hard enough to fund raise to become part of … to get a team going for FRC. You don’t need to have to pay to watch those video tutorials.

Michael: Actually, just before I got on the air with you, I actually went in and checked out some of the tip jar videos. I was looking at the last one, number 18 or it says everything so far. I believe you had code from team 843. Is that the team that you were mentoring?

Ben: Wild oaks, in Oakville, Ontario. Go Wildcats. That’s right. We’re obligated to say that.

Michael: Was this code that the actual students wrote or is it something you … how much involvement did you have with sort of the writing of this code?

Ben: A fair bit, certainly. There was one student in particular and that’s the code from, actually from two years ago. There’s one student in particular who was the most brilliant natural programmer I’ve yet to meet. He actually did a tremendous amount of it. We worked on it together and we had a lot of integrative design changes. A lot of things didn’t work and we had to figure things out because there really weren’t any other resources out there. I’m not going to pretend that I didn’t have quite a hand in the way that structure went.

What was impressive to me in that process of working with some of these students who were 14 through 17 was, it didn’t take that much for them to really get it. When we’re talking about things like using functional globals and multiple differently prioritized loops, one to do a PID, one to do the actual low level control for the motor speed using a P Diagram output and then the second loop or any other slower rate to change your set point, all of which are communicating the functional global variables to the main VI. The level of complexity that you can get to within the FRC framework, I think you can blow away a lot of, probably seasoned LabVIEW professionals who may not have seen or had to do what a lot of these kids are doing day in day out on these teams.

Michael: The cRIO environment is actually very interesting and perhaps we should dedicate like a whole show just to that. There’s a lot of components on there that are worth talking about. One thing that I noticed in the code was the use of global variables. I know that when you’re programming on the cRIO environment, there are some limitations of things you can do. Does a choice of global … the usage of such global variables, was this specific to this used case or is this … how did that come about? Because we all know as LabVIEW programmers that globals are evil, right?

Ben: For sure. I struggled a lot and I think I’ve had some heated conversations with Greg McKascall and some other people about the way the framework is structured and there are advantages and disadvantages that have a particular relevance when you need it to be used by 16-year-olds. There’s a lot of things that are in that framework that … I’m not going to go into details that make it kind of difficult to do what we as seasoned LabVIEW programmers would like to do.

The reason for that is, it’s got to be able to just work and it’s got to be easily modifiable. In fact, the code tour that I provided in and the modifications that I, or the approaches that I suggested were in some ways quite complicated. I will defend the global variable usage in that application. If you watch some of the other Tip Jars, there’s some very, very careful discussions about global variables and race conditions are discussed very, very carefully.

The way global variables are used, there are only two places where the global variable can be written to. They can be read in many places and that is very strictly controlled and very clearly pointed out to the students. I would love to talk through that code with people because it’s been … with all due respect to the rest of the team 843, the robot that year did not live up to the software. We had this amazing … we had four different PID loops controlling motor speed. We can do all kinds of great stuff with the software. The robots, they just didn’t work that good. In the end, almost all of these cool software features got disabled.

Michael: That is the challenge of the first competition as what team can sort of pull together all the different elements in order to a cohesive working robot because there’s not just software, there’s the mechanical, there’s organizing and all that stuff.

Ben: Absolutely. There’s a time crunch. You only have six weeks to do this. You don’t know when the game is going to be until January. You’ve got basically six or seven weeks to get into a shipping crate or you’ve blown your budget. You don’t get to go on to the competition.

Michael: Are you still involved in mentoring at this point?

Ben: Very much so. Back into the main discussion, you completely diverted me with global variables and functional globals and fun stuff like that but I made all these videos. They were watched a lot. I think I did a calculation and we gave away in that first year, 25,000 person hours of LabVIEW training just for those tip jar videos because they were long. They were long detailed videos and they were watched thousands and thousands of times.

What happened was, I got an interesting call from the product manager at National Instruments. Stephanie who was in that position at the time, because she said she kept going to competitions and so on, and getting thanked for the awesome Tip Jar videos.

She said, “What the heck are these Tip Jar?” She eventually realized and then contacted me and to thank me saying basically, “You know, we being National Instruments are donating this material and giving it, either donating it or giving in at such a low cost. The teams can buy a complete cRIO with LabVIEW software for $750 to buy second device. It’s a part of their $7,000 kit or $5,000 kit which includes all kinds of stuff. We know what that stuff is worth for industrial customers. It’s not a tremendous discount but it’s being provided to the teams through FIRST.

Stephanie made it clear. Unfortunately, there just wasn’t a huge budget left for creating tutorials and training and other support resources. Although NI has great phone text support during the season, they just didn’t have the bandwidth to do what we were already doing. That led to a great relationship and working together and making sure that what we were doing jived with what NI was planning. That really got us turning the corner in the direction that Enable Training & consulting was going and allowed us to kind of reach out in a different way into this robotics ecosystem. It led to making LEGO education training material for the MindStorms-based FIRST competition, the FTC competition.

We have another website called FTC mastery, where there’s a bunch of material given away for free. For a modest fee, you can also upgrade and watch the tutorial videos in addition to the basic content. That has been very much where our business has been … one of the major areas that our business has been growing in over the last two years has been becoming almost an OEM provider of training material for other companies. The skill set that we have, that we demonstrated and really sharpened creating the LV mastery material and the Tip Jars, has led us into the realm of being not just LabVIEW integrators but also people who can create training material for you. That’s been a very rewarding side of the business because it really meets that initial goal I had of never being called at two in the morning and feeling like I’m working on really rewarding projects. When you’re working on stuff that’s going into elementary schools or we’ve got to play with the LEGO WeDo product which is a very, very cool thing. That could be another discussion all on itself.

Work with material for kids in grades two and three, all the way up to university level stuff. We have been creating a lot. We’ve been very busy and really generating a tremendous amount of growth around being technical experts who are also educational experts. For example on staff now, I’ve got two teachers, full-time, just working on curriculum resources. I’ve now got a full-time graphic designer in addition to a whole bunch of LabVIEW people.

Two years ago, when we were creating the Tip Jar videos… I keep using the word ‘we’ but it was just me. It was really just me until about two years ago. All of this has kind of been hand in hand. That as our capability grew, we’ve been getting a lot more work on the consulting side, on the contract programming side. Now we’re at 15 people, we’re moving out of our 823 sq. ft. office in a week and a half into a 3,000 sq. ft. office which means that we each get more than 60 sq. ft. which is really nice.

Michael: I’d like to just close with maybe one last question. With all your knowledge on LabVIEW and training, what would you say would be the best way or maybe a tip for those who want to learn LabVIEW don’t know what LabVIEW is, they just want to get started.

Ben: I’ve often felt and I’m going to try and say this in such a way that it’s not a cheesy sales pitch because there are all kinds of resources out there. There are a lot of YouTube videos now. My feeling is always been that the magic bullet to training is self-paced video plus mentorship. That mentorship can take a lot of forms. It can be forums like the LAVA Forum, like ni.com Forums.

I’m a big believer that you can’t learn by watching, you can only learn by doing and that every time I teach a course or create material, it drives that home. You really need to be able to exercise the skills as you’re learning them. I’m not a huge fan of a setting where you’re just following a bunch of steps and not understanding the big picture context.

My preference is that you get to watch either an expert present material, whether it’s in a video or in a classroom setting and then you are then able to flex those muscles and solve problems right away. But It has to be tied back together with the ability to ask someone questions right way. That’s why I think like the work that you’ve done, Michael, like all over the past several years, bringing LAVA to the critical mass that it reached now. The changes that NI has made to their … that there would be ni.com forums and info-LabVIEW if you’re an old timer LabVIEW guy like me. Being able to ask those questions and get almost real time answers while you’re flexing the muscles that you’re growing, I think that’s the magic bullet for training.

My advice to anyone who’s learning LabVIEW for the first time is to do three things. One, find some sort of course, find some sort of step-by-step curriculum that will make sure that you don’t jump over any of the very fundamental things. How many times I’ve met people who never learned that there’s a bundle by name in there beside the bundle. Something that fundamentally will show you the materials and there’s lots of great textbooks out there and Jim Kring's is also a great place to start.

Start with something like that then supplement it by going through the example finder trying to figure these darn things out especially some of the really esoteric ones. Search for X, Y chart. No. X, Y graph. If you look at the X, Y graph example, I love that one as a teaching tool. If you can figure that out, you’re a good LabVIEW programmer. Thirdly, find someone or a place where you can ask your questions and get them answered.

Michael: Remember when I was learning, I didn’t have that.

Ben: Neither did I.

Michael: The one thing that I stumbled on which was kind of silly now, thinking back was, in the early releases of LabVIEW, when I started to way back in 3.0. They only had a true Boolean constant. They didn’t have the false in the pallets. So I would put down a TRUE …

Ben: Then put a NOT down.

Michael: Right. I didn’t know how to put a FALSE. I would see a FALSE in an example then I would copy it from an NI example, and I would put it down or something like that. So then I went to this seminar and the only question I wanted to ask was, “How do I get a FALSE Boolean constant?” Once I got this, “Oh I can actually toggle that?” Something as simple as that could hold you back and it’s like, “How do I get over this hurdle?”

Ben: I think that the fact that there are so many resources out there now and then there have been for five or seven years, really, really good resources. Makes it a different kind of world.

Michael: Ben, I’d like to thank you for joining me today on this episode. Hopefully, we’ll have you back.

Ben: My pleasure. I hope to.

Michael: Thanks a lot.

Ben: My pleasure. Have a good one!

In this video from RoboBusiness 2008, we interview Steven from Powercast who shows off some cool wireless power technology.

From the Powercast website:

Founded in 2003, Powercast developed a receiver module with breakthrough efficiency levels. Coupled with a transmitter that sends RF energy using algorithms developed by Powercast, the Powercast Wireless Power Platform was born. While the concept of sending power “through the air” has been discussed for more than 100 years, Powercast is the first company to make it commercially viable. Powercast is now leading the cross-industry initiative to bring wireless power to a hundreds of low power devices.

A video from NIWeek 2008. Benjamin Cook really had fun building this electric guitar effects system based around NI hardware and LabVIEW.

This is a wireless audio processing project. A 550 MHz transmitter transmits FM modulated data to a 5600 down converter. It down converts the data to 25MHz. That gets sent to a 5640R IF-RIO card. The IF-RIO card has an FPGA. That's where all the demodulation and audio processing happens which then gets sent out the sound card. You get very low latency audio response.

The big announcement this year at the FIRST robotics finals in Atlanta was the new robot controller from National Instruments. This new controller called cRIO runs a real-time OS and can be programmed using LabVIEW. The power of this new technology will open the door for new and more interesting challenges for future FIRST competitions.One area that is underdeveloped in the FRC category of the competition is the autonomous mode. This is in contrast to FLL which is mostly autonomous. Hopefully we will see some interesting games ahead.

In this video VI Shots interviews Ray Almgren who leads the worldwide academic relations program for National Instruments. We also interview several mentors and students to get their feedback on this change in direction for next years competition. Teams 2023, 1739, 47, 107 and 2053 are featured.

Boston Engineering decided to demonstrate their FlexStack product by attaching it to an iRobot Create programmable robot, have it scan RFID tags and then make it do several dances. FlexStack is powered by LabVIEW Embedded. Take a look at this original VI Shots video.

Roving VI Shots corespondent and LAVA member Justin Goeres participated in the “buy one get one” program that the OLPC foundation announced last year. This is where you spend $400 and you donate one laptop to a child in an impoverished nation and in return you get one laptop for yourself.

I caught up with him and got his feedback on the unit. One thing I learned was that it ships with an application called TurtleDraw. This little app is great for teaching programming in a graphical way. If you're thinking LabVIEW here, well, take a look and judge for yourself.

Resources:
• OLPC Wiki
• Justin's LAVA thread on the OLPC

Another video taken at the FIRST final competition of 2008 in Atlanta. NI built a robot called NITRO to demonstrate the powerful capabilities of the new cRIO controller that will be used by the competition teams this year.

In addition to a cool ball shooting mode, NITRO has some advanced image analysis capabilities. Here we see it doing some pattern recognition and executing autonomous moves based on the image viewed.

What is not shown in the video is the ability to execute a specific move just by drawing a series of segmented lines in the provided dashboard application and then transmitting them to the bot. A huge improvement over last year.

The ability of the teams to take advantage of the power of LabVIEW graphical programming is really going to be an asset.

Resources:
• Additional video of NITRO

In this video taken at Robo Business 2008, Jim Lynch gives us an overview of the latest iRobot robot called the Looj.
Resources:

• iRobot Gutter Cleaning Robot – Purchase on Amazon.com

This video highlights the new Compact RIO hardware that will be used as the controller for the 2009 FIRST robotics competition in the FRC category.

National Instruments had a booth close to the pits at the 2008 FRC final championship in Atlanta. They built several robots demonstrating the capabilities of the new controller. One of the robots is shown here and the various components of the control hardware are explained.

The FlexStack product is a 2.5 inch, rugged platform that takes advantage of the flexibility of LabVIEW Embedded with the power of the Analog Devices Blackfin Processor.

Additional Resources:

• Boston Engineering Website
• FlexStack Information
• LabVIEW Microprocessor SDK

Dexter is a biped teleoperated robot created by the Mountain View, CA based company – Anybots. Dexter's walking is performed autonomously and is a demonstration of the type of hybrid robot that Anybots is working on. It will mainly be teleoperated but certain tasks will be automated such as walking.

Here's a VI Shots video of the Anybots team during last years Robodevelopment conference:

• Anybots
• Dexter's first steps
• Trevor Blackwell
• Paul Graham writes about Dexter

At the end of the video, Maria talks a little about here background and the K10 robotics platform which NASA used in the Canadian Arctic recently. The robots, K10 Black and K10 Red, carried 3-D laser scanners and ground-penetrating radar. The two NASA robots surveyed a rocky, isolated polar desert within a crater in the Arctic Circle. The study helped scientists learn how robots could evaluate potential outposts on the moon or Mars.

Resources mentioned in video:

• Intelligent Robotics group
• NASA Robots Practice Moon Survey in the Arctic Circle (Haughton Crater Site Survey Field Test)
• Gigapan Website
• Gigapan Hardware

Additional Video:

Galileo is the innovator of a unique breakthrough technology, The Galileo Wheel which combines wheel and track in a single component. The simple mechanism enables switching back and forth between the two modes within seconds. The technology enables the device to use wheels whenever possible, and tracks whenever needed.

They are currently looking for partners to adapt their invention to the consumer robotics market after successfully landing a contract with an Israeli defense contractor.

Resources in this Video:

• Galileo Mobility Instruments
• Robodevelopment 2007

Additional video:

Resources mentioned:

• Download Video
• Microsoft Robotics Studio
• Robodevelopment 2007

Braintech's VOLTS-IQ Visual Intelligence Software Suite provides feature recognition, object localization and robot guidance in the form of Microsoft Robotics Studio (MSRS) services.

VOLTS-IQ uniquely combines Braintech’s proven robot vision expertise with Microsoft’s powerful MSRS service-based architecture. Using VOLTS-IQ, researchers, commercial product developers and hobbyists can “vision-enable” their robotic projects and products with unprecedented ease and speed, leap-frogging the traditional barriers involved with vision development and bringing their ideas to life faster than ever.

Resources mentioned in this video:

• Volts-IQ
• Microsoft Robotics Studio
• Braintech
• Mindstorms NXT

Resources mentioned in Video:

• Infinity Project
• NI Speedy-33
• HiTechnic
• LabVIEW
• Lego

Are you working with LabVIEW on the Mac? Tell us about your experiences in the comments.

Check out all their great videos at: sbmsteenpress.org

CoroBot was created to minimize the complexity of robot development. By combining a powerful PC-class platform with a robust, object-oriented software development system, the CoroBot empowers you to rapidly deploy and develop robotics solutions. The CoroBot also assists the hardware developer with additional physical mounting space, ports, sensors and communication devices.

Kenneth Salisbury, a professor of Computer Science and of Surgery leads the Personal Robotics Program at Stanford with CS Assistant Professor Andrew Ng in coordination with the department's STAIR project. After about 18 months of work, they have developed a first prototype. It is remotely controlled now (eventually it will become more autonomous) but it is an early milestone on the way to releasing a practical, affordable and complete robotics platform.

See also: CNET Article

• Team Hassenplug
• Article in Wired
• Steve's Lego page

Mark Balla is a very active member of the LabVIEW community and contributes his valuable time to the LAVA forums. He developed an Icon editor replacement for LabVIEW, is currently a member of the Code Repository review team and is an organizer for the LAVA Coding Challenges. I spent a few minutes at NIWeek this year to talk to him about LAVA and why LabVIEW community involvement is important to him.

Mike Kleinigger is currently a sophomore at RPI (Rensselaer Polytechnic Institute) pursuing a dual degree in Mechanical and Electrical Engineering. In this video He discusses the MOT-V (Medium Object Transport Vehicle) at NIWeek 2007. Unlike the Segway style vehicle, the MOT-V always tries to keep it's position vertical as oppose to moving forward.We were surprised to see a unicyle which also uses a control system for stabilization.

In this video interview we have Amanda Emnett from the University of Tulsa give us a tour of the vehicle her team worked on for the Challenge X competition. The “brain” of the vehicle control system is powered by a Compact RIO Real-Time FPGA system that was programmed with LabVIEW.Challenge X is a three year national competition that started in 2004. It's sponsored by General Motors and the US Department of Energy. The objective is to take a GM Chevy Equinox and modify the vehicle to minimize emissions and consumption, without sacrificing utility and performance. Now in its final year, the focus is on delivering a “showroom” vehicle that addresses the requirements of consumers.

• YouTube page with more videos on the car.
• Nice AutoChannel video covering Challenge X.

Jay is also a freshman mechanical engineering student at Rose-Hulman Institute of Technology. Jay caught the entrepreneurial spirit at 15 years old and has formed Jbotics Innovations LLC (www.jbotics.com) to leverage his ideas related to internal combustion engines and transmission designs. He currently is pursuing 41 patents on a variety of products. Some of his transmission designs are built into his Lego robots.

So Chris Anderson the Editor-in-chief of Wired magazine did the final keynote presentation at NIWeek 2007 this past August. I was really excited about this since up to the run up to NIWeek I had managed to purchase and read his book, The Long Tail. I was also eager to get him to sign it, which I managed to do.

Chris did an amazing job in the keynote of describing his involvement with the LEGO Mindstorms NXT robotics system and how he created a UAV which was controlled by the NXT. This is marketing gold for LEGO and an inspiration to all, young and old as to what can be accomplished with a few low cost LEGO parts and a cell phone. He mentioned how his 9 year old son programmed the NXT using the NXT-G graphical programming language (which we all know is really LabVIEW in disguise).

I left that keynote feeling happy and all geeked out because, hey, when it really comes down to it, the Editor-in-chief of Wired magazine is using LabVIEW! How cool is that?

Well, not so cool it turns out. Chris just posted on his geekdad blog that Robot C is “The Best Programming Language for Lego Mindstorms” I mean, c'mon Chris, really? Can you seriously tell us that a 9 year old kid will jump for joy when you show her a screen full of this? Give me a break. I'm beginning to wonder if you've turned from a geek dad to simply a geek. We shouldn't lose sight of the fact that this intended for kids. No, really it is. The biggest challenge we have as parents is to find ways to pull our children away from various mind numbing distractions onto something useful. Showing them pages of C code is not one of them.

In this video my 8 year old son built and programmed the NXT claw on his own. I mentioned to him that he was programming in LabVIEW and he was surprised. He was surprise because he thought LabVIEW was this complicated software that only dad knew how to use and was for automating complicated machinery he knew nothing of. This is the whole point. He was able to build the mechanics and write the automation program without writing one line of code.

The future is not C or text based programming languages. The future is graphical programming. Chris mentions several times that it's time to use a “real programming language”. I agree. This is why we should all be programming the NXT using LabVIEW. See, LabVIEW is a real programming language and contains all the things that Chris misses in NXT-G. LabVIEW has “if…then…else”, “while”, even “for…next”. It also has sophisticated debugging tools. Can it rise up to the challenge? Well, if Virginia Tech uses it for DARwIn and the DARPA challenge then I'm sure it will work on the poor little NXT brain. Oh, and if the cost is too high, there's always LabVIEW Student Edition.

Edit: LAVA has picked up the discussion here.

It's great to see LabVIEW once again at the forefront of autonomous robotics. This time with an impressive finish by Virginia Tech team Victor Tango and their vehicle named Odin.

Virginia Tech, along with TORC Technologies, won the $500,000 third place prize last weekend at the Defense Advanced Research Projects Agency (DARPA) Urban Challenge. In a close race with teams from Carnegie Mellon and Stanford universities, the Virginia Tech team used National Instruments LabVIEW software and CompactRIO hardware in its vehicle. Virginia Tech’s team, Victor Tango, was one of only six robotic teams to finish the 55-mile DARPA Urban Challenge course.

“National Instruments congratulates team Victor Tango on its remarkable achievement,” said Ray Almgren, NI vice president of academic relations. “Team Victor Tango is a great example of how domain experts, rather than computer scientists, use NI LabVIEW graphical system design to quickly design, prototype and deploy sophisticated robotic designs. NI is proud to offer technologies for applications in this exciting and growing field of mobile robotics.”

As part of the competition, TORC Technologies created a set of LabVIEW tools for Joint Architecture for Unmanned Systems (JAUS), an autonomous ground vehicle standard for passing messages and status information between various vehicle subsystems. LabVIEW running on a separate Microsoft Windows Server performed image processing and path planning. The team integrated an NI touch panel with the vehicle dashboard to select appropriate modes of operation.

“This exceptional team of Virginia Tech graduate and undergraduate students has been a true joy to work with, as they share the same passion for robotics as TORC,” said Michael Fleming, president of TORC Technologies. “With LabVIEW, the team implemented parallel processing of high-end vision algorithms running on two quad-core servers that perform the primary perception in our vehicle. The ability of LabVIEW to automatically multithread our application, in addition to the optimizations we performed in the language itself, drastically reduced our development time.”

The development of DARwIn started back in 2005 with version 1 and the current incarnation is at version 2b. DARwIn runs LabVIEW Real Time on a PC104 board and RoMeLa has decided to standardize on this platform for all their robots.

LabVIEW controls DARwIn’s motion over RS-485 and can read joint positions on the same serial network from the servo motors’ built-in potentiometers. While the robot is walking or moving, a rate gyro with acceleration and orientation information communicates with LabVIEW over an RS-232 serial connection so that the program modifies the walking gait to effectively balance the robot in real time.

Karl told VI Shots that RoMeLa is planning on evolving DARwIn hardware so it can be sold at the consumer level at a lower cost. I think this would be very cool.

Hanson Robotics is collaborating with Massive Software on this one. Massive has built their business on artificial intelligence algorithms used in computer animation for simulating crowds. They started off by developing the computer animation for Peter Jackson's Lord of the Rings battle sequences.

The vision and decision making components in Massive Software give Zeno the ability to navigate, make facial expressions, and move his body based on what he sees in his physical environment. The video coming in from Zeno's eye camera is fed into the Massive part of his brain so that he can move appropriately and respond emotionally to what is going on around him.