Podcast: Download
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:
- Include LabVIEW Version Number in Application Icon (LabVIEW Feature Suggestion)
- Diagram Cleanup Feedback Group
- Darren's Weekly Nugget 02/08/2010 (16×16 glyphs that ship with LabVIEW)
Show Transcription:
Michael: Hello everyone and welcome to another episode of VIShots. My name is Michael Aivaliotis and this is the podcast devoted to the world of LabVIEW. With each episode I bring you interviews, discussions and share with you ideas for how you can take your LabVIEW development to the next level.
Well, thank you for joining me today for the second episode of the VIShots podcast. Coming up in the show we have an interview that I did with Darren Nattinger of National Instruments. He discusses some of the tips and tricks that he uses to speed up LabVIEW code development. If that interest you then please stick around. But first of all before we get into that I'd like to thank all the listeners so far to this podcast. It's been a difficult start because I wasn't sure if there were any listeners out there. But if you are out there and you like what you're hearing, please leave a comment on the VIShots website for this show. Or even if you don't like what you hear, I want to hear that too.
If you'd like to send an e-mail directly to myself you can send it to feedback@vishots.com. I also like to thank the people who participated on our Facebook page and made the page one of their liked pages. I like to thank you for that. As of this post, we have 107 likes which is just great. Also, since the first episode aired I have put up two LabVIEW tutorials videos which are also available on the VIShots site.
One of the video shows you how to separate compiled code from your VIs. This is a new feature in LabVIEW 2010 and how you can use this effectively to improve your source code control integration with LabVIEW. The other tutorial talks about how to do hardware emulation using LabVIEW classes. This is something that I use almost every day in my projects, so hopefully this will help you in your development.
For those of you that want to listen to the podcast through your iPod or some other electronic device. I like to let you know that the VI Shots podcast are now available on iTunes. You can do go on to iTunes and do a search for VIShots and that should come right up. We’re also available on the Zune podcast network if you have a Zune device. We're also Blackberry users have an application that accesses podcast and we're actually registered on there as well. If you have the Blackberry podcasting application you should be able to find VI Shots on there as well.
One last thing before we get into the interview, I like to apologize for the audio quality especially on my end of the microphone for the interview that you're about to hear. There is some static on my side and that's definitely something I'm working on eliminating for future episodes. If you are annoyed by the static, I apologize and it will be eliminated moving forward.
Having said that, let's get into the interview. So on our show today we have Darren Nattinger from National Instruments. He's a Senior Software Engineer and a Certified LabVIEW Architect. It's actually an honour to have Darren on the show because he's probably one of the fastest LabVIEW programmers I know. He has pretty fast fingers and also I believe Darren you've proven this in a competition at National Instruments at NIWeek correct?
Darren: Yes, for three years in a row I've won the LabVIEW Coding Challenge actually.
Michael: This is not an official tournament type challenge, but it's something that National Instruments puts on every NIWeek. I think you've been the winner every year. You're famous for pushing sort of the productivity and development speed in LabVIEW. You're pretty adamant about coding fast and you've come up with a couple of tips and tricks that you use yourself to be able to code faster. Could you go through some of those with us?
Darren: Sure, so at this year’s NIWeek 2010, I gave a presentation outlining a lot of the daily features and tips that I use programming in LabVIEW. Just things that I use every single day, multiple times a day that I think really helped contribute to increasing my programming speed.
One of those obviously is QuickDrop everybody knows that's my baby in LabVIEW. I believe I've mentioned four in that presentation. QuickDrop was the first, another one is the Auto Tool. I'm a very big fan of letting the Auto Tool choose the right tool for me as I think it's much faster than tabbing between tools manually. Another feature that I use on a daily basis is the New Icon Editor in LabVIEW. In addition to some usability enhancements that it has, like being able to create text based icons very quickly.
One of the things that I really like to use in conjunction with the Icon Editor is most of my VIs in my projects are in libraries and classes. Since my libraries and classes all have a pre-defined banner on the icon of those libraries and classes. When I create new VIs, I already got a banner all I have to do is go in and edit the text and the icon that I need to change. A new VIs icon takes maybe two or three seconds for me to create just because of having those things in place.
Michael: Some people might not know this, the new LabVIEW Icon Editor, do you remember when that was introduced?
Darren: It was in 2009.
Michael: So that has a feature a new feature with layers. How do you use exactly, do you create your own templates, sort of predefined layers?
Darren: When you program — when you use libraries or classes, when you set up an icon for that library, that's the default layer for your icon. So whenever you create a new VI under that library, the library layer has already been applied to that icon. If you're just creating a text based icon for your VI, the library layer is already there and typically that's a banner. Then I just fill in the lines of text on the Icon Text Tab and Icon Editor and then I'm done. I don't have to touch any of the layering stuff because that library has already been applied.
Michael: You also mentioned the Auto Tool — can you explain a little bit more about what you like about the Auto Tool?
Darren: The Auto Tool's actually been around for a long time. Out of the features that I've discussed in NIWeek presentation that was probably the oldest feature. It's been around since LabVIEW 6.1 and I actually learned LabVIEW in version 5.0.
I programmed in multiple versions without the Auto Tool. When it came out the selling point for it was basically the tools that you need to tab through when you're manually tabbing through tools. The operate tool, the positioning tool, the wiring tool, the whole draw of the Auto Tools that as you mouse over certain regions of the diagram that would figure out for you, which one of those tools you wanted to use.
Unfortunately, when the feature first came out, it wasn't very good at guessing. I mean it guessed right some of the time, but certainly not all the time. But I noticed that with each LabVIEW released 7.0, 7.1, 8.0 whatever heuristics we use under the hood to make those decisions got better and better. Now I think it's perfect, I mean the selections that it makes are exactly what I know and what I'm expecting. As a result, my left hand is free to do QuickDrop or control E, control N, just all the keyboard shortcuts that I use without ever having to go over the Tab key to switch between tools.
Michael: Yeah, one thing I find, well I kind of use to it by now, but as a new user using the Auto Tool I think one of the difficulties is on the front panel or sometimes on the diagram, but just selecting an object and moving it. Is a little bit of a challenge because you have to actually position your mouse cursor or mouse pointer I should say, right at the border of the control, right? Because if you push it — if you move it to the inside of the control then it become sort of either text entry or button press or whatever. But if you want to move it like grab it and move it, then you actually have to put it right at the border to select. Select is a little bit of a challenge sometimes.
Darren: I agree for a new user I could definitely see that being an issue. Let's see, I think 6.1 came out about eight years ago and I've been using the Auto Tool ever since then. So I'd know what you are talking about, but my hands are just naturally good to those locations that I know for positioning in particular, to get the Auto Tool to pick the right thing.
Michael: Right, another thing we could mention as well was if you want to select something, you can also sort of click and drag around it. Create like a dotted box and then you will just grab the control as well that way.
Darren: Yes. Oh! One of the things I just thought of to mention about the Auto Tool is when you are having those difficulties, there's a tools option setting that locks the Auto Tool. I actually had that disabled, because on the rare occasion where I do want to manually tab to another tool I don't want LabVIEW to prevent me from doing so.
I have the Auto Tool locked turned off and alt tab tool I need every once in a while. There's a keyboard shortcuts that's if you have tabbed away from the Auto Tool if you press Shift + Tab it will switch back to the Auto Tool. I just wanted to mention that real quick. We do have an out whenever we occasionally do need to move away from using the Auto Tool.
Michael: So what other tips do you have for speeding up your development?
Darren: During my NI Week presentation, as I mentioned there were four essentials that I talked about. Just things that I use every day, the Auto Tool, the New Icon Editor, QuickDrop and then the other one is Block Diagram Clean-up. That's one that I guess could be viewed a little more controversially, if there was such a thing as controversial LabVIEW topics.
I, for a very long time here in LabVIEW R&D, I guess it's still that way. I really haven't transferred ownership of this, but I actually own the LabVIEW Style Guide that ships in the LabVIEW documentations. For many years, people knew me as the Style Guy. I guess now they know me as the fast programming guy. I've always advocated clean diagrams.
Unfortunately, with my focus moving more towards the speed of LabVIEW development in recent years I noticed that diagram arrangement was a huge bottle neck in my programming. I would spend half of my time writing the code and then another half of my time cleaning it up. I decided to — I guess a little over a year ago, I decided that I was just going to use diagram clean up for everything and see what happens.
I've observed over the past year that there are some VIs that I still naturally arrange myself. Those tend to be VIs that are top level architecture type VIs, like my main state machine or my main cued message handler. I will make sure to arrange those diagrams myself because one of the keys to understanding a top level architecture VI like that is the arrangement of the diagram itself. I don't want diagram clean up just go on crazy on one of those VIs, so I'll still arrange those myself.
I've also noticed the diagrams that have a whole a lot of nesting. Lots of case structures and loops, diagram clean-up tends to explode those diagrams. I tend to not use it on those sub-diagrams as well. The vast majority of the VIs I write fit on one screen, they are internal type VIs that are use within the application that I'm working on. For those Vis, Block Diagram Clean-Up doesn't do a perfect job, but it does a good enough job. I think it does a good enough job that the diagram is still understandable. We made some improvements in LabVIEW 2009 and 2010 in terms of the positioning of comments on the diagram. In LabVIEW 8.6, all comments will just be moved off into one corner, which is basically made the feature useless, because you would document your code and then the documentation will be wiped away somewhere. In 2009 and 2010, we try to preserve that positioning, it's not perfect but it's pretty good. I think its good enough.
Michael: Also in 2010, those are new feature added, but one which I really like is sort of putting comments on wires.
Darren: Yes
Michael: That goes together with the diagram clean-up very well, I think.
Darren: Yes, it does. Yeah commenting your wires, being labelling nodes I think is a good trick. If you've got a section of codes that sort of revolves around a single node or a single structure. Assigning a label to that and using that as your comment is good, because that positioning will always be preserved. Ultimately, I'd say in my current project that I'm working on which has a code base of hundreds of VIs I'd say that probably 90 to 95% of those VIs I've just use diagram clean-up on. I've arrange the other ones myself. It’s just a huge time saver even if it’s not perfect.
Michael: I use diagram clean-up a lot, too. I agree with you it's good in those scenarios. I use state machines a lot and it’s difficult to use it on a state machine. There are some improvements that can be done and we could suggest some.
One thing it kind of annoys me is the way it bends some certain types of wires, like let say you're doing a bundle by name. Let’s say you want to put a constant somewhere and you want to do like a bundle by name from the constant. Then it actually position the constant way out in the middle of nowhere, instead of like right next to the bundle by name for example. It tries to0 strictly too conserve the left to right and then it sacrifices sort of creates a lot of bends in the wires, and puts things away in the middle of nowhere when it could just be place like right next to the object for example.
Darren: I agree. I actually created a group on ni.com/community site called Diagram Clean-up feedback. It's basically place for us to post screen shots, before and after screen shots. Let the developers that work on that feature knows about situations where diagram clean-up is making decisions that it seems like should be much easier to make a better decision.
I'll recommend that you post. I've posted multiple screen shots on there. I'd recommend you post some of yours. Maybe other listeners listening to our discussion here could go there as well. If you just go to ni.com/community and search for a group called diagram clean-up feedback. That's a place where we can post that type of feedback to the diagram clean-up team.
Michael: Great and also in the show notes on the web I’ll put a link to that as well.
Darren: Cool! Yeah, those were my four essentials. Things that I do every day, using the Auto Tool, using Diagram Clean-up, the New Icon Editor and QuickDrop.
Michael: You program in LabVIEW, correct?
Darren: Yes
Michael: Do you do a lot of C development there?
Darren: I have never written a text based program in my life, except for like Pascal in high school.
Michael: You're basically…you're one of us (laughs)?
Darren: Yes I am. I'm one of you I just happen to receive my pay checks from the Nationalist Instruments Corporation.
Michael: Is there…I was always curious about this. Is there sort of the LabVIEW people that you program in G and sort of a C people and like do you guys mingle, and do you have lunch together or do you have like sit in a separate tables and stuff like that?
Darren: Yes, it's nothing like that. I would say that in LabVIEW indeed there's a small member of us that do this type of G programming. I'd say the majority of people are working more on the source code itself. That's actually one of the really, really cool things about having the job that I do. Is that, as suppose to someone maybe in your position where you would need to talk to AEs, have cars filed, try to get those bugs and those features implemented from outside these walls, I can actually just walk over to someone’s desk and discuss with them things that I need to change. That's one of the really just wonderful things about working where I do.
Yeah, but as far as working together, mingling together, of course we do. I mean there are a lot of the C developers in LabVIEW who actually write G features as well.
One good example would be Christina [Rogers], she wrote the “Getting Started Window” which is all in G, but she also owns many of the core source code features as well, so that's and…Then you've got situations like I know you know about this and hope a lot of your listeners too, but Steven Mercer and I worked together to try to get the community to vote up the create sub-VI improvements idea on the idea exchange. Hopefully, we're going to see something along those lines implemented in LabVIEW 2011. But the plan that he and I have for that feature involves some changes to the LabVIEW source code, to allow for a VI to be called to actually perform the create SubVI operation. We've got some C work and G work going together into this one feature.
Yeah, there's definitely lots of inter-mingling and in the case of some features that actually working together on both components of the product, so that we can get stuff implemented.
Michael: When was the first time you sort of experienced LabVIEW and either heard about it or touched it, or worked with it, when was the first time that you did that?
Darren: The very first time was in undergraduate work that I did in college. I went to the University of Texas in Austin, got a Mechanical Engineering degree actually. In one of our Labs, we were taking some temperature measurements and pressure measurements with a very, very old Mac computer that was running LabVIEW three something or four something.
It was actually a pretty bad first experience just because that…and I don't even think it was LabVIEW’s fault. They had such terrible computers in this Lab. It's just terribly old and beat up that I don't think any software would have worked on that computer much less LabVIEW. I didn't really do any programming of it then that was just using pre-written VIs for the Lab. My first experience programming was actually in my first week of employment here at National Instruments. Because I started as an AE and all the AEs get LabVIEW training in their first week. That was my first experience. I actually the first program I wrote, there's this card game that I really like to play called Set. I wrote a LabVIEW version of Set during LabVIEW basics one training. That was my first experience and it was LabVIEW 5.01 was the version that we used at that time.
Michael: Well, that's interesting that the first program would be a game (laughing), considering that I believe that you are an avid gamer.
Darren: I do play a lot of board games, and card games, and video games and yes just about any games I can get my hands on.
Michael: Do you think that some of your experience from gaming, being very fast. I know you're a good guitar hero player (laughs) and that of everything kind of influenced you to speed up your LabVIEW development as well?
Darren: Yeah, I mean there are a lot of games that I like. Like chess, but a lot of people are much better than me at because they can do that really deep critical thinking that I'm not so good at, as I am the speed type games.
The game I just describe to you Set, the card game that I wrote a LabVIEW version for, it’s a very fast pace speed oriented game. Yeah, just over the years in LabVIEW you have noticed that there's things that could make me program faster. Things that are bottle-necking me. Back in LabVIEW 8.5 I'd noticed that the palettes were big bottle neck and that's why I prototyped QuickDrop. After that I noticed that arranging my diagram was a bottle neck, so I started using a diagram clean-up. I guess it really has been the focus of my LabVIEW programming here over the past couple of years, is just how fast I can get things done. Following the process, of course, I never neglect to write my specification documents or create my auto test for my features. The actual programming of the feature I try to make. I try to find how fast I can get it done, just because LabVIEW is such an intuitive environment. That I think you and I talked about this one time it comes down to those little repetitive tasks. Those things that you have to do, they're part of your programming that it seems like there's ways to make them faster.
Michael: Is there something that's on your mind right now, that it's kind of a bottle neck that you wish that could be fixed or some way improve in the future?
Darren: We're working on that create sub-VI thing that improvements to that, that's definitely a big one. Not much is coming to mind, I've got some ideas up there. One of which is (laughs) this one is not necessary a lacking feature, but one of the limits to QuickDrop is that it has to load the whole palette set. Loading the whole palette set can often take a long time.
Actually I have an idea up there. It's for us to find a way to eliminate that initial delay for loading the palette set. Another one of my ideas, not really a speed based idea. I know you guys are just like me you all will do develop them in multiple lively versions. The fact that all the icons of all my LabVIEWs look exactly the same on my Window's taskbar is really annoying. That's another one of my ideas, that's probably the one that I've submitted that has the highest number of votes is putting a little version of the number on the LabVIEW icon in the taskbar. I think that would just…not necessary speed me up, but reduce my frustration when I've got four-five LabVIEWs running. And I have to go guess which one is LabVIEW 2009, which one is LabVIEW 8.2 et cetera.
Michael: Do you do that often? Do you have like multiple LabVIEW versions up?
Darren: Yeah actually I do, I mean we LabVIEW 2010 came out in August. The project I'm currently working on, we didn't switch to the 2010 code based until a month, six weeks afterwards. I was still doing 2009 development for that project. But then for all the little LabVIEW features that I own, and I do own a lot of little features in LabVIEW. The fix bugs on that and stuff I would want to use the latest release version which is 2010. I would be using 2010 for those type of bug fixes and then 2009 for my main development. Yes, so that's certainly does happen.
Michael: I know you also have a regular feature somewhere on the ni.com forums which is “Darren's Weekly Nugget”. Can you explain exactly what that is?
Darren: Yes, so every Monday, hopefully, occasionally I don't get 'til Tuesday, but every Monday I just post some tip on the NI forums, just some little titbits of information that I come across in LabVIEW, that I think would be helpful to users.
Whenever there's a new LabVIEW release I like to talk about new features in LabVIEW that I think are going to be helpful.
I started doing the Weekly Nuggets back in 2006 and I did them for a whole year. Then in 2007, I started to take a break because it's actually hard to come up with a brand new tip to discuss once a week for a whole year. I did occasional Nuggets in 2007 and 2008.
In 2009, I was asked to start up the Weekly Nuggets again. For 2009 and all of 2010, I've been doing them weekly. Looks like I have written 152 Nuggets over the past I guess four or five years. Yeah, the ones I've have been writing lately have had to do with LabVIEW 2010 features that I think were really cool. If any of your listeners want to see links to every single one of those 152 nuggets I've ever written. All you have to do is go to ni.com/community and search for Darren's Nuggets. The first link that comes up is a page that has a link to every single Nugget that I have ever written.
Michael: Cool! Can you tell us maybe pick one of those Nuggets?
Darren: Sure! One of the ones I wrote, this one really surprise me, I wrote this one back in February. It has the second highest rating, in terms of number of kudos that it received on the forums. Has the second highest rating of any Nugget that I've ever written. This is Darren's Weekly Nugget from February 8, 2010.
On that webpage I just mentioned, you could just scroll down and click the link for that. Basically, I mentioned in that Nugget that there is a folder under the LabVIEW directory that contains a huge collection of 16 x 16 images that are frequently used within dialogues. Like pictures of folders, pictures of VIs, lots of file icons, icons for things you might see in the project Window. Like a little My Computer icon or a little FPGA target icon.
Little images of those, for those icons– there's dozens of them in this one folder. I just mentioned that in a Nugget because I figured well I use pictures that are in there once in a while so many other people might want to use those, too. I was just amazed how many people thought that was just the best tip they'd ever heard of. That's one kind of interesting to talk about.
Michael: Okay, well I guess I just learned something too, because I wasn't aware of that (laughs). Yeah, I mean I don't follow your Nuggets on a weekly basis. I might have missed a few. That was definitely the one I've missed. It’s showing icon– actually these are used in the project as well, right? The project dialogue?
Darren: Yes, the Project Windows uses those exact glyphs. Yeah, there's actually multiple ways to sort of be notified about my Nuggets. One way is to subscribe to the feed for this page itself whenever changes are made to it. Better way I think is that I have a blog on the NI Community site, but all it is, is links to the nuggets so every week that blog is updated with the link to that Week's Nugget. I think most people subscribe to my Nuggets that way. You just set up an RSS feed for that blog on NI Community site.
Michael: Thank you again for coming on the show. I think we're going to have you back in the future.
Darren: Excellent! Thanks for having me.
Michael: We'll have maybe a special Darren's Nuggets segment of the show (laughs).
Darren: That sounds great!
Michael: Well, Thank you very much and also just before you leave. Can you tell us what your blog web URL is so people can visit that?
Darren: Yes, I have a blog called LabVIEW Artisan and on that blog it’s not really so much a Nugget type material as it is. It gets more abstract discussion about LabVIEW features or LabVIEW sort of musing on LabVIEW programming. It's not really in specific tips or anything. That blog is labviewartisan.blogspot.com.
Michael: Well, thank you and that's it.
Darren: Thanks!
