Skip navigation

Community

1

If any of you subscribe to Joel on Software, you may have come across this article where he provides a 12-step checklist for developing quality software. These recommendations are just as true of LabVIEW development as they are of any other programming language:

 

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

 

In Joel’s opinion, if you can’t answer ‘Yes’ to at least 10 of these, you have serious problems with your development process that could slow you down and lead to low-quality code. I went through these with NI’s NPI process in mind and happily scored a 12.

 

As a LabVIEW developer, if you would like to share insights or feedback on any of these topics, we’re eagerly hoping to hear from you…


Originally posted by ekerry at http://ekerry.wordpress.com/2009/04/10/applying-12-steps-to-better-software-to-l abview/

0

To anyone who is afraid or worried about upgrading, we hear you and we’ve made changes to help.  Back in January of this year, David Fuller wrote an entry on John Pasquarette’s blog describing what we’re doing in R&D to reduce problems associated with upgrading.  To summarize:

  • Our move towards an annual release schedule results in incremental changes and updates, which mitigates the risk associated with introducing several completely new features at once, as we did with LabVIEW 8.0.
  • The regular release cycle provides more opportunities for guidance from customers as features evolve - consider the changes to the LabVIEW Project Explorer between 8.0 and 8.5 as an example of this evolution.
  • Internal alignment across all teams means better coordination between all software products, drivers, and hardware

However, it’s important to realize that there is something you can do to help.  Try the Beta of LabVIEW 2009.  Upgrade issues are top priority for us - the trick has always been finding these problems, and for that we need your help.

 

As of April 2nd, the entire platform of the next version of LabVIEW is now in Beta and available for your evaluation - this means all software, toolkits and drivers.

As always, the new version contains new features that aim to improve developer productivity and application performance.  To see a list of new features and provide feedback to the community, click here.

Finally, for more resources on best-practices for upgrading your application, consult this guide on ni.com.


Originally posted by ekerry at http://ekerry.wordpress.com/2009/04/03/taking-a-bite-out-of-upgrades-and-prepari ng-for-labview-2009/

5

The flexibility of front panel objects in LabVIEW is something many people, including myself, take for granted.  We quickly drop down charts, knobs, and sliders, leaving them unchanged, and as a result, most LabVIEW programs have an unmistakably similar look and feel.  Of course, this makes it much easier to spot in a lab or during cameo appearances on shows like MythBusters, but many people are looking for ways to make more impressive and even 'sexy' user interfaces.

 

The success of commercial products like the iPhone are clear examples of the growing desire for intuitive user interfaces, but the world of engineers and scientists is not exempt.  There are a lot of practical reasons why a clear and appealing UI is valuable for a large LabVIEW application, as it can reduce learning curves and improve the effeciency of the user.

 

What many LabVIEW developers don't realize, is the level of customization and flexibility that LabVIEW controls and indicators provide.  Realizing this, my friend and colleage, SimonH, set out to see just how easy it would be to make some impressive controls and indicators for LabVIEW that broke the mold.  He's posted his first few examples in his new UI Interest Group, but I happen to know he's got a lot more up his sleeve.  Join his group and look for more soon!

 

http://decibel.ni.com/content/servlet/JiveServlet/downloadImage/102-4028-2-3603/ni.com+theme+-+Preview+Image.png

Here's another particularly slick user interface that was made in LabVIEW for OptiMedica

LV UI.png

0

About a month ago I wrote a blog on LabVIEW application architectures, but I wanted to supplement that with links to more advanced resources that are specific to certain applications and offer a more holistic insight into the task of architecting your LabVIEW application.

 

  • A Primer for Machine Control - If you're building a large system for machine control using CompactRIO and aren't sure where to start, this should help.  It includes example applications and insights into networking and how to manage multiple tasks.

 

 

  • TestStand Architecture Series - as automated test systems are becoming larger and more complex, it's becoming increasingly important to architect your code to ensure scalability, quality and re-usability.  This series of content was written largely by NI Alliance Partners who have extensive experience with applications of this nature.

 

Architecting applicatioins in any language is one of the biggest challenges any software programmer faces.  Compared to the task of designing code, the task of actually developing it is often the easiest par.  Without carteful consideration, many programmers get the 're-factor' twinge about half-way into the development process.  If any of this sounds familiar, spend some time looking through these resources to get some insight into paradigms that might help you and your application succeed.

