LabVIEW Novice 5 Big error

 

While NI LabVIEW software has long been helping engineers and scientists quickly develop functional measurement and control applications, not all new users will follow the best practices of LabVIEW programming. LabVIEW's graphical programming is unique, as it is immediately possible to see whether the user is following the best method of coding, just by looking at the user's application. Some users make these mistakes because they do not really understand the rationale behind the LabVIEW block diagram data stream, and some users do not know which features improve the quality of LabVIEW programming.

This article describes some of the most common programming errors that inexperienced LabVIEW programmers have made, as well as suggestions for using the correct LabVIEW programming approach.

Figure 1. LabVIEW Novice Typical "masterpiece"

Over-using tiled sequential structures

Many LabVIEW novices do not fully understand the concepts behind "data Flow" execution, which are the basis of LabVIEW programming. One phenomenon is that users tend to overuse tiled sequential structures in the program block diagram. Instead of using data flow and connection between nodes, users often rely on tiled sequential structures to implement code serial execution of the program block diagram.

Figure 2. Users tend to over-rely on tiled sequential structures without fully understanding the concept of data flow programming

Data flow programming means that the nodes (Sub VI, primitive, structure, etc.) on the block diagram begin to execute only when the required data input is all reached. This is useful for programmers using LabVIEW, because the standalone process itself can be run in parallel, whereas imperative languages require additional setup for parallel execution. As computer CPUs continue to grow, LabVIEW automatically decomposes parallel processes and improves code performance without the need for any additional code to be written by the user. Forcing the use of a tiled sequential structure to execute a program block diagram will not only limit parallel operation, but will also lose this advantage. Limiting the unnecessary structure in the program block diagram helps to improve overall readability and maintain a more concise block diagram.

Error lines can effectively implement the flow of data on the program block diagram without relying on tiled sequential structures, and error-handling strategies are also helpful.

When should I use a tiled sequential structure?

Using a tiled sequential structure to execute a program block diagram helps benchmark the performance of the code. By using a sequential structure with time counters within a frame, you can determine how long it takes for code execution between two time counters. This is not possible with general data flow execution.

Figure 3. Tiled sequential structure and time counter VI help benchmark your code

For more information on data flow programming, please visit the "Data Flow" of the online self-study training (ni.com/self-paced-training) LabVIEW Core course 1. Users who purchase LabVIEW or have a standard service item (NI.COM/SSP) membership can participate in online self-paced training free of charge.

Error using local variables

Another common mistake in LabVIEW programming is excessive use of local variables. A local variable is a region in shared memory that is used to pass data between different parts of a computer program. Local variables are commonly used in text programming languages and have a very powerful function, but if there is a race condition, problems can arise.

For other programming languages, passing data through variables is required, and LabVIEW provides a data flow method that moves data from one part of the program to another. The inherent parallelism mechanism of LabVIEW determines that the user cannot overuse variables because the shared memory is accessed by programs that typically have multiple different locations at the same time. If you overuse variables, a read/write operation will win "competition", while others lose "competition", the loss of data will be ignored, so excessive use of variables in LabVIEW may eventually result in data loss.

There are several ways to safely pass data from one part of the LabVIEW program to another, including lines, queues, events, notifications, functional global variables, and so on. Each mechanism is designed for a specific situation, but has the ability to eliminate competitive conditions.

For more information about moving data correctly within the LabVIEW program, visit the "local variables" of the online self-study training (ni.com/self-paced-training) LabVIEW Core Course 1 and the "Announcements, queues, and events" of LabVIEW Core course 2.

Ignore Code modularity

Typically, a new LabVIEW user creates a "write-and-forget" application to complete a simple task without taking into account whether the code will be used in the future. As programming works more and more, they will find themselves rewriting the same piece of code over and over again. If you create a modular sub VI that can be reused for other applications while programming, you can save a lot of development time.

If you know that a particular part of the code will be reused for the same application, or that the part of the code might be used for future applications, then you should take a moment to turn that part of the code into a sub VI. If you want to make a part of the code a sub-VI, you need to do is to add a document, use "terminal", disable some VI properties. One of the simplest ways to create a child VI is to highlight a portion of the code in the program diagram and choose Edit >> Create Sub vi from the menu bar. This part of the code will be placed in a separate VI, and then use "terminal". You still need to add a description for the icon, add the document to the program block diagram and the VI property, and then cancel some vi settings, but edit >> Create Sub VI helps you understand the modular functionality of the code well.

Figure 4. Modular operation with the right LabVIEW code can help you save a lot of development time

One of the settings that must be canceled when the code is modularized is "Allow debugging." You can find this option in the execution directory under VI properties (File >>vi properties). When the code is fully functional and you do not need to use the debug features such as highlight execution, cancel "Allow debugging" in the execution settings, and then run VI again. The benefit of this is that the application may run faster due to optimizations made during the compilation process, and the disk physical space taken up by VI is reduced due to the shutdown of the code that started debugging.

LabVIEW Novice 5 Big Error Time:2013-09-06 Source: NIKey words:LabVIEW

For more information on the modularity of the code, please visit the "Understanding modularity" of the online self-study training LabVIEW Core course 1.

Create a huge and cumbersome program block diagram

Many new LabVIEW users will write the program block diagram very cumbersome. For some complex applications, we will inevitably need to write a larger program block diagram, but a large program block diagram can also show that the program lacks the programming architecture. Without a basic architecture, it is difficult to maintain the program over the long term, and it can be very difficult to add new features later. Just as there is only one good framework to build a well-structured house, a good programming architecture can provide a secure and reliable framework for building your application.

Almost all programmers will find a common framework in which software architecture is very useful. In fact, many architectures in LabVIEW, such as producer/consumer and state machine, are very similar to other programming languages.

Understanding the architecture of LabVIEW can shorten development time and increase the scalability of your application. LabVIEW 2012 includes templates and project examples to make it easier to understand the architecture. The template explains the different architectures and applications. The project paradigm is a larger, template-based application that demonstrates how to use templates to address real-world challenges. You can add hardware to the sample project, or you can use the project paradigm as a monolithic application, while the project paradigm is open and the documentation is complete, so you can customize it for your specific application.

Figure 5. Examples of templates and projects in LabVIEW 2012 make it easy to understand software architectures

For more information on the LabVIEW architecture, please visit the "design mode" of the online self-study training (ni.com/self-paced-training) for LabVIEW Core course 2.

Do not attach importance to document records

A good code document can help others understand the program they write effectively. Unfortunately, many programmers often start writing documents after the end of the development cycle. This makes the time for documenting the code very little. The right approach should be to take the time to start documenting the documentation during the development process. Documents are also very useful to programmers themselves, especially when they come back to see the code for a while and don't remember why they chose some code. Programmers often drink coffee while staying up late programming, which tends to appear "short-term amnesia." The document can help the programmer to remember.

In general, the graphical nature of LabVIEW makes it easier to read programs than text-based programs, but effective documentation can reduce the time it takes to "decode" a program. The simplest way to add a document comment to a program block diagram is to use a free label. You can double-click in the blank position of the block diagram and enter text to add comments. Then, use the arrow markers to point to the specific code referenced by the free label. If you need to add pictures, you can copy them to the Clipboard and paste them into the program block diagram. Physical system pictures and mathematical formulas help clarify the code context within the program block diagram.

Figure 6: Well-architected and well-documented code can help others understand your code and help you better understand your code

Documenting the code is not just for the reuse library, but for each program. When a person needs to explain to someone else, he will have a deeper understanding of the subject. Document records are essentially forcing programmers to explain themselves to help them better understand their code.

LabVIEW Novice 5 Big error