Abstract: This paper analyzes the characteristics of the LabVIEW dataflow language and provides several effective control methods. It points out that LabVIEW itself can solve problems such as variable conflicts, response timing control, and adaptive initial state adjustment in dataflow control while ensuring its versatility, without needing to resort to other coding languages (such as C). This reduces program complexity, improves efficiency, and enriches the applications of LabVIEW. The paper details specific solutions to problems such as variable conflicts, response timing control, and adaptive initial state adjustment using a radio button design example. The feasibility and effectiveness of these methods are verified in the actual operation of a certain type of equipment testing system.
Keywords: data flow; LabVIEW; variable conflict; timing control
Abstract: The character of LabVIEW dataflow programming is analyzed and some methods on the control of dataflow in LabVIEW are given. Problems such as variable conflict, time responding sequence control and initial status self-adjustment are able to be settled out without using other codes (eg C language), so that the programming complexity is less and the efficiency is higher and the application of LabVIEW is more extensive. The example of the design of single-activated buttons is detailed showing how to solute the problems above concretely and the experiment result running on Some measurement systems proves the solution is feasible and reliable.
Keywords: dataflow;LabVIEW;variable conflict;time responding sequence control;initial status self-adjustment
0 Introduction
LabVIEW (Laboratory Virtual Instrument Engineering Workbench) is the originator of the concept of virtual instruments and is the world's best virtual instrument software development platform [1][2]. It uses a graphical dataflow programming language, and this emerging programming method has brought new difficulties to programmers, mainly in the control of data flow. LabVIEW programmers often turn to C language when they encounter difficulties [3]. With the widespread application of virtual instruments, it is necessary to truly understand and flexibly master the LabVIEW dataflow language in order to improve programming efficiency.
1. Characteristics of Dataflow Programming
Each node in a dataflow language requires valid data from all its input ports before execution. LabVIEW allows users to have any number of different nodes on a graph, and all nodes can execute in parallel. The LabVIEW environment also supports the parallel execution of multiple VIs, regardless of the operating system or computer capabilities. These features allow users to freely and synchronously execute various different tasks without performing any special programming work.
LabVIEW dataflow programming overcomes many of the difficulties of memory management in text-based programming languages. In LabVIEW, there's no need to allocate memory for variables, assign values to variables, or retrieve values from variables; you simply create a block diagram program that describes the internal relationships between data transformations. Functions that generate data can carefully allocate memory for that data, and the corresponding memory is released when the data is no longer needed. When new data is added to an array or string, sufficient memory resources for managing the new data are automatically allocated—this automatic memory allocation is one of LabVIEW's main advantages.
2. Challenges and Solutions in Dataflow Programming
LabVIEW programs manage memory automatically, making the capture and control of intermediate states extremely difficult. For example, issues such as real-time display of the maximum value of the field-acquired data string, manually controlling the data string at a specific moment for comparison via a button, and implementing radio button functions are all seemingly simple but actually challenging. Based on programming practice, the following solutions are summarized:
(1) Structural control
Loop structures, such as For and While loops; Sequence structures, which can improve program readability and allow data to flow clearly when used appropriately; Case structures; Event structures, which allow users to directly intervene in the front panel or communicate between different parts of the program to influence program execution; and Timed Loop structures, which can create multi-rate, time-critical data acquisition applications and define loops with different priorities.
(2) Shift Register Control
Shift registers, when combined with While or For loops, can save various state information; uninitialized shift registers retain their previous contents.
(3) Variable control
Variables here refer to local variables and global variables. Local variables are used to pass data within a single VI program. They not only solve the difficulty of wiring but also allow data to be written to and read from the same control multiple times. Global variables, on the other hand, can be used to pass data between different programs. Global variables also store data in the form of a control, but this control is independent of the VI that calls it, using a special VI as its container.
(4) Notifier and Queue Control
Notifications and queues can sometimes replace variables for data transmission. When using notifications, data can only be read after it has been written and announced. Notifications are broadcast, and any user who receives the broadcast can read the data. Queues, on the other hand, erase the data after the first user reads it, ensuring only one user receives the data at a time. Using only one of these methods in isolation is often insufficient; a comprehensive and flexible approach is necessary to achieve better results in programming.
3 Case Analysis
The design of radio buttons is a common part of many integrated test system designs. It is required to perform the following functions:
(1) When one button is pressed, all other buttons are in an inactive state.
(2) The button that is pressed should be able to activate the system’s function without error.
The following issues need to be addressed in the design:
(1) Variable conflicts. The program involves mutual control between buttons, and conflicts between controls and local variables are particularly prominent;
(2) Response timing control. The order of button operation and button status reading needs to be adaptively controlled; otherwise, abnormal situations such as gaps (buttons being pressed but the system function not being activated) and multiple buttons being pressed simultaneously may occur, leading to program disorder.
(3) The problem of adaptive adjustment of the initial state.
The following is an illustration of the flowchart and its diagram design using LabVIEW:
BUTTON ARRAY: An array of buttons grouped together;
SEARCH 1D ARRAY: Compares two arrays and returns the index of the distinct element;
INDEX ARRAY(INDEX, ELEM): An array ARRAY, where INDEX is the index and ELEM is the element. This function finds the element in the array ARRAY whose index is INDEX.
NULL: No operation;
DIFFERENCES: Difference information;
DB: Digital buttons, which are buttons that are numbered to represent different buttons.
The overall process involves looping the process shown in flowchart 1 twice, and then performing the process shown in flowchart 2. The specific steps are detailed below:
To address problem (1), the program follows the principle of "do not operate on buttons that are to be operated." As shown in block diagram 1, the SEARCH 1D ARRAY function is used to identify the operated button, and other buttons are set to "false." In this way, conflicts between buttons can be avoided.
Flowchart 1
Flowchart 2
Regarding problem (2), the data "flow" process of the program must be fully considered. This is explained in detail below:
① Each time a BUTTON boolean value is read, it is necessary to consider whether there is any input to the button on the external interface, which is clearly reflected in block diagrams 1 and 2;
② It is crucial that Flowchart 1 loops twice. Consider the following scenario: if the external operation on the button occurs between BUTTON ARRAY (1) and BUTTON ARRAY (2), the button operation will not have any effect in the first loop, but it will transmit the button information to the beginning through a feedback mechanism. Since the program runs much faster than the manual operation speed on the human interface, there will be no external input in the second loop. Thus, the button operation will respond after the second loop, without being suspended. Similarly, when the external operation on the button is between BUTTON ARRAY (2) and read BUTTONs in Flowchart 2, the external operation on the button will take effect in the next loop (which will definitely be a large-scale loop operation in the actual test system). Since the program runs very fast, the operator sees the "real-time" operation. If it occurs after read BUTTONs, it will return to the beginning of Flowchart 1. Therefore, the program will run normally whenever the button is pressed.
Regarding problem (3), uninitialized shift registers can retain their original state. Before the program runs, if a button malfunction occurs, the program will immediately correct the malfunctioning button since it assumes one button is pressed.
For the implementation of digital buttons (see flowchart diagram 2), the button state is changed to 0 or 1. A continuous addition operation is used to determine whether multiple buttons, a single button, or no button is pressed at the same time based on the size of the sum, thereby leading out the button signal.
Figure 2. Examples of some LabVIEW programs
4. Conclusion
The reason we widely use C and other text-based languages to solve LabVIEW problems is precisely because our understanding of this dataflow control programming approach is not deep enough. This article provides several LabVIEW dataflow control methods, emphasizing that flexible application can solve problems encountered in actual programming. The design of a radio button is a typical example of dataflow control. The methods presented in this article for solving variable conflicts, response timing control, and initial state adaptive adjustment using LabVIEW itself do not use event-driven structures, thus avoiding conflicts that can arise from parallel use of event-driven structures in the test system. These methods have program and version universality and have proven to be feasible and effective in actual operation.
The innovation of this paper lies in its analysis of the characteristics of LabVIEW's dataflow language and its provision of several effective control methods. The methods presented in the paper for resolving variable conflicts, response timing control, and initial state adaptive adjustment using LabVIEW itself do not use event-driven structures, thus avoiding conflicts that can arise from parallel use of event-driven structures in test systems. This approach offers program and version universality without relying on other coding languages (such as C), thereby reducing program complexity, improving efficiency, and enriching the applications of LabVIEW.
References
[1] Yang Leping, Li Haitao, Zhao Yong, et al. Advanced LabVIEW Programming [M]. Beijing: Tsinghua University Press, 2003.
[2] Gary W. Johnson, Richard Jennings. LabVIEW Graphics Programming [M]. Beijing: Peking University Press, 2002.
[3] Zhou Guangqing, Chen Guangjie. Design of single-selection function keys in LabVIEW environment [J]. Medical and Health Equipment, 2003(5): 9-11
[4] Lei Zhenshan. Practical Technical Tutorial of LabVIEW7 EXPRESS [M]. China Railway Publishing House, 2004.
[5] Mike Trimborn. Bridging the gap with ease—LabVIEW 7 Express combines ease of use with powerful programming capabilities [J]. Today's Electronics, 2003(8): 58
[6] Feng Jinmei, Lian Zhiwei. Discussion on several issues in the use of LabVIEW [J]. China Manufacturing Informatization, 2003(9): 121-124
[7] Li Yang, Zheng Yingna, Zhu Zhengtao. LabVIEW graphical programming language environment and its openness [J]. Computer Engineering, 1999(4): 63-65
[8] Cai Jijun, Zhang Yanbin, Mi Xiaoyuan, Yao Shifeng. Design of Human-Machine Interface for Virtual Instruments Based on Event-Driven Programming. Microcomputer Information, 2005, No. 31: 119-121