0

I read a great article in The Economist this morning entitled 'Software that makes Software Better.'  This article discusses the growing role and importance of development tools for improving the quality of software and talks about the growing challenge developers face.

 

This article is proof of how far we've come in the last half-century.  We're seeing a number of trends converge and software engineers are struggling to keep up.  Development times are shorter, team size is bigger, the criticality of the applications is increasing, the expectations for quality and reliability are greater, code has to be modular and re-usable, and on top of all this, developers are expected to learn how to use numerous, poorly integrated tools that claim to make everything easier.

 

I've had a number of engineers, especially those in the mil/aero industry, tell me that they spend a mere 20% of their time actually developing code.  This may be slightly over-exaggerated, but a study conducted by the Standish group revealed that this number was closer to about 30%.  The rest is dedicated to refining requirements, discussing work with teammates, documenting, unit testing, integration testing... you get the picture.

 

The good news is that we're making progress.  As another study revealed, the Standish group "found that 35% of software projects started in 2006 were completed on time, on budget and did what they were supposed to, up from 16% in 1994; the proportion that failed outright fell from 31% to 19%."

 

LabVIEW is being used in larger applications, with larger code bases, and larger development teams.  Of course, graphical programming inherently abstracts many of the common tasks text-based developers struggle with during development, and with a set of tightly integrated software engineering tools, we aim to automate and improve the experience of applying software engineering practices to LabVIEW.  If you're interested in learning more about best-practices for software engineering with LabVIEW, visit ni.com/largeappsor go to ni.com/SoftwareEngineering to see a list of products that can help.

0

There is perhaps no more appropriate place to announce the arrival of two new toolkits for large application development than here in the Large LabVIEW Application Community.  The Desktop Execution Trace and Unit Test Framework Toolkits have been introduced to automate common practices for software engineering and help developers improve code quality.

 

The Desktop Execution Trace Toolkit facilitates dynamic code analysis for low-level debugging of applications during runtime.   The Unit Test Framework is designed for automated unit testing and requirements-based validation of software.

 

Feedback from users in highly regulated industries was one of the primary motivations for creating these products.  As we continue to invest in LabVIEW for large applications, we are benefited by feedback on these products and the needs of our users.

 

So to those of you who have had a chance to use these and similar tools, please use this community as an opportunity to share and exchange your ideas.  We look forward to hearing form you.

1

One of the most appealing things about LabVIEW is that you don't need to be a computer scientist to write fairly large and complex software. For many, their journey with LabVIEW starts in school or at a benchtop with a simple application to quickly acquire some data. Once they're hooked on the ease of graphical programming, it's only a matter of time beforethe ideas start flowing, and pretty soon they're off developing amazing applications like a mind-controlled wheel chair, the world's largest particle accelerator, or how about a 3D Space Ship that flies through a starflied.

 

The problem is that the same approach people use when throwing together a prototype or a proof of concept will land them in a world of pain if they don't ever stop and consider fundamental questions like, "how should I architect this application?" All too often, I see the tangled mess of spheghetti code emerge as the result of thoughtless, or ill-planned development.

 

badCode.pngFor most people, their very first experience with LabVIEW leads to messy, un-readible code.  Even LabVIEW gurus have humble beginnings.  The expert G developer, D Natt, was kind enough to send me a screenshot of his very first LabVIEW program. Let the image on the right serve as an example of what not to do. If you find yourself wishing you had 8 more screens to see a single block diagram, or if your block diagram looks anything at all like this one, you may want to consider giving more thought to the architecture of your application. As an exercise, see how long it takes to determine what the VI on the right actually does.

 

It's important to realize that spaghetti code is not unique to LabVIEW. As someone who started with text-based languages, I've seen plenty in all sorts of different languages. The difference is that it's a lot easier to write graphical code that will run, even if it's completely illegible. When the result doesn't work correctly or yields unexpected performance, it can be very difficult to debug and many prefer to point the finger at LabVIEW rather than acknowledge their own lack of foresight or experience.

 

