Known as the Father of LabVIEW by engineers and scientists worldwide, Jeff Kodosky cofounded National Instruments in 1976 and has continued to mentor the organization and pioneer graphical system design approach through NI LabVIEW.
Kodosky's invention of LabVIEW was named as one of the 'Top 50 Milestones for the Industry' and he holds 68 patents associated with LabVIEW technology. Ferret Editor, Kevin Gomez caught up with Kodosky in Austin, Texas at NIWeek 2013 to get some clues on the evolution and future of LabVIEW.
Was the GPIB board the start of LabVIEW?
It was definitely the start of the company. It put us front and centre in automated test, at the intersection of computers and instruments. It gave us a lot of insight because a customer would buy our GPIB board, plug it in, connect the instruments and if it didn't work they'd call us because we're the ones that were connecting all of these things.
So we learned a lot about what customers were doing, a lot about how the instruments were working and a lot about how to diagnose and troubleshoot over the phone. The software that we'd built for our boards had a lot of extra capability to help us troubleshoot problems. We learned a lot about measurement and automation because we were right in the middle and that set the stage for our later expansion into virtual instrumentation.
How did G language evolve?
Once we were established as a GPIB supplier we got to thinking, what can we do next to simplify the task of automating measurement systems?
Went out and talked to customers, they said, yeah if you have better library of the fixed basics we'll do this. But that's not exactly what we had in mind.
We wanted to do something a little more revolutionary and a little more far reaching. So I went up to an office near campus, scratched my head a lot and pottered around. A major milestone for me was when I got introduced to the Macintosh computer.
All of a sudden, seeing those graphics made me realise - that's the future of human computer interaction. I said, this has to be part of our solution.
We've got to be able to build virtual instruments on a computer and connect up to real instruments or connect up to the data acquisition part or whatever. We've got to have these like front panels because people could then operate it without having to read a big manual, they could experiment.
Programmers were writing basic programs to automate a few instruments and collect data, asking them to write an interactive graphical interface program would be impossible. They just wouldn't be able to do that. So how would we program a system like that?
I pottered around, thinking of different ways we could use graphics. Looked at dataflow, it was nice but as soon as you tried to do loops it got inordinately complex.
Looked at flow charts, there wasn't enough leverage in use of graphics. Nothing seemed to be a eureka kind of answer. I kept coming back to dataflow because of its phenomenal logical level of understanding. You could see what's going on, understand it very easily.
So somewhere along the line it occurred to me that if we could add controlled structures from structured programing into dataflow then we would simplify the creation of loops and other kinds of case structures and so on. It would have the simplicity of dataflow and the composability of structured programming.
That was when we realised, okay this is a germ of an idea that could work. So we kicked off the LabVIEW project and the rest is history.
Is mobile is the next big leap for LabVIEW?
Mobile devices need to be exploited in test and measurement and control applications. How much more and the timescale is still kind of fuzzy. We want to make sure that we're figuring out how we can use new technology and make it available to our broad base of users.
Sometimes it's not always clear what the long term is going to be so we have research projects that we do and experiments that we run. I definitely think mobile devices are going to have a profound influence although I'm not exactly sure where it's going to be. I know what's in the HMI area but unsure how much more we will see.
Over the years we have been working on major advances that are poised to be included in the LabVIEW framework. The higher level of abstraction that we refer to is a system diagram. Basically a graphical representation of the project where you can see all the components in your system and how they're interconnected, both at a hardware configuration level as well as a software distribution level.
Looking back, is there anything you would have done differently?
Well of course if I knew what I know now back then. it could have influenced a lot of things. Although the technology we had back then is nothing like we have available today. Even if I knew that there were going to be FPGAs in the late 90s back in late 80s I wouldn't have been able to do anything about it.
I think we made different trade-offs because there's always more to do than we have resources available. If we did this before that, is it better or worse?
I don't know. We did it this way, it seems to have worked fine and so I don't know how to second guess that. There's been a lot of cases, a lot of decisions along the path where it's not clear what's best when we made a choice. Thinking about it again you might think, well maybe it would have worked a little better for me on another choice but it's not really clear that it would.