U.S. patent application number 11/462393 was filed with the patent office on 2008-05-29 for asynchronous wires for graphical programming.
Invention is credited to Jeffrey L. Kodosky, Jacob Kornerup.
Application Number | 20080126956 11/462393 |
Document ID | / |
Family ID | 39030581 |
Filed Date | 2008-05-29 |
United States Patent
Application |
20080126956 |
Kind Code |
A1 |
Kodosky; Jeffrey L. ; et
al. |
May 29, 2008 |
Asynchronous Wires for Graphical Programming
Abstract
System and method for asynchronous communication in a graphical
program. A first node and a second node are displayed in a
graphical program, e.g., on a display device of a computer,
possibly in one or more respective loops. The graphical program
includes a plurality of interconnected nodes that visually indicate
functionality of the graphical program. Each of the first and
second nodes has a respective terminal. An asynchronous wire
connecting the first node and the second node via their respective
terminals is included in the graphical program, and configured for
asynchronous communication between the first and second nodes,
possibly including: configuring a data structure included in or
associated with the asynchronous wire, a buffer size, a read
policy, a write policy, and/or semantics of wire branching. The
graphical program is executed, including executing the first and
second nodes, where the first and second nodes communicate
asynchronously during execution.
Inventors: |
Kodosky; Jeffrey L.;
(Austin, TX) ; Kornerup; Jacob; (Austin,
TX) |
Correspondence
Address: |
MEYERTONS, HOOD, KIVLIN, KOWERT & GOETZEL, P.C.
P.O. BOX 398
AUSTIN
TX
78767-0398
US
|
Family ID: |
39030581 |
Appl. No.: |
11/462393 |
Filed: |
August 4, 2006 |
Current U.S.
Class: |
715/763 |
Current CPC
Class: |
G06F 3/0484 20130101;
Y10S 715/964 20130101; G06F 8/34 20130101; Y10S 715/967
20130101 |
Class at
Publication: |
715/763 |
International
Class: |
G06F 3/048 20060101
G06F003/048 |
Claims
1. A computer-implemented method for asynchronous communication in
a graphical program, the method comprising: displaying a first node
and a second node in a graphical program, wherein the graphical
program comprises a plurality of interconnected nodes that visually
indicate functionality of the graphical program, wherein each of
the first and second nodes has a respective functionality, and
wherein each of the first and second nodes includes a respective
terminal; including an asynchronous wire in the graphical program,
wherein the asynchronous wire connects the first node and the
second node via their respective terminals; configuring the
asynchronous wire for asynchronous communication between the first
and second nodes; executing the graphical program, wherein said
executing comprises: executing the first and second nodes; and the
first and second nodes communicating asynchronously during said
executing the first and second nodes.
2. The method of claim 1, wherein the graphical program is a first
graphical program, wherein the asynchronous wire is implemented by
a second graphical program, and wherein the second graphical
program is separate and distinct from the first graphical
program.
3. The method of claim 2, wherein being implemented by a second
graphical program comprises the asynchronous wire being implemented
by an instance of the second graphical program.
4. The method of claim 3, wherein the instance of the second
graphical program includes data transmitted by the asynchronous
wire.
5. The method of claim 2, wherein the second graphical program is
not viewable by a user of the first graphical program.
6. The method of claim 1, wherein at least one of the first and
second nodes is comprised in a respective loop.
7. The method of claim 1, wherein said configuring the asynchronous
wire for asynchronous communication between the first and second
nodes comprises configuring one or more of: a data structure
included in or associated with the asynchronous wire; a buffer size
for the asynchronous wire; a read policy for the asynchronous wire;
a write policy for the asynchronous wire; directionality of the
asynchronous wire; or semantics of wire branching.
8. The method of claim 7, wherein configuring directionality of the
asynchronous wire configures the asynchronous wire for one or both
of: one way communications between the first node and the second
node; or two way communications between the first node and the
second node.
9. The method of claim 1, wherein said configuring the asynchronous
wire implements a model of computation.
10. The method of claim 9, wherein the model of computation
comprises one or more of: Kahn Process Networks (PN); or
Communicating Sequential Processes (CSP).
11. The method of claim 1, wherein the asynchronous wire has a
default configuration comprising default values for one or more
attributes of the asynchronous wire.
12. The method of claim 11, wherein said configuring the
asynchronous wire comprises 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.
13. The method of claim 1, wherein said configuring the
asynchronous wire further comprises configuring the terminals of
the first and second nodes for asynchronous communication via the
asynchronous wire.
14. The method of claim 1, further comprising configuring one or
both of the terminals of the first and second nodes for
asynchronous communications, wherein after configuring a terminal
for asynchronous communications, any wire connected to the terminal
is automatically configured as an asynchronous wire.
15. The method of claim 1, wherein the graphical program is a data
flow program; and wherein the asynchronous wire does not operate
according to data flow protocol.
16. The method of claim 1, wherein the asynchronous wire includes
or is associated with one or more data structures for storing data
transmitted on the asynchronous wire.
17. The method of claim 16, wherein the one or more data structures
for storing data transmitted on the asynchronous wire comprise a
queue.
18. The method of claim 17, wherein the queue is implemented as one
or more of: a software data structure; a field programmable gate
array (FPGA) first in first out (FIFO) structure; or a real time
(RT) FIFO.
19. The method of claim 1, further comprising: including one or
more additional asynchronous wires in the graphical program
connecting at least a subset of the plurality of nodes for
asynchronous communication among the at least a subset of the
plurality of nodes.
20. The method of claim 19, wherein the graphical program includes
at least one cycle formed by at least some of the asynchronous
wires and nodes in the graphical program.
21. The method of claim 19, wherein at least one of the nodes in
the graphical program receives input from two different
asynchronous wires.
22. The method of claim 19, wherein at least one of the nodes in
the graphical program provides output to two different asynchronous
wires.
23. The method of claim 1, wherein the graphical program is
operable to perform one or more of: an industrial automation
function; a process control function; a test and measurement
function.
24. A computer readable memory medium that stores program
instructions for asynchronous communication in a graphical program,
wherein the program instructions are executable by a processor to
perform: displaying a first node and a second node in a graphical
program, wherein the graphical program comprises a plurality of
interconnected nodes that visually indicate functionality of the
graphical program, wherein each of the first and second nodes has a
respective functionality, and wherein each of the first and second
nodes includes a respective terminal; including an asynchronous
wire in the graphical program, wherein the asynchronous wire
connects the first node and the second node via their respective
terminals; configuring the asynchronous wire for asynchronous
communication between the first and second nodes; executing the
graphical program, wherein said executing comprises: executing the
first and second nodes; and the first and second nodes
communicating asynchronously during said executing the first and
second nodes.
25. A system for asynchronous communication in a graphical program,
comprising: a processor; and a memory medium coupled to the
processor, wherein the memory medium stores program instructions
for asynchronous communication in a graphical program, wherein the
program instructions are executable by a processor to: display a
first node and a second node in a graphical program, wherein the
graphical program comprises a plurality of interconnected nodes
that visually indicate functionality of the graphical program,
wherein each of the first and second nodes has a respective
functionality, and wherein each of the first and second nodes
includes a respective terminal; include an asynchronous wire in the
graphical program, wherein the asynchronous wire connects the first
node and the second node via their respective terminals; configure
the asynchronous wire for asynchronous communication between the
first and second nodes; execute the graphical program, wherein to
execute the graphical program, the program instructions are
executable to: execute the first and second nodes, wherein the
first and second nodes communicate asynchronously during
execution.
26. A system for asynchronous communication in a graphical program,
comprising: means for displaying a first node and a second node in
a graphical program, wherein the graphical program comprises a
plurality of interconnected nodes that visually indicate
functionality of the graphical program, wherein each of the first
and second nodes has a respective functionality, and wherein each
of the first and second nodes includes a respective terminal; means
for including an asynchronous wire in the graphical program,
wherein the asynchronous wire connects the first node and the
second node via their respective terminals; means for configuring
the asynchronous wire for asynchronous communication between the
first and second nodes; means for executing the graphical program,
wherein said executing comprises: executing the first and second
nodes; and the first and second nodes communicating asynchronously
during said executing the first and second nodes.
Description
FIELD OF THE INVENTION
[0001] 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.
DESCRIPTION OF THE RELATED ART
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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).
[0011] 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.
[0012] Thus, improved means for asynchronous communications between
graphical program nodes are desired.
SUMMARY OF THE INVENTION
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] Note that in preferred embodiments, an asynchronous wire
does not explicitly carry data at run-time, and so it may not be
considered as part of the data flow graph (of the graphical
program). This means that its fire count (i.e., iterative execution
count) may be ignored at run-time and that it may not use explicit
tunneling to cross structures. Instead the asynchronous wire may
visually "float" over structure boundaries, e.g., over the
boundaries of loop nodes.
[0022] In one embodiment, asynchronous wires may be evaluated
during a type propagation phase, e.g., at compile time. This wire
evaluation may be performed as a part of the type propagation
phase, e.g., in the LabVIEW development system. In this phase the
diagram may be traversed and logically executed by type (not by
value), so that it is possible to compute the types of all wires
and terminals, and thus to type-check the diagram. For example,
constant folding may be used to propagate constant values from the
source of an asynchronous wire to its sink. In this approach, as a
part of type propagation, the values of constants are evaluated as
far as possible on the diagram. This allows the elimination of dead
code, such as unreachable cases in a case statement. This may allow
the end points to share static entities such as block diagram
constants and constant references, such as references to a VI
instance. At run-time this may result in a connection between
source and sink that does not obey standard (e.g., LabVIEW)
data-flow rules.
[0023] For example, a source and sink in a graphical program may be
connected through an asynchronous wire that may carry a string
constant used to access a common, named queue, which is a FIFO data
structure. Note that a significant difference between a traditional
LabVIEW wire and the asynchronous wire connection between the
source and sink is that there is no data flow dependency between
them in the latter case, and so the two graphical program nodes can
run in parallel, while exchanging data. In other words, the
asynchronous wire is a new type of wire with different semantics,
where, in particular, there is not the normal data flow dependency
between nodes connected with an asynchronous wire, and in fact,
nodes connected by such a wire are actually supposed to run in
parallel, as opposed to serially when connected with a regular
wire. Note that in general, it would be an error to connect two
nodes with both a regular wire and an asynchronous wire. Note
further that asynchronous wires may be allowed to create cycles in
a graphical program, e.g., in a LabVIEW graph, since doing so may
not introduce a danger of deadlock or undefined behavior at
run-time. Additionally, in some embodiments, multiple sources on
asynchronous wires may be facilitated. Similarly, in some
embodiments, multiple sinks on asynchronous wires may be
allowed.
[0024] The asynchronous wire may be denoted by a type attribute
(and so behaviorally polymorphic nodes may be possible), namely, a
typedef with a special name. In other words, asynchronous wires may
have a data type, and so may benefit from the many uses of such
typing, as is well known to those of skill in the programming arts,
e.g., polymorphism and type checking, among others.
[0025] It should be noted that while the example uses of
asynchronous wires described herein are within a single program, in
other embodiments, asynchronous wires may be used to connect
different programs, e.g., to connect nodes that are comprised in
different respective graphical programs. Moreover, in some
embodiments, the different programs may be even running on
different processors or programmable hardware elements, such as
field programmable gate arrays (FPGAs).
[0026] In preferred embodiments, the asynchronous wires may each be
implemented by a respective graphical program. In other words, the
functionality of an asynchronous wire may be provided by an
associated graphical program. More specifically, each asynchronous
wire may use, be associated with, or represent, an instance of a
graphical program, which, for brevity, may be referred to simply as
a graphical program. Thus, multiple asynchronous wires may each
utilize or have a respective instance of the same graphical
program. The graphical program for each asynchronous wire may be
configured to implement and enforce the various communication
policies of the wire, e.g., read and write policies, as discussed
above. Thus, each instance of the graphical program may be
configured for the particular behavior desired for the respective
asynchronous wire. Note that since graphical programs may store and
maintain state information, the data transmitted on or by the
asynchronous wire may also be included in or implemented by the
graphical program. Note also that the graphical program associated
with an asynchronous wire may not generally be visible to the user,
i.e., may be hidden, although of course, means may be provided for
displaying the graphical program of an asynchronous wire for
development purposes.
[0027] Since the endpoints of an asynchronous wire may share a
common, static reference to a VI instance it may be possible to
implement a wide variety of run-time connections between the
endpoints, thus allowing custom run-time behavior of a node. For
example, in various embodiments, some of the possible behaviors of
an asynchronous wire may include: implementing queues of various
kinds, including FPGA FIFOs and RT (real time) FIFOs; single
element communication (e.g., anonymous global variables);
synchronization primitives, such as notifiers, semaphores,
rendesvous and occurrences; and expressing a connection to and from
a part of a diagram that is being executed on a remote target,
e.g., "roping in" of a piece of a diagram so that it can execute on
the remote target in conjunction with local execution of the
remainder of the diagram.
[0028] In some embodiments, an asynchronous wire may not be limited
to propagating information from terminal sources to terminal sinks.
In other words, in some embodiments, the asynchronous wire (and
possibly the terminals of the connected nodes) may be configured to
transmit data in either direction or in both directions. In other
words, in some embodiments and configurations, the asynchronous
wire may facilitate two-way communications between the connected
nodes. For example, in one embodiment, a dual queue may be used to
facilitate such two-way communications, where one queue is used for
a first direction, and another queue is used for a second
direction, although any other data structures and techniques may be
used as desired.
[0029] Thus, various embodiments of the asynchronous wire(s)
described herein may facilitate asynchronous communications between
nodes in a graphical program, or between graphical programs.
BRIEF DESCRIPTION OF THE DRAWINGS
[0030] A better understanding of the present invention can be
obtained when the following detailed description of the preferred
embodiment is considered in conjunction with the following
drawings, in which:
[0031] FIG. 1 illustrates a graphical program with communication
between two while loops via a shared variable, according to the
prior art;
[0032] FIG. 2A illustrates a computer system operable to execute a
graphical program according to an embodiment of the present
invention;
[0033] FIG. 2B illustrates a network system comprising two or more
computer systems that may implement an embodiment of the present
invention;
[0034] FIG. 3A illustrates an instrumentation control system
according to one embodiment of the invention;
[0035] FIG. 3B illustrates an industrial automation system
according to one embodiment of the invention;
[0036] FIG. 4A is a high-level block diagram of an exemplary system
which may execute or utilize graphical programs;
[0037] FIG. 4B illustrates an exemplary system that may perform
control and/or simulation functions utilizing graphical
programs;
[0038] FIG. 5 is an exemplary block diagram of the computer systems
of FIGS. 2A, 2B, 3A and 3B and 4B;
[0039] FIG. 6 is a flowchart diagram illustrating one embodiment of
a method for asynchronous communication in a graphical program;
[0040] FIG. 7 is graphical program illustrating use of asynchronous
wires, according to one embodiment;
[0041] FIG. 8 illustrates one embodiment of an exemplary graphical
program that includes two separately executable while loops with
respective nodes coupled via an asynchronous wire;
[0042] FIG. 9 illustrates one embodiment of an exemplary signal
processing graphical program with multiple asynchronous wires
illustrates a cycle, and nodes with multiple asynchronous inputs or
outputs;
[0043] FIG. 10 illustrates exemplary output from the signal
processing graphical program of FIG. 9; and
[0044] FIG. 11 illustrates an exemplary embodiment of a downsample
node from the graphical program of FIG. 9, where asynchronous I/O
for the node is implemented via queues.
[0045] While the invention is susceptible to various modifications
and alternative forms, specific embodiments thereof are shown by
way of example in the drawings and are herein described in detail.
It should be understood, however, that the drawings and detailed
description thereto are not intended to limit the invention to the
particular form disclosed, but on the contrary, the intention is to
cover all modifications, equivalents and alternatives falling
within the spirit and scope of the present invention as defined by
the appended claims.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
INCORPORATION BY REFERENCE
[0046] The following references are hereby incorporated by
reference in their entirety as though fully and completely set
forth herein:
[0047] U.S. Pat. No. 4,914,568 titled "Graphical System for
Modeling a Process and Associated Method," issued on Apr. 3,
1990.
[0048] U.S. Pat. No. 5,481,741 titled "Method and Apparatus for
Providing Attribute Nodes in a Graphical Data Flow
Environment".
[0049] U.S. Pat. No. 6,173,438 titled "Embedded Graphical
Programming System" filed Aug. 18, 1997.
[0050] U.S. Pat. No. 6,219,628 titled "System and Method for
Configuring an Instrument to Perform Measurement Functions
Utilizing Conversion of Graphical Programs into Hardware
Implementations," filed Aug. 18, 1997.
[0051] U.S. Patent Application Publication No. 20010020291 (Ser.
No. 09/745,023) titled "System and Method for Programmatically
Generating a Graphical Program in Response to Program Information,"
filed Dec. 20, 2000.
Terms
[0052] The following is a glossary of terms used in the present
application:
[0053] Memory Medium--Any of various types of memory devices or
storage devices. The term "memory medium" is intended to include an
installation medium, e.g., a CD-ROM, floppy disks 104, or tape
device; a computer system memory or random access memory such as
DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile
memory such as a magnetic media, e.g., a hard drive, or optical
storage. The memory medium may comprise other types of memory as
well, or combinations thereof. In addition, the memory medium may
be located in a first computer in which the programs are executed,
or may be located in a second different computer which connects to
the first computer over a network, such as the Internet. In the
latter instance, the second computer may provide program
instructions to the first computer for execution. The term "memory
medium" may include two or more memory mediums which may reside in
different locations, e.g., in different computers that are
connected over a network.
[0054] Carrier Medium--a memory medium as described above, as well
as signals such as electrical, electromagnetic, or digital signals,
conveyed via a communication medium such as a bus, network and/or a
wireless link.
[0055] Programmable Hardware Element--includes various types of
programmable hardware, reconfigurable hardware, programmable logic,
or field-programmable devices (FPDs), such as one or more FPGAs
(Field Programmable Gate Arrays), or one or more PLDs (Programmable
Logic Devices), such as one or more Simple PLDs (SPLDs) or one or
more Complex PLDs (CPLDs), or other types of programmable hardware.
A programmable hardware element may also be referred to as
"reconfigurable logic".
[0056] Medium--includes one or more of a memory medium, carrier
medium, and/or programmable hardware element; encompasses various
types of mediums that can either store program instructions/data
structures or can be configured with a hardware configuration
program. For example, a medium that is "configured to perform a
function or implement a software object" may be 1) a memory medium
or carrier medium that stores program instructions, such that the
program instructions are executable by a processor to perform the
function or implement the software object; 2) a medium carrying
signals that are involved with performing the function or
implementing the software object; and/or 3) a programmable hardware
element configured with a hardware configuration program to perform
the function or implement the software object.
[0057] Program--the term "program" is intended to have the full
breadth of its ordinary meaning. The term "program" includes 1) a
software program which may be stored in a memory and is executable
by a processor or 2) a hardware configuration program useable for
configuring a programmable hardware element.
[0058] Software Program--the term "software program" is intended to
have the full breadth of its ordinary meaning, and includes any
type of program instructions, code, script and/or data, or
combinations thereof, that may be stored in a memory medium and
executed by a processor. Exemplary software programs include
programs written in text-based programming languages, such as C,
C++, Pascal, Fortran, Cobol, Java, assembly language, etc.;
graphical programs (programs written in graphical programming
languages); assembly language programs; programs that have been
compiled to machine language; scripts; and other types of
executable software. A software program may comprise two or more
software programs that interoperate in some manner.
[0059] Hardware Configuration Program--a program, e.g., a netlist
or bit file, that can be used to program or configure a
programmable hardware element.
[0060] Graphical Program--A program comprising a plurality of
interconnected nodes or icons, wherein the plurality of
interconnected nodes or icons visually indicate functionality of
the program.
[0061] The following provides examples of various aspects of
graphical programs. The following examples and discussion are not
intended to limit the above definition of graphical program, but
rather provide examples of what the term "graphical program"
encompasses:
[0062] The nodes in a graphical program may be connected in one or
more of a data flow, control flow, and/or execution flow format.
The nodes may also be connected in a "signal flow" format, which is
a subset of data flow.
[0063] Exemplary graphical program development environments which
may be used to create graphical programs include LabVIEW, DasyLab,
DiaDem and Matrixx/SystemBuild from National Instruments, Simulink
from the MathWorks, VEE from Agilent, WiT from Coreco, Vision
Program Manager from PPT Vision, SoftWIRE from Measurement
Computing, Sanscript from Northwoods Software, Khoros from Khoral
Research, SnapMaster from HEM Data, VisSim from Visual Solutions,
ObjectBench by SES (Scientific and Engineering Software), and
VisiDAQ from Advantech, among others.
[0064] The term "graphical program" includes models or block
diagrams created in graphical modeling environments, wherein the
model or block diagram comprises interconnected nodes or icons that
visually indicate operation of the model or block diagram;
exemplary graphical modeling environments include Simulink,
SystemBuild, VisSim, Hypersignal Block Diagram, etc.
[0065] A graphical program may be represented in the memory of the
computer system as data structures and/or program instructions. The
graphical program, e.g., these data structures and/or program
instructions, may be compiled or interpreted to produce machine
language that accomplishes the desired method or process as shown
in the graphical program.
[0066] Input data to a graphical program may be received from any
of various sources, such as from a device, unit under test, a
process being measured or controlled, another computer program, a
database, or from a file. Also, a user may input data to a
graphical program or virtual instrument using a graphical user
interface, e.g., a front panel.
[0067] A graphical program may optionally have a GUI associated
with the graphical program. In this case, the plurality of
interconnected nodes are often referred to as the block diagram
portion of the graphical program.
[0068] Node--In the context of a graphical program, an element that
may be included in a graphical program. A node may have an
associated icon that represents the node in the graphical program,
as well as underlying code or data that implements functionality of
the node. Exemplary nodes include function nodes, terminal nodes,
structure nodes, etc. Nodes may be connected together in a
graphical program by connection icons or wires.
[0069] Data Flow Graphical Program (or Data Flow Diagram)--A
graphical program or diagram comprising a plurality of
interconnected nodes, wherein the connections between the nodes
indicate that data produced by one node is used by another
node.
[0070] Graphical User Interface--this term is intended to have the
full breadth of its ordinary meaning. The term "Graphical User
Interface" is often abbreviated to "GUI". A GUI may comprise only
one or more input GUI elements, only one or more output GUI
elements, or both input and output GUI elements.
[0071] The following provides examples of various aspects of GUIs.
The following examples and discussion are not intended to limit the
ordinary meaning of GUI, but rather provide examples of what the
term "graphical user interface" encompasses:
[0072] A GUI may comprise a single window having one or more GUI
Elements, or may comprise a plurality of individual GUI Elements
(or individual windows each having one or more GUI Elements),
wherein the individual GUI Elements or windows may optionally be
tiled together.
[0073] A GUI may be associated with a graphical program. In this
instance, various mechanisms may be used to connect GUI Elements in
the GUI with nodes in the graphical program. For example, when
Input Controls and Output Indicators are created in the GUI,
corresponding nodes (e.g., terminals) may be automatically created
in the graphical program or block diagram. Alternatively, the user
can place terminal nodes in the block diagram which may cause the
display of corresponding GUI Elements front panel objects in the
GUI, either at edit time or later at run time. As another example,
the GUI may comprise GUI Elements embedded in the block diagram
portion of the graphical program.
[0074] Front Panel--A Graphical User Interface that includes input
controls and output indicators, and which enables a user to
interactively control or manipulate the input being provided to a
program, and view output of the program, while the program is
executing.
[0075] A front panel is a type of GUI. A front panel may be
associated with a graphical program as described above.
[0076] In an instrumentation application, the front panel can be
analogized to the front panel of an instrument. In an industrial
automation application the front panel can be analogized to the MMI
(Man Machine Interface) of a device. The user may adjust the
controls on the front panel to affect the input and view the output
on the respective indicators.
[0077] Graphical User Interface Element--an element of a graphical
user interface, such as for providing input or displaying output.
Exemplary graphical user interface elements comprise input controls
and output indicators
[0078] Input Control--a graphical user interface element for
providing user input to a program. Exemplary input controls
comprise dials, knobs, sliders, input text boxes, etc.
[0079] Output Indicator--a graphical user interface element for
displaying output from a program. Exemplary output indicators
include charts, graphs, gauges, output text boxes, numeric
displays, etc. An output indicator is sometimes referred to as an
"output control".
[0080] Computer System--any of various types of computing or
processing systems, including a personal computer system (PC),
mainframe computer system, workstation, network appliance, Internet
appliance, personal digital assistant (PDA), television system,
grid computing system, or other device or combinations of devices.
In general, the term "computer system" can be broadly defined to
encompass any device (or combination of devices) having at least
one processor that executes instructions from a memory medium.
[0081] Measurement Device--includes instruments, data acquisition
devices, smart sensors, and any of various types of devices that
are operable to acquire and/or store data. A measurement device may
also optionally be further operable to analyze or process the
acquired or stored data. Examples of a measurement device include
an instrument, such as a traditional stand-alone "box" instrument,
a computer-based instrument (instrument on a card) or external
instrument, a data acquisition card, a device external to a
computer that operates similarly to a data acquisition card, a
smart sensor, one or more DAQ or measurement cards or modules in a
chassis, an image acquisition device, such as an image acquisition
(or machine vision) card (also called a video capture board) or
smart camera, a motion control device, a robot having machine
vision, and other similar types of devices. Exemplary "stand-alone"
instruments include oscilloscopes, multimeters, signal analyzers,
arbitrary waveform generators, spectroscopes, and similar
measurement, test, or automation instruments.
[0082] A measurement device may be further operable to perform
control functions, e.g., in response to analysis of the acquired or
stored data. For example, the measurement device may send a control
signal to an external system, such as a motion control system or to
a sensor, in response to particular data. A measurement device may
also be operable to perform automation functions, i.e., may receive
and analyze data, and issue automation control signals in
response.
FIG. 2A--Computer System
[0083] FIG. 2A illustrates a computer system 82 operable to execute
a graphical program configured to utilize the asynchronous
communication techniques disclosed herein. As shown in FIG. 2A, the
computer system 82 may include a display device operable to display
the graphical program as the graphical program is created and/or
executed. The display device may also be operable to display a
graphical user interface or front panel of the graphical program
during execution of the graphical program. The graphical user
interface may comprise any type of graphical user interface, e.g.,
depending on the computing platform.
[0084] The computer system 82 may include a memory medium(s) on
which one or more computer programs or software components
according to one embodiment of the present invention may be stored.
For example, the memory medium may store one or more graphical
programs that are executable to perform the methods described
herein. Also, the memory medium may store a graphical programming
development environment application used to create and/or execute
such graphical programs. The memory medium may also store operating
system software, as well as other software for operation of the
computer system. Various embodiments further include receiving or
storing instructions and/or data implemented in accordance with the
foregoing description upon a carrier medium.
FIG. 2B--Computer Network
[0085] FIG. 2B illustrates a system including a first computer
system 82 that is coupled to a second computer system 90. The
computer system 82 may be connected through a network 84 (or a
computer bus) to the second computer system 90. The computer
systems 82 and 90 may each be any of various types, as desired. The
network 84 can also be any of various types, including a LAN (local
area network), WAN (wide area network), the Internet, or an
Intranet, among others. The computer systems 82 and 90 may execute
a graphical program in a distributed fashion. For example, computer
82 may execute a first portion of the block diagram of a graphical
program and computer system 90 may execute a second portion of the
block diagram of the graphical program. As another example,
computer 82 may display the graphical user interface of a graphical
program and computer system 90 may execute the block diagram of the
graphical program.
[0086] In one embodiment, the graphical user interface of the
graphical program may be displayed on a display device of the
computer system 82, and the block diagram may execute on a device
190 connected to the computer system 82. The device 190 may include
a programmable hardware element and/or may include a processor and
memory medium which may execute a real time operating system. In
one embodiment, the graphical program may be downloaded and
executed on the device 190. For example, an application development
environment with which the graphical program is associated may
provide support for downloading a graphical program for execution
on the device in a real time system.
Exemplary Systems
[0087] Embodiments of the present invention may be involved with
performing test and/or measurement functions; controlling and/or
modeling instrumentation or industrial automation hardware;
modeling and simulation functions, e.g., modeling or simulating a
device or product being developed or tested, etc. Exemplary test
applications where the graphical program may be used include
hardware-in-the-loop testing and rapid control prototyping, among
others.
[0088] However, it is noted that the present invention can be used
for a plethora of applications and is not limited to the above
applications. In other words, applications discussed in the present
description are exemplary only, and the present invention may be
used in any of various types of systems. Thus, the system and
method of the present invention is operable to be used in any of
various types of applications, including the control of other types
of devices such as multimedia devices, video devices, audio
devices, telephony devices, Internet devices, etc., as well as
general purpose software applications such as word processing,
spreadsheets, network control, network monitoring, financial
applications, games, etc.
[0089] FIG. 3A illustrates an exemplary instrumentation control
system 100 which may implement embodiments of the invention. The
system 100 comprises a host computer 82 which connects to one or
more instruments. The host computer 82 may comprise a CPU, a
display screen, memory, and one or more input devices such as a
mouse or keyboard as shown. The computer 82 may operate with the
one or more instruments to analyze, measure or control a unit under
test (UUT) or process 150.
[0090] The one or more instruments may include a GPIB instrument
112 and associated GPIB interface card 122, a data acquisition
board 114 and associated signal conditioning circuitry 124, a VXI
instrument 116, a PXI instrument 118, a video device or camera 132
and associated image acquisition (or machine vision) card 134, a
motion control device 136 and associated motion control interface
card 138, and/or one or more computer based instrument cards 142,
among other types of devices. The computer system may couple to and
operate with one or more of these instruments. The instruments may
be coupled to a unit under test (UUT) or process 150, or may be
coupled to receive field signals, typically generated by
transducers. The system 100 may be used in a data acquisition and
control application, in a test and measurement application, an
image processing or machine vision application, a process control
application, a man-machine interface application, a simulation
application, or a hardware-in-the-loop validation application,
among others.
[0091] FIG. 3B illustrates an exemplary industrial automation
system 160 which may implement embodiments of the invention. The
industrial automation system 160 is similar to the instrumentation
or test and measurement system 100 shown in FIG. 3A. Elements which
are similar or identical to elements in FIG. 3A have the same
reference numerals for convenience. The system 160 may comprise a
computer 82 which connects to one or more devices or instruments.
The computer 82 may comprise a CPU, a display screen, memory, and
one or more input devices such as a mouse or keyboard as shown. The
computer 82 may operate with the one or more devices to a process
or device 150 to perform an automation function, such as MMI (Man
Machine Interface), SCADA (Supervisory Control and Data
Acquisition), portable or distributed data acquisition, process
control, advanced analysis, or other control, among others.
[0092] The one or more devices may include a data acquisition board
114 and associated signal conditioning circuitry 124, a PXI
instrument 118, a video device 132 and associated image acquisition
card 134, a motion control device 136 and associated motion control
interface card 138, a fieldbus device 170 and associated fieldbus
interface card 172, a PLC (Programmable Logic Controller) 176, a
serial instrument 182 and associated serial interface card 184, or
a distributed data acquisition system, such as the Fieldpoint
system available from National Instruments, among other types of
devices.
[0093] FIG. 4A is a high-level block diagram of an exemplary system
which may execute or utilize graphical programs. FIG. 4A
illustrates a general high-level block diagram of a generic control
and/or simulation system that comprises a controller 92 and a plant
94. The controller 92 represents a control system/algorithm the
user may be trying to develop. The plant 94 represents the system
the user may be trying to control. For example, if the user is
designing an ECU for a car, the controller 92 is the ECU and the
plant 94 is the car's engine (and possibly other components such as
transmission, brakes, and so on.) As shown, a user may create a
graphical program that specifies or implements the functionality of
one or both of the controller 92 and the plant 94. For example, a
control engineer may use a modeling and simulation tool to create a
model (graphical program) of the plant 94 and/or to create the
algorithm (graphical program) for the controller 92.
[0094] FIG. 4B illustrates an exemplary system that may perform
control and/or simulation functions. As shown, the controller 92
may be implemented by a computer system 82 or other device (e.g.,
including a processor and memory medium and/or including a
programmable hardware element) that executes or implements a
graphical program. In a similar manner, the plant 94 may be
implemented by a computer system or other device 144 (e.g.,
including a processor and memory medium and/or including a
programmable hardware element) that executes or implements a
graphical program, or may be implemented in or as a real physical
system, e.g., a car engine.
[0095] In one embodiment of the invention, one or more graphical
programs may be created which are used in performing rapid control
prototyping. Rapid Control Prototyping (RCP) generally refers to
the process by which a user develops a control algorithm and
quickly executes that algorithm on a target controller connected to
a real system. The user may develop the control algorithm using a
graphical program, and the graphical program may execute on the
controller 92, e.g., on a computer system or other device. The
computer system 82 may be a platform that supports real time
execution, e.g., a device including a processor that executes a
real time operating system (RTOS), or a device including a
programmable hardware element.
[0096] In one embodiment of the invention, one or more graphical
programs may be created which are used in performing Hardware in
the Loop (HIL) simulation. Hardware in the Loop (HIL) refers to the
execution of the plant model 94 in real time to test operation of a
real controller 92. For example, once the controller 92 has been
designed, it may be expensive and complicated to actually test the
controller 92 thoroughly in a real plant, e.g., a real car. Thus,
the plant model (implemented by a graphical program) is executed in
real time to make the real controller 92 "believe" or operate as if
it is connected to a real plant, e.g., a real engine.
[0097] In the embodiments of FIGS. 2A, 2B, and 3B above, one or
more of the various devices may couple to each other over a
network, such as the Internet. In one embodiment, the user operates
to select a target device from a plurality of possible target
devices for programming or configuration using a graphical program.
Thus the user may create a graphical program on a computer and use
(execute) the graphical program on that computer or deploy the
graphical program to a target device (for remote execution on the
target device) that is remotely located from the computer and
coupled to the computer through a network.
[0098] Graphical software programs which perform data acquisition,
analysis and/or presentation, e.g., for measurement,
instrumentation control, industrial automation, modeling, or
simulation, such as in the applications shown in FIGS. 2A and 2B,
may be referred to as virtual instruments.
FIG. 5--Computer System Block Diagram
[0099] FIG. 5 is a block diagram representing one embodiment of the
computer system 82 and/or 90 illustrated in FIGS. 1A and 1B, or
computer system 82 shown in FIGS. 2A or 2B. It is noted that any
type of computer system configuration or architecture can be used
as desired, and FIG. 5 illustrates a representative PC embodiment.
It is also noted that the computer system may be a general-purpose
computer system, a computer implemented on a card installed in a
chassis, or other types of embodiments. Elements of a computer not
necessary to understand the present description have been omitted
for simplicity.
[0100] The computer may include at least one central processing
unit or CPU (processor) 160 which is coupled to a processor or host
bus 162. The CPU 160 may be any of various types, including an x86
processor, e.g., a Pentium class, a PowerPC processor, a CPU from
the SPARC family of RISC processors, as well as others. A memory
medium, typically comprising RAM and referred to as main memory,
166 is coupled to the host bus 162 by means of memory controller
164. The main memory 166 may store the graphical program operable
to implement various embodiments of the asynchronous communications
techniques disclosed herein. The main memory may also store
operating system software, as well as other software for operation
of the computer system.
[0101] The host bus 162 may be coupled to an expansion or
input/output bus 170 by means of a bus controller 168 or bus bridge
logic. The expansion bus 170 may be the PCI (Peripheral Component
Interconnect) expansion bus, although other bus types can be used.
The expansion bus 170 includes slots for various devices such as
described above. The computer 82 further comprises a video display
subsystem 180 and hard drive 182 coupled to the expansion bus 170.
In some embodiments, the computer 82 may also include or be coupled
to other buses and devices, such as, for example, GPIB card 122
with GPIB bus 112, an MXI device 186 and VXI chassis 116, etc., as
desired.
[0102] As shown, a device 190 may also be connected to the
computer. The device 190 preferably includes a programmable
hardware element. The device 190 may also or instead comprise a
processor and memory that may execute a real time operating system.
The computer system may be operable to deploy a graphical program
to the device 190 for execution of the graphical program on the
device 190. The deployed graphical program may take the form of
graphical program instructions or data structures that directly
represent the graphical program.
[0103] Alternatively, the deployed graphical program may take the
form of text code (e.g., C code) generated from the graphical
program. As another example, the deployed graphical program may
take the form of compiled code generated from either the graphical
program or from text code that in turn was generated from the
graphical program.
FIG. 6--Method For Asynchronous Communication in a Graphical
Program
[0104] FIG. 6 illustrates a computer-implemented method for
asynchronous communication in a graphical program according to one
embodiment. The method shown in FIG. 6 may be used in conjunction
with any of the computer systems or devices shown in the above
Figures, among other devices. In various embodiments, some of the
method elements shown may be performed concurrently, performed in a
different order than shown, or omitted. Additional method elements
may also be performed as desired. As shown, this method may operate
as follows.
[0105] First, in 602 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.
[0106] The graphical program may be created or assembled by the
user arranging on a display a plurality of nodes or icons and then
interconnecting the nodes to create the graphical program. In
response to the user assembling the graphical program, data
structures may be created and stored which represent the graphical
program. The nodes may be interconnected in one or more of a data
flow, control flow, or execution flow format. The graphical program
may thus comprise a plurality of interconnected nodes or icons that
visually indicates the functionality of the program. As noted
above, the graphical program may comprise a block diagram and may
also include a user interface portion or front panel portion. Where
the graphical program includes a user interface portion, the user
may optionally assemble the user interface on the display. As one
example, the user may use the LabVIEW graphical programming
development environment to create the graphical program.
[0107] In an alternate embodiment, the graphical program may be
created by the user creating or specifying a prototype, followed by
automatic or programmatic creation of the graphical program from
the prototype. This functionality is described in U.S. patent
application Ser. No. 09/587,682 titled "System and Method for
Automatically Generating a Graphical Program to Perform an Image
Processing Algorithm", which is hereby incorporated by reference in
its entirety as though fully and completely set forth herein. The
graphical program may be created in other manners, either by the
user or programmatically, as desired. The graphical program may
implement a measurement function that is desired to be performed 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.
[0108] In 604, 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. FIG. 7 is a high-level illustration of such
source and sink nodes, labeled accordingly, connected via an
asynchronous wire. However, it should be noted that in other
embodiments the asynchronous wire may facilitate two-way
communication between the nodes, i.e., from the first node to the
second and from the second node to the first.
[0109] In 606, 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; 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.
[0110] 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.
[0111] 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.
[0112] 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.
[0113] In 608, the graphical program may 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.
[0114] FIG. 8 illustrates one embodiment of an exemplary graphical
program that includes two separately executable while loops similar
to those of FIG. 1, where a first loop 802 includes a first node,
in this case a random number generation node 803, and a second loop
804 includes a second node, in this case an add node 805, similar
to the graphical program of FIG. 1. However, as may be seen, in
this embodiment, the first node (random number node) 803 is
connected to the second node (add node) 805 via an asynchronous
wire 806. Note that in this example, the asynchronous wire is
attached only to the terminals of the first and second nodes, and
does not attach to the loops themselves. Thus, in this example
program, while both loops are executing, causing their respective
included nodes to execute per cycle, the nodes may communicate in
an asynchronous manner. More specifically, during execution, the
random number generator node 803 may operate to send random number
over the asynchronous wire 806 to the add node 805, which may add
"1" to the received value, and output the resultant value for
display (as a double value).
[0115] Thus, the asynchronous wire may allow users to create a
static connection between nodes in a (block diagram of) a 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. Examples of such a graphically rendered asynchronous wire
are illustrated in FIGS. 7 and 8. 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.
[0116] Note that in preferred embodiments, an asynchronous wire
does not explicitly carry data at run-time, and so it may not be
considered as part of the data flow graph (of the graphical
program). This means that its fire count (i.e., iterative execution
count) may be ignored at run-time and that it may not use explicit
tunneling to cross structures. Instead the asynchronous wire may
visually "float" over structure boundaries, e.g., over the
boundaries of loop nodes, as may be seen in FIG. 8. In one
embodiment, asynchronous wires may be evaluated during a type
propagation phase, e.g., at compile time. This wire evaluation may
be performed as a part of the type propagation phase, e.g., in the
LabVIEW development system. In this phase the diagram may be
traversed and logically executed by type (not by value), so that it
is possible to compute the types of all wires and terminals, and
thus to type-check the diagram. For example, constant folding may
be used to propagate constant values from the source of an
asynchronous wire to its sink. In this approach, as a part of type
propagation, the values of constants are evaluated as far as
possible on the diagram. This allows the elimination of dead code,
such as unreachable cases in a case statement. This may allow the
end points to share static entities such as block diagram constants
and constant references, such as references to a VI instance. At
run-time this may result in a connection between source and sink
that does not obey standard (e.g., LabVIEW) data-flow rules.
[0117] For example, in the simple example program of FIG. 7, the
source and sink are connected through an asynchronous wire that may
carry a string constant used to access a common, named queue, which
is a FIFO data structure. Note that a significant difference
between a traditional LabVIEW wire and the asynchronous wire
connection between the source and sink is that there is no data
flow dependency between them in the latter case, and so the two
graphical program nodes can run in parallel, while exchanging data.
In other words, the asynchronous wire is a new type of wire with
different semantics, where, in particular, there is not the normal
data flow dependency between nodes connected with an asynchronous
wire, and in fact, nodes connected by such a wire are actually
supposed to run in parallel, as opposed to serially when connected
with a regular wire. Note that in general, it would be an error to
connect two nodes with both a regular wire and an asynchronous
wire. Note further that asynchronous wires may be allowed to create
cycles in a graphical program, e.g., in a LabVIEW graph, since
doing so may not introduce a danger of deadlock or undefined
behavior at run-time. Additionally, in some embodiments, multiple
sources on asynchronous wires may be facilitated. Similarly, in
some embodiments, multiple sinks on asynchronous wires may be
allowed.
[0118] The asynchronous wire may be denoted by a type attribute
(and so behaviorally polymorphic nodes may be possible), namely, a
typedef with a special name. In other words, asynchronous wires may
have a data type, and so may benefit from the many uses of such
typing, as is well known to those of skill in the programming arts,
e.g., polymorphism and type checking, among others.
[0119] It should be noted that while the example uses of
asynchronous wires described herein are within a single program, in
other embodiments, asynchronous wires may be used to connect
different programs, e.g., to connect nodes that are comprised in
different respective graphical programs. Moreover, in some
embodiments, the different programs may be even running on
different processors or programmable hardware elements, such as
field programmable gate arrays (FPGAs).
[0120] In preferred embodiments, the asynchronous wires may each be
implemented by a respective graphical program. In other words, the
functionality of an asynchronous wire may be provided by an
associated graphical program. More specifically, each asynchronous
wire may use, be associated with, or represent, an instance of a
graphical program, which, for brevity, may be referred to simply as
a graphical program. Thus, multiple asynchronous wires may each
utilize or have a respective instance of the same graphical
program. The graphical program for each asynchronous wire may be
configured to implement and enforce the various communication
policies of the wire, e.g., read and write policies, as discussed
above. Thus, each instance of the graphical program may be
configured for the particular behavior desired for the respective
asynchronous wire. Note that since graphical programs may store and
maintain state information, the data transmitted on or by the
asynchronous wire may also be included in or implemented by the
graphical program. Note also that the graphical program associated
with an asynchronous wire may not generally be visible to the user,
i.e., may be hidden, although of course, means may be provided for
displaying the graphical program of an asynchronous wire for
development purposes.
[0121] Since the endpoints of an asynchronous wire may share a
common, static reference to a VI instance it may be possible to
implement a wide variety of run-time connections between the
endpoints, thus allowing custom run-time behavior of a node. For
example, in various embodiments, some of the possible behaviors of
an asynchronous wire may include: implementing queues of various
kinds, including FPGA FIFOs and RT (real time) FIFOs; single
element communication (e.g., anonymous global variables);
synchronization primitives, such as notifiers, semaphores,
rendesvous and occurrences; and expressing a connection to and from
a part of a diagram that is being executed on a remote target,
e.g., "roping in" of a piece of a diagram so that it can execute on
the remote target in conjunction with local execution of the
remainder of the diagram.
[0122] In some embodiments, an asynchronous wire may not be limited
to propagating information from terminal sources to terminal sinks.
In other words, in some embodiments, the asynchronous wire (and
possibly the terminals of the connected nodes) may be configured to
transmit data in either direction or in both directions. In other
words, in some embodiments and configurations, the asynchronous
wire may facilitate two-way communications between the connected
nodes. For example, in one embodiment, a dual queue may be used to
facilitate such two-way communications, where one queue is used for
a first direction, and another queue is used for a second
direction, although any other data structures and techniques may be
used as desired.
[0123] FIG. 9 is an exemplary graphical program utilizing
asynchronous wires that is slightly more complex than those of
FIGS. 7 and 8, wherein various aspects of asynchronous wires are
demonstrated in a signal processing application. As FIG. 9 shows,
beginning from the far left of the figure, a generate node 902 is
configured to generate 100 samples of a function or signal, e.g., a
sine wave, and communicate these data over an asynchronous wire 903
to upsample node 904, which may operate to upsample the transmitted
signal from the generate node 902 by a factor of 3, as indicated.
The upsampled data may then be transmitted over asynchronous wire
905 to finite filter response (FIR) filter node 906, which is
configured with a window of 10 samples. This node may filter the
received signal and transmit the resulting data to downsample node
908, which may operate to downsample the data by a factor of 2,
e.g., halving the number of samples in the signal. The resultant
signal or data then proceeds to split node 910 via asynchronous
wire 909, where the signal is propagated along asynchronous wires
911 and 921. Note that split node 910 demonstrates two asynchronous
wires 911 and 921 sharing a common source, specifically, split node
910, whose function is to take an input and provide output on two
different wires. As shown, the data on asynchronous wire 921 is
provided to display node 920 for display, which, as indicated, is
configured to display 150 samples at a time, e.g., on a graphical
user interface (GUI). The sinusoidal waveform display 1010 of FIG.
10 illustrates exemplary output from the display node 920.
[0124] As FIG. 9 indicates, asynchronous wire 911 may transmit the
signal to merge node 912 which may operate to interleave data
received from asynchronous wires 911 and 919, where, as shown, the
signal on asynchronous wire 919 is from delay node 918, described
below. The results of the merge node 912 may be transmitted on
asynchronous wire 913 to split node 914, which, as shown, may
provide the received signal to display node 922 via asynchronous
wire 923, where the signal may be displayed 300 samples at a time.
The sinusoidal waveform display 1020 of FIG. 10 illustrates
exemplary output from the display node 922.
[0125] The split node 914 may also provide the received signal to
downsample node 916 via asynchronous wire 915, where the downsample
node 916 may operate to downsample the received signal by a factor
of 2, and transmit the resultant downsampled signal over
asynchronous wire 917 to delay node 916. Note that the delay node
918 is initialized with 150 values (samples), and may operate to
provide 1 sample at a time to the merge node 912, introduced above.
Thus, the merge node 912 may receive data from asynchronous wires
919 and 911, and interleave samples to generate the signal
transmitted on asynchronous wire 913, as described above. Note that
merge node 912 illustrates a sink (merge node 912) with two sources
(split node 910 via asynchronous wire 911, and delay node 918 via
asynchronous wire 919). Note also that nodes 912, 914, 916, and 918
form a cycle via respective asynchronous wires 913, 915, 917, and
919, which is not supported in standard data flow diagrams, thus,
as noted above, the asynchronous wires may facilitate or
accommodate non-data flow behaviors.
[0126] FIG. 11 illustrates one embodiment of asynchronous
communication mechanisms used in the downsample nodes of FIG. 9.
More specifically, FIG. 11 illustrates use of a queue, a FIFO
structure, for receiving data from an asynchronous wire, and
providing data as output to another asynchronous wire.
[0127] As shown, a downsample node, whose functionality is
illustrated in the top block diagram 1108 of FIG. 11, has access to
a queue reference via the incoming asynchronous wire, denoted as
QRef. The node preferably accesses and reads data from the queue of
the input asynchronous wire using a dequeue process implemented in
a dequeue block 1104, a detailed view of which is illustrated in
the bottom left block diagram 1110 of FIG. 11. For example, in one
embodiment, the (bottom left) block diagram 1110 receives a
reference to a dequeue function of the queue and invokes this
dequeue function to read values from the queue. The output read
values may then be output, as indicated by the output Array shown
on the right side of the block diagram 1110, and provided as input
for use by downsample code 1108 included in the block diagram. Note
that values may be read from the queue singly, or in multiples, as
desired. Once the signal has been downsampled by the downsample
code 1108, the results may be provided to an enqueue process for
output on the exiting asynchronous wire, as described below.
[0128] Similarly, to transmit data as output onto the asynchronous
wire exiting the downsample node, the node may access and write
data to a queue referenced by an output queue reference, denoted in
the top block diagram as QRef Out (see far right of the block
diagram). The node preferably accesses and writes data to the queue
of the output asynchronous wire using an enqueue process
implemented in an enqueue block 1106, illustrated in the bottom
right block diagram 1120 of FIG. 11. For example, in one
embodiment, the (bottom right) block diagram 1120 receives a
reference to an enqueue function of the output queue and invokes
the enqueue function to write values to the queue. The values to be
written to the queue may be provided in the form of an input array,
as indicated by the input Array shown on the left side of the block
diagram. Note that similar to the dequeue process, values may be
written to the queue singly, or in multiples, as desired. Writing
the data to the output queue thus places the data on the exiting
asynchronous wire for transmission to a node connected to the other
end of the asynchronous wire.
[0129] While the example asynchronous wires/terminals presented
above use queues, it should be noted that any other types of data
structure may be used as desired, e.g., other FIFO structures,
stacks, graphs, arrays, lists, and so forth.
[0130] Although the embodiments above have been described in
considerable detail, numerous variations and modifications will
become apparent to those skilled in the art once the above
disclosure is fully appreciated. It is intended that the following
claims be interpreted to embrace all such variations and
modifications.
* * * * *