REGISTER  |  SIGN IN
United States Patent6437805
Sojoodi , ; et al.August 20, 2002
Title
System and method for accessing object capabilities in a graphical program
Abstract
A system and method for creating a graphical program, wherein the graphical program is operable to access capabilities of an object. During creation of the graphical program, the user operates to place an object node in the graphical program, wherein the object node is operable to access capabilities of the object. This preferably includes the user arranging on the screen the graphical program, including the object node and various other nodes, and connecting the various nodes to create the graphical program. The user then configures the object node to receive information on the object, preferably by the user configuring the object node with a reference to the object, e.g., a pointer, address, or other information which specifies the identity and/or location of the object. The user also selects one or more methods to be invoked on the object and/or one or more properties to get/set on the object. Once the graphical program has been created, then during execution of the graphical program, the object node accesses the capabilities of the object.
Inventors:Sojoodi; Omid (Austin, TX), Dye; Robert  (Austin, TX), Parthasarathy; Murali  (Austin, TX), Kudukoli; Ram  (Austin, TX)
Assignee:National Instruments Corporation (Austin, TX)
Appl. No.:136123
Filed:August 18, 1998
Current U.S. Class:715/763 717/105 
Current International Class:G09G 5/00 (20060101)
Field of Search:345/333,335,349,339,334,967,440,357,835,765,744,854,619,763,764 717/1,104-109,132 709/225,220
U.S. Patent Documents
4901221February 1990Kodosky et al.
5097411March 1992Doyle et al.
5251322October 1993Doyle et al.
5261043November 1993Wolber et al.
5291587March 1994Kodosky et al.
5337262August 1994Luthi et al.
5359546October 1994Hayes et al.
5361336November 1994Atchison
5390325February 1995Miller
5394522February 1995Sanchez-Frank et al.
5428776June 1995Rothfield
5481741January 1996McKaskle et al.
5513311April 1996McKiel, Jr.
5576946November 1996Bender et al.
5640572June 1997Mondrik et al.
5673403September 1997Brown et al.
5727175March 1998Malone et al.
5734863March 1998Kodosky et al.
5751914May 1998Coley et al.
5758071May 1998Burgess et al.
5758084May 1998Silverstein et al.
5768578June 1998Kirk et al.
5784275July 1998Sojoodi et al.
5784583July 1998Redpath
5801942September 1998Nixon et al.
5802514September 1998Huber
5802526September 1998Fawcett et al.
5812133September 1998Schultz et al.
5821934October 1998Kodosky et al.
5847953December 1998Sojoodi et al.
5848273December 1998Fontana et al.
5850548December 1998Williams
5862339January 1999Bonnamre et al.
5862379January 1999Rubin et al.
5867665February 1999Butman et al.
5895474April 1999Maarek et al.
5905649May 1999Sojoodi et al.
5966532October 1999McDonald et al.
6064812May 2000Parthasarathy et al.
6102965August 2000Dye et al.
Other References
Rijnders et al., "Versatile Visual Programming Environment for Scientific Applications," ACM, 1991, pp. 21-26.
Primary Examiner: Bayerl; Raymond J.
Assistant Examiner: Hailu; Tadesse
Attorney, Agent or Firm:Conley, Rose & Tayon PC Hood; Jeffrey C.
Parent Case Text


PRIORITY INFORMATION

This application claims the benefit of priority of:

U.S. Provisional Application No. 60/056,528 titled "System and Method for Providing Automation Server Capabilities in Graphical Programs," by Ram Kudukoli, Robert Dye and Murali Parthasarathy, filed on Aug. 21, 1997;

CONTINUATION DATA

This is a continuation-in-part of co-pending patent application Ser. No. 08/916,005 titled "System and Method for Providing Client/Server Access to Graphical Programs" filed on Aug. 21, 1997, whose inventors were Robert Dye and Omid Sojoodi which issued Aug. 15, 2000 as U.S. Pat. No. 6,102,965 which is a continuation in part of co-pending patent application Ser. No. 08/810,079 titled "System and Method for Developing Automation Clients using a Graphical Data Flow Program" filed on Mar. 4, 1997, whose inventors were Murali Parthasarathy and Omid Sojoodi, which issued May 16, 2000 as U.S. Pat. No. 6,064,812 which is a continuation-in-part of co-pending application Ser. No. 08/717,771 which issued Dec. 8, 1998 as U.S. Pat. No. 5,847,953 titled "System and Method for Performing Class Checking of Objects in a Graphical Data Flow Program" and filed Sep. 23, 1996, whose inventors were Omid Sojoodi and Stephen W. Rogers, which issued Dec. 8,1998 as U.S. Pat. No. 5,847,953.

This is also a continuation in part of co-pending patent application Ser. No. 08/810,079 titled "System and Method for Developing Automation Clients using a Graphical Data Flow Program" filed on Mar. 4, 1997, whose inventors were Murali Parthasarathy and Omid Sojoodi, which issued May. 16, 2000 as U.S. Pat. No. 6,064,812 which is a continuation-in-part of co-pending application Ser. No. 08/717,771 titled "System and Method for Performing Class Checking of Objects in a Graphical Data Flow Program" and filed Sep. 23, 1996, whose inventors were Omid Sojoodi and Stephen W. Rogers which issued Dec. 8, 1998 as U.S. Pat. No. 5,847,953.

This is also a continuation-in-part of co-pending application Ser. No. 08/717,771 titled "System and Method for Performing Class Checking of Objects in a Graphical Data Flow Program" and filed Sep. 23, 1996, whose inventors were Omid Sojoodi and Stephen W. Rogers which issued Dec. 8, 1998 as U.S. Pat. No. 5,847,953.

CROSS-REFERENCE TO RELATED APPLICATIONS

The following applications are related to the present application:

U.S. patent application Ser. No. 08/916,005 titled "System and Method for Providing Client/Server Access to Graphical Programs" filed on Aug. 21, 1997, whose inventors were Robert Dye and Omid Sojoodi which issued Aug. 15, 2000 as U.S. Pat. No. 6,102,965;

U.S. patent application Ser. No. 08/810,079 titled "System and Method for Developing Automation Clients using a Graphical Data Flow Program" filed on Mar. 4, 1997, whose inventors were Murali Parthasarathy and Omid Sojoodi, which issued May. 16, 2000 as U.S. Pat. No. 6,064,812,

U.S. patent application Ser. No. 08/811,187 titled "System and Method for Performing Class Propagation and Type Checking in a Graphical Automation Client" and filed on Mar. 4, 1997, whose inventors were Murali Parthasarathy and Omid Sojoodi, which issued May. 16, 2000 as U.S. Pat. No. 6,064,812,

U.S. patent application Ser. No. 08/717,771 titled "System and Method for Performing Class Checking of Objects in a Graphical Data Flow Program" which issued Dec. 8, 1998 as U.S. Pat. No. 5,847,953 Stephen W. Rogers.

U.S. patent application Ser. No. 08/717,772 titled "System and Method for Performing Interface Independent Virtual Instrumentation Functions Using Attribute Nodes in a Graphical Data Flow Program" which issued May. 18, 2000 as U.S. Pat. No. 5,905,648 and filed Sep. 23, 1996, whose inventors were Omid Sojoodi and Stephen W. Rogers.
Claims

What is claimed is:
1. A computer-implemented method for creating a graphical program, wherein the method for creating the graphical program operates in a computer including a display screen and a user input device, the method for creating the graphical program comprising: creating the graphical program in response to user input, wherein the graphical program is created in a first graphical program development environment, wherein said creating the graphical program includes: displaying on the screen a first node in the graphical program in response to user input, wherein the first node is operable to access capabilities of a software object, wherein the software object is not present in the first graphical program development environment; configuring the first node to receive information on the software object in response to user input; wherein, during execution of the graphical program, the first node is operable to access the capabilities of the software object.

2. The method of claim 1, wherein the software object is created in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

3. The method of claim 2, wherein the second program development environment is a text-based program development environment.

4. The method of claim 1, further comprising: creating the software object in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

5. The method of claim 1, wherein the software object is operable to execute independently of the graphical program.

6. The method of claim 1, wherein the software object exists prior to said creating the graphical program.

7. The method of claim 1, further comprising: executing the graphical program, wherein the graphical program is executed by a graphical program execution engine; wherein said executing the graphical program comprises executing the first node to access the capabilities of the software object; wherein said accessing the capabilities of the software object comprises executing the software object; wherein the software object executes without use of the graphical program execution engine.

8. The method of claim 1, further comprising: executing the graphical program in a first process; wherein execution of the graphical program causes execution of the software object; wherein the software object executes in a second process.

9. The method of claim 1, wherein said creating the graphical program in response to user input does not include receiving user input specifying text-based programming language source code to implement the graphical program; wherein the software object is a pre-existing software object that was constructed in response to text-based programming language source code.

10. The method of claim 1, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object is not one of the plurality of nodes.

11. The method of claim 1, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object does not implement functionality of any of the plurality of nodes.

12. The method of claim 1, further comprising: compiling the graphical program to produce a first portion of executable code; wherein the software object comprises a second portion of executable code which is independent from the first portion of executable code.

