I started this blog with a lot of excitement, as do many people, but haven’t managed to post very regularly. All the regular bloggers in the world will of course think of course, lots of people try and blog but it takes a lot of effort. My personal running blog is much easier for me to manage this blog poses a few challenges. The biggest one is that most of what I work on in the LabVIEW R&D team I can’t really talk about yet, it’s fun, it’s exciting, it’s challenging but alas not all publicly discussable. After NI-Week this year when we plan to preview some of these technologies and kick off some pioneer programs to gather feedback on the ideas and user experiences I should be able to be much more open … I can’t wait!
Until then I think I’ll start posting about some of the things I’ve been learning lately, some related to what I’m working on and others are areas of interest I’m spending time on to improve my knowledge in general about the types of applications and challenges LabVIEW developers face. My latest role at NI has me in the LabVIEW R&D team focusing more on our Real-Time, FPGA and web connectivity areas so I’ll start there. Coming up will be a few posts on timing and synchronization in LabVIEW FPGA and DSP (digital signal processing) using LabVIEW FPGA. Bear with me as I spew out my understanding on some pretty random topics as I find purpose and direction for this blog.
A few years ago at NI-Week the keynote there was a discussion on encouraging more involvement and enthusiasm for science and engineering for education and as a career. I’ve seen this Intel ad on TV and just loved it, here it is on youtube.
Nothing can really take the place of NI Week, our annual user and customer conference. It’s really a unique opportunity for many of us to interact with, listen to and learn from our customers. We get to share what we’re working on and thinking up during the keynotes, present to customers, sit in on presentation from customers and pretty much just get to hang out. We can’t forget the social on Wednesday night, as much as some of us might want to
Tomorrow and Saturday is NI Tech, it is an internal R&D conference where the engineers at NI present to all the other engineers. It’s a good way for everybody to see what the other groups are doing, get exposed to new technologies that somebody might be experimenting with and just like NI-Week to get to hang out, relax and learn. Like NI-Week everybody can submit a session topic, they’re voted on and then scheduled. Some of the most entertaining sessions can be the ones that aren’t technical. A few years ago there was one that compared development to waste water management, and there is also the “Town Hall” open forum. All in all it’ll be a good time to recharge by seeing all the interesting things going on in the different groups, the toughest thing is going to be making it all the sessions I’d like to attend since many are at the same time … I guess that’s another similarity to NI Week!
The rumors are true. This is the real reason for my return to R&D from marketing, I guess you could say I fell off the wagon and just couldn’t stay away from performance enhancers n R&D.
A few of us had a good discussion this Friday on the different interactions engineers in the LabVIEW team have with customers. Some of the people in the room should be familiar to many of you and included Brian Powell, Kennon Cotton and Deirdre Walsh. We talked about a number of things, this included what is it that motivates some engineers to be more actively engaged with LabVIEW customers through NI discussion forums, non-NI sponsored forums like Lava or by blogging. The part of the conversation I enjoyed the most and was hoping for some insight into from actual LabVIEW customers is what types of interactions they value the most.
I’ll start by listing some of the opportunities LabVIEW R&D engineers, managers or product managers have to interact with customers:
Information on the internals of LabVIEW and how things are implemented and their side effects can be answers to questions on discussion forums or of blogs
Active brainstorming on some features in active development is the focus on the developer brainstorm forum as well as lead user programs
Policy discussions and feedback are things John Pasquarette has recently been spending time on in his blog
Road-maps and future directions are often discussed in visits to customer sites and in one-on-one interactions.
All of these are performed to different extents and by different people throughout R&D and product management. As we were discussing these different things one of the questions in our minds was what do LabVIEW users find the most valuable in their daily work and also on a long term basis. Also, what are the ways you as a LabVIEW developer prefer to get each type of information and at what frequency?
Today a few of us were discussing how front panel editing and execution works in LabVIEW, what it’s good at and where we could improve things. I’d be curious as to how people developing in LabVIEW day to day use some of these features and what works well for them and what doesn’t.
How Things Work Today
In general (ignoring the case of multiple instances of a VI Front Panel for re-entrant VIs or those targeted to multiple embedded devices) there is a one to on mapping between a Front Panel and a Block Diagram. On a Front Panel each control has a default value associated with it.
The following is really about interactive execution not use of a VI as a sub-VI:
I run a VI the first time interactively it uses the default values on controls and gives me a result.
I run the VI continuously or because there’s a for loop and while running the VI I can change the value of controls (inputs).
When the VI stops the control retains that value.
I run it again it keeps that updated value and runs again.
Now I close the VI and open it again it starts up with the default value.
Some Things that can Cause Confusion
There are a couple of interesting things that happened in this simple example.
In Step 4 and 5, did I really want to make those values the default value. Since the VI stopped running and it looked like it was in “edit mode” and I then save and close it there are times some people expect that value to be saved. Now this isn’t desirable in the case where this is really a sub-VI where I want the default value to remain as it was since that impacts programmatic behavior.
Step 2, 3 and 4 can be a process I repeat multiple times when I’m characterizing a chip or a component. In that case I’d like to be able to see a history of that information and I only see the latest values.
What are the Different Ways People Need This to Work
Note: The above two examples I cited are really just two out of a very long list of use cases, we’ll keep discussing those but for now I’m interested in how people are affected by these.
I’m curious about how people make use of the interactive execution mode for VIs and default values and the data logging option with VIs. When do you use it in your regular work and which situations have you been confused by the current behavior? I’d like to make use of this information to help prioritize and guide some of our internal brainstorming on these topics so we can use these as validation use cases. Look forward to your thoughts.
I’ve spent a couple of days this week at the NI Berkeley office. This is a relatively new office and it has a
View from NI Berkely Office
great view of the bay. The office isn’t too far of a walk from the Berkeley campus. This is my first visit to the area and the campus was very green, hilly and picturesque. During the visit I got a chance to visit the NI Embedded Systems Lab which was opened in May 2007.
The visit inlcuded getting an overview of Chess (Center for Hybrid and Embedded Software Systems) from Dr. Edward Lee who’s in the Electrical Engineering and Computer Science deparement. Dr. Lee has some papers in the areas of Models of Computation which is something you’ve probably seen, even if the term may not be familiar from NI. At it’s simplest level it’s providing the appropriate representations for the problem at hand. For example, dataflow in LabVIEW “G” VIs, Statecharts and Simulation diagrams were introduced to try and address different application and domain needs. The main thing I found useful in the discussion with Dr. Lee and also with the engineers at the NI office was the formal methods that can be applied to the concepts we’ve worked on in the past and continue to examine.
Your Hybrid Isn't Green Enough
On the way back from the office we came across this pretty interesting sign. It brought home to me that I might have though Austin was a green city but Berkeley sure has an upper hand when a hybrid gets called out as not being “green enough” On the trip I also got to catch up with Jim Kring from JKI. It was a good discussion that covered a number of things including integration into LabVIEW for tools providers (which you’ll hopefully see better documentation and information on later this year), release times and how to better share product roadmaps with partners.
For anybody that develops application in LabVIEW make sure you take a look at this blog. Darren, the creator of Darren’s Weekly Nuggets which then resulted in Community Nuggets has joined the blogosphere. He’s an active developer in the LabVIEW team, codes in LabVIEW every day and has a wealth of knowledge and tips and tricks. This year you’ll hopefully see some very through writings from him on how to extend the LabVIEW environment. Hope you find his blog as useful as I’ve found all his Weekly Nuggets in the past.
I wrote a post over the weekend about trying to improve examples for people using LabVIEW. Michael Aivaliotis and Yari had some good comments and I wanted to follow up on those as well as share a recent discussion and give some insight into the complication (some might say unnecessary) with getting the right LabVIEW examples in the hands of people that need them. As a follow-up to recent discussions by the LabVIEW Champions I had a good lunch discussion today with Todd, a LabVIEW Product Manager on this area.
Michael made a very good point about shipping examples being a starting point of many applications. That is entirely true. Now there are sometimes more than one way of doing something so it’s important we present the pro’s and con’s but overall having a high bar for shipping examples should be paramount. There are a few steps Todd and I discussed to take some short term action:
Prioritize the code to focus on using web traffic and download information.
Investigate the current shipping example review. During our lunch today, Todd, Dr. Truchard and I discussed the importance of example code. An analogy that came up was the code review process we use in engineering for software development. If example code is used as the framework for peoples applications it probalby deserves similar attention. This is more of an investigation task for Todd and me, we both really don’t know what we do today, we may be doing all the right things already.
Determine what the update process for examples is (shipping and on line). How do we review examples that should be updated because the way of solving a task has improved as a result of a new feature? How do users with older versions still continue to be able to find relevant examples?
Create a collaborative environment with the LabVIEW Champions and others to identify code to improve and possibly be part of the solution.
Yair brought up a great point about Tutorials and their relationship to example code. It really is key to make examples tie to tutorials better, make it bi-directional since I could find one or the other when I search on-line. The NI web-site does have related links that show up on pages that are automatically generated but in these cases having a very specific tutorial referenced would make much more sense. This is an area that we’re still discussing. How can tagging help with this? How should search work versus browsing? This example might be a step in the right direction: Queued Message Handler
Finding Examples
2002 - Example Finder and Example Database (EPD)
There are a lot of different places developers can go to find examples. The Example Finder in LabVIEW is one of them. With this tool people can search for installed examples as well as on-line examples on the NI web-site. I found very old diagram (2002) that has a simple representation of the systems and how they were connected. The details aren’t correct today but the overall structure is relevant. What you can see here is a web service that provides access to examples that are created on the NI web-site through the Example Finder. The Notes EPD DB was the repository of all examples in 2002.
There’s another database today, actually there are two. This really shouldn’t matter as far as people being able to find examples since the information in each system is identical. If you’re wondering about look around on NI Developer Zone you’ll see a UI difference on the between some examples.
One issue that came up in our discussion at lunch is that depending on where you are on NI Developer Zone when you search you may or not get all the examples. Specifically f you want the whole set of examples make sure you search from the main NI Developer Zone page: http://zone.ni.com/dzhp/app/main and not from the NI Developer Zone Community section: http://decibel.ni.com/content/community/zone
The latter only searches through one of the databases I just mentioned. Another thing for the list for us , I put this into the make it possible to find the examples column as opposed to improve the examples that people find.
There’s been a recent discussion between a LabVIEW Product Manager and the LabVIEW Champions on example code I’ve been interested in. The Champions had a lot of great points, there are regular meetings and a private discussion forum for communication, and I wanted to expand on a few of the things that come to my mind and see what others think.
Purpose of Examples I think of two primary goals of an example. The first is get people up and running with a task they’re starting and the second is to teach people about best development practices. Examples as templates should also demonstrate common applications or needs in applications that people can use as a starting point and customize.
The Right Way or the Fast Way One specific example used by a LabVIEW Champion got me thinking. Let’s say I want to have my application do something after I click on a button. The traditional way to do this in LabVIEW was to use a while loop and detect a value change on a button. This approach is often referred to as “polling” and it can eat up your processors since the while loop is continually executing and reading the value. When the Event Structure was introduced it provided a much better way where we essentially wait for interumpts from the OS so you’re not just spinning processor cycles polling the current value of a control.
Ideally you should use an Event Structure, you application will respond better and the performance of your application and machine should improve over polling. We do though need to keep in mind that some people are just looking to perform a quick and dirty task where using polling is sufficient and faster to write. Many people transition from this to using that code in a larger application and then the polling approach can break down.
In this case I would want any example that uses polling to call out the pro’s and con’s with polling and mention the event structure as the “right” way and ideally provide a link to that example.
Newer Versions of LabVIEW Introduce Better Ways to Do Something
The event structure is a good example of something that wasn’t in LabVIEW at one time. When it was introduced it provided a better way to develop interactive user interfaces. We should really do something with those older examples shouldn’t we? On Developer Zone we do list the version an example is written in but that doesn’t really inform people that there are features in a newer version, one you may be using, that provides a better way to do something.
Improving Examples in LabVIEW Improving examples shouldn’t just be about creating more example code. I should ideally be about updating existing examples and in some cases deleting or removing them. Examples are installed with LabVIEW and are available on NI Developer Zone as well as other community sites. The LabVIEW R&D feature specification process does have a section titled “Examples Impact”. I’m going to work with Todd, the product manager I mentioned earlier, to revisit what that sections goals should be. In addition to what examples we need to create, things like what examples need to be updated or obsoleted should be considered. There are some challenges to this process as far as how to manage it and track the use of features in examples but those are details, the overall goal should come first and we should find something we can do today and define what we need in the future.
Your Ideas
If you have any other things you’d like to see in examples or LabVIEW to help get you up and running as well as develop your applications please share your ideas by commenting on this post, I’ll be sure to catalog them and share them.
Posted by Kamran 
Posted by Kamran 
Posted by Kamran 