So lets turn our attention to how we can architect our LabVIEW application. Start with the main problem you're trying to solve and figure out what the software needs to be able to do in order to be considered 'succesful.' The criteria that emerges from this assessment will help you make informed decisions about how the code should be structured. This is, in many cases, the product of experimenting, prototyping and developing proof of concepts that highlight the areas of difficulty and help you understand what type of information or data will need to be shared between different 'pieces' of an application.  At this point, we need to take a step back and make sure we understand design patterns.

 

LabVIEW Design Patterns.pngA 'Design pattern' refers to a template that serves as the building blocks for software. If you have an application that requires a responsive user interface, consider how many other developers have been faced with the exact same requirement. You're not alone, and there's no reason you should be starting from scratch. Design patterns are universal to programmers in any programming language. They save you time by helping you avoid reinventing the wheel and give us the solutions to common problems that have evolved over time to be the best, and most appropriate solution. If you're new to design patterns, check out the File >> New dialog in LabVIEW (show on the left). This is a great place to get started with some basic design patterns that are very specific to LabVIEW. Be sure to read the descriptions to understand exactly what problemsthey can best help you solve.

 

I also recommend visiting expressionflow.com. Anthony Lukindo wrote an excellent, indepth article on the QSM-PC (Queued State Machine - Producer / Consumer) design pattern, which is a fairly common and very useful pattern for a-sychronous computations in a fairly large application.

 

For those of you familiar with text-based design patterns, AristosQueue posted a great article filled with examples of how to map classics like the Factory Design Pattern to LabVIEW using object-orientation.

 

The JKI State Machine also serves as another great template for developing clean code.

 

Architecting a high-quality piece of code ensures that it's readible, scalable, maintainable and reduces the chance that errors or incorrect behavior will occur. I've focused a lot on design patterns, but don't lose sight of the fact that just is one small piece of the puzzle. You'll also want to think about how the application can be modularized and design APIs early on. Oh and of course, documentation is paramount.

 

One final word of caution: keep it simple and pick the archicture best suited to what you're doing. But as always, have fun

0

I had a thread on the LAVA forums brought to my attention on the topic of 'What is your LabVIEW application development process?, Best and worst development practices?'  This thread prompted an interesting discussion regarding some of the common challenges developers face when tackling a large application.

 

One of the primary goals of creating this group in the new NI community was to foster conversation and dialog amonst those of you working on these large LabVIEW applications and to share your insights on what you've learned from experience - both good and bad.  I'm excited to see that this same exchange is taking place in a number of different venues, including the thread that I stumbled across and the new wiki on LAVA dedicated to Software Engineeringhttp://zone.ni.com/devzone/cda/tut/p/id/7117

 

Several people mentioned the difficulty of requirements management in this thread.  The consensus amongst software developers is that requirements gathering is a difficult art to master, but the fact is that it can be extremely costly if overlooked.  After analysis of 63 different software projects at companies such as IBM, GTE and TRW, we can actually put a number next to the 'cost of getting it wrong'

Cost of getting it wrong.png

The fact is that LabVIEW often falls victom to oversight of requirements as well as a lack of due dillegence for other software engineering practices due to the fact that it is so commonly used for rapid prototyping of small applications.  Too often, I've seen developers try to scale these initially small projects into much larger and more complex systems without giving proper thought to requirements and especially to code architecture.  Good requirements are typically generated as a result of iteratations between prototyping and documenting the findings of prototyping, which then lend themsleves to proper archiecture and better insight into how an application should be designed and help developers apply sound software engineering practices to ensure quality and reliability.

 

If you're interested to learn more about requirements management with LabVIEW, check out some of these links.

2

Is LabVIEW A Programming Language?

 

Yes.

 

As a LabVIEW fanatic and enthusiast, I commonly field this question from customers and text-based programmers on a regular basis.At first glance, graphical programming appears abstract and so radically different from C and similar languages, that for many it’s hard to grasp how this grid of wires and colored blocks could possibly represent code.

 

  While studying for my degree in computer engineering at the University of Missouri, I regularly programmed in C++, Java, and spent many long hours in labs going through the painful process of writing x86 assembly and even VHDL.I was also an avid web developer and had written many programs in a combination of HTML, PHP and Adobe Flash for a research lab at the school.Sadly, I had never used LabVIEW or graphical programming, but I did have one friend who kept egging me on to try it out.He claimed it would make my life much easier and that I could do all the same things I was already doing in a fraction of the time.

 