13. The method of claim 1, wherein the first node is an object node specifically designed to access capabilities of software objects external to graphical programs.

14. The method of claim 1, wherein the computer is a first computer coupled to a second computer through a network; wherein the software object is stored on the second computer.

15. The method of claim 14, further comprising: executing the graphical program, wherein the graphical program executes on the first computer; wherein said executing the graphical program comprises executing the first node to access the capabilities of the software object, wherein said accessing the capabilities of the software object causes execution of the software object on the second computer.

16. The method of claim 15, further comprising: displaying on the screen a user interface panel in response to user input for displaying data input to and/or output from the graphical program.

17. The method of claim 1, wherein the method for creating the graphical program further comprises: arranging on the screen the graphical program including said first node.

18. The method of claim 17, wherein the graphical program comprises a plurality of nodes, wherein the method for creating the graphical program further comprises: arranging on the screen said plurality of nodes, including said first node; and connecting said plurality of nodes and said first node in response to user input to create the graphical program.

19. The method of claim 18, wherein the method creates a graphical data flow program; wherein said connecting includes connecting said plurality of nodes and said first node to provide data flow between said plurality of nodes and said first node.

20. The method of claim 17, wherein the method for creating the graphical program further comprises: displaying on the screen a user interface panel in response to user input for displaying data input to and/or output from the graphical program.

21. The method of claim 20, wherein the method for creating the graphical program further comprises: arranging on the screen the user interface panel in response to user input.

22. The method of claim 1, further comprising: constructing execution instructions in response to said graphical program, wherein said execution instructions are executable to access said capabilities of the software object; and executing said execution instructions, wherein said first node accesses said capabilities of the software object during said executing.

23. The method of claim 1, wherein the software object is an independent application; wherein the first node is operable to perform one or more of 1) trigger execution of the independent application; or 2) get/set one or more properties of the independent application.

24. The method of claim 1, wherein the software object comprises one of: an ActiveX object; a Java object; a C++ object; a CORBA object.

25. The method of claim 1, wherein the software object comprises a first method; wherein the first node is operable to invoke the first method of the software object.

26. The method of claim 25, further comprising: configuring the first node to invoke the first method of the software object in response to user input.

27. The method of claim 1, wherein the software object comprises a first property; wherein the first node is operable to perform one or more of: get the first property; set the first property.

28. The method of claim 27, further comprising: configuring the first node to get/set the first property of the software object in response to user input.

29. The method of claim 1, wherein said first node includes an object reference input for receiving a reference to the software object; wherein said configuring comprises connecting said object reference input of said first node to receive the reference to said software object.

30. The method of claim 29, wherein said object node receives said information on said software object on said object reference input during execution of the graphical program.

31. The method of claim 30, wherein said configuring comprises: displaying on the screen an object reference node which includes an object reference output that provides the reference to said software object; and connecting the object reference output of said object reference node to said object reference input of said first node.

32. The method of claim 1, wherein said configuring comprises configuring said first node with a reference to said software object in response to user input.

33. The method of claim 1, wherein the graphical program comprises a diagram portion and a user interface portion; wherein the first node is comprised in the diagram portion.

34. The method of claim 1, wherein the graphical program comprises a diagram portion and a user interface portion; wherein the first node is comprised in the user interface portion.

35. The method of claim 1, wherein the software object is comprised in a server, wherein said configuring comprises: displaying on the screen a list of libraries associated with one or more servers; selecting a library from said list of libraries in response to user input displaying on the screen a list of possible classes from the selected library; and selecting a class from said list of possible classes in response to user input; wherein said software object is instantiated from said class.

36. A computer-implemented method for creating a graphical program, wherein the method for creating the graphical program operates in a computer including a display screen and a user input device, the method for creating the graphical program comprising: creating the graphical program in response to user input, wherein the graphical program is created in a first graphical program development environment, wherein said creating the graphical program includes: displaying on the screen an object node in the graphical program in response to user input, wherein said object node is operable to access capabilities of a software object, wherein the software object is external to, and created independently of, the first graphical program development environment; configuring the object node to receive information on the software object in response to user input; wherein, during execution of the graphical program, the object node is operable to access said capabilities of the software object.

37. A computer-implemented method for creating a graphical program, wherein the method for creating the graphical program operates in a computer including a display screen and a user input device, the method for creating the graphical program comprising: executing a first graphical program development environment application; receiving user input to the first graphical program development environment application for creation of the graphical program; wherein said receiving user input to the first graphical program development environment application comprises: receiving user input requesting inclusion of a first node in the graphical program; receiving user input to configure the first node to access capabilities of a pre-existing software object; wherein, during execution of the graphical program, the first node is operable to access said capabilities of the pre-existing software object.

38. The method of claim 37, further comprising: compiling the graphical program to produce executable code; wherein the executable code of the graphical program is executable to invoke execution of the pre-existing software object.

39. The method of claim 37, further comprising: executing the graphical program; wherein execution of the graphical program causes execution of the software object; wherein the software object executes independently of the graphical program.

40. The method of claim 37, further comprising: executing the graphical program in a first process; wherein execution of the graphical program causes execution of the software object; wherein the software object executes in a second process.

41. The method of claim 37, wherein the pre-existing software object was created in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

42. The method of claim 37, wherein said receiving user input to the first graphical program development environment application for creation of the graphical program does not include receiving user input specifying text-based programming language source code; wherein the pre-existing software object was constructed in response to text-based programming language source code.

43. The method of claim 37, further comprising: executing the graphical program, wherein the graphical program is executed by a graphical program execution engine; wherein said executing the graphical program comprises executing the first node to access the capabilities of the software object; wherein said accessing the capabilities of the software object comprises executing the software object; wherein the software object executes without use of the graphical program execution engine.

44. The method of claim 37, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object is not one of the plurality of nodes.

45. The method of claim 37, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object does not implement functionality of any of the plurality of nodes.

46. The method of claim 37, further comprising: compiling the graphical program to produce a first portion of executable code; wherein the software object comprises a second portion of executable code which is independent from the first portion of executable code.

47. The method of claim 37, wherein the computer is a first computer coupled to a second computer through a network; wherein the pre-existing software object is stored on the second computer.

48. The method of claim 47, further comprising: executing the graphical program, wherein the graphical program executes on the first computer; wherein said executing the graphical program comprises executing the first node to access the capabilities of the software object, wherein said accessing the capabilities of the software object causes execution of the software object on the second computer.

49. The method of claim 37, wherein the graphical program comprises a plurality of nodes, wherein the method further comprises: arranging on the screen said plurality of nodes, including said first node; and connecting said plurality of nodes and said first node in response to user input to create the graphical program.

50. The method of claim 49, wherein the method creates a graphical data flow program; wherein said connecting includes connecting said plurality of nodes to provide data flow between said plurality of nodes.

51. The method of claim 37, further comprising: constructing execution instructions in response to said graphical program, wherein said execution instructions are executable to access said capabilities of the software object; and executing said execution instructions, wherein said first node accesses said capabilities of the software object during said executing.

52. The method of claim 37, wherein the pre-existing software object comprises one of: an ActiveX object; a Java object; a C++ object; a CORBA object.

53. The method of claim 37, wherein the software object comprises a first method; wherein the first node is operable to invoke the first method of the software object.

54. The method of claim 53, further comprising: configuring the first node to invoke the first method of the software object in response to user input.

55. The method of claim 37, wherein the software object comprises a first property; wherein the first node is operable to perform one or more of: get the first property; set the first property.

56. The method of claim 55, further comprising: configuring the first node to get/set the first property of the software object in response to user input.

57. A memory medium which stores a graphical program development environment, wherein the graphical program development environment comprises program instructions executable to create a graphical program in response to user input, wherein said creating the graphical program includes: displaying on a display screen a first node in the graphical program in response to user input, wherein the first node is operable to access capabilities of a software object, wherein the software object is not present in the first graphical program development environment; configuring the first node to receive information on the software object in response to user input; wherein, during execution of the graphical program, the first node is operable to access the capabilities of the software object.

58. The memory medium of claim 57, wherein the software object is created in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

59. The memory medium of claim 58, wherein the second program development environment is a text-based program development environment.

60. The memory medium of claim 57, further comprising: creating the software object in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

61. The memory medium of claim 57, wherein the software object is operable to execute independently of the graphical program.

62. The memory medium of claim 57, wherein the software object exists prior to creating the graphical program.

63. The memory medium of claim 57, wherein the graphical program development environment further comprises program instructions executable to manage execution of the graphical program; wherein said executing the graphical program comprises executing the first node to access the capabilities of the software object; wherein said accessing the capabilities of the software object comprises executing the software object; wherein said execution of the software object is not managed by the graphical program development environment.

64. The memory medium of claim 57, wherein said creating the graphical program in response to user input does not include receiving user input specifying text-based programming language source code to implement the graphical program; wherein the software object is a pre-existing software object that was constructed in response to text-based programming language source code.

65. The memory medium of claim 57, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object is not one of the plurality of nodes.

66. The memory medium of claim 57, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object does not implement functionality of any of the plurality of nodes.

