VI Shots LabVIEW Audio Podcast

In this 3rd episode of the VI Shots LabVIEW podcast. I sat down with Justin Goeres and we chatted about the NI 2011 CLA (Certified LabVIEW Architect) summit, we both attended, which happened in Austin March 7-8. Justin gives us a run down of all the reasons why you should be attending next year if you are a CLA. I also play a funny clip of Justin discovering an event structure “bug” that caught him and others at the CLA summit by surprise.

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:

As always, discussion is encouraged. Please leave a comment on our site or send an email to [email protected]

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 7th and 8th. 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.

In this episode of VI Shots we sit down with Darren Nattinger of National Instruments to see why he is known as the fastest LabVIEW developer around. Darren is a senior software engineer and a Certified LabVIEW Architect and among the few people at National Instruments who codes in G. He shares some of his tips and tricks with us so we can be just as fast.

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

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 [email protected]. 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!

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.

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!