When I finally learned LabVIEW after beginning work at National Instruments, it was like a whole new world had opened up to me.It all made so much sense and I found myself wishing I’d listened and saved myself many all-nighters in college.

 

If you look back at 1986, the year LabVIEW 1.0 was released; graphical programming was a part of the natural progression. Apple had just announced the first graphical user interface ever for the commercial market.The use of computers had previously been entirely through the command-line and it seems logical that only text-based programming was around up until then.

 

Enter graphical interfaces… enter graphical programming.It was simple at the time, but the concept of dataflow made the representation of information and the relationships between operations to be performed much more apparent and easy for someone without a programming background to understand. It took off and became the foremost tool for anyone who wanted to control a bench top instrument and perform analysis in software.

 

  These days, LabVIEW has evolved dramatically.  The abstraction LabVIEW provides still enables scientists and engineers to solve complex problems without worrying about lower-level details, but it still has the ability to control more granular aspects of your application and push that same graphical code down to the pin with FPGAs and embedded targets.What would’ve taken dozens of pages of VHDL can now be accomplished with just a few simple VIs in graphical code.LabVIEW is object oriented and open; developers can re-use libraries developed in .NET or other languages.Users can build professional, end-use applications for commercial re-sale.

 

The flexibility of the development environment even allows users to combine different models of computation within a single application.Dataflow can be combined with text-based *.mfiles or tools like Statechart to take advantage of the strengths of every paradigm.All of these different models of computations are compiled by LabVIEW into a single binary.

 

Because of the abstraction that is inherent to graphical programming and the investment we’ve made in the compiler, LabVIEW is even smart enough to perform optimizations in the background that result in performance that can often exceed that of text-based counterparts.This is especially true when optimizing applications for multiple cores, which is a growing concern as the personal computer continues to offer consumers more and more cores within a single machine without any significant gains in clock frequency.

 

At National Instruments, we even develop many of our software products and a large portion of LabVIEW itself in LabVIEW.For those of you who use Vision Builder, you’re using a LabVIEW application that spans roughly 5,000 VIs and is developed by a team of about 3 individuals.The fact is that LabVIEW is a programming language in every sense of the word and it presents users with more options and more flexibility than other monolithic environments.

 

Why do so many people still refuse to believe LabVIEW is a programming language?Perhaps after 23 years of development, LabVIEW is still just that far ahead of its’ time.

 

Share your thoughts on LabVIEW as a Programming Language!  Leave a comment below.

0

Anthony Lukindo wrote an excellent article on expressionflow.com that explains how to utilize a queued state machine architecture with multiple producer / consumer loops.  The example he uses in this article draws from several of the fundamental design patterns that should serve as the building blocks for almost any new LabVIEW application (see image below).

 

PC-QSM.png

 

If you've never seen them, make sure you review the design patterns that ship inside of LabVIEW as starting points for your applications - even simple ones.  You can navigate several Frameworks for development by clicking File >> New in LabVIEW.  The dialog that will appear is shown below.  Note the descriptions for each design pattern under the image on the right.

 

LabVIEW Design Patterns.png.

If any of you want to add your own design patterns to this dialog, you can.  This is potentially useful for groups of developers who would need to use a common, custom template regularly in their work.

To add a template, follow the pattern used for the existing patterns, which can be found here: C:\Program Files\National Instruments\LabVIEW 8.6\templates\Frameworks\DesignPatterns

This should include a png thumbnail and *vit template file.  Don't forget to enter descriptions in the VI Documentation Property so that users will know what they're getting themselves into!

1

Since this is my first blog entry, I feel it’s only appropriate that I begin with a discussion about how to start developing a LabVIEW application.  These days, it’s not uncommon for some of the more complex LabVIEW applications to span thousands of VIs, which can pose a number of challenges if not given proper thought.  What many don’t realize is that they can simplify their life and perhaps keep more of their hair by knowing how to use some best-practices combined with some of the latest tools in LabVIEW.

And this is true for all applications, large and small - be it one developer or 50.

The nature of graphical programming offers scientists and engineers a clear advantage when it comes to reducing development time and rapidly prototyping complex systems that need to interface with hardware.  However, as a result, many jump directly into writing code without really giving proper consideration to some of the more mundane practices.  Is this you?  Have you ever thought to yourself…