67. The memory medium of claim 57, wherein the graphical program development environment further comprises program instructions executable to compile the graphical program to produce a first portion of executable code; wherein the software object comprises a second portion of executable code which is independent from the first portion of executable code.

68. The memory medium of claim 57, wherein the memory medium is on a first computer coupled to a second computer through a network; wherein the software object is stored on the second computer.

69. The memory medium of claim 57, wherein the graphical program comprises a plurality of nodes, wherein the graphical program development environment further comprises program instructions executable to: arrange on the display screen said plurality of nodes, including said first node; and connect said plurality of nodes and said first node in response to user input to create the graphical program.

70. The memory medium of claim 57, wherein the graphical program development environment further comprises program instructions executable to display on the display screen a user interface panel in response to user input for displaying data input to and/or output from the graphical program.

71. The memory medium of claim 57, wherein the graphical program development environment further comprises program instructions executable to: construct execution instructions in response to said graphical program, wherein said execution instructions are executable to access said capabilities of the software object; and execute said execution instructions, wherein said first node accesses said capabilities of the software object during said executing.

72. The memory medium of claim 57, wherein the software object comprises one of: an ActiveX object; a Java object; a C++ object; a CORBA object.

73. The memory medium of claim 57, wherein the software object comprises a first method; wherein the first node is operable to invoke the first method of the software object.

74. The memory medium of claim 57, wherein the software object comprises a first property; wherein the first node is operable to perform one or more of: get the first property; set the first property.

75. A memory medium which stores a graphical program development environment, wherein the graphical program development environment comprises program instructions executable to create a graphical program in response to user input, wherein said creating the graphical program includes: receiving user input requesting inclusion of a plurality of nodes in the graphical program, wherein the plurality of nodes includes a first node; receiving user input to configure the first node to access capabilities of a pre-existing software object; wherein, during execution of the graphical program, the first node is operable to access said capabilities of the pre-existing software object.

76. The memory medium of claim 75, wherein the graphical program development environment further comprises program instructions executable to compile the graphical program to produce executable code; wherein the executable code of the graphical program is executable to invoke execution of the pre-existing software object.

77. The memory medium of claim 75, wherein the pre-existing software object was created in a second program development environment, wherein the second program development environment is different than the first graphical program development environment.

78. The memory medium of claim 75, wherein the user input to the first graphical program development environment application for creation of the graphical program does not include receiving user input specifying text-based programming language source code; wherein the pre-existing software object was constructed in response to text-based programming language source code.

79. The memory medium of claim 75, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object is not one of the plurality of nodes.

80. The memory medium of claim 75, wherein the graphical program includes a plurality of nodes visually indicating functionality of the graphical program; wherein the software object does not implement functionality of any of the plurality of nodes.

81. The memory medium of claim 75, wherein the graphical program development environment further comprises program instructions executable to compile the graphical program to produce a first portion of executable code; wherein the software object comprises a second portion of executable code which is independent from the first portion of executable code.

82. The memory medium of claim 75, wherein the pre-existing software object comprises one of: an ActiveX object; a Java object; a C++ object; a CORBA object.

83. The memory medium of claim 75, wherein the memory medium is on a first computer coupled to a second computer through a network; wherein the software object is stored on the second computer.

84. The memory medium of claim 75, wherein the graphical program comprises a plurality of nodes, wherein the graphical program development environment further comprises program instructions executable to: arrange on the display screen said plurality of nodes, including said first node; and connect said plurality of nodes and said first node in response to user input to create the graphical program.
Description
RESERVATION OF COPYRIGHT

A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.

FIELD OF THE INVENTION

The present invention relates to graphical programming, and in particular to a system for creating graphical programs, wherein the graphical programs are operable to access functionality or properties of objects.

DESCRIPTION OF THE RELATED ART

Traditionally, high level text-based programming languages have been used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to 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/she can efficiently program a computer system in a text-based environment. The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical 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 conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.

Examples of fields in which computer systems are employed to model and/or control physical systems are the fields of instrumentation, process control, and industrial automation. Computer modeling or control of devices such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing complexity and variety of instruments and devices available for use. However, due to the wide variety of possible testing/control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a program to control a desired system. As discussed above, computer programs used to control such systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation or industrial automation data. Thus, development and maintenance of the software elements in these systems often proved to be difficult.

U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e., a graphical programming environment, which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. A graphically based programming environment can be represented at level above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor, such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. In response to the user constructing a data flow diagram or graphical program using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, industrial automation systems and modeling processes, as well as for any type of general programming.

Therefore, Kodosky et al teaches a graphical programming environment wherein a user places or manipulates icons in a block diagram using a block diagram editor to create a data flow "program." A graphical program for controlling or modeling devices, such as instruments, processes or industrial automation hardware, is referred to as a virtual instrument (VI). In creating a virtual instrument, a user preferably creates a front panel or user interface panel. The front panel includes various front panel objects, such as controls or indicators that represent the respective input and output that will be used by the graphical program or VI, and may include other icons which represent devices being controlled. When the controls and indicators are created in the front panel, corresponding icons or terminals are automatically created in the block diagram by the block diagram editor. Alternatively, the user can first place terminal icons in the block diagram which cause the display of corresponding front panel objects in the front panel. The user then chooses various functions that accomplish his desired result, connecting the corresponding function icons between the terminals of the respective controls and indicators. In other words, the user creates a data flow program, referred to as a block diagram, representing the graphical data flow which accomplishes his desired function. This is done by wiring up the various function icons between the control icons and indicator icons. The manipulation and organization of icons in turn produces machine language that accomplishes the desired method or process as shown in the block diagram.

A user inputs data to a virtual instrument using front panel controls. This input data propagates through the data flow block diagram or graphical program and appears as changes on the output indicators. 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 adjusts the controls on the front panel to affect the input and views the output on the respective indicators.

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), and supervisory control and data acquisition (SCADA) applications, among others.

In parallel to the development of graphical data flow programming for various applications, such as virtual instrumentation, object and/or component technology has emerged in the area of software development. The notion of object technology relates to an application program or object using capabilities or services of an object. For example, object technology includes the notion of "servers" "exporting" their "objects" for use by "clients." A server is a software application which makes available its classes to be accessed from another application, referred to as a client. A client instantiates objects from the classes in the type libraries. In addition, the term "object" also includes various other types of components or objects, including applications, which offer services or functionality that can be accessed by a client.

Objects generally have properties and methods. Properties are the data associated with the object and typically determine attributes of the object, such as the number of columns of a spreadsheet. Methods are functions or operations which the object is capable of performing, such as drawing a spreadsheet on a display screen. A server exports an object by making the methods and properties of the object invokable by a client.

An example of a server is Microsoft Excel.RTM. which exports its objects for use by clients. An example of an object technology is Active X, formerly called OLE (Object Linking and Embedding), promulgated by Microsoft. For example, the Microsoft Excel spreadsheet program, the Microsoft Access.RTM. database program, and the Microsoft Word.RTM. word processing program, all export objects using the Active X interface. Active X is an industry standard object or component interface used by application programs to provide objects in a consistent manner to other application programs, development tools, and macro languages. Other examples of object technologies are OpenDoc.RTM. and the Common Object Request Broker Architecture (CORBA).

It is desirable for a program, such as a graphical program, to be able to access functionality provided by an object or server. For example, often it is desirable for a program, such as a graphical program, to display, manipulate, catalog, edit or perform other operations, such as may be performed by an object or server, on data acquired or generated by a graphical program or virtual instrument. For example, it may be desirable for a virtual instrument to display acquired temperature samples in a spreadsheet, such as a Microsoft Excel spreadsheet. More generally, it would be desirable to provide a system and method which enables a graphical program to be able to invoke objects, such as from a server, for a variety of applications.

Therefore, improved methods are desired for enabling a graphical data flow programming system to access objects. More particularly, an improved system and method is desired which enables a graphical data flow program to be constructed which uses capabilities of objects.

SUMMARY OF THE INVENTION

The present invention comprises a system and method for creating a graphical program, wherein the graphical program is operable to access capabilities of an object. The present invention preferably operates in a computer including a display screen and a user input device.

During creation of the graphical program, the user operates to place an object node in the graphical program, wherein the object node is operable to access capabilities of the object. Stated another way, during program creation the computer system displays on the screen an object node in the graphical program in response to user input, wherein the object node is operable to access capabilities of the object. This preferably includes the user arranging on the screen the graphical program, including the object node. The graphical program will typically comprise a plurality of nodes, and the method for creating the graphical program comprises arranging on the screen the plurality of nodes, including the object node, and connecting the various nodes to create the graphical program. In the preferred embodiment, the nodes are connected in a data flow paradigm.

The user then configures the object node to receive information on the object, preferably by the user configuring the object node with a reference to the object, e.g., a pointer, address, or other information which specifies the identity and/or location of the object. This preferably includes the user selecting a class of the object. In the preferred embodiment, the object node includes an object reference input for receiving a reference to the object, and the user connects the object reference input of the object node to receive the reference to the object. This preferably includes the user placing an object reference node in the graphical program, wherein the object reference node includes an object reference output that provides the reference to the object, and the user connecting the object reference output of the object reference node to the object reference input of the object node. The object node then receives the information on the object on the object reference input during execution of the graphical program.

