Site News  |   Monitor Keywords  |   Monitor Archive  |   Organizer  |   Account Info  |

Asynchronous wires for graphical programming

The present invention relates to the field of graphical programming, and more particularly to a system and method for asynchronous communication in a graphical program.

Traditionally, high-level text-based programming languages have been used by programmers in writing application programs. Many different high level text-based programming languages exist, including BASIC, C, C++, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level text-based languages are translated to the machine language level by translators known as compilers or interpreters. The high level text-based programming languages in this level, as well as the assembly language level, are referred to herein as text-based programming environments.

Increasingly, computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.

There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptualize a problem or process and then to program a computer to implement a solution to the problem or process. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his solution, the efficiency with which the computer system can be utilized often is reduced.

To overcome the above shortcomings, various graphical programming environments now exist which allow a user to construct a graphical program or graphical diagram, also referred to as a block diagram. U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical programming environment which enables a user to easily and intuitively create a graphical program. Graphical programming environments such as that disclosed in Kodosky et al can be considered a higher and more intuitive way in which to interact with a computer. A graphically based programming environment can be represented at a level above text-based high level programming languages such as C, Basic, Java, etc.

A user may assemble a graphical program by selecting various icons or nodes which represent desired functionality, and then connecting the nodes together to create the program. The nodes or icons may be connected by lines, referred to as “wires”, representing data flow between the nodes, control flow, or execution flow. Thus the block diagram may include a plurality of interconnected icons such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables and/or producing one or more output variables. In response to the user constructing a diagram or graphical program using the block diagram editor, data structures and/or program instructions may be automatically constructed which characterize an execution procedure that corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer.

A graphical program may have a graphical user interface. For example, in creating a graphical program, a user may create a front panel or user interface panel. The front panel may include various graphical user interface elements or front panel objects, such as user interface controls and/or indicators, that represent or display the respective input and output that will be used by the graphical program, and may include other icons which represent devices being controlled.

Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, modeling, simulation, image processing/machine vision applications, and motion control, among others. Graphical programs may be referred to herein as “virtual instruments” (VIs), and nodes that represent graphical programs or graphical subroutines may be referred to as sub-VIs.

However, in data flow based graphical programs, the wires used to communicate between graphical program nodes (which may themselves be or represent graphical programs) are subject to data flow rules or protocols. For example, in graphical programs that are data flow diagrams, a node will not execute or “fire” until all data inputs to the node are present, and thus communication between nodes via current data flow wires is constrained to be synchronous, which may limit the functionality and execution of graphical programs, especially those that include multiple (substantially) concurrently executing portions, e.g., nodes, VIs, sub-VIs, or other graphical program elements or constructs, which may be referred to herein generally as nodes. In some prior art approaches to asynchronous communication between nodes, variables, such as local or global variables, or queues, may be used to pass data back and forth between the nodes. For example, applications that include communicating concurrent loops typically require queues or global variables to transfer data between the loops. However, there is currently no graphical way of depicting this connection, and moreover, it is not very convenient to construct. For example, using global variables only provides the name association, and using built-in queues involves a non-intuitive construction where the queue is allocated at the top level diagram and the reference is passed down both to the writer and to the reader.

FIG. 1 illustrates communication between two while loops 102 and 104 via a shared variable, where, as may be seen, a random number is generated by a first node 103 represented by an icon of a pair of dice and contained in the top while loop 102, and placed in or written to a numeric variable, labeled “numeric”. The numeric variable is then accessed or read by a second node 105, in this case, an add node (a triangle node labeled “+1”, contained in the bottom while loop 104), and the value incremented by 1, and the result displayed (as a double).

As may be seen, there is no explicit indication of the variable-based means for communicating between the while loops, and so, for program nodes, elements, etc., that are not placed near one another, it may not be clear that such communication is occurring or accommodated, possibly leading to confusion, and/or programming or operational errors.

Thus, improved means for asynchronous communications between graphical program nodes are desired.

Various embodiments of a system and method for enabling asynchronous communications in a graphical program are described. A first node and a second node may be displayed in a graphical program, where the graphical program includes a plurality of interconnected nodes that visually indicate functionality of the graphical program. Each of the first and second nodes preferably has a respective functionality, and includes a respective terminal. In other words, each node may include a terminal for connecting or wiring the node to another graphical program element, such as another node, for sending and/or receiving data to and/or from the other node. The graphical program may implement a measurement function that is desired to be performed, e.g., by one or more instruments. In other embodiments, the graphical program may implement other types of functions, e.g., control, automation, simulation, and so forth, as desired.

