|
|
|
Virtual device driver (VxD) |
Instrumentation system and method including an improved driver software architecture5963726
Abstract
A system and method for controlling an instrumentation system, wherein the present invention includes an improved instrument driver software architecture. The instrument driver software architecture of the present invention provides a number of features, including instrument interchangeability, i.e., the use of interchangeable virtual instruments or interchangeable instrument drivers, improved performance, an improved attribute model, improved range checking, and improved simulation features, among others.
Claims
We claim:
1. An instrumentation system including an instrument driver software architecture with an improved attribute model, the instrumentation system comprising:
a computer system comprising a CPU and memory;
at least one instrument coupled to the computer system, wherein the instrument includes a plurality of settings which indicate a state of operation of the instrument;
wherein the memory of the computer system stores:
a user application which performs an application using the instrument;
an instrument driver which controls the instrument, wherein the instrument driver includes a plurality of functions which control operation of the instrument, wherein the instrument driver includes a plurality of attributes which model said plurality of settings of said instrument;
an interchangeable virtual instrument (IVI) engine, wherein the IVI engine includes at least one set attribute function for setting values of attributes in the instrument and includes at least one get attribute function for obtaining values of attributes from the instrument;
wherein said user application includes calls which are operable to invoke said set attribute function and/or said get attribute function in said IVI engine to set and/or get attributes in the instrument.
2. The instrumentation system of claim 1, wherein said set attribute function and said get attribute function in said IVI engine are common for a plurality of instrument drivers.
3. The instrumentation system of claim 1,
wherein said user application includes calls to said functions in said instrument driver;
wherein one or more of said plurality of functions in said instrument driver include calls to said set attribute function and/or said get attribute function in said IVI engine;
wherein said IVI engine receives said calls to said set attribute function and/or said get attribute function from said instrument driver and is operable to execute said set attribute function and/or said get attribute function to set and/or get attributes in the instrument.
4. The instrumentation system of claim 1, wherein said instrument driver includes at least one set attribute function and at least one get attribute function;
wherein said user application includes calls to said set attribute function and/or said get attribute function in said instrument driver;
wherein calls to said set attribute function and/or said get attribute function in said instrument driver operate to invoke said set attribute function and/or said get attribute function, respectively, in said IVI engine.
5. The instrumentation system of claim 1,
wherein said instrument driver includes write and read functions which are executable to write and read attributes, respectively, to/from the instrument;
wherein said set attribute function and said get attribute function are executable to invoke said write and read functions, respectively, in the instrument driver to write and read attributes in the instrument.
6. The instrumentation system of claim 1, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein the instrument driver is operable to receive a value for said first attribute within said continuous range and coerce the received value to a coerced value comprising one of said discrete values;
wherein the set attribute function is operable to set the coerced value of said first attribute in the instrument.
7. The instrumentation system of claim 1, wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein the instrument driver is operable to receive a value for said first attribute within said continuous range and coerce the received value to a coerced value comprising one of said discrete values;
wherein the set attribute function is operable to set the coerced value of said first attribute in the instrument.
8. The instrumentation system of claim 1, wherein the computer system memory includes a cache portion which stores the value of an attribute written to the instrument.
9. The instrumentation system of claim 1, wherein the set attribute function in the IVI engine is operable to store the value of an attribute written to the instrument in a cache in the computer system memory.
10. The instrumentation system of claim 9,
wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein the instrument driver is operable to receive a value for said first attribute within said continuous range and coerce the received value to a coerced value comprising one of said discrete values;
wherein the set attribute function is operable to store the coerced value of said first attribute in the cache;
wherein the coerced value of said first attribute is written to the instrument.
11. The instrumentation system of claim 9, wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein the instrument driver is operable to receive a value for said first attribute within said continuous range and coerce the received value to a coerced value comprising one of said discrete values;
wherein the set attribute function is operable to store the coerced value of said first attribute in the cache;
wherein the coerced value of said first attribute is written to the instrument.
12. The instrumentation system of claim 9,
wherein the user application attempts to set an attribute to a write value;
wherein said set attribute function in the IVI engine is operable to compare the write value to which the user application is attempting to set the attribute with a cached value;
wherein the write value is not written to the instrument if the cached value is determined to equal the write value to which the user application is attempting to set the attribute.
13. The instrumentation system of claim 12, wherein, if the cached value is determined to not equal the write value to which the user application is attempting to set the attribute, then:
the write value of the attribute is written to the instrument; and
the write value of the attribute is stored in the cache.
14. The instrumentation system of claim 12, wherein said set attribute function in the IVI engine is operable to determine whether the cached value was stored from a prior set operation or a prior get operation;
wherein, if the cached value was stored from a prior get operation, the set attribute function compares the value to which the user application is attempting to set an attribute with the cached value that was stored from the previous get attribute operation, wherein the comparison accounts for differences in floating point precision between the computer and the instrument.
15. The instrumentation system of claim 12,
wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein the instrument driver is operable to receive a value for said first attribute within said continuous range and coerce the received value to a coerced value comprising one of said discrete values;
wherein the set attribute function is operable to compare the coerced value of said first attribute with the cached value.
16. The instrumentation system of claim 9, wherein the memory of the computer system further includes an invalidation list for the attribute, wherein the invalidation list lists one or more attributes which are affected when the attribute is written to the instrument;
wherein the set attribute function is operable to invalidate cache values of said one or more attributes in the invalidation list which are affected when the attribute is written to the instrument.
17. The instrumentation system of claim 1, wherein the get attribute function in the IVI engine is operable to determine if a cached value of the attribute is valid;
wherein the get attribute function does not obtain the value of the attribute from the instrument if the cached value of the attribute is valid;
wherein the get attribute function returns the cached value if the cached value of the attribute is valid.
18. The instrumentation system of claim 1,
wherein said IVI engine further includes attribute information corresponding to each of said attributes of the instrument driver, wherein said set attribute function and said get attribute function are operable to access said attribute information in setting and getting attributes in the instrument.
19. The instrumentation system of claim 18, wherein, for a plurality of said attributes, said attribute information includes one or more attribute flags which indicate availability of said attribute;
wherein, for a respective attribute, said set attribute function and said get attribute function are operable to examine said one or more attribute flags associated with said respective attribute to determine availability of said attribute;
wherein said set attribute function and said get attribute function in the IVI engine do not operate if said attribute is determined to be not available.
20. The instrumentation system of claim 18, wherein, for a plurality of said attributes, said attribute information includes range information which indicates one or more permissible ranges of said attribute;
wherein, for a respective attribute, said set attribute function is operable to examine said range information for said respective attribute to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
21. The instrumentation system of claim 20, wherein the instrument driver is operable to provide said range information to the IVI engine;
wherein said set attribute function is operable to check said range information and determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
22. The instrumentation system of claim 18, wherein, for a plurality of said attributes, said range information indicates coerced values for said attribute;
wherein, for a respective attribute, said set attribute function is operable to coerce the value to which the user application is attempting to set an attribute to one of said coerced values.
23. The instrumentation system of claim 18, wherein the instrument driver does not provide range information to the IVI engine;
wherein said set attribute function is operable to examine the instrument driver to determine whether the value to which the user application is attempting to set an attribute is within one or more permissible ranges.
24. The instrumentation system of claim 18, wherein the instrument driver does not provide range information to the IVI engine;
wherein said set attribute function is operable to examine the instrument driver to determine a coerced value for the value to which the user application is attempting to set an attribute.
25. The instrumentation system of claim 1, wherein the instrument driver includes one or more software attributes;
wherein the set attribute function and the get attribute function are operable to set and get, respectively, said software attributes in the instrument driver.
26. The instrumentation system of claim 1, wherein the instrument is of a first instrument class; wherein the instrument driver is specific to the instrument;
the instrumentation system further comprising:
a class driver which is operable to control a class of instruments, wherein the class driver is operable to control instruments of said first instrument class, wherein said class driver includes generic functions for instruments of said first instrument class;
wherein said user application includes calls to said generic functions of said class driver;
wherein said class driver receives said calls to said generic functions of said class driver and invokes said functions in said instrument driver.
27. The instrumentation system of claim 26,
wherein said IVI engine maintains a plurality of pointers to functions in said instrument driver;
wherein, in response to a received call to a generic function in said class driver, said class driver is operable to obtain a pointer to a function in said instrument driver from said IVI engine and invoke said function in said instrument driver.
28. A computer-implemented method for controlling an instrument in an instrumentation system, wherein the instrumentation system includes a computer system comprising a CPU and memory, wherein the instrumentation system also includes at least one instrument coupled to the computer system, wherein the instrumentation system includes an instrument driver software architecture with an improved attribute model, the method comprising:
a user application making a call to a function to control the instrument;
executing one or more of a set attribute function or a get attribute function in response to said user application making the call, wherein the set attribute function is executable for setting values of attributes in the instrument and wherein the get attribute function is executable for obtaining values of attributes in the instrument, wherein said executing said one or more of said set attribute function or said get attribute function includes invoking a write/read function in an instrument driver;
the write/read function in the instrument driver executing to write/read attribute values to/from the instrument in response to said invoking.
29. The method of claim 28, wherein said set attribute function and said get attribute function are common for a plurality of instrument drivers.
30. The method of claim 29,
wherein the user application making a call comprises the user application making a call to a function in the instrument driver; the method further comprising:
said function in said instrument driver executing in response to the user application making the call;
said function in said instrument driver making a call to said one or more of said set attribute function or said get attribute function;
wherein said executing said one or more of said set attribute function or said get attribute function is performed in response to said function in said instrument driver making said call.
31. The method of claim 30, wherein said set attribute function and said get attribute function are comprised in an interchangeable virtual instrument (IVI) engine;
wherein said instrument driver includes a set attribute function and a get attribute function;
wherein the user application making a call comprises the user application making a call to said set attribute function and/or said get attribute function in said instrument driver;
wherein said executing said one or more of said set attribute function or said get attribute function in said IVI engine is performed in response to said calls to said set attribute function and/or said get attribute function in said instrument driver.
32. The method of claim 29, wherein said executing one or more of the set attribute function or the get attribute function includes:
said set attribute function invoking said write function in the instrument driver to set an attribute in the instrument; and
said get attribute function invoking said read function in the instrument driver to read an attribute of the instrument.
33. The method of claim 28, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein said executing said set attribute function includes:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values;
wherein the write/read function in the instrument driver executing comprises the write function writing said coerced value to the instrument.
34. The method of claim 28,
wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein said executing said set attribute function includes:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values;
wherein the write/read function in the instrument driver executing comprises the write function writing said coerced value to the instrument.
35. The method of claim 28, further comprising:
storing the value of the attribute written to the instrument in a cache in the computer system memory.
36. The method of claim 35, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein said executing said set attribute function includes:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values; and
storing the coerced value in the cache memory;
wherein the write/read function in the instrument driver executing comprises the write function writing said coerced value to the instrument.
37. The method of claim 35,
wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein said executing said set attribute function includes:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values;
storing the coerced value in the cache memory;
wherein the write/read function in the instrument driver executing comprises the write function writing said coerced value to the instrument.
38. The method of claim 35, wherein the user application makes a call to set an attribute to a write value;
wherein said executing the set attribute function includes comparing the write value to which the user application is attempting to set the attribute with a cached value;
wherein the write value is not written to the instrument if the cached value is determined to equal the write value to which the user application is attempting to set the attribute.
39. The method of claim 38, wherein, if the cached value is determined to not equal the write value to which the user application is attempting to set the attribute, then the method comprises:
writing the write value of the attribute to the instrument; and
storing the write value of the attribute in the cache.
40. The method of claim 38, wherein said executing the set attribute function includes determining whether the cached value was stored from a prior set operation or a prior get operation;
wherein, if the cached value was stored from a prior get operation, said comparing accounts for differences in floating point precision between the computer and the instrument.
41. The method of claim 38, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein said executing said set attribute function includes:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values;
wherein said comparing includes comparing the coerced value with the cached value.
42. The method of claim 35, wherein the memory of the computer system further includes an invalidation list for the attribute, wherein the invalidation list lists one or more attributes which are affected when the attribute is set by the write function;
the method further comprising:
the set attribute function invalidating cache values of said one or more attributes in the invalidation list which are affected when the attribute is set by the write function.
43. The method of claim 35, wherein said executing the get attribute function includes:
determining if a cached value of the attribute is valid; and
returning the cached value if the cached value of the attribute is valid;
wherein the get attribute function does not invoke said read function if the cached value of the attribute is valid.
44. The method of claim 28, wherein said set attribute function and said get attribute function are comprised in an interchangeable virtual instrument (IVI) engine and are common for a plurality of instrument drivers;
wherein said IVI engine further includes attribute information corresponding to each of said attributes of the instrument driver, the method further comprising:
said set attribute function and said get attribute function accessing said attribute information prior to setting and getting attributes in the instrument.
45. The method of claim 44, wherein, for a plurality of said attributes, said attribute information includes one or more attribute flags which indicate availability of said attribute;
wherein, for a respective attribute, the method further comprises:
each of said set attribute function and said get attribute function examining said one or more attribute flags associated with said respective attribute to determine availability of said attribute;
wherein said set attribute function and said get attribute function do not operate if said attribute is determined to be not available.
46. The method of claim 44, wherein, for a plurality of said attributes, said attribute information includes range information which indicates one or more permissible ranges of said attribute;
wherein, for a respective attribute, said executing the set attribute function further compnses:
said set attribute function examining said range information for said respective attribute to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
47. The method of claim 46, further comprising:
the instrument driver providing said range information to the IVI engine prior to said executing the set attribute function;
the set attribute function examining said range information and determining whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
48. The method of claim 46, wherein, for a plurality of said attributes, said range information indicates coerced values for said attribute;
wherein, for a respective attribute, the method further comprises:
said set attribute function coercing the value to which the user application is attempting to set an attribute to one of said coerced values.
49. The method of claim 44, wherein the instrument driver does not provide range information to the IVI engine; the method further comprising:
said set attribute function examining the instrument driver to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
50. The method of claim 44, wherein the instrument driver does not provide range information to the IVI engine; the method further comprising:
said set attribute function examining the instrument driver to determine a coerced value for the value to which the user application is attempting to set an attribute.
51. The method of claim 28, wherein the instrument driver includes one or more software attributes; the method further comprising:
one or more of the set attribute function and the get attribute function executing to set and get, respectively, said software attributes in the instrument driver.
52. The method of claim 28, wherein the instrument is of a first instrument class; wherein the instrument driver is specific to the instrument;
wherein the user application making the call comprises the user application making a call to a class driver, wherein the class driver is operable to control instruments of said first instrument class, wherein said class driver includes generic functions for instruments of said first instrument class, wherein said user application makes a call to said generic functions of said class driver; the method further comprising:
the class driver receiving said call to said generic functions of said class driver; and
the class driver invoking one or more functions in said instrument driver;
wherein said executing one or more of the set attribute function or the get attribute function is performed in response to the class driver invoking one or more functions in said instrument driver.
53. The instrumentation system of claim 52, wherein said set attribute function and said get attribute function are comprised in an interchangeable virtual instrument (IVI) engine and are common for a plurality of instrument drivers;
wherein said IVI engine maintains a plurality of pointers to functions in said instrument driver; the method further comprising:
the class driver obtaining a pointer to a function in said instrument driver from said IVI engine in response to a received call to a generic function in said class driver;
wherein the class driver invokes one or more functions in said instrument driver in response to obtaining said pointer.
54. A computer-implemented method for controlling an instrument in an instrumentation system, wherein the instrumentation system includes a computer system comprising a CPU and memory, wherein the instrumentation system also includes at least one instrument coupled to the computer system, wherein the instrumentation system includes an instrument driver which controls the instrument, wherein the instrumentation system includes an instrument driver software architecture with an improved attribute model, the method comprising:
a user application making a call to a function in the instrument driver to control the instrument;
the function in the instrument driver executing in response to the user application making the call;
the function in the instrument driver invoking one or more of a set attribute function or a get attribute function in an interchangeable virtual instrument (IVI) engine;
executing one or more of the set attribute function or the get attribute function in the IVI engine in response to said invoking, wherein the set attribute function is executable for setting attributes in the instrument and wherein the get attribute function is executable for obtaining values of attributes in the instrument.
55. The method of claim 54, wherein said set attribute function and said get attribute function in said IVI engine are common for a plurality of instrument drivers.
56. The method of claim 54,
wherein said executing said one or more of the set attribute function or the get attribute function includes invoking a write/read function in the instrument driver; the method further comprising:
the write/read function in the instrument driver executing to write/read attribute values to/from the instrument in response to said invoking.
57. A method for controlling an instrument in an instrumentation system, wherein the instrumentation system includes a computer system comprising a CPU and memory, wherein the instrumentation system also includes at least one instrument coupled to the computer system, wherein the instrumentation system includes an instrument driver software architecture with an improved attribute model, the method comprising:
a user application executing in the computer system making a call to a function to control the at least one instrument;
an instrument driver executing the function to control the at least one instrument in response to said user application making the call, wherein the instrument driver includes a plurality of functions which control operation of said at least one instrument, wherein the instrument driver includes a plurality of attributes which indicate a state of operation of said at least one instrument;
executing one or more of a set attribute function or a get attribute function in an interchangeable virtual instrument (IVI) engine, wherein the set attribute function is executable for setting attributes in the instrument and wherein the get attribute function is executable for obtaining values of attributes in the instrument.
58. A memory media which stores software programs that implement an instrument driver software architecture with an improved attribute model, wherein the memory media is comprised in an instrumentation system including a computer system and at least one instrument coupled to the computer system, wherein the instrument includes a plurality of attributes which indicate a state of operation of the instrument, wherein the memory media stores:
a user application which performs an application using the instrument;
an instrument driver which controls the instrument, wherein the instrument driver includes a plurality of functions which control operation of the instrument, wherein the instrument driver includes a plurality of attributes which model said plurality of attributes of said instrument;
an interchangeable virtual instrument (IVI) engine, wherein the IVI engine includes a set attribute function for setting values of attributes in the instrument and includes a get attribute function for obtaining values of attributes from the instrument;
wherein said user application includes calls which are operable to invoke said set attribute function and/or said get attribute function in said IVI engine to set and/or get attributes in the instrument.
59. The memory media of claim 58, wherein said set attribute function and said get attribute function in said IVI engine are common for a plurality of instrument drivers.
60. The memory media of claim 58,
wherein said user application includes calls to said functions in said instrument driver;
wherein one or more of said plurality of functions in said instrument driver include calls to said set attribute function and/or said get attribute function in said IVI engine;
wherein said IVI engine receives said calls to said set attribute function and/or said get attribute function from said instrument driver and is operable to execute said set attribute function and/or said get attribute function to set and/or get attributes in the instrument.
61. The memory media of claim 58, wherein said instrument driver includes a set attribute function and a get attribute function;
wherein said user application includes calls to said set attribute function and/or said get attribute function in said instrument driver;
wherein said IVI engine executes said one or more of said set attribute function or said get attribute function in response to said calls to said set attribute function and/or said get attribute function in said instrument driver.
62. The memory media of claim 58, wherein the instrument driver includes a write function for writing an attribute to the instrument; and
wherein the instrument driver includes a read function for reading an attribute from the instrument.
63. The memory media of claim 58, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein said set attribute function is executable to perform or invoke program instructions which implement:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values.
64. The memory media of claim 58, wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein said set attribute function is executable to perform or invoke program instructions which implement:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values.
65. The memory media of claim 58, wherein the memory media includes a cache portion which stores the value of the attribute written to the instrument.
66. The memory media of claim 58, wherein the set attribute function is executable to store the value of the attribute written to the instrument in a cache memory.
67. The memory media of claim 66, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein the set attribute function is executable to perform or invoke program instructions which implement:
receiving a value for said first attribute within said continuous range;
coercing the received value to a coerced value comprising one of said discrete values;
storing the coerced value in the cache memory; and
writing said coerced value to the instrument.
68. The memory media of claim 66, wherein the instrument accepts a continuous range of values for a first attribute;
wherein the instrument coerces values within that continuous range to one of a set of discrete values;
wherein said set attribute function is executable to perform or invoke program instructions which implement:
receiving a value for said first attribute within said continuous range;
coercing the received value to a coerced value comprising one of said discrete values;
storing the coerced value in the cache memory; and
writing said coerced value to the instrument.
69. The memory media of claim 66, wherein, when the user application makes a call to set an attribute to a write value, the set attribute function is executable to perform or invoke program instructions which implement comparing the write value to which the user application is attempting to set the attribute with a cached value;
wherein the write value is not written to the instrument if the cached value is determined to equal the write value to which the user application is attempting to set the attribute.
70. The memory media of claim 69, wherein, if the cached value is determined to not equal the write value to which the user application is attempting to set the attribute, then the set attribute function is executable to perform or invoke program instructions which implement:
writing the write value of the attribute to the instrument; and
storing the write value of the attribute in the cache.
71. The memory media of claim 69, wherein the set attribute function is executable to perform or invoke program instructions which implement determining whether the cached value was stored from a prior set operation or a prior get operation;
wherein, if the cached value was stored from a prior get operation, said comparing accounts for differences in floating point precision between the computer and the instrument.
72. The memory media of claim 69, wherein the instrument accepts only a discrete set of discrete values for a first attribute;
wherein the instrument driver allows a continuous range of values for said first attribute;
wherein the set attribute function is executable to perform or invoke program instructions which implement:
receiving a value for said first attribute within said continuous range; and
coercing the received value to a coerced value comprising one of said discrete values;
wherein said comparing includes comparing the coerced value with the cached value.
73. The memory media of claim 66, wherein the memory media further includes an invalidation list for the attribute, wherein the invalidation list lists one or more attributes which are affected when the attribute is set by the write function;
wherein the set attribute function is executable to perform or invoke program instructions which implement:
invalidating cache values of said one or more attributes in the invalidation list which are affected when the attribute is set by the write function.
74. The memory media of claim 66, wherein the get attribute function is executable to implement:
determining if a cached value of the attribute is valid; and
returning the cached value if the cached value of the attribute is valid;
wherein the get attribute function in said IVI engine does not invoke said read function if the cached value of the attribute is valid.
75. The memory media of claim 58,
wherein said IVI engine further includes attribute information corresponding to each of said attributes of the instrument driver;
wherein said set attribute function and said get attribute function are executable to access said attribute information prior to setting and getting attributes in the instrument.
76. The memory media of claim 75, wherein, for a plurality of said attributes, said attribute information includes one or more attribute flags which indicate availability of said attribute;
wherein, for a respective attribute, each of said set attribute function and said get attribute function in the IVI engine are executable to examine said one or more attribute flags associated with said respective attribute to determine availability of said attribute;
wherein said set attribute function and said get attribute function in the IVI engine do not operate if said attribute is determined to be not available.
77. The memory media of claim 75, wherein, for a plurality of said attributes, said attribute information includes range information which indicates one or more permissible ranges of said attribute;
wherein, for a respective attribute, the set attribute function is executable to examine said range information for said respective attribute to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
78. The memory media of claim 77,
wherein the instrument driver is executable to provide said range information to the IVI engine prior to execution of the set attribute function;
wherein the set attribute function includes or invokes program instructions for performing a check function, wherein the check function examines said range information and determines whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
79. The memory media of claim 77, wherein, for a plurality of said attributes, said range information indicates coerced values for said attribute;
wherein, for a respective attribute, the set attribute function includes or invokes program instructions for coercing the value to which the user application is attempting to set an attribute to one of said coerced values.
80. The memory media of claim 75, wherein the instrument driver does not provide range information to the IVI engine;
wherein the set attribute function is executable to examine the instrument driver and determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
81. The memory media of claim 75, wherein the instrument driver does not provide range information to the IVI engine;
wherein the set attribute function is executable examine the instrument driver and determine a coerced value for the value to which the user application is attempting to set an attribute.
82. The memory media of claim 58, wherein the instrument driver includes one or more software attributes;
wherein one or more of the set attribute function and the get attribute function are executable to set and get, respectively, said software attributes in the instrument driver.
83. The memory media of claim 58, wherein the instrument is of a first instrument class; wherein the instrument driver is specific to the instrument;
wherein the memory media further stores a class driver which is executable to control instruments of said first instrument class, wherein said class driver includes generic functions for instruments of said first instrument class;
wherein said user application includes calls to said generic functions of said class driver;
wherein said class driver receives said calls to said generic functions of said class driver and invokes said functions in said instrument driver.
84. The memory media of claim 83,
wherein said IVI engine maintains a plurality of pointers to functions in said instrument driver;
wherein, in response to a received call to a generic function in said class driver, said class driver is operable to obtain a pointer to a function in said instrument driver from said IVI engine and invoke said function in said instrument driver.
85. An instrumentation system including an instrument driver software architecture with development and production modes, the instrumentation system comprising:
a computer system comprising a CPU and memory;
at least one instrument coupled to the computer system, wherein the at least one instrument is of a first instrument class;
wherein the memory of the computer system stores:
a user application which controls the at least one instrument;
a class driver which is operable to control a class of instruments, wherein the class driver is operable to control instruments of said first instrument class, wherein said class driver includes generic functions for instruments of said first instrument class;
a specific instrument driver which is specific to said at least one instrument, wherein said specific instrument driver includes functions for controlling the instrument, wherein said specific driver includes attributes which model attributes of the instrument, wherein said attributes include development/production attributes comprising at least a subset of the following: state caching, interchangeability checking, range checking, instrument status checking, and coercion recording;
an initialization file which stores attribute settings for the instrument;
an interchangeable virtual instrument (IVI) engine which is operable to examine the initialization file and configure the attributes in the specific driver with said attribute settings;
wherein the initialization file is operable to be configured with said development/production attributes in a development mode during development of said user application to place said development/production attributes in said development mode during development of said user application;
wherein the initialization file is operable to be configured with said development/production attributes in a production mode during production of said user application to place said development/production attributes in said production mode during production of said user application.
86. The instrumentation system of claim 85, wherein said state caching attribute is disabled in said development mode and is enabled in said production mode.
87. The instrumentation system of claim 85, wherein said interchangeability checking attribute is enabled in said development mode and is disabled in said production mode.
88. The instrumentation system of claim 85, wherein said range checking attribute is enabled in said development mode and is disabled in said production mode.
89. The instrumentation system of claim 85, wherein said instrument status checking attribute is enabled in said development mode and is disabled in said production mode.
90. The instrumentation system of claim 85, wherein said coercion recording attribute is enabled in said development mode and is disabled in said production mode.
91. An instrumentation system including an instrument driver software architecture with improved range checking, the instrumentation system comprising:
a computer system comprising a CPU and memory;
at least one instrument coupled to the computer system, wherein the instrument includes a plurality of attributes which indicate a state of operation of the instrument;
wherein the memory of the computer system stores:
a user application which performs an application using the instrument;
an instrument driver which controls the instrument, wherein the instrument driver includes a plurality of functions which control operation of the instrument, wherein the instrument driver includes a plurality of attributes which model said plurality of attributes of said instrument;
an interchangeable virtual instrument (IVI) engine, wherein the IVI engine includes attribute information corresponding to each of said attributes of the instrument driver, wherein the IVI engine includes at least one set attribute function for setting attributes in the instrument and includes at least one get attribute function for obtaining values of attributes from the instrument; wherein, for a plurality of said attributes, said attribute information includes range information which indicates one or more permissible ranges of said attribute;
wherein, for a respective attribute, said set attribute function in the IVI engine is operable to examine said range information for said respective attribute to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
92. The instrumentation system of claim 91, wherein the instrument driver is operable to provide said range information to the IVI engine;
wherein said set attribute function the IVI engine is operable to invoke a check callback function in the IVI engine, wherein said check callback function is operable to examine said range information and determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
93. The instrumentation system of claim 91, wherein the instrument driver does not provide range information to the IVI engine;
wherein said set attribute function in the IVI engine is operable to invoke a check callback function in the instrument driver, wherein said check callback function is operable to determine whether the value to which the user application is attempting to set an attribute is within one or more permissible ranges.
94. A computer-implemented method for controlling an instrument in an instrumentation system, wherein the instrumentation system includes a computer system comprising a CPU and memory, wherein the instrumentation system also includes at least one instrument coupled to the computer system, wherein the instrumentation system includes an instrument driver software architecture with improved range checking, the method comprising:
a user application making a call to a function to control the instrument;
executing one or more of a set attribute function or a get attribute function in an interchangeable virtual instrument (IVI) engine in response to said user application making the call, wherein the set attribute function is executable for setting attributes in the instrument and wherein the get attribute function is executable for obtaining values of attributes in the instrument, wherein said IVI engine further includes attribute information corresponding to each of said attributes of the instrument driver, wherein, for a plurality of said attributes, said attribute information includes range information which indicates one or more permissible ranges of said attribute;
said set attribute function and said get attribute function in the IVI engine accessing said attribute information prior to setting and getting attributes in the instrument, wherein, for a respective attribute, said executing the set attribute function further comprises:
said set attribute function in the IVI engine examining said range information for said respective attribute to determine whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
95. The method of claim 94, further comprising:
the instrument driver providing said range information to the IVI engine prior to said executing the set attribute function;
the set attribute function in the IVI engine invoking a check callback function in the IVI engine;
the check callback function examining said range information and determining whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
96. The method of claim 94, wherein the instrument driver does not provide range information to the IVI engine; the method further comprising:
said set attribute function in the IVI engine invoking a check callback function in the instrument driver;
the check callback function in the instrument driver determining whether the value to which the user application is attempting to set an attribute is within said one or more permissible ranges.
97. The method of claim 94, firther comprising:
enabling range checking prior to said executing.
Description
FIELD OF THE INVENTION
The present invention relates to instrument driver software for instrumentation systems, and more particularly to an instrumentation driver software architecture for communicating with and controlling instruments in an instrumentation system.
DESCRIPTION OF THE RELATED ART
An instrument is a device which collects data or information from an environment or unit under test and displays this information to a user. An instrument may also perform various data analysis and data processing on acquired data prior to displaying the data to the user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc., and the types of information which might be collected by respective instruments include voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others.
In the past, many instrumentation systems comprised individual instruments physically interconnected with each other. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems, the user interacts with software executing on the computer system through the computer's video monitor rather than through a manually operated front panel to control one or more real world instruments. The software executing on the computer system can be used to simulate the operation of an instrument in software or to control or communicate with one or more real world instruments, these software created/controlled instruments being referred to as virtual instruments.
Therefore, modern instrumentation systems are moving from dedicated stand-alone hardware instruments such as oscilloscopes, digital multimeters, etc., to a concept referred to as virtual instrumentation. Virtual instrumentation comprises general purpose personal computers and workstations combined with instrumentation software and hardware to build a complete instrumentation system. In a virtual instrumentation system, a virtual instrument operating on a central computer controls the constituent instruments from which it acquires data which it analyzes, stores, and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use, and computerized instrumentation systems provide significant performance efficiencies over earlier systems for linking and controlling test instruments.
The various hardware interface options currently available for instrumentation systems can be categorized into various types, including IEEE 488-controlled instruments (GPIB instruments), VXI bus instruments, plug-in data acquisition (DAQ) boards, PCI bus and PXI bus instruments, and serial instruments, such as RS-232-controlled, USB, or IEEE 1394 instruments, among others. Background on these various hardware interface options is deemed appropriate.
The GPIB (general purpose interface bus) began as a bus designed by Hewlett-Packard in 1965, referred to as the Hewlett-Packard Interface Bus (HPIB), to connect their line of programmable instruments to their computers. National Instruments Corporation expanded the use of this bus to computers manufactured by companies other than Hewlett-Packard and hence the name General Purpose Interface Bus (GPIB) became more widely used than HPIB. The GPIB interface bus gained popularity due to its high transfer rates and was later accepted as IEEE standard 488-1975, and the bus later evolved to ANSI/IEEE standard 488.1-1987. In order to improve on this standard, two new standards were drafted, these being ANSI/IEEE 488.2-1987 and the SCPI (Standard Commands for Programmable Instruments) standard. The IEEE 488.2 standard strengthened the original standard by defining precisely how controllers and instruments communicated. The IEEE 488.2 standard removed ambiguities of the IEEE 488.1 standard by defining data formats, status reporting, a message exchange protocol, IEEE 488.2 controller requirements, and common configuration commands to which all IEEE 488.2 instruments must respond in a precise manner. Thus, the IEEE 488.2 standard created more compatible, more reliable systems that were simpler to program. In 1990, a new specification was developed referred to as the Standard Commands for Programmable Instruments (SCPI), which used the command structures defined in the IEEE 488.2 standard and formed a single, comprehensive programming command set that is used with any SCPI instrument. The SCPI standard simplified the programming process for manufacturers and users alike. Rather than having to learn a different command set for each instrument, the user could focus on solving the measurement tests of his or her application, thus decreasing programming time.
The VXI (VME eXtension for Instrumentation) bus is a platform for instrumentation systems that was first introduced in 1987 and was originally designed as an extension of the VME bus standard. The VXI standard has experienced tremendous growth and acceptance around the world and is used in a wide variety of traditional test and measurement and ATE applications. The VXI standard uses a mainframe chassis with a plurality of slots to hold modular instruments on plug-in boards. The VXI architecture is capable of interfacing with both message-based instruments and register-based instruments. A message-based instrument is an instrument which is controlled by a string of ASCII characters, whereas a register-based instrument is controlled by writing a bit stream of 1's and 0's directly to registers in the instrument hardware.
An instrumentation system using a data acquisition interface method typically includes transducers which sense physical phenomena from the process or unit under test and provide electrical signals to data acquisition hardware inside the computer system. The electrical signals generated by the transducers are converted into a form that the data acquisition board can accept, typically by signal conditioning logic positioned between the transducers and the data acquisition card in the computer system.
PCI (Peripheral Component Interconnect) bus instruments and PXI (PCI eXtensions for Instrumentation) instruments leverage off of the PCI bus found in mainstream computer systems. These instruments include a connector which is electrically compatible with the PCI bus. "Desktop PCI" instruments have a conventional PCI form factor for use in desktop PCs. The PXI instrumentation bus standard, promulgated by National Instruments, includes a CompactPCI mechanical form factor, is electrically compatible with the PCI bus, and includes extra signal definitions for instrumentation purposes.
A computer can also control an instrumentation system through a serial connection, such as the computer's serial or RS-232 port, the USB (Universal Serial Bus), or the IEEE 1394 or 1394.2 bus, referred to as Firewire. There are currently thousands of instruments with an RS-232 interface.
Due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it is often necessary for a user to develop a program to control respective instruments in the desired instrumentation system. Therefore, implementation of such systems frequently requires the involvement of a programmer to develop software for acquisition, analysis and presentation of instrumentation data.
The software architecture for an instrumentation system, such as a virtual instrumentation system, comprises several components. The top level of the software architecture typically comprises an application program used for high level control of the virtual instrument. Examples of high level application programs for instrumentation control are LabVIEW, LabWindows.backslash.CVI, and ComponentWorks from National Instruments Corp. Other examples of applications programs are HP VEE from Hewlett-Packard and DasyLab from DasyTec GMBH, among others. These application programs provide a user with the tools to control instruments, including acquiring data, analyzing data, and presenting data.
The application programs mentioned above typically operate in conjunction with one or more instrument drivers to interface to actual physical instruments. For example, the LabVIEW and LabWindows application software each include instrument libraries comprising drivers for more than six hundred GPIB, VXI, and RS-232 instruments from numerous manufacturers. The instrument drivers are designed to reduce a user's application development time by providing intuitive high level functions that relieve the user of complex low level instrument programming.
A software level referred to as driver level software is below the instrument driver level. Driver level software is used to interface the commands in the instrument driver to the actual hardware interface being used, such as a GPIB interface card, a data acquisition card, or a VXI card. In other words, driver level software handles the details of communication, i.e., the transfer of commands and data, over a physical connection between the computer and instruments. There have been many implementations of I/O control software, some of which were custom-developed by end users, while others were developed by vendors and sold along with interface hardware. Examples of driver level software include NI-488, NI-DAQ, and NI-VXI driver level software offered by National Instruments, Inc., which have become de facto standards in the industry. Another example of driver level software is the Standard Instrument Control Library (SICL) offered by Hewlett-Packard and the VISA (Virtual Instrument Software Architecture) promulgated by the VXIplug&play Consortium.
FIG. 1 illustrates the historical evolution of instrument drivers. When IEEE 488.1 instruments were first introduced, standardized I/O libraries were provided which allowed users to provide strings to instruments. These standardized libraries include libraries for IEEE 488.1, IEEE 488.2 and the VISA I/O libraries. The progression from IEEE 488.1 to IEEE 488.2 and then to VISA represent a progression or evolution of the I/O libraries and how the user communicates with an instrument. However, each of these libraries generally still required the user to understand command strings and/or what registers were required to peek and poke within an application to control an instrument.
After the introduction of standardized I/O libraries, there was a movement to standardize the commands that users provided to instruments. This standardization of commands was referred to as SCPI (Standard Commands for Programming Instruments). SCPI allowed generic applications that worked with any of a plurality of instruments. In other words, each of the instruments accepted the same commands and behaved generically based on those commands. However, SCPI did not provide a sufficient number of commands to cover all the different types of instruments available.
During this time, companies such as National Instruments and Hewlett Packard, among others, have been developing instrument drivers. Instrument drivers are custom written libraries of software that are specific to a given instrument. These instrument drivers encapsulate, at a high level, the commands that are required to communicate to a given instrument. These instrument drivers encapsulate all of the low level syntax and the order of operation that is required to send commands to an instrument, which can be very difficult and time consuming.
Examples of current prior art instrument drivers are those developed for LabVIEW and LabWindows/CVI. These instrument drivers present the user with a set of high level functions that are easy to understand and use in their programs. The VXIplug&play consortium was formed to extend these instrument drivers. The VXIplug&play standard ensured that the user could install instrument drivers from a variety of vendors on one computer, and those instrument drivers would not conflict with each other. In other words, instrument drivers which conformed to the VXIplug&play standard would behave gracefully in a system comprising a plurality of instrument drivers supplied by a variety of vendors, thus providing system interoperability. However, the VXIplug&play instrument drivers did not address other high level system issues, such as state caching, simulation and instrument interchangeability, among others.
A primary problem with the traditional software architecture for an instrumentation system is that a separate instrument driver is required for each specific instrument. In addition, the user is required to include certain instrument driver specific commands in an application program. Thus, when a user creates an application program using an instrument of a certain class, if the user later desires to use a different instrument of that same class, such as instrument from a different vendor, or if the user desires to use an instrument of that same class but having a different hardware interface type, the user is required to modify the application program and then recompile the program.
Therefore, it would be highly desirable for instrument driver software to be independent or generic with respect to a certain class of instruments. In other words, when a user writes a software application to control a specific instrument of a first class, it would be desirable for the software application to control all instruments of that first class, such as instruments supplied from different vendors or with different hardware interface types. It would further be desirable to provide other high level instrument driver features, including state caching, simulation, verification of replacement instruments, and an attribute model.
Therefore, an improved system and method is desired for controlling instrumentation systems and for providing a user or developer with the capability to develop instrument drivers and application software for controlling instrumentation systems. An instrument driver software architecture is further desired which allows the use of generic instrument drivers and provides enhanced features.
SUMMARY OF THE INVENTION
The present invention comprises a system and method for controlling an instrumentation system, wherein the present invention includes an improved instrument driver software architecture. The instrument driver software architecture of the present invention provides a number of features, including instrument interchangeability, i.e., the use of interchangeable virtual instruments or interchangeable instrument drivers, improved performance, an improved attribute model, improved range checking, and improved simulation features, among others.
The instrumentation system comprises a computer system including a CPU and memory and at least one instrument coupled to the computer system. The instrument includes a plurality of settings which indicate a state of operation of the instrument.
The memory of the computer system stores a user application which performs an application using the instrument. The memory also stores a specific instrument driver which controls the instrument, wherein the specific instrument driver includes a plurality of functions which control operation of the instrument. The specific instrument driver includes a plurality of attributes which model the attributes or settings of the instrument. If the system includes a plurality of instruments, the memory preferably stores a specific i.d. for each instrument.
In the preferred embodiment, the instrument is of an instrument class, such as DMM, scope, etc. The memory of the computer system preferably stores a class driver which is generic to instruments of the respective class. Thus the class driver incorporates capabilities or functions which are generic or common to instruments of the respective class, and the class driver operates with substantially all instruments of the respective class. For example, the instrumentation system includes a class driver which is generic to all DMMs (digital multimeters), a class driver which is generic to oscilloscopes, etc. The class driver operates for any instrument within the class of instruments regardless of manufacturer or hardware interface type.
The memory of the computer system also stores an interchangeable virtual instrument (IVI) engine. The IVI engine operates as a support library to each of the class drivers. Thus, the IVI engine is generic to each of the class drivers, and provides services to each of the class drivers. The IVI engine includes one or more set attribute functions for setting attributes in the instrument and includes one or more get attribute functions for obtaining values of attributes from the instrument. The set attribute functions and the get attribute functions in the IVI engine are common for each of the class drivers and specific instrument drivers.
The memory of the computer system further stores an initialization (INI) file which includes configuration information for a virtual instrument, wherein the virtual instrument includes the instrument and the specific driver. The INI file specifies the name and location of the specific driver and the address of the instrument as well as other information regarding the virtual instrument. According to the present invention, the user is generally required only to change configuration information in the INI file in order to replace instruments of a class or change functionality of the virtual instrument.
The user application includes an initialization (init) function call to the class driver which initializes the class driver and the specific driver. After the single init call, the user application can make calls to functions in the class driver or the specific driver. The user application preferably makes calls to the class driver. All the functions in the class driver are generic functions, i.e., functions which are common to all or most of the specific drivers within the class. This provides the instrument interchangeability benefits of the present invention. The user application can also make calls to generic functions directly to the specific driver. The user application can further make calls to unique functions, also referred to as instrument-specific functions, i.e., functions which are not generic to the class and hence do not reside in the class driver, directly to the specific driver.
When the class driver receives a function call from the user application, the class driver obtains a function pointer from the IVI engine. The class driver uses the pointer to invoke the corresponding function in the specific instrument driver. Functions in the specific driver perform operations on the respective instrument. The functions include calls to VISA to communicate directly with the instrument and/or they include calls to the set attribute functions and/or get attribute functions in the IVI engine, which operate to set and get attributes in the specific driver.
The set and get attribute functions perform a standard set of operations. These operations include range checking, coercion of attribute values, state caching, writing a setting to the instrument, reading a setting from the instrument, and checking the instrument status. To perform these operations, the set and get attribute functions access range tables provided by the specific instrument driver and invoke callback functions in the specific instrument driver.
As noted above, the specific driver includes attributes which model attributes or settings of the instrument. The specific driver also includes attributes referred to as development/production attributes, such as state caching, interchangeability checking, range checking, instrument status checking, and coercion recording. The INI file stores the attribute values for the virtual instrument, and the IVI engine is operable to examine the initialization file and configure the attributes in the specific driver with attribute settings from the INI file. According to the present invention, the initialization (INI) file is operable to be configured with these development/production attributes in a development mode during development of the user application. The initialization (INI) file is operable to be configured with these development/production attributes in a production mode during production of the user application. In other words, during development and testing of the system, the user can configure the INI file with these attributes in a mode for testing and development, e.g., state caching disabled, and interchangeability checking, range checking, instrument status checking, and coercion recording enabled for debugging purposes. After development has been completed, the user can configure the INI file with these attributes in a mode which provides increased performance, such as enabling state caching, and disabling interchangeability checking, range checking, instrument status checking, and coercion recording.
Each class of instruments includes one or more of three types of attributes and functions, these being fundamental, extension and instrument-specific. Fundamental attributes and functions are those which are generic or fundamental to the class of instruments, i.e., all or most instruments of the class have each of the fundamental attributes and functions. Accordingly, the class driver and each of the specific drivers are required to include each of the fundamental attributes and functions. Extension attributes and functions are those which are generic or common to a subset, but not all, of the instruments of the class. Extension attributes and functions are required to be in the class driver and are included in some specific drivers, but are not required in all specific drivers. Instrument-specific attributes and functions are those which are specific to only one or more instruments of the class. Instrument-specific attributes and functions are not included in the class driver, and are included in only the specific drivers corresponding to the one or more instruments which support the instrument-specific attributes and functions.
Capability groups are groups of related functions and attributes. There are two types of capability groups, these being the fundamental capabilities group and extension groups. Each class of instruments contains one fundamental capabilities group. The fundamental capabilities group contains all of the fundamental functions and fundamental attributes. Extension groups are groups of related extension functions and extension attributes. If a specific driver implements any of the functions or attributes of an extension group, the specific driver must implement all of the functions and attributes that the extension group contains.
The present invention provides a feature referred to as instrument interchangeability, meaning that once an application is created for an instrumentation system using a specific instrument of a first class, wherein the application was created using a class driver which is generic to the first class, the user can readily substitute other instruments of the first class without modifying the user application. Rather, the user is required only to change configuration information in the INI file to interchange instruments of a class.
The class driver of the present invention also performs instrument interchangeability checking when a function call is received to verify that an instrument is in an interchangeable state. Thus, when the class driver receives a function call which causes the instrument to perform a function based on a current configuration of the instrument, the class driver performs instrument interchangeability checking. In the preferred embodiment, instrument interchangeability checking includes first determining if fundamental attributes which will affect instrument behavior in the current configuration are in a user-specified state, i.e., the application program took explicit actions to set the states of the attributes. If one or more fundamental attributes which will affect instrument behavior in the current configuration are not in a user-specified state, the class driver records an error.
The class driver then determines which extension groups have extension attributes that have ever been in a user-specified state. If an extension group contains attributes which have ever been in a user-specified state and also contains one or more attributes that will affect instrument behavior but which are not currently in user-specified state, the class driver records an error.
The class driver also determines if one or more extension groups have never been in a user-specified state and are implemented in the specific driver. If all of the extension attributes of one or more extension groups have never been in a user-specified state and are implemented in the specific driver, the class driver sets all the extension attributes that are in the groups and that will affect instrument behavior to default values, thereby placing the instrument in an interchangeable state.
In order to ensure instrument interchangeability, the user preferably creates the initialization file to include default values of the instrument-specific attributes of the virtual instrument. Thus, when the user application makes a call to the initialization function in the class driver to control the instrument, the class driver sets the instrument-specific attributes to the default values according to the information in the initialization file. Thus the user can replace the instrument with a second instrument of the same class, wherein the replacement does not require any modifications to the user application, but rather only requires changing a portion of the initialization file to include different default values for the instrument-specific attributes.
The present invention thus provides an instrument driver software architecture which provides a number of features and benefits. The system includes an attribute model which provides improved performance over prior systems. The present invention also provides features such as state caching for improved performance, simulation features, development/production modes, instrument interchangeability, interchangeability checking and verification of replacement instruments. Therefore, the present invention comprises a system and method for controlling an instrumentation system. The present invention allows for greater flexibility and greater reusability of code as well as simplified driver and/or application development.
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 the historical evolution of instrument drivers;
FIGS. 2A and 2B illustrate representative instrumentation control systems of the present invention including various I/O interface options;
FIG. 3 is a block diagram of a computer system used to control an instrumentation system;
FIG. 4 illustrates the current software architecture for instrumentation systems;
FIG. 5 illustrates the software architecture of the preferred embodiment of the present invention;
FIG. 6A is a flowchart diagram illustrating user creation of a user application;
FIG. 6B is a flowchart diagram illustrating configuration and execution of a user application;
FIGS. 7A-7D are a flowchart diagram illustrating execution of an initialization function in the user application;
FIGS. 8A-8C are flowchart diagrams illustrating execution of functions in the user application;
FIG. 8A is a flowchart diagram illustrating execution of functions in the specific driver;
FIG. 9 illustrates the Set Attribute Mechanism;
FIGS. 10A-10B illustrate the Update Instument mechanism in the Set Attribute mechanism of FIG. 9;
FIGS. 11A-11B illustrate the Get Attribute Mechanism;
FIG. 12 illustrates the attribute/callback relationship;
FIG. 13 is a flowchart diagram illustrating the IVI Default Check Callback;
FIG. 14 is a flowchart diagram illustrating the IVI.sub.-- Get AttrRangeTable callback;
FIG. 15 is a flowchart diagram illustrating the IVI Default Coerce Callback;
FIG. 16 is a flowchart diagram illustrating the IVI Default Compare Callback;
FIG. 17 is a flowchart diagram illustrating an example of the Write Callback for a Message-Based Device;
FIG. 18 is a flowchart diagram illustrating an example of the Write Callback for a Register-Based Device;
FIG. 19 is a flowchart diagram illustrating an example of the Read Callback for a Message-Based Device;
FIG. 20 is a flowchart diagram illustrating an example of the Read Callback for a Register-Based Device;
FIGS. 21A and 21B illustrate a class driver obtaining a pointer to a simulation VI;
FIG. 22 is a flowchart diagram illustrating instrument interchangeability;
FIG. 23 is a flowchart diagram illustrating instrument interchangeability checking;
FIG. 24 is a flowchart diagram illustrating setting of extension attributes to class-specified default values;
FIGS. 25A and 25B are flowchart diagrams of the check status utility function and the check status callback function; and
FIG. 26 illustrates a user perspective of the IVI system.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Incorporation by Reference
U.S. patent application Ser. No. 09/045,243 titled "Instrumentation System and Method Using Generic Instrument Drivers" filed Mar. 20, 1998 now pending whose inventors are Scott Rust, Jon Bellin, and James Grey, is hereby incorporated by reference in its entirety as though fully set forth herein.
U.S. Pat. No. 5,724,272, titled "Method and Apparatus for Controlling an Instrumentation System," whose inventors were Bob Mitchell, Hugo Andrade, Jogen Pathak, Samson DeKey, Abhay Shah, and Todd Brower, and which was assigned to National Instruments Corporation, is hereby incorporated by reference in its entirety as though fully set forth herein, including the appendices therein. The above-referenced patent application discloses a system referred to as the Virtual Instrument Software Architecture (VISA), which is being formulated as IEEE standard 1226.5 and VXIPlug&Play specification VPP 4.1.
U.S. patent application Ser. No. 08/544,286, titled "System and Method for Creating Resources in an Instrumentation System," filed Oct. 17, 1995, now U.S. Pat. No. 5,710,727, whose inventors were Bob Mitchell, Hugo Andrade, Jogen Pathak, Samson DeKey, Abhay Shah, and Todd Brower, and which was assigned to National Instruments Corporation, is hereby incorporated by reference in its entirety as though fully set forth herein, including the appendix therein.
FIGS. 2A and 2B--Instrumentation and Industrial Automation Systems
Referring now to FIG. 2A, 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 130.
The one or more instruments may include a GPIB instrument 112, a data acquisition board 114, and/or a VXI instrument 116. The GPIB instrument 112 is coupled to the computer 102 via a GPIB interface card 122 provided by the computer 102. 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. Both the GPIB card 122 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 and 114 are shown external to computer 102 for illustrative purposes. The VXI 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) comprised in the computer 102.
The one or more instruments may also include PXI (PCI eXtensions for Instrumentation) instruments (not shown), which are preferably comprised in a PXI chassis (not shown) connected to the computer system. In addition, 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 130, 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. 2B, an industrial automation or process control system 140 is shown. The industrial automation system 140 is similar to the instrumentation or test and measurement system 100 shown in FIG. 2A. Elements which are similar or identical to elements in FIG. 1 have the same reference numerals for convenience. The system 140 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 MMI (Man Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed acquisition, advanced analysis, or control.
The one or more devices may include a data acquisition board 114, a serial instrument 142, a PLC (Programmable Logic Controller) 144, or a fieldbus network card 156. The data acquisition board 114 is coupled to or comprised in the computer 102, and preferably interfaces through signal conditioning circuitry 124 to the process 150. The signal conditioning circuitry 124 preferably comprises an SCXI (Signal Conditioning extensions for Instrumentation) chassis comprising one or more SCXI modules 126. The serial instrument 142 is coupled to the computer 102 through a serial interface card 152, or through a serial port, such as an RS-232 port, provided by the computer 102. The PLC 144 couples to the computer 102 through a serial port, Ethernet port, or a proprietary interface. The fieldbus interface card 156 is preferably comprised in the computer 102 and interfaces through a fieldbus network to one or more fieldbus devices, such as valve 146. Each of the DAQ card 114, the serial card 152 and the fieldbus card 156 are typically plugged in to an I/O slot in the computer 102 as described above. However, these cards 114, 12 and 156 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.
In the present disclosure, the term "instrument" is used to refer to various types of instruments such as GPIB instruments, VXI instruments, PXI instruments and RS-232 instruments. The term "instrument" is also used to refer to a data acquisition (DAQ) board in a computer system and/or a computer system configured with a DAQ board. The term "instrument" is further intended to include industrial automation and process control devices. In addition, the term instrument also refers to "virtual instruments" (combinations of hardware and/or software instruments) executing on a computer system, including VISA resources. In addition, the term "instrumentation system" is used herein to refer to test and measurement systems as well as industrial automation, process control and modeling systems, among others.
Referring again to FIGS. 2A and 2B, the host computer 102 preferably includes a memory media, such as an installation media, e.g., CD-ROM, tape drive, or floppy disks 104. The host computer 102 also preferably includes a non-volatile media, such as a magnetic media, e.g., a hard drive, or optical storage, as well as system memory, such as DRAM, SRAM etc. The memory media preferably stores a programning development system for developing and executing programs to configure or control the instruments or perform instrumentation functions. The host programming development system is preferably a graphical programming system, e.g., LabVIEW, for developing and executing graphical programs.
The memory media also stores an instrument driver software architecture according to the present invention. As discussed below, the instrument driver software architecture preferably includes one or more class drivers, one or more specific instrument drivers, and an IVI (interchangeable virtual instrument) engine, as well as other software tools and utilities. The host CPU executing code and data from the system memory comprises a means for performing generic instrument driver functions according to the steps described below.
Although in the preferred embodiment the instrument driver software architecture is involved with controlling or communicating with instruments, it is noted that the present invention can be used for a plethora of applications and is not limited to instrumentation or industrial automation applications. In other words, FIGS. 2A and 2B are exemplary only, and the present invention may be used in any of various types of systems.
Computer System Block Diagram
Referring now to FIG. 3, a block diagram of the computer system illustrated in FIGS. 1 and 2 is shown. It is noted that any type of computer system configuration or architecture can be used as desired, and FIG. 3 illustrates a representative PC embodiment. It is also noted that the computer system may be a general purpose computer system as shown in FIGS. 2A and 2B, a computer implemented on a VXI card installed in a VXI chassis, a computer implemented on a PXI card installed in a PXI chassis, or other types of embodiments. 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 160 which is coupled to a processor or host bus 162. The CPU 160 may be any of various types, including an x86 processor, e.g., a Pentium class, a PowerPC processor, a CPU from the SPARC family of RISC processors, as well as others. Main memory 166 is coupled to the host bus 162 by means of memory controller 164.
The main memory 166 stores a program development system, such as a graphical programming system, e.g., LabVIEW, or other types of development environments such as LabWindows.backslash.CVI, ComponentWorks, Visual Basic, etc. The main memory 166 also stores a generic instrument driver software architecture according to the present invention. The main memory 166 also stores operating system software as well as the software for operation of the computer system, as well known to those skilled in the art. The generic instrument driver software architecture will be discussed in more detail below.
The host bus 162 is coupled to an expansion or input/output bus 170 by means of a bus controller 168 or bus bridge logic. The expansion bus 170 is preferably the PCI (Peripheral Component Interconnect) expansion bus, although other bus types can be used. The expansion bus 170 includes slots for various devices such as the data acquisition board 114 (of FIG. 1), a GPIB interface card 122 which provides a GPIB bus interface to the GPIB instrument 112 (of FIG. 1), and a VXI or MXI bus card 186 coupled to the VXI chassis 116 for receiving VXI instruments. The computer 102 further comprises a video display subsystem 180 and hard drive 182 coupled to the expansion bus 170.
Instrumentation Software Architecture (prior art)
Referring now to FIG. 4, a diagram illustrating a representative software architecture for an instrumentation system according to the prior art is shown. As discussed in the background section, the top level of the software architecture typically comprises an application program used for high level control of the virtual instrument.
The application program typically operates in conjunction with one or more instrument drivers to interface to actual physical instruments. The instrument drivers are designed to reduce a user's application development time by providing intuitive high level functions that relieve the user of complex low level instrument programming. In prior art systems, each specific instrument requires its own instrument driver with a different set of functions.
A software level referred to as driver level software or I/O control software is below the instrument driver level. Driver level software is used to interface the commands in the instrument driver to the actual hardware interface being used, such as a GPIB interface card, a data acquisition card, or a VXI card. In other words, driver level software handles the details of communication, i.e., the transfer of commands and data, over the physical I/O connection between the computer and instruments.
FIG. 5--Generic Instrument Driver System Architecture
The present invention comprises a system and method for controlling an instrumentation system using an improved instrument driver software architecture. The improved instrument driver software architecture is referred to as Interchangeable Virtual Instruments (IVI) or Intelligent Virtual Instruments (IVI). The instrument driver software architecture of the present invention provides generic or interchangeable instrument drivers. The phrase "generic instrument drivers" refers to instrument drivers which are generic to a specific class of instruments. In the present disclosure, an instrument driver which is generic to a specific class of instruments is referred to as a class driver. The instrument driver software architecture of the present invention also provides other features, such as an improved attribute model, improved simulation, state caching, improved range checking, instrument interchangeability checking, and deferred updates.
Referring now to FIG. 5, a diagram illustrating the software architecture of the preferred embodiment of the present invention is shown. As shown, the generic instrument driver software architecture of the preferred embodiment includes at least one user application 302, preferably one or more class drivers 304, one or more specific instrument drivers 308, an IVI (interchangeable virtual instrument) engine 306 and a configuration or initialization file 310, referred to as IVI.ini
The user application includes calls to one or more of the class drivers 304 and/or the specific drivers 308. As shown, the specific instrument driver includes an instrument-specific capabilities portion as well as a generic or fundamental capabilities portion. The user application can interface directly to the instrument-specific capabilities portion, much like prior art systems where the application communications directly with an instrument driver specific to a particular instrument. As shown, the user application can also interface through the class driver 304 to the generic capabilities portion of the specific instrument driver. The user application can further interface directly to the generic capabilities portion of the specific instrument driver. When the user application interfaces through the class driver 304 to the generic capabilities portion of the specific instrument driver, the instrument interchangeability features of the present invention are realized.
Each of the one or more class drivers 304 is generic to a certain class of instruments. For example, the instrumentation system includes a class driver which is generic to DMMs (digital multimeters), a class driver 304 which is generic to oscilloscopes, a class driver which is generic to switches, a class driver generic to power supplies, a class driver generic to waveform generators, etc. The class driver is generic to instruments within the class, regardless of manufacturer and/or hardware interface type.
In one embodiment, the class driver 304 operates for any instrument, i.e., is generic to all instruments in the class. In the preferred embodiment, the class driver 304 operates for a majority of instruments within the class of instruments. More particularly, the class driver 304 is preferably designed for the most common application needs within the class, or for the fundamental capabilities of instruments within the class, including functions, attributes, and attribute values. In the preferred embodiment, the fundamental capabilities of the class driver 304 are designed to support more than 95% of the instruments of the respective class. The term "extensions" refers to less common capabilities of instruments within a class, i.e., capabilities which are supported by only a subset of the instruments within the class. One or more of these extension capabilities are implemented in the class driver 304 and are optionally supported by a specific driver 308. Extension groups are groups of related extension attributes and functions. Instrument-specific capabilities are capabilities which are specific to only one or more instruments of the class. Instrument-specific capabilities are preferably not included in the class driver, and are included in only the specific drivers corresponding to the one or more instruments which support the instrument-specific capabilities.
Therefore, each class of instruments includes one or more of three types of attributes and functions, these being fundamental, extension, and instrument-specific. Fundamental attributes and functions are those that are generic or fundamental to the class of instruments, i.e., all or most instruments of the class have each of the fundamental attributes and functions. Accordingly the class driver and each of the specific drivers are required to include each of the fundamental attributes and functions. Extension attributes and functions are those that are generic or common to a subset, but not all, of the instruments of the class. Extension attributes and functions are required to be in the class driver and are included in some specific drivers, but are not required in all specific drivers. Instrument-specific attributes and functions are those which are specific to only one or more instruments of the class. Instrument-specific attributes and functions are not included in the class driver, and are included in only the specific drivers corresponding to the one or more instruments which support the instrument-specific attributes and functions. The term "generic" attributes and functions is intended to include one or both of fundamental attributes and functions and extension attributes and functions.
Capability groups are groups of related functions and attributes. There are two types of capability groups, these being the fundamental capabilities group and extension groups. Each class of instruments contains one fundamental capabilities group. The fundamental capabilities group contains all of the fundamental functions and fundamental attributer. Extension groups are groups of related extension functions and extension attributes. If a specific driver implements any of the functions or attributes of an extension group, the specific driver must implement all of the functions and attributes that the extension group contains.
Each class driver includes a defined API (Application Programming Interface). Where instrument interchangeability is desired, the user uses the class driver 304 to write his/her application 302, i.e., the user creates an application 302 which makes calls to the class driver 304. The class driver 304 essentially operates as a router, i.e., the class driver includes a pass-through layer to the specific driver. The class driver 304 thus knows how to find functions in the specific instrument driver 308 required to perform the desired function. Each of the specific instrument drivers 308 are specific to a specific instrument. In other words, each of the specific instrument drivers 308 are specific to an instrument of a certain class, manufacturer, model and hardware interface type. Thus the system still requires specific drivers 308 for each instrument. If an instrumentation system only includes one or more instruments of a first class, the instrumentation system is only required to include the class driver corresponding to that first class, in addition to IVI-compliant specific drivers for each instrument in the system.
The class driver 304 initializes a virtual instrument based on a logical name. The class driver 304 also adds all class specified attributes. Attributes are marked as "Not Supported" if not implemented in the specific driver. The class driver 304 also simulates output parameter data for class functions when simulation is enabled.
When applications are written using the class driver, the user can swap instruments using a configuration utility, with no source code changes and no re-compilation. Thus the class driver provides instrument interchangeability.
As discussed above, the specific instrument driver 308 includes a generic capabilities portion and a specific driver portion for instrument-specific capabilities. The generic capabilities portion comprises capabilities which are generic or common to every specific instrument driver of that class. The specific instrument driver 308 contains all instrument driver source code, including fundamental capabilities or functions, extension capabilities, and driver specific capabilities. The specific instrument driver 308 includes driver functions such as initialization (init), configuration (config), and various other functions for communicating with and/or controlling the instrument. The specific instrument driver 308 also includes attribute callbacks and range tables. The specific instrument driver 308 also operates to publish/add all of its attributes to the IVI engine 306. It is noted that the specific driver 308 can be used independently of the class driver 304.
According to the present invention, the user and/or user application 302 is required to interface only to the class driver 304 when using common functionality. In other words, when creating a user application 302, the user is generally only required to have knowledge of the class driver 304, unless specific non-common functionality (referred to as instrument-specific capabilities) of a particular instrument is desired.
In the preferred embodiment, the class driver 304 incorporates references to the core functionality of the class of instruments, i.e., the generic capabilities portion. Thus a user application 302 is required to access a specific instrument driver 308 directly only when non-common functionality (instrument-specific capabilities) of a specific instrument is desired. In an alternate embodiment, the class driver 304 incorporates additional non-core capabilities (extension capabilities) of the class that exist only for certain specific instruments within the class. In other words, the class driver 304 incorporates functionality which is common to most instruments within the class, but not all. In this embodiment, if a certain function is not implemented by the respective instrument, the class driver 304 returns an error message.
The instrumentation system of the preferred embodiment preferably includes the initialization or configuration file (INI file) 310 which comprises information on each of the instruments or virtual instruments present in the instrumentation system. The term "virtual instrument" is used herein to refer to an instrument and its respective specific driver, i.e., a combination of hardware and software. The INI file 310 maps Logical Names used in a program to a Virtual Instrument section. The Virtual Instrument Section operates to link a hardware section and a driver section. The Virtual Instrument Section also sets driver modes, such as range checking, simulation, spying, interchangeability checking, and instrument status checking, using parameters called rangeCheck, simulate, spy, interchangeCheck, and queryInstrStatus. The INI file also defines Virtual Channel Names which map channel name aliases to instrument-specific channel names and specifies a default instrument setup for the virtual instrument.
For example, if the user application generically references a DMM as "DMM1", the configuration file stores information regarding which actual instrument and instrument driver in the system corresponds to DMM1. The configuration file stores information regarding the address of the instrument and the location of the instrument driver. This enables the system to load the specific driver and communicate with the instrument. An example INI file for a DMM is included in the present application. If the user desires to replace DMM1 with a different DMM, the user simply modifies the configuration file or INI file. The user is not required to recompile the program, but rather changing the configuration information in the INI file operates to replace the instrument.
As noted above, the instrumentation system of the preferred embodiment includes an IVI engine, also referred to as the IVI (Intelligent/Interchangeable Virtual Instrument) engine 306. As shown, the IVI Engine 306 communicates with each of the class drivers 304, the generic capabilities portion of the specific driver 308 and the instrument-specific capabilities portion of the specific driver 308. The IVI engine also couples to the initialization file referred to as IVI.INI 310. As shown, the IVI engine 306 and the specific driver 308 include bi-directional communication. The IVI engine 306 operates to create and manipulate IVI instrument driver objects. The IVI engine 306 also manages function pointers to the specific driver and calls driver-specific attribute callbacks. The IVI engine 306 further manages all instrument driver attributes and performs Set and Get attribute operations. The IVI engine 306 also performs state caching and attribute simulation operations.
When the user application 302 makes a call or invokes a method on the class driver 304, the class driver 304 accesses information in the IVI Engine 306. The class driver 304 uses services provided by the IVI engine 306 to access the respective function in the specific instrument driver 308 which performs the operation on the specific instrument. More specifically, when the class driver receives a function call, the IVI engine 306 provides a pointer to the class driver, wherein the pointer points to the respective function in the specific driver. In other words, all calls to the class driver 304 actually invoke the specific instrument driver 308 of the instrument being called. Thus the class driver 304 itself does not actually configure or "touch" the instrument, but rather preferably in every case the specific instrument driver 308 of the instrument is invoked to actually perform the configuration or operation. The IVI engine 306 thus operates with a respective class driver 304 to enable operation of the class driver 304 within the system. The IVI engine 306 is capable of operating with each of the class drivers 304 within the system. Thus the IVI engine 306 is generic to each of the class drivers 304 and provides services to each of the class drivers 304.
The user application 302 couples through the class driver 304 to the generic capabilities portion of the instrument driver 308. Thus the user application 302 invokes common or generic functionality of an instrument preferably using calls to the class driver 304. The user application 302 preferably accesses the generic capabilities portion of the instrument driver 308 through the class driver 304, and not directly. It is noted that the user application 302 can still access the generic capabilities directly, i.e., without invoking the class driver 304. However, this does not provide the replacement and re-usability benefits of the present invention. Rather, when the user application 302 is developed primarily or exclusively with the concept of a generic instrument, such as a generic DMM, using calls to the class driver 304, the user and/or user application 302 is not required to think in terms of the specific driver and/or the specific instrument. This greatly simplifies application development.
As shown, the user application 302 couples directly to the specific driver portion of the instrument driver 308 for instrument-specific capabilities. Thus the user application 302 can access non-core or non-common functionality, referred to as instrument-specific capabilities, of a particular instrument by making a call directly to the specific driver portion of the instrument driver 308. Thus instrument-specific functions, e.g., functions that only the respective specific instrument can perform, are still available for the user to directly access.
The specific driver 308 is operable to use services and/or functions in the IVI engine 306, such as set attribute and get attribute functions in the IVI engine 306. Likewise, the IVI engine 306 is operable to invoke callbacks in the specific driver 308 to perform its services and/or functions. The IVI engine 306 preferably includes a plurality of set attribute and get attribute functions, each for a respective data type. For example, the IVI engine 306 preferably includes set attribute and get attribute functions for data types such as int32, real 64, Booleans, strings, pointers, etc.
It is noted that prior art specific instrument drivers include functions which begin with the particular name of the instrument, such as FL45.sub.-- function or HP34401.sub.-- function. Accordingly, prior art user applications are generally required to uses the specific function names. Thus in a prior art system when it is desired to switch to a different instrument of the same class, thus user is at least required to change the program to now reference the correct driver. According to the present invention, the user application simply references generic instrument functions, and thus the user application can be used with different instruments of the same class.
Instrument Attributes
According to the present invention, an instrument is partitioned or broken up into various settings or attributes. The attributes are used to define the configuration or state of the instrument, and are also used to represent internal IVI options. More specifically, an instrument includes settings which reflect the state of the instrument. The specific driver includes attributes which model the settings of the instrument. A "virtual instrument" includes the instrument as well as one or more of the specific driver and the class driver. A virtual instrument includes attributes, including the attributes or settings of the instrument as well as the attributes of the specific driver. In the preferred embodiment, calls to get and set attributes in the specific driver are used to program the instrument, or more generally are used to program the virtual instrument.
A user application reads an attribute value to determine the current state of the resource, for example, how the resource is processing an operation, or how the resource should operate when something occurs. A user application sets an attribute to change the way in which the resource operates. The manipulation of attributes, i.e., setting/getting attributes, is enabled by the IVI engine 306. The user application 302 invokes set and get attribute functions in the class driver 304 or specific driver 308. When the class driver or specific driver receives a call to the set or get attribute functions, the class driver or the specific driver invokes the set or get attribute function in the IVI engine 306. The IVI engine invokes callbacks in the specific driver 308. As discussed further below, attributes provide simulation, caching and deferred update features, among others.
Each Attribute has the following: ID, flags, callback function pointers, a range table pointer, and an invalidation list. The ID is a defined constant which is the name of the attribute.
The flags of an attribute include the following:
NOT.sub.-- READABLE
NOT.sub.-- WRITABLE
NOT.sub.-- USER.sub.-- READABLE
NOT.sub.-- USER.sub.-- WRITABLE
NEVER.sub.-- CACHE
ALWAYS.sub.-- CACHE
NO.sub.-- DEFERRED.sub.-- UPDATE
DONT.sub.-- RETURN.sub.-- DEFERRED.sub.-- VALUE
WAIT.sub.-- FOR.sub.-- OPC.sub.-- BEFORE.sub.-- READS
WAIT.sub.-- FOR.sub.-- OPC.sub.-- AFTER.sub.-- WRITES
NOT.sub.-- SUPPORTED
FLUSH.sub.-- ON.sub.-- WRITE
MULTI.sub.-- CHANNEL
COERCEABLE.sub.-- ONLY.sub.-- BY.sub.-- INSTR
USE.sub.-- CALLBACKS.sub.-- FOR.sub.-- SIMULATION
DON'T.sub.-- CHECK.sub.-- STATUS
Each attribute includes callback function pointers which define how operations are performed on the attribute, including Read, Write, Check, RangeTable, Coerce, Compare, etc. The Read and Write callback function pointer references a function which defines how to read or write this attribute for the instrument. The Check callback function pointer references a function which verifies that a value is valid for the attribute. The RangeTable callback function pointer references a function which obtains the correct range table for the attribute. The Coerce callback function pointer references a function which coerces a value that the user application specified to a value that the instrument accepts or the value to which the instrument itself would coerce the application-specified value. The Compare callback function pointer references a function which compares a cached value that was previously obtained by a read from the instrument with the value the application program is attempting to write to the instrument.
The range table pointer holds the address of the range table for the attribute. The range table expresses all possible values for the attribute. The range table also contains the command strings or register values that the driver sends to the instrument to set a particular value. Based on a range table, the IVI engine can perform range checking and coercion operations for the attribute. The IVI engine performs these operations by providing default check and coerce callbacks. Thus, the specific driver is not required to include callback functions for this purpose.
The invalidation list defines the attributes to invalidate when this attribute is written. In general, whenever the user sets an attribute, this can cause the state of another attribute to become unknown. Thus, each attribute includes an invalidation list which specifies all the attributes whose cached values becomes invalid when the respective attribute is set.
FIG. 6A--Creating a User Application
FIG. 6A is a simple flowchart diagram which illustrates creation of a user application 302. As shown, in step 402 the user or developer edits or modifies an IVI.INI file. In step 402 the user creates a logical name that is used in the user's program when the program calls the INIT function on the class driver. In step 402 the user or developer also specifies information in a virtual instrument section in the IVI.INI file for the respective instrument. The logical name identifies which specific driver to load and the address of the instrument that the program will communicate with. The logical name maps to the virtual instrument section in the IVI.INI file, which includes information on a virtual instrument. The virtual instrument is a combination of software, e.g., an instrument driver for the specific instrument, and hardware, the specific instrument that is being controlled or communicated with.
The virtual instrument section in the INI file includes tag names which refer to a hardware section later in the INI file and a driver tag that refers to a driver section later in the INI file. The hardware section specifies the VISA resource descriptor or address used to talk to the instrument. The driver section lists the module path, i.e., the file name and path on the computer to access the specific instrument driver. The driver section also includes the prefix that is used by the functions in the respective instrument driver. The IVI.INI file includes this information so that, when the user application is executed, the IVI engine can locate and load the correct specific driver, determine the functions that can be called on the specific instrument driver, obtain function pointers to the functions, and can assemble the function names correctly.
The virtual instrument section entry in the INI file also includes other information, including parameters for different modes of operation, such as enabling or disabling of state caching, simulation, interchangeability checking, spying, and range checking, among others. The virtual instrument section entry in the INI file also includes a virtual channel name list. The virtual channel name list comprises a list of virtual channel names that can be used in the user application and specifies how the virtual channel names map to specific channel names that the specific driver understands.
The virtual instrument section entry in the INI file also includes a default setup entry which references an optional section in the INI file called the default setup section. The default setup section lists names of attributes and a default value for each of the attributes. The default setup section is used later by the class driver to set a default state for the instrument.
In step 404 the user creates a user application. The user application first includes an initialization function which operates to initialize the software and the instrument being controlled. The initialization function call includes a parameter where the user passes in a logical name to identify the specific instrument that the user desires to initialize. The logical name was previously configured in step 402.
The user application also includes calls to the generic class driver. For example, if the class of instruments is "DMM", the user application includes generic DMM configure, DMM measure, etc., calls. The user application may also include "Get Attribute" and "Set Attribute" calls which operate to get and set attributes on the instrument. The user application further may include calls made directly to the specific driver, such as calls to access instrument-specific capabilities which are not included in the class driver.
FIG. 6B--Execution of a User Application
FIG. 6B is a flowchart diagram illustrating operation of a user configuring an INI file with a configuration for a virtual instrument and then executing a user application according to the preferred embodiment of the present invention.
As shown, in step 412 the user configures the IVI.INI file with a logical name and a definition of a virtual instrument. As discussed above, the logical name refers to a virtual instrument. The virtual instrument comprises the actual physical instrument, i.e., one or more instruments, as well as the corresponding specific driver for that instrument. The virtual instrument definition includes information such as which instrument driver corresponds to the instrument, the identification of the instrument, and mode information, such as whether state caching, instrument interchangeability checking, and other features are enabled or disabled.
In step 414 the user application is executed. In general, the first function call in a user application is an init call. In step 416 the user application calls the init function. The operation of the init function is discussed in further detail with respect to FIG. 7A-7D. In step 418 the user application calls functions and gets and sets attributes to control the instrument. In other words, in step 418 the body of the user application is executed to perform the desired application for which the user application is intended, such as performing a desired test and measurement, among others.
In general the last call in the user application is the close call. In step 420 the user application calls the close function.
FIG. 7--Executing the Initialization Function in the User Application
FIGS. 7A-7D are a flowchart diagram which illustrates execution of an initialization function call in the user application 302. Here it is presumed that a class driver 304 has been created which includes functions and attributes. The functions and attributes in the class driver represent the generic capabilities of the class of instruments for which the class driver is intended. It is also presumed that the user has received or developed a specific instrument driver 308 which was written using the IVI engine 306 and developed in accordance with the specification of a given class, i.e., is an IVI compliant specific instrument driver.
The specific instrument driver 308 was developed using the API of the class driver 304. Thus the function names that exist in the class driver 304 are similar to the function names in the generic capability section of the specific driver 308. In the preferred embodiment, the functions are identical with the exception of the prefix, wherein the prefix is a unique identifier for the instrument driver. In addition, the parameters, attributes, and the values accepted for those parameters and attributes are identical between the class driver 304 and the specific driver 308. The user application 302 makes calls to the functions in the class driver 304, and also operates to get or set attributes in the class driver 304.
As shown, in step 422 the user application calls an initialization function in the class driver 304. Step 422 corresponds to step 416 of FIG. 6B, and the remaining steps of FIGS. 7A-7D involve execution of the init function. As noted above, the user application includes calls to a driver initialization function (init) in the class driver 304 which creates or instantiates the driver and returns a handle. The user application can either initialize the class driver or the specific driver. Where the generic instrument driver of the present invention is used or desired, the user application includes an initialization command to initialize the class driver.
The init call uses a logical name which represents a virtual instrument, i.e, represents the instrument being called, the instrument specific driver 308, as well as related configuration information. The logical name is a reference to a virtual instrument section in the IVI.ini file.
In step 424 the class driver 304 receives the initialization command. In response to receiving the initialization function call in step 424, in step 426 the class driver 304 makes a call to the IVI engine 306. In step 426 the class driver 304 provides the logical name received from the user application 302 for the instrument being called or initialized to the IVI engine 306. The class driver 304 also provides an array of all the function names that the class driver 304 defines and that might be present in the specific driver 308. Therefore, in a later step (step 432), the IVI engine 306 knows which function pointers to find in the specific driver 308 when the specific driver 308 is loaded. The class driver 304 thus effectively informs the IVI engine 306 that the class driver 304 is attempting to initialize the particular instrument.
In response to receiving the initialization function call and the instrument logical name in step 426, in step 428 the IVI engine 306 uses the logical name to reference into the IVI.ini file to retrieve the information associated with the logical name. This operates to retrieve all the information that is held in the IVI.ini file into memory. As discussed below, the IVI engine 306 uses this information to perform various operations in later steps. For example, in step 430 based on the specific driver module path, i.e., where the specific driver module 308 is located, the IVI engine 306 loads the specific driver 308 into memory and then examines the driver 308 to obtain all of the function pointer entry points for the functions that the class driver 306 indicated might be present in the driver 308 when the class driver 306 passed in the array of function names. Thus, in step 428 the IVI engine 306 utilizes the logical name to reference into the IVI.ini file and obtain the necessary information corresponding to the logical name and store it in memory.
In step 430 the IVI engine 306 determines where the specific instrument driver 308 is located for the instrument being initialized and operates to load the specific instrument driver 308. In step 432 the IVI engine 306 examines the specific driver and attempts to find functions that correspond to each function name in the array of function names that the class driver passed to the IVI engine. The IVI engine contains an array of function pointers. Each element in the array corresponds to the same element in the array of function names. When the IVI engine finds a function in the specific driver with the same name as one of the names in the array of function names, the IVI engine sets the corresponding element in the function pointer array to the actual address of the function in the specific driver.
In step 434 the IVI engine 306 provides a pointer to the IviInit function of the specific driver 308 to the class driver and returns control to the class driver. More specifically, in step 434 the class driver 304 invokes a function in the IVI engine 306 to retrieve the pointer to the IviInit function in the specific driver 308. The IVI engine 306 executes this function to return the pointer to the class driver 304. It is noted that the specific driver includes a special function called IviInit, which the class driver calls to initialize the specific driver. If the end user initializes the specific driver directly (i.e., does not use the class driver), the end user calls the regular init function.
In step 436 the class driver 304 c |