Creation of the graphical program may also include configuring a user interface to display data input to and/or output from the graphical program. Once the graphical program has been created, then during execution of the graphical program, the object node accesses the capabilities of the object. More specifically, after creation of the graphical program, the system/method constructs execution instructions in response to the graphical program, wherein the execution instructions are executable to access the capabilities of the object. When these execution instructions are executed, the object node accesses the capabilities of the object.

In the preferred embodiment, the object may be any of various types of software, such as a software object according to the standard principles of object-oriented software, a software component, other types of re-usable software elements, or an application, among others. Where the object is a software object or component, the object node is executable to either invoke a method of the object, get and/or set one or more properties of the object, or access other capabilities of the object. Where the object is an application, the object node is operable to perform one or more of 1) initiate execution of the application; or 2) get/set one or more properties of the application. Also, the object may reside in the same computer where the graphical program is being created, or may reside in a different computer connected through a network.

In the preferred embodiment, the graphical program comprises a diagram or execution portion and a user interface portion, and the object node is comprised in the diagram portion. Alternatively, the object node may be comprised in the user interface portion. In this case where the object node is located in the user interface, the object is preferably comprised in the object node, and the object node operates to manipulate the object. For example, a document may be comprised in the object node, wherein the object node is operable to display changes to the document during execution of the graphical program. As another example, the object may be a user interface element, such as a control or indicator, wherein the object node is operable to affect the data input to or output from the control or indicator - - - . - - - .

BRIEF DESCRIPTION OF THE DRAWINGS

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:

FIG. 1 illustrates an instrumentation control system according to one embodiment of the present invention;

FIG. 1A illustrates an industrial automation system according to one embodiment of the present invention;

FIG. 2 is a block diagram of the computer of the control system of FIG. 1;

FIG. 3 is a block diagram illustrating the relationship of portions of the instrumentation control system of FIG. 1 according to a first embodiment;

FIG. 3a is a block diagram illustrating the relationship of portions of the instrumentation control system of FIG. 1 according to a second embodiment;

FIG. 4 is a flowchart diagram illustrating creation of a graphical program including an object node according to the present invention;

FIG. 5 is a flowchart diagram illustrating execution of the graphical program created in FIG. 4, wherein the object node operates to access capabilities of an object according to the present invention;

FIG. 6 is a screen shot illustrating the VI block diagram and front panel of an exemplary automation virtual instrument of FIG. 3;

FIG. 7 is a screen shot illustrating the automation nodes palette;

FIG. 8 is a flowchart illustrating steps taken to create and use a graphical automation client program of FIG. 3;

FIGS. 8a, 8b, and 8c are a flowchart illustrating steps taken to create and use a graphical automation client program in more detail than the flowchart of FIG. 8;

FIG. 9 is a screen shot illustrating the automation control refnum palette;

FIG. 10 is a screen shot illustrating an automation refnum in a VI block diagram and a pop-up menu of the automation refnum with a menu selection item for selecting an automation class;

FIG. 11 is a screen shot illustrating an exemplary list of the type libraries associated with the OLE Automation servers present in a system;

FIG. 12 is a screen shot illustrating a type library browse menu selected from the pop-up menu of FIG. 10;

FIG. 13 is a screen illustrating an automation class having been chosen for the automation refnum of FIG. 10 and an automation open node being wired to the automation refnum;

FIG. 14 is a screen shot illustrating an automation property node wired to the automation open node of FIG. 13 and a list of properties of the automation class which was chosen in FIG. 13;

FIG. 15 is a screen shot illustrating a property having been chosen for the automation property node of FIG. 14;

FIG. 16 is a screen shot illustrating an automation invoke node wired to the automation property node of FIG. 14 and a list of methods of the automation class which was chosen in FIG. 14;

FIG. 17 is a screen shot illustrating a method having been chosen for the automaton invoke node of FIG. 16;

FIG. 18 is a flowchart illustrating steps taken to display an application help screen for an automation object according to the preferred embodiment of the present invention;

FIG. 19 is a screen shot illustrating the step of displaying a method of an automation invoke node according of the flowchart of FIG. 18;

FIG. 20 is a screen shot illustrating the step of displaying an application help option for a method of an automation invoke node according of the flowchart of FIG. 18;

FIG. 21 is a screen shot illustrating the step of displaying a application help screen of the flowchart of FIG. 18;

FIG. 22 is a flowchart illustrating steps taken to propagate the automation class of an automation node to another automation node;

FIGS. 23 through 25 are screen shots illustrating steps of the flowchart of FIG. 22;

FIG. 26 is a flowchart illustrating steps taken to propagate the automation class of an automation node to another automation node;

FIGS. 27 and 28 are screen shots illustrating steps of the flowchart of FIG. 24;

FIG. 29 is a flowchart illustrating steps taken to perform type propagation checking of automation nodes;

FIGS. 30 through 32 are screen shots illustrating steps of the flowchart of FIG. 29;

FIG. 33 is a flowchart illustrating in more detail the step of FIG. 29 of performing type propagation;

FIGS. 34, 35 and 36 are screen shots illustrating a help screen for an automation open node, an automation property node, and an automation invoke node, respectively.

FIG. 37 is a block diagram illustrating the relationship of portions of the instrumentation control system of FIG. 1 according to a first embodiment;

FIG. 37a is a block diagram illustrating the relationship of portions of the instrumentation control system of FIG. 1 where the server is located on a remote computer system;

FIG. 38 illustrates the VI Server front panel refnum controls;

FIGS. 39-42 illustrate the VI Server function nodes which can be placed in a graphical program and used for programmatically accessing functionality of other graphical programming applications or programs;

FIG. 43 illustrates a block diagram or graphical program which uses Strictly-typed VI references and utilizes the call by reference node to call a server VI in a client VI;

FIG. 44 illustrates a block diagram or graphical program which uses Generic VI references with the Property and Invoke nodes;

FIG. 45 illustrates a block diagram or graphical program which includes an Open Application node and the Property and/or Invoke nodes to access capabilities of a server application;

FIG. 46 is a is a screen shot illustrating the "Select LabVIEW Class" submenu;

FIG. 47 is a is a screen shot illustrating the Server Configuration Dialog Box;

FIG. 48 is a is a screen shot illustrating the TCP/IP Access Dialog Box for selecting Exported VIs;

FIG. 49 is a is a screen shot illustrating the TCP/IP Access Dialog Box for selecting TCP/IP access;

FIGS. 50A-D illustrate how VIs and applications are accessed on remote computer systems according to the present invention.

FIG. 51 illustrates ActiveX controls referred to as ActiveX container and ActiveX variant; and

FIGS. 52-54 illustrate the Insert Object dialog box for inserting different types of objects into the front panel.

While the invention is susceptible to various modifications and alternative forms specific embodiments are shown by way of example in the drawings and will herein be described in detail. It should be understood however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed. But on the contrary the invention is to cover all modifications, equivalents and alternative following within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Incorporation by Reference

The following U.S. Patents and patent applications are hereby incorporated by reference in their entirety as though fully and completely set forth herein.

U.S. Pat. No. 4,901,221 titled "Graphical System for Modeling a Process and Associated Method," issued on Feb. 13, 1990.

U.S. Pat. No. 5,481,741 titled "Method and Apparatus for Providing Attribute Nodes in a Graphical Data Flow Environment".

U.S. patent application Ser. No. 08/916,005 titled "System and Method for Providing Client/Server Access to Graphical Programs" filed on Aug. 21, 1997, whose inventors were Robert Dye and Omid Sojoodi.

U.S. patent application Ser. No. 08/810,079 titled "System and Method for Developing Automation Clients using a Graphical Data Flow Program" filed on Mar. 4, 1997, whose inventors were Murali Parthasarathy and Omid Sojoodi,

U.S. patent application Ser. No. 08/717,771 titled "System and Method for Performing Class Checking of Objects in a Graphical Data Flow Program" and filed Sep. 23, 1996, whose inventors were Omid Sojoodi and Stephen W. Rogers.

The LabVIEW and BridgeVIEW graphical programming manuals and help files, including the "G Programming Reference Manual", available from National Instruments Corporation, are also hereby incorporated by reference in their entirety.

FIGS. 1 and 1A--Instrumentation and Industrial Automation Systems

Referring now to FIG. 1, an instrumentation control system 100 is shown. The system 100 comprises a host computer 102 which connects to one or more instruments. The host computer 102 comprises a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through the one or more instruments to analyze, measure or control a unit under test (UUT) or process 150.

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 132
and associated image acquisition 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 GPIB instrument 112 is coupled to the computer 102 via a GPIB interface card 122 provided by the computer 102. In a similar manner, the video device 132 is coupled to the computer 102 via the image acquisition card 134, and the motion control device 136 is coupled to the computer 102 through the motion control interface card 138. The data acquisition board 114 is coupled to the computer 102, and preferably interfaces through signal conditioning circuitry 124 to the UUT. The signal conditioning circuitry 124 preferably comprises an SCXI (Signal Conditioning eXtensions for Instrumentation) chassis comprising one or more SCXI modules 126.