An asynchronous wire may be included in the graphical program, where the asynchronous wire connects the first node and the second node via their respective terminals. In other words, a first end of the asynchronous wire may be connected to the terminal of the first node, and a second end of the asynchronous wire may be connected to the terminal of the second node. For example, in one embodiment, the nodes may be specified or intended respectively as source and sink nodes with respect to communication between the nodes. However, it should be noted that in other embodiments, the asynchronous wire may facilitate or implement two-way communication between the nodes, i.e., from the first node to the second and from the second node to the first.

The asynchronous wire may be configured for asynchronous communication between the first and second nodes. For example, various attributes of the asynchronous wire may be configured or set to facilitate asynchronous communication between the first node and the second node. In one embodiment, these attributes may include one or more of: a data structure type included in or used by the wire, e.g., a first in first out (FIFO) queue; a buffer size for the asynchronous wire; read policy, e.g., block reads if the buffer is empty or uninitialized, remove the element upon a read from the buffer (e.g., destructive/non-destructive reads), read chunk size, etc.; write policy, e.g., block all writes to the buffer if the buffer is full, overwrite if the buffer is full or always, write chunk size, etc.; initial value on the wire; directionality of the asynchronous wire; and semantics of wire splits, i.e., how branching of the wire may affect communications using the wire, among others. Note that the various policies specified for use of the asynchronous wire may accommodate various models of computation (MoC) for the graphical program, including, for example, Kahn Process Networks (PN) and Communicating Sequential Processes (CSP), among others.

In some embodiments, the asynchronous wire may have a default configuration, i.e., one or more of the attributes may be preset with default values. Thus, the configuration of the asynchronous wire (at least with respect to the default valued attributes) may effectively occur when the wire is included in the block diagram of the graphical program. Of course, even were some or all of the attributes to have default values, subsequent configuration of the asynchronous wire, e.g., by the user or by another process, may overwrite these default values with new values. In other words, configuring the asynchronous wire may include overwriting at least one of the default values for the one or more attributes of the asynchronous wire with a respective at least one new value.

In one embodiment, a user may be able to configure a terminal on a node to be “asynchronous”, after which wires connected to this terminal may have asynchronous behavior. In other words, connecting a wire to an asynchronous terminal may automatically invoke creation or instantiation of an asynchronous wire, e.g., via conversion of a normal “synchronous” wire to the asynchronous wire, or replacement of the normal wire with the asynchronous wire. Users may then click on the asynchronous wire and configure its run-time behavior, such as the size of the queue and the read/write policies (blocking/non-blocking, destructive/non-destructive reads), as described above. In other words, once a terminal of a node is configured to be asynchronous, any wire connected to that terminal may automatically be configured as an asynchronous wire.

In one embodiment, the asynchronous wire and/or the terminal(s) may be configured via invocation of a graphical user interface (GUI), e.g., one or more dialogs, menus, property pages, attribute nodes, etc., e.g., by the user right-clicking on the asynchronous wire or terminal. The user may then select or input values for various attributes of the asynchronous wire or terminal. Alternatively, or additionally, the asynchronous wire and/or the terminal(s) may be configured via input from another process, such as a graphical program generation program or wizard. For example, in the case of a wizard, the user may provide input to various panels or dialogs specifying the attributes. Thus, in various embodiments, configuration information for the asynchronous wire and/or the node terminals may be provided by a use via a GUI, and/or programmatically by another process, e.g., another program.

The graphical program may then be executed. In preferred embodiments, executing the graphical program includes executing the first and second nodes, where the first and second nodes communicate asynchronously during the execution of the first and second nodes.

Thus, the asynchronous wire may allow users to create a static connection between nodes in a graphical program (e.g., a block diagram of the graphical program) to facilitate asynchronous communication between the nodes. In some embodiments, this connection may be depicted as a special, asynchronous, wire with a specific graphical appearance. For example, in one embodiment, the asynchronous wire may have a 3D tube-like appearance, although any other appearance may be used as desired. In some embodiments, the directionality of the asynchronous wire may also be indicated, e.g., via an arrow or multiple arrows, displayed on or near the asynchronous wire.