·         “My files are so disorganized - I don’t even know if I’m working on the latest copy of my code!”

·         “Oh no, someone else overwrote all my work with their changes – I just lost a week’s worth of work!”

·         “I’m too scared to rename or move subVIs because LabVIEW will never find the right ones and I’ll have to re-link them all!”

·         “I want to compare my latest changes with a previous version to examine exactly what the differences are!”

If you’re anything like me, you’d probably rather be coding in LabVIEW than thinking about any of these things, but I’ve seen too many developers paint themselves into a corner by ignoring some of these until the last possible second. This is not an exhaustive list, but for the sake of today’s entry, we’ll keep it simple.

For anyone reading this that comes from a Computer Science or Software Engineering background, you’ve probably already heard of SCM, or software configuration management.  For those of you who have no idea what I’m talking about, this just refers to a combination of tools and practices that developers have been using for years to avoid some of these common problems.  I’m going to discuss some of the tools that you can take advantage of in LabVIEW.

Perhaps the most fundamental and important tool for any and all LabVIEW developers is the Project Explorer.  Those of you who have just recently transitioned from 7.1 or earlier may still be fighting adoption, but hear me out – this tool was designed to make your life easier - you just have to know how to use it.

The Project debuted with LabVIEW 8.0 to mixed reviews.  For many who had grossly outgrown using their operating system’s file browser (ie: Windows Explorer or Finder) to manage all their files, the Project Explorer was a welcome relief and had a lot of potential.  However, as with any completely new features, there was plenty of feedback and discussion on what could be improved.

Fast forward two years.  LabVIEW 8.5 came out in August of 2007, and with it came a revamped version of the Project that incorporated much of the feedback we’d been hearing from you.  It is this version and all the latest features that I’m going to be discussing in this entry.

Project Explorer.jpg

This is a screenshot of a Project in LabVIEW 8.6 that happened to be open on my computer while writing this blog.  It’s true – I code in LabVIEW for fun whenever I can, but I always use the Project and source code control (note the checkboxes).  Friends don’t let friends code without the Project.

I have a golden rule that I preach to all LabVIEW developers who are just starting out with the Project: “Think of the Project Explorer as an opportunity to tell LabVIEW: ‘here are my files – this is what I intend to use in my application – nothing more, nothing less.’ By doing this, LabVIEW is smart enough to help you make informed decisions and manage your application.”  To clarify, you can and should use the Project to manage all of your files – not just the VIs.  Note that in my screenshot I have VIs, as well as PDfs, videos, DLLs, documents – anything and everything related to my application.

So what exactly can LabVIEW’s Project Explorer tell you if you use it correctly?  It can show you your entire system – including all the hardware targets and build specifications your project uses.  It can warn you when you’re potentially using the wrong subVI.  It can tell you when moving or renaming a file will change a link from another caller.  It can instantly tell you when you’ve added a new file on disk.  It can tell you when someone else is modifying a file and help you track down the latest version of that file.  It can show you, graphically, the differences between your revisions and the last changes someone else made (also known as ‘diffing’).  The Project Explorer can even tell you if you’re breaking my golden rule (subVIs you haven’t yet added appear in a flat list under dependencies).

For those of you scratching your head at source code control (SCC), I’m referring generically to third party tools that are commonly used for large application management.  They essentially serve as an intermediate layer between you and the centralized storage location for all your code.  You, as a developer, communicate with SCC by telling it things like “I’m going to modify this VI.”  Through this exchange of information, other developers can then be made aware of potential changes, which avoids overwriting work and helps the rest of your team know when changes were made and who made them.  SCC is beneficial even for individuals who just need to keep track of all of their revisions.  I myself keep a Perforce server on my laptop which I use to store and manage all of my side projects (Perforce is free for individual use – check it out at perforce.com).

Interested in learning about how to set up the Project Explorer to take advantage of all these features?  You can find technical details on all the topics I’ve mentioned here and more on this wiki: Managing LabVIEW Application Development in the Project Explorer.  This guide provides best-practices and technical how-to’s for using the Project, so be sure to check it out and let me know if you have any questions or feedback.

1 2 3 4 Previous Next