The GPIB card 122, the image acquisition card 134, the motion control interface card 138, and the DAQ card 114 are typically plugged in to an I/O slot in the computer 102, such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided by the computer 102. However, these cards 122, 134, 138 and 114 are shown external to computer 102 for illustrative purposes.

The VXI chassis or instrument 116 is coupled to the computer 102 via a VXI bus, MXI bus, or other serial or parallel bus provided by the computer 102. The computer 102 preferably includes VXI interface logic, such as a VXI, MXI or GPIB interface card (not shown), which interfaces to the VXI chassis 116. The PXI chassis or instrument is preferably coupled to the computer 102 through the computer's PCI bus.

A serial instrument (not shown) may also be coupled to the computer 102 through a serial port, such as an RS-232 port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 bus, provided by the computer 102. In typical instrumentation control systems an instrument will not be present of each interface type, and in fact many systems may only have one or more instruments of a single interface type, such as only GPIB instruments.

The instruments are coupled to the unit under test (UUT) or process 150, or are 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, a process control application, or a man-machine interface application.

Referring now to FIG. 1A, an industrial automation system 160 is shown. The industrial automation system 160 is similar to the instrumentation or test and measurement system 100 shown in FIG. 1. Elements which are similar or identical to elements in FIG. 1 have the same reference numerals for convenience. The system 160 comprises a computer 102 which connects to one or more devices or instruments. The computer 102 comprises a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through the one or more devices to a process or device 150 to perform an automation function, such as M (Man Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed data acquisition, process control, advanced analysis, or other control.

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.

The DAQ card 114, the PXI chassis 118, the video device 132, and the image acquisition card 136 are preferably connected to the computer 102 as described above. The serial instrument 182 is coupled to the computer 102 through a serial interface card 184, or through a serial port, such as an RS-232 port, provided by the computer 102. The PLC 176 couples to the computer 102 through a serial port, Ethernet port, or a proprietary interface. The fieldbus interface card 172 is preferably comprised in the computer 102 and interfaces through a fieldbus network to one or more fieldbus devices. Each of the DAQ card 114, the serial card 184, the fieldbus card 172, the image acquisition card 134, and the motion control card 138 are typically plugged in to an I/O slot in the computer 102 as described above. However, these cards 114, 184, 172, 134, and 138 are shown external to computer 102 for illustrative purposes. In typical industrial automation systems a device will not be present of each interface type, and in fact many systems may only have one or more devices of a single interface type, such as only PLCs. The devices are coupled to the device or process 150.

Referring again to FIGS. 1 and 1A, the computer system 102 preferably includes a memory media on which computer programs according to the present invention are stored. The term "memory media" is intended to include an installation media, e.g., a CD-ROM, or floppy disks 104, a computer system memory such as DRAM, SRAM, EDO RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory media preferably stores a graphical programming development system for developing and executing graphical programs. The graphical programs are operable to access capabilities or functionality of an object, such as an object exported by a server. The host CPU executing code and data from the memory thus comprises a means for creating and executing graphical programs according to the methods described below.

The instruments or devices in FIGS. 1 and 1A are controlled by graphical software programs. Graphical software programs which perform data acquisition, analysis and/or presentation, e.g., for instrumentation control or industrial automation, are referred to as virtual instruments.

In the preferred embodiment, the present invention utilizes the LabVIEW or BridgeVIEW graphical programming systems, hereafter collectively referred to as LabVIEW, available from National Instruments. Also, in the preferred embodiment, the term "LabVIEW" is intended to include graphical programming systems which include G programming functionality, i.e., which include at least a portion of LabVIEW graphical programming functionality, including the BridgeVIEW graphical programming system.

Also, the term "graphical programming system" is intended to include any of various types of systems which are used to develop or create graphical code or graphical programs, including LabVIEW and BridgeVIEW from National Instruments, Visual Designer from Intelligent Instrumentation, Hewlett-Packard's VEE (Visual Engineering Environment), Snap-Master by HEM Data Corporation, DASYLab by DasyTec, GFS DiaDem, and GEDAE, among others.

Although in the preferred embodiment the graphical programming system is involved with data acquisition/generation, analysis, and/or display, and for controlling or modeling instrumentation or industrial automation hardware, it is noted that the present invention can be used for a plethora of applications and are not limited to instrumentation or industrial automation applications. In other words, FIGS. 1 and 1A 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 for creating graphical programs or graphical code for any of various types of applications, including general purpose software applications such as word processing, spreadsheets, network control, games, etc.

FIG. 2--Computer Block Diagram

FIG. 2 is a representative block diagram of the host computer 102 (of FIG. 1). It is noted that the block diagram of FIG. 2 is representative only, and the computer 102 may have any of various architectures. Also, the elements of a computer not necessary to understand the operation of the present invention have been omitted for simplicity.

The computer 102 includes at least one central processing unit or CPU 200 which is coupled to a processor or host bus 202. The CPU 200 may be any of various types, including an x86 processor, a PowerPC processor, a CPU from the Motorola family of processors, a CPU from the SPARC family of RISC processors, as well as others. Main memory 206 is coupled to the host bus 202 by means of memory controller 204. The main memory 206 stores a graphical programming system. The main memory 206 also stores operating system software as well as other software for operation of the computer system, as well known to those skilled in the art. The instrumentation control software will be discussed in more detail below.

The host bus 202 is coupled to an expansion or input/output bus 210 by means of a bus controller 208 or bus bridge logic. The expansion bus 210 is preferably the PCI (Peripheral Component Interconnect) expansion bus, although other bus types can be used. The expansion bus 210 includes slots for various devices such as the data acquisition board 114 (of FIG. 1), a GPIB interface card 122 which provides a GPIB bus interface for coupling to the GPIB instrument 112 (of FIG. 1), and a VXI or MXI bus card 186 for coupling to the VXI chassis 116 for receiving VXI instruments.

The computer 102 further preferably comprises a video display subsystem 220 which interfaces to video monitor 222, and a non-volatile memory such as hard drive 224, each preferably coupled to the expansion bus 210. The computer 102 further preferably comprises various input devices, such as mouse 230 and keyboard 232, as shown. The input devices are shown coupled to the expansion bus 210, but may be connected to the computer in any of various ways, such as a USB port (not shown). The computer 102 further preferably comprises various other standard components, as is well known in the art.

Graphical Programming System

As noted above, in the preferred embodiment the present invention utilizes the LabVIEW or BridgeVIEW graphical programming system. A graphical program created using LabVIEW comprises an instrument front panel in a first window and a block diagram in a second window. The block diagram comprises program execution elements, referred to as nodes, which are wired or linked together to produce a data flow program. The front panel comprises controls for providing input data to the block diagram and indicators for receiving and/or displaying output data from the nodes of the block diagram. Certain drawings in the present disclosure comprise screen shots displayed during the execution of LabVIEW according to the present invention.

Graphical Programming Environment

Referring now to FIG. 3, a block diagram illustrating the relationship of portions of the instrumentation control systems 100 or 160 (of FIGS. 1 and 1A) are shown. Preferably, the elements shown in FIG. 3 (with the exception of the hardware instrument 254) are software elements which are executed on the computer 102 (of FIGS. 1 and 1A). The present invention is used to create a graphical program which is operable to access capabilities of one or more objects during execution. The present invention is also useable to create a graphical program portion which is a part of a larger graphical program.

The present invention may be used to create a graphical program which is able to access capabilities of various types of objects, including software objects according to the standard notion of object oriented software, such as Java objects, C++ objects, etc.; software components, such as ActiveX controls; other types of re-usable software elements; and applications; as well as other types of software constructs which offer capabilities or functionality.

In the preferred embodiment, a programmer employs a front panel editor 262, a block diagram editor 264, and optionally a connector pane/icon editor 272 of a graphical programming environment to produce the graphical program. In the instrumentation application of the preferred embodiment, the graphical program is referred to as a virtual instrument (VI) 250. The block diagram editor 264 generates executable instructions, i.e., machine language instructions, in response to the VI
250. The VI 250 developed by the programmer is executed by an execution subsystem 256 of the graphical programming environment to control an instrument 254. The instrument 254 is illustrative of instruments such as those of FIGS. 1 and 1A.

FIG. 6 is a screen shot from a graphical programming environment including a virtual instrument or graphical program exemplary of the VI 250 of FIG. 3 according to one embodiment. The screen shot of FIG. 6 comprises an instrument front panel in a window in the upper portion of the screen and a block diagram in a window in the lower portion of the screen. The block diagram comprises program execution elements, referred to as nodes, which are wired or linked together to produce a data flow program. The front panel comprises controls for providing input data to the block diagram and indicators for receiving and/or displaying output data from the nodes of the block diagram.

Preferably the graphical programming system comprises portions of National Instruments LabVIEW software. The drawings of the present disclosure include numerous screen shots displayed during the execution of LabVIEW. In the screen shots, LabVIEW is executing under the supervision of the Microsoft Windows 95 operating system. For more information on the LabVIEW graphical programming environment of the preferred embodiment, please see U.S. Pat. No. 5,481,741 referenced above.

Referring again to FIG. 3, the graphical programming environment further comprises one or more object controls 274. The front panel editor 262 is preferably operable to generate a VI front panel or user interface. The front panel editor 262
communicates with the control(s) 274. More specifically, the user arranges on the screen one or more user interface items, referred to as controls and indicators, optionally including one or more of the object controls 274. Alternatively, the front panel or user interface is created automatically in response to creation of the block diagram, and the front panel editor 262 is not included. The control(s) 274 communicates with an object manager 268 to obtain or provide information regarding class/type libraries 270 in the system and object classes in the object type libraries 270. In one embodiment, the object controls operate as object nodes to reference an object and display changes made to the object.

The graphical programming environment further comprises object nodes 266, also referred to as object function nodes. Examples of object nodes 266 according to one embodiment are shown in the object nodes palette of FIG. 7. The object nodes 266
preferably include an object refnum, an object open node, an object close node, an object invoke node, an object property node, and a call node, among others. The block diagram editor 264 is operable to create a VI block diagram, or block diagram. The block diagram editor 264 communicates with the object nodes 266, which in turn communicate with the object manager 268. More specifically, the user arranges on the screen a plurality of nodes on the screen, including one or more object function nodes
266, to create a block diagram or graphical program.

The object manager 268 accesses object class/type libraries 270 to acquire information necessary to perform object management operations. Preferably, the object manager 268 communicates with the Windows operating system Registry, or other similar data structures, to obtain information regarding the object class/type libraries 270 in the system. The object control 274, object nodes 266, and object manager 268 will be discussed in more detail below.

Advantageously, the graphical programming environment, and in particular the object control 274, the object nodes 266, the object manager 268, and the object manager run-time library 258, enable a graphical program to instantiate objects of an unlimited number of object classes of object applications, and to remotely invoke properties and methods of the instantiated objects.

The graphical programming environment further preferably includes a connector pane/icon editor 272 for forming VI's into subVI's, i.e., a VI which may be used as a graphical programming element in another VI. The reader is referred to U.S. Pat. No. 5,301,336 for more information about the subVI's and the icon editor 272.

The execution subsystem 256 executes the executable instructions constructed from a block diagram of the VI 250. For more information about the execution subsystem 256 the reader is referred to U.S. Pat. No. 5,481,741.

Preferably, the VI 250 invokes methods and properties of objects of an object server 252, or more than one object server, indirectly through the services of the object manager run-time library 258. Examples of the object server 252 include Microsoft Excel, Access, Word, and National Instruments ComponentWorks controls. Other examples of the object server 252 include Claris Works. The VI 250 controls the instrument 254 through an instrument device driver 253 which includes executable functions which are called by the VI 250 to perform operations in order to control the instrument 254.

The object nodes 266 and object control(s) 274 preferably comprise classes and objects,2 according to the notion of classes and objects in the art of object-oriented programming. Each of the object nodes 266 and the object controls 274 comprise their own properties and methods. The methods include a method for drawing an icon representation of the object on the video display 145 of the computer 102 either in the VI block diagram or front panel, a method for generating code associated with the different functions of each node or control, and a method for performing type propagation checking. The operation of object nodes 266 and object control 274 will be explained in more detail below. As mentioned above, the object nodes 266 comprise an object refnum associated with the object control 274, an object open node, an object property node, an object invoke node, and an object close node.

FIG. 3a illustrates an alternate embodiment of the system 100 of FIG. 3. This embodiment is similar to that shown in FIG. 3 and corresponding elements are numbered identically. In the embodiment of FIG. 3a the object server 252 is a program capable of controlling an instrument 254. In other words, in FIG. 3 the graphical program client directly controls the instrument 254, and the client uses the object server to aid in controlling the instrument 254. In FIG. 3a, the object or object server directly controls the instrument 254. For example, the object server 252 may be a program written in the C language for controlling a GPIB instrument. The client VI 250 instantiates objects from the classes exported by the object server 252 and invokes methods and properties of the objects to direct the object server 252 to control the instrument hardware 254.

As mentioned above, the graphical program 250 is not necessarily related to controlling an instrument, but rather the graphical program 250 may be for any of various applications. That is, the object client may have an application other than instrumentation control. In one embodiment similar to that of FIG. 3a, the VI 250 is an object client application which performs other functions. For example, a programmer desires to develop a stock portfolio viewer in a graphical programming environment and develops an object client to access Microsoft Excel spreadsheet objects in order to display a stock portfolio.

Advantageously, the graphical system and method for producing the graphical program or VI 250 has a number of benefits. These benefits include reduction in the development time required to create the VI 250 as well as reduction of the number of code defects in the VI 250. Yet another benefit is the simplicity of programming which makes the development of a graphical program, such as an instrumentation control program, more practical for a larger number of people, i.e., those who might not have the skills, or resources to develop the skills, to develop programs according to more conventional text-based methods. The system and method also provides class propagation, class checking and type checking in a graphical programming environment, discussed further below, thus simplifying program development.

FIGS. 4 and 5--Creation and Execution of a Graphical Program Including Object Nodes

FIG. 4 is a flowchart diagram illustrating creation of a graphical program including an object node according to the present invention. As shown, during creation of the graphical program, in step 302 the user operates to place an object node in the graphical program, wherein the object node is operable to access capabilities of the object. Stated another way, during program creation the computer system displays on the screen an object node in the graphical program in response to user input, wherein the object node is operable to access capabilities of the object. In the preferred embodiment, the user drags the object node from a palette onto the graphical program window.

In step 304 the user arranges on the screen the graphical program, including the object node. The graphical program will typically comprise a plurality of nodes, and the method for creating the graphical program preferably comprises arranging on the screen the plurality of nodes, including the object node, and connecting the various nodes to create the graphical program. In the preferred embodiment, the nodes are connected in a data flow paradigm, wherein nodes include inputs and outputs, and each node receives input data from another node, or from an input user interface node or terminal, and each node provides output data to another node, or to an output user interface node or terminal.

In step 306 the user then configures the object node to receive information on the object, preferably by the user configuring the object node with a reference to the object, e.g., a pointer, address, or other information which specifies the identity and/or location of the object. Step 306 is preferably performed as part of arranging the graphical program on the screen in step 304.

In the preferred embodiment, the object node includes an object reference input for receiving a reference to the object, and the user connects the object reference input of the object node to receive the reference to the object. This preferably includes the user placing an object reference node in the graphical program, wherein the object reference node includes an object reference output that provides the reference to the object, and the user connecting the object reference output of the object reference node to the object reference input of the object node. The object node then receives the information on the object on the object reference input during execution of the graphical program.

Alternatively, the user "pops up" on the object node to configure the object node with the reference to the object. When the user "pops up" on the object node, a dialog box appears. The user then enters information into the dialog box to configure the object node with the reference to the object.

Step 306 also preferably includes the user selecting the class of the object. Once the class is selected, then the object is preferably instantiated at run time. Step 306 further includes selecting any desired methods to be invoked on the object or properties to get/set on the object. For example, if the object node is an invoke node, the user preferably selects one or more methods which are to be invoked on the object by the invoke node during execution of the graphical program. If the object node is a property node, the user preferably selects one or more properties to get/set on the object during execution of the graphical program. The user preferably selects the methods and/or properties by "popping up" on the object node and using a dialog box or menu to select the desired methods and/or properties. Thus, the user preferably configures the object node for the desired functionality.

Creation of the graphical program may also include configuring a user interface to display data input to and/or output from the graphical program. In one embodiment, such as the LabVIEW graphical programming system from National Instruments, the user may separately configure or assemble a user interface panel including user interface nodes, such as dials, switches, charts, graphs, etc. In this embodiment, terminals which correspond to each of the user interface nodes appear in the block diagram and operate to provide or represent data input to/output from the block diagram. In another embodiment, the user assembles user interface nodes into the block diagram with the function nodes, wherein the user interface nodes have associated user interface elements, such as dials, sliders, text boxes, graphs, charts, etc. The user may then selectively view the user interface elements associated with each of the user interface nodes, such as in Hewlett Packard's VEE product. Alternatively, the user interface panel is automatically constructed from the user interface nodes in the block diagram, such as in the Visual Designer product from Intelligent Instrumentation.

Once the graphical program has been created, then during execution of the graphical program, the object node is operable to access the capabilities of the object. More specifically, after creation of the graphical program, execution of the graphical program operates as shown in FIG. 5. FIG. 5 is a flowchart diagram illustrating execution of the graphical program created in FIG. 4, wherein the object node operates to access capabilities of an object according to the present invention. As shown, in step 312 the system/method constructs execution instructions in response to the graphical program, wherein the execution instructions are executable to access the capabilities of the object. In step 314 the execution instructions are executed. When these execution instructions are executed, the object node accesses the capabilities of the object, such as invoking method(s) of the object and/or getting/setting properties of the object.

In the preferred embodiment, the object may be any of various types of software, such as a software object according to the standard principles of object-oriented software, a software component, other types of re-usable software elements, or an application, among others. Where the object is a software object or component, the object node is executable to either invoke a method of the object, get and/or set one or more properties of the object, or access other capabilities of the object. Where the object is an application, the object node is operable to perform one or more of 1) initiate execution of the application; or 2) get/set one or more properties of the application. Also, the object may reside in the same computer where the graphical program is being created, or may reside in a different computer connected through a network.

