Podcast: Download
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!