In the preferred embodiment, the graphical program comprises a diagram or execution portion and a user interface portion, and the object node is comprised in the diagram portion. Alternatively, the object node may be comprised in the user interface portion. In this case where the object node is located in the user interface, the object is preferably comprised in the object node, and the object node operates to manipulate the object. For example, the document comprised in the object node, wherein the object node is operable to display object may be a changes to the document during execution of the graphical program. As another example, the object may be a user interface element, such as a control or indicator, wherein the object node is operable to affect the data input to or output from the control or indicator - - - . - - - .

EMBODIMENTS OF THE INVENTION

The following comprise various embodiments of the present invention. FIGS. 8-36 illustrate one embodiment of the present invention used for creating a graphical program, wherein the graphical program is executable to access capabilities of one or more objects. FIGS. 37-50 illustrate a specific embodiment of FIGS. 8-36, where the object whose capabilities are being accessed is an application, such as a graphical program application, e.g., LabVIEW. FIGS. 51-55 illustrate an embodiment where the object node is a user interface element, such as an ActiveX container, which manipulates data on objects comprised in the node.

FIGS. 8-36: First Embodiment

Graphical Program Client Creation

FIG. 8 is a flowchart illustrating steps taken to create a graphical program, referred to as a graphical program client or graphical automation client, according to the preferred embodiment of the method. The flowchart of FIG. 8 provides a high level view of the method of the preferred embodiment. The flowchart of FIGS. 8a-8c provide a more detailed view of the method of this embodiment. Thus the flowchart of FIG. 8 provides a high level view of the steps of the flowchart of FIGS. 8a, 8b, and
8c, and corresponding steps are numbered identically. The screen shot of FIG. 6 illustrates an example graphical program created according to the flowchart of FIG. 8. The nodes illustrated in FIG. 7 are example object nodes, referred to as automation function nodes, which are used in the flowchart of FIG. 8. In this description, the terms "automation" and "object" are used substantially interchangeably.

As shown in FIG. 8, the user drops or places an automation control icon on a virtual instrument front panel, and in response the block diagram editor 264 displays a corresponding automation class refnum icon in the block diagram, in step 380. The user then selects an automation class to associate with the automation refnum. The automation refnum receives the user input and associates the user-selected automation class with the automation refnum, in step 392.

The user drops an automation open node on the block diagram and in response the block diagram editor 264 displays an automation open node icon, in step 394. The user connects the automation refnum and the automation open node and in response the block diagram editor 264 displays a wire connecting the automation refnum and the automation open node, in step 396.

The user drops an automation function node in the block diagram and in response the block diagram editor 264 displays an automation function node, in step 398. An automation function node preferably comprises an automation property node or an automation invoke node. In one embodiment, an automation function node may perform functions or access capabilities of automation objects other than invoking methods and properties, such as event handling, i.e., the automation function node may be an automation event node. The user connects the automation open node and the automation function node and in response the block diagram editor 264 displays a wire connecting the automation open node and the automation function node, in step 400. The user may drop both an automation invoke node and an automation property node in creating the graphical automation client. Furthermore, the user may drop one or more of both automation property nodes and automation invoke nodes in order to invoke multiple properties and/or methods in creating the graphical automation client. Alternatively, a single invoke node may be configured to invoke multiple methods and a single property node may be configured to get/set multiple properties.

The user then selects a property or method and in response the automation property node or automation invoke node receives the user input and associates the user-selected property or method, respectively, with the automation property node or automation invoke node, respectively, in step 406.

The graphical programming environment then constructs execution instructions based on the graphical program comprising the automation refnum, automation open node, automation property node and/or automation invoke node, and wires, in step 426. The graphical programming environment then executes the execution instructions, in step 428. A more detailed description of the steps of FIG. 8 is given below with regard to FIGS. 8a, 8b, and 8c.

In the embodiment of FIG. 8, the user selects the object class in steps 382 and 392 utilizing an automation class refnum, and in steps 394 and 396 an automation open node is placed in the block diagram, which operates to instantiate an object of the selected class. In one embodiment, a single refnum or node is used to both select the object class and instantiate the object. Alternatively, selection of the class and instantiation of the object are performed when the object node is displayed in step 398. In this latter embodiment, when the user selects the object node or automation function node for inclusion in the graphical program, at that time the user selects the desired class and then selects the methods and/or properties. An object from this selected class is then instantiated by the object node at run-time.

FIGS. 8a, 8b, and 8c are a more detailed flowchart illustrating steps taken to create a graphical automation client according to the preferred embodiment of the method. The flowchart of FIGS. 8a-8c illustrates an embodiment which presumes the use of an automation close refnum and an open node to select the class and instantiate the object, respectively. A user drags, preferably using a mouse, an automation control from a refnum palette, shown in FIG. 9, and drops the automation control on a VI front panel.

In response to the user dropping the automation refnum, the front panel editor 262 displays an automation control in the front panel, and the block diagram editor 264 displays an automation refnum associated with the automation control in a block diagram in step 380. Alternatively, the user drops an automation refnum from the palette of FIG. 7 and the front panel editor 262 invokes a method of the automation control 274 to draw an automation control icon in the front panel.

Preferably, the automation control 274 comprises a draw method which the front panel editor 262 and block diagram editor 264 invoke in order to display an automation control icon in the front panel and to display an automation refnum icon in the block diagram, respectively. FIG. 8 shows an automation refnum displayed in a block diagram. FIG. 8 also shows a pop-up menu for the automation refnum including a "Select OLE Class" menu item with a "Browse" item. Preferably, the user right clicks a mouse on the automation refnum in order to see the pop-up menu.

In one embodiment, an automation client program, i.e., a VI, developed using the graphical programming environment is capable of invoking methods of and modifies attributes of objects via a plurality of automation technologies, including Microsoft Automation. Examples of other automation technologies are OpenDoc and the Common Object Request Broker Architecture (CORBA). In this embodiment, the object manager 68 obtains a list of automation technologies in the system. The automation refnum queries the object manager 268 for the list and displays the list of automation technologies for the user in step 382. The user selects one of the automation technologies from the displayed list of automation technologies. In response to the user selection, the automation refnum selects the automation technology from the list of automation technologies and associates the selected automation technology with the automation refnum in step 384.

The automation refnum is a reference to a user-selected automation class. The automation refnum includes a refnum output terminal, to which a wire may be connected. At edit-time, the automation refnum provides, at its output terminal, a type descriptor which specifies an automation class and the type library to which the automation class belongs. The type library is one of the type libraries 270 of FIG. 3. Type descriptors will be described in detail below. The time during which a user is creating, i.e., editing a VI 50, by dropping nodes and wiring them together, is referred to as "edit-time." The time when instructions of the VI 50 are executed is referred to as "run-time".

Referring again to FIG. 8a, in response to user input, the automation refnum queries the object manager 268 for a list of type libraries 270 (of FIG. 3) associated with the automation servers present in the system. The automation refnum displays the list of type libraries 270 associated with the automation servers in step 386. Preferably, the object manager 268 provides the automation refnum with a list of OLE Automation type libraries in the system. In one embodiment, the object manager 268
provides the automation refnum with a list of type libraries for each automation technology in the system.

Preferably, the user input includes the user clicking on the "Browse" item of the "Select OLE class" item of the automation refnum pop-up menu, shown in FIG. 12, and selecting the pull-down menu in the "Type Library" window shown in FIG. 12. Preferably, the object manager 268 queries the Windows Registry to obtain a list of OLE Automation type libraries present in the system. Preferably, the automation refnum displays the type libraries associated with the OLE Automation servers present in the system, as shown in FIG. 11. In one embodiment, the automation refnum displays the type libraries associated with the automation technology which was selected in step 384.

The user selects one of the type libraries from the displayed list of type libraries. In response, the automation refnum selects the type library from the list of type libraries and associates the selected type library with the automation refnum in step 388. At edit-time the automation refnum provides a type descriptor, including information identifying the selected type library, to other automation nodes of the VI 50. FIG. 12 shows the user having selected the "Microsoft Excel 5.0 Object Library Version 1.0" type library from the list of FIG. 11.

In response to the user having selected a type library, the automation refnum queries the object manager 268 for a list of possible automation classes associated with the selected type library in step 390. The object manager 268 queries the selected type library for a list of possible automation classes in the type library. The object manager 268 receives the list of automation classes from the type library and provides the list to the automation refnum. The automation refnum receives the list from the object manager 68 and displays the list, as shown in FIG. 12. FIG. 12 shows the list of possible Microsoft Excel 5.0 automation classes from which automation objects may be instantiated. Preferably, the user may choose for the automation refnum to selectively display only those objects which are creatable, as shown in FIG. 12.

The user selects an automation class from the displayed list of automation classes. In response, the automation refnum selects the automation class from the list of automation classes and associates the selected automation class with the automation refnum in step 392. At edit-time the automation refnum provides a type descriptor, including information identifying the selected automation class, to other automation nodes of the VI 50. FIG. 13 shows the user having selected the "Excel Application" automation class from the list of FIG. 12. Thus, the system and method displays an automation refnum icon which is used to indicate an input type library and automation class.

Below an automation open node is described in detail. In one embodiment, the system and method displays the automation open node icon which is used to indicate the type library and automation class information input from a user, rather than the automation refnum. That is, the automation open node serves the function of the automation refnum by receiving the type library and automation class information from the user and displaying the selected information.

Type Descriptor

Each wire and terminal in a block diagram has an associated data type. The programming environment keeps track of the data type in a structure in memory called a type descriptor. The type descriptor comprises a string of word integers that describe the data type. The generic format of a type descriptor is: <size> <typecode>.

Table 1 lists three of the supported data types, the type codes, and type descriptors in one embodiment of the programming environment.

TABLE 1 Data Type Type Code Type Descriptor Long Integer 0x03 0004 xx03 Handle 0x31 0006 xx31 <kind> Array 0x40 <nn> 0x40 <k> <k dimensions> <element type descriptor>

When a wire is initially connected to a terminal, the wire takes on the data type of the terminal. i.e., the programming environment creates a type descriptor for the wire. When the user connects this wire to another terminal in the block diagram at edit-time, the programming environment performs type propagation checking by comparing the type descriptor of the wire with the type descriptor of the terminal. If the type descriptors do not match, then a type conflict error is generated. In one embodiment, the programming environment performs type propagation checking on each wire and terminal in the block diagram each time a change is made to the diagram. That is, type descriptors are propagated on the wires of the block diagram at edit-time in order to perform type propagation checking.

The method advantageously comprises a new type descriptor for the automation refnum terminal. The automation refnum terminal type descriptor includes an identifier for the automation class associated with the automation refnum and an identifier for the type library for the automation class. In one embodiment, the automation refnum type descriptor has the format:

<size> <RefnumCode> <AutoRefnumKind> <AutomationType> <no of intl6's> <kCoClassCLSID> <CLSID of created object> <kTypeLibCLSID> <CLSID of type library> <DISPID>.

The <size> byte of the type descriptor is as described above. The <refnumCode> is the type code for a refnum. The <AutoRefnumKind> value distinguishes this refnum from other refnums as an automation refnum. The <AutomationType> indicates the OLE automation type, such as the <kStOLEAutoType> value which indicates a static OLE automation type. The <no of intl6's> field indicates the number of 16 bit words which follow. The <kCoClassCLSID> value indicates the following 128 bits are a class identifier. The <CLSID of created object> is a unique 128 bit number associated with the particular automation class which the automation refnum references. The <kTypeLibCLSID> value indicates the following 128 bits are a type library identifier. The <CLSID of type library> is a unique 128 bit number associated with the particular type library to which the automation class belongs. The <DISPID> is a Dispatch ID, which is a long integer which uniquely specifies a class within a type library. The Dispatch ID is associated with the Microsoft IDispatch interface for dispatch methods and properties. The Dispatch ID is unique within a type library. In the example shown in FIG. 11, the type descriptor provided by the automation refnum includes information to specify the Microsoft "Excel" automation application type library and the "Application" automation class.

The automation nodes comprise a type propagation checking method which may be invoked by the block diagram editor 64 to perform type propagation checking. When the user connects a wire to a terminal of an automation node, the type propagation method of the node is invoked and the type descriptor of the wire being connected to the terminal is passed as an argument to the type propagation method. This information in the type descriptor enables the type propagation method to advantageously determine class conflicts in the block diagram.

Thus, the method advantageously performs type propagation checking to determine program correctness when wiring automation function nodes. This checking advantageously prevents run-time errors which would occur when the user attempted to invoke a method or property which is invalid for the automation class selected. Type propagation checking is discussed further below.

The user creates an automation open node for instantiating an object from the automation class referred to by the automation refnum. Preferably, the user drags an automation open node from the automation nodes palette of FIG. 7 and drops the automation open node on the block diagram.

In response to the user dropping the automation open node on the block diagram, the block diagram editor 264 displays an automation open node in the block diagram, as shown in FIG. 13, in step 394. Preferably, the block diagram editor 264
invokes a draw method of the automation open node to display an automation open node icon in the block diagram. At run-time, the automation open node instantiates an object based on the automation class and type library information received from the automation refnum.

The system then connects the automation refnum to the automation open node in response to user input. The user wires the automation open node to the automation refnum using a wiring tool. In response, the block diagram editor 264 displays a wire connecting the automation open node and the automation refnum in step 396. The automation refnum provides the automation class and type library information to the automation open node so that the automation open node may perform type propagation checking.

The automation open node includes a refnum input terminal which is designed to receive an output from an automation refnum icon. In an embodiment where an automation refnum icon is not used to designate class and type library information, the automation open node receives the class and type library information by other means, preferably via user input in a similar manner which the automation refnum received the class and type library information. At edit-time, the automation open node receives a type descriptor on the wire, such as from the automation refnum, which includes type library and automation class information. The automation open node also includes a refnum output terminal, to which a wire may be connected. At edit-time, the automation open node forwards the type descriptor received at its refnum input terminal to the refnum output terminal. The type descriptor is forwarded on a connected wire to all other nodes connected to the wire.

At run-time, the automation open node provides a reference to the object instantiated by the automation open node on the wire connected to the refnum output terminal. Automation nodes, such as automation invoke nodes and automation property nodes, receive the object reference in order to invoke methods and properties of the object as will be described below.

The user creates an automation property node in order to invoke properties, i.e., to set or get properties, of the object instantiated by the automation open node. Preferably, the user drags an automation property node from the automation nodes palette of FIG. 7 and drops the automation property node on the block diagram, as shown in FIG. 16. The user may also create an automation property node via the pop-up menu of the automation open node.

In response to the user dropping the automation property node, the block diagram editor 264 invokes a method on the automation property node to display an automation property node icon in the block diagram in step 398a. The automation property node is used to invoke properties of the object. The properties to be invoked by the automation property node are selected by the user creating the VI 50.

The user wires the automation property node to the automation open node using a wiring tool. The automation property node includes a refnum input terminal through which the automation property node receives an object reference and type descriptor. In response to the user wiring the automation property node and the automation open node, the block diagram editor 64 displays a wire connecting the refnum input terminal of the automation property node and the refnum output terminal of the automation open node in step 400a.

It is noted that the refnum input terminal of the automation property node may instead be connected to other wires which provide the reference to the object and type descriptor rather than the automation open node refnum output terminal. For example, the refnum input terminal of the automation property node may be connected to the refnum output terminal of another automation property node of the same object or to the refnum output terminal of an automation invoke node of the same object.

At run-time, the automation property node receives a reference to the instantiated object via its refnum input terminal so that the automation property node may set or get properties of the instantiated object.

At edit-time, the automation property node receives a type descriptor via its refnum input terminal so that the automation property node may perform type propagation checking. The automation property node also uses the information in the type descriptor at edit-time to perform other operations, such as displaying property lists as described below.

The automation property node also includes a refnum output terminal. The automation property node passes the information received on its refnum input terminal to its refnum output terminal, i.e., the type descriptor, at edit-time and the object reference at run-time.

Preferably, the user selects the "Properties" menu item from the automation property node pop-up menu in order to view a list of properties associated with the automation class, as shown in FIG. 14. In response to the user selecting the Properties item, the automation open node (or other automation node) provides information on the selected automation class and selected type library to the automation property node in step 102. Preferably, providing information on the automation class and selected type library includes providing a type descriptor which includes the information.

Using the automation class and type library information, the automation property node queries the object manager 268 for a list of properties associated with the selected automation class in step 403. In response, the object manager 268 queries the selected type library for a list of properties of the specified automation class in step 404. The object manager 68 receives the list of properties from the type library and provides the list to the automation property node. The automation property node uses the information received from the object manager 268 to display the list of properties of the selected automation class, as shown in FIG. 14, in step 405.

The user selects one of the properties in the displayed list of properties. In response to the user selection, the automation property node selects the selected property to be invoked by the automation property node in step 406a. The automation property node displays the selected property in the automation property node, as shown in FIG. 15, in step 408. FIG. 15 shows a "Visible" property displayed in the Excel Application automation property node.

The automation property node displays a terminal for the selected property, as shown in FIG. 15, in step 410. If the property may be set, i.e., written, the automation property node displays an input terminal. If the property may be gotten, i.e., read, the automation property node displays an output terminal. Preferably, a property may be set to be readable or writable in response to user input. In FIG. 15, the Visible property includes an input terminal since the property may be set, i.e., changed. The Visible property input terminal receives a Boolean, i.e., True/False, input value which may be toggled on the front panel in response to user input.

In a similar manner, the user is enabled to add more properties to the automation property node for the purpose of invoking the properties of the object. Typically, the properties are set via controls on the front panel associated with the block diagram or gotten and displayed on indicators on the front panel. In addition, the properties may be invoked programmatically using nodes and terminals of the VI 50.

The user creates an automation invoke node in order to invoke methods of the object instantiated by the automation open node. Preferably, the user drags an automation invoke node from the automation nodes palette of FIG. 7 and drops the automation invoke node on the block diagram, as shown in FIG. 16. The user may also create an automation inv