U.S. patent application number 11/418075 was filed with the patent office on 2006-11-02 for motion control systems.
Invention is credited to David W. Brown, Jay S. Clark.
Application Number | 20060247801 11/418075 |
Document ID | / |
Family ID | 39940165 |
Filed Date | 2006-11-02 |
United States Patent
Application |
20060247801 |
Kind Code |
A1 |
Brown; David W. ; et
al. |
November 2, 2006 |
Motion control systems
Abstract
A system for communicating with at least one motion control
device, comprising a set of software drivers, a motion control
component, and a network protocol. At least one software driver is
selectable and associated with at least one motion control device.
The motion control component exposes component functions for
commanding at least one selected motion control device based on at
least one selected software driver and the exposed component
functions. The component functions exposed by the motion control
component may be used through the network protocol.
Inventors: |
Brown; David W.; (Bingen,
WA) ; Clark; Jay S.; (Bingen, WA) |
Correspondence
Address: |
SCHACHT LAW OFFICE, INC.
SUITE 202
2801 MERIDIAN STREET
BELLINGHAM
WA
98225-2412
US
|
Family ID: |
39940165 |
Appl. No.: |
11/418075 |
Filed: |
May 4, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10316451 |
Dec 10, 2002 |
|
|
|
11418075 |
May 4, 2006 |
|
|
|
10021669 |
Dec 10, 2001 |
6516236 |
|
|
10316451 |
Dec 10, 2002 |
|
|
|
09191981 |
Nov 13, 1998 |
|
|
|
10021669 |
Dec 10, 2001 |
|
|
|
08656421 |
May 30, 1996 |
5867385 |
|
|
09191981 |
Nov 13, 1998 |
|
|
|
08454736 |
May 30, 1995 |
5691897 |
|
|
08656421 |
May 30, 1996 |
|
|
|
09795777 |
Feb 27, 2001 |
6513058 |
|
|
10316451 |
|
|
|
|
09205627 |
Dec 3, 1998 |
6209037 |
|
|
10316451 |
|
|
|
|
09191981 |
Nov 13, 1998 |
|
|
|
10316451 |
|
|
|
|
08656421 |
May 30, 1996 |
5867385 |
|
|
09191981 |
Nov 13, 1998 |
|
|
|
08454736 |
May 30, 1995 |
5691897 |
|
|
08656421 |
May 30, 1996 |
|
|
|
09633633 |
Aug 7, 2000 |
6941543 |
|
|
10316451 |
|
|
|
|
09191981 |
Nov 13, 1998 |
|
|
|
10316451 |
|
|
|
|
08656421 |
May 30, 1996 |
5867385 |
|
|
09191981 |
Nov 13, 1998 |
|
|
|
08454736 |
May 30, 1995 |
5691897 |
|
|
08656421 |
May 30, 1996 |
|
|
|
60067466 |
Dec 4, 1997 |
|
|
|
Current U.S.
Class: |
700/56 |
Current CPC
Class: |
G05B 2219/36036
20130101; G05B 2219/23265 20130101; G05B 2219/43167 20130101; G05B
2219/34216 20130101; G05B 19/0426 20130101; G05B 19/19 20130101;
G05B 2219/34287 20130101; G05B 2219/23262 20130101; G05B 2219/36035
20130101; B25J 9/1602 20130101; G05B 19/416 20130101 |
Class at
Publication: |
700/056 |
International
Class: |
G05B 19/18 20060101
G05B019/18 |
Claims
1. A system for generating a sequence of control codes for
commanding at least one motion control device, comprising: a
software system comprising a set of at least one module function
call, where the software system is capable of directing a motion
control device to perform at least one motion operation; a set of
software drivers for generating a one or more control codes for
commanding the at least one motion control device, where at least
one software driver is selectable and associated with at least one
motion control device; a motion control module for commanding at
least one motion control device based on at least one selectable
software driver and the module functions called by the software
system;
2. A system as recited in claim 1, further comprising a network
protocol by which the motion control module and the software system
are capable of communicating.
3. A system as recited in claim 1, further comprising a network
protocol by which the motion control module and at least one
software driver are capable of communicating.
4. A system as recited in claim 1, in which a network protocol
allows communication between the motion control module and at least
one selected software driver.
5. A system as recited in claim 1, in which at least one motion
operation is capable of causing data to be read from the motion
control device.
6. A system as recited in claim 1, in which at least one motion
operation is capable of causing digital input-output data to be
read from the motion control device.
7. A system as recited in claim 1, in which at least one motion
operation is capable of causing analog input-output data to be read
from the motion control device.
8. A system as recited in claim 1, in which at least one motion
operation is capable of causing motion related data to be read from
the motion control device.
9. A system as recited in claim 1, in which at least one motion
operation is capable of causing program related data to be read
from the motion control device.
10. A system as recited in claim 1, in which the motion control
device is a program logic controller.
11. A system as recited in claim 1, in which the motion control
device comprises a program logic controller.
12. A system as recited in claim 1, in which the motion control
device is capable of communicating with a program logic
controller.
13. A system as recited in claim 1, in which at least one motion
operation is capable of causing digital input-output data to be
written to the motion control device.
14. A system as recited in claim 1, in which at least one motion
operation is capable of causing analog input-output data to be
written to the motion control device.
15. A system as recited in claim 1, in which at least one motion
operation is capable of causing motion related data to be written
to the motion control device.
16. A system as recited in claim 1, in which at least one motion
operation is capable of causing the motion control device to
perform an action.
17. A system as recited in claim 16, in which the motion control
device comprises a program logic controller that performs the
action.
18. A system as recited in claim 16, in which the motion control
device is a program logic controller that performs the action.
19. A system as recited in claim 16, in which the motion control
device is capable of causing program logic controller to perform
the action by communicating with the program logic controller.
20. A system as recited in claim 1, in which at least one motion
operation is capable of causing the motion control device to move
an object.
21. A system as recited in claim 1, in which the software system
comprises an application program.
22. A system as recited in claim 1, in which the software system
comprises server software.
23. A system as recited in claim 1, in which at least one software
driver further comprises at least one driver function for
commanding at least one motion control device.
24. A system as recited in claim 23, in which at least one driver
function commands the motion control device to perform a primitive
operation.
25. A system as recited in claim 24, in which at least one driver
function calls at least one primitive driver function to command at
least one motion control device to perform an operation.
26. A system as recited in claim 24, in which the motion control
device is commanded to communicate with a program logic
controller.
27. A system as recited in claim 24, in which the motion control
device comprises a program logic controller.
28. A system as recited in claim 25, in which the motion control
device is commanded to communicate with a program logic
controller.
29. A system as recited in claim 25, in which the motion control
device comprises a program logic controller.
30. A system for generating a sequence of control commands to be
communicated with at least one selectable motion control device
selected from a group of supported motion control devices,
comprising: a software system comprising a set of module function
calls, where the software system defines the steps for operating
motion control devices in a desired manner; a set of software
drivers for generating commands for controlling at least one motion
control device, where at least one software driver is associated
with at least one motion control device in the group of supported
motion control devices; a motion control module for commanding at
least one selectable motion control device based on at least one
software driver and module functions called by the software system;
and a set of stream modules for transmitting data to and receiving
data from at least one motion control device, where at least one
stream module sends data from at least one software driver to at
least one motion control device in a data format associated with
the motion control device.
31. A system as recited in claim 30, further comprising a network
protocol over which at least one software driver is capable of
communicating with at least one software stream.
32. A system as recited in claim 30, further comprising a network
system, where the network system implements the network
protocol.
33. A system as recited in claim 30, further comprising selection
software capable of selecting at least one selectable software
driver using a network protocol.
34. A system as recited in claim 30, in which a network protocol
allows communication between the motion control module and at least
one software driver.
35. A system as recited in claim 30, in which a network protocol
allows communication between the software system and the motion
control module.
36. A system as recited in claim 35, in which the software system
comprises an application program.
37. A system as recited in claim 35, in which the software system
comprises a server module.
38. A system as recited in claim 35, in which at least one software
driver function commands the motion control device to perform a
primitive operation.
39. A system as recited in claim 35, in which at least one driver
function calls at least one primitive driver function to command at
least one motion control device to perform an operation.
40. A system as recited in claim 38, in which the motion control
device is commanded to communicate with a program logic
controller.
41. A system as recited in claim 38, in which the motion control
device comprises a program logic controller.
42. A system as recited in claim 39, in which the motion control
device is commanded to communicate with a program logic
controller.
43. A system as recited in claim 39, in which the motion control
device comprises a program logic controller.
44. A system for generating a sequence of control codes for
commanding at least one motion control device, comprising: a
software system comprising a series of module function calls, where
the software system is capable of directing at least one motion
control device to perform at least one motion operation; a motion
control module for commanding at least one motion control device
based on module functions called by the software system; a set of
software drivers, where at least one software driver is selectable
and associated with at least one motion control device; and a
network interface, where the software system, motion control
module, and software drivers conform to the network interface.
45. A system as recited in claim 44, in which at least one motion
operation is capable of causing data to be read from the motion
control device.
46. A system as recited in claim 44, in which at least one motion
operation is capable of causing the motion control device to
perform an action.
47. A system as recited in claim 44, in which at least one motion
operation is capable of causing the motion control device to move
an object.
48. A system as recited in claim 44, in which the software system
comprises an application program.
49. A system as recited in claim 44, in which the software system
comprises server software.
50. A system for communicating with at least one motion control
device, comprising: a set of motion operations; a software system
comprising a set of module function calls, where the software
system is capable of commanding at least one motion control device
to perform at least one motion operation; a set of software
drivers, where at least one software driver is a selectable
software driver and is associated with at least one motion control
device; and a motion control module for commanding at least one
motion control device based on at least one selectable software
driver and at least one module function call called by the software
system; a network protocol by which the motion control module and
the software module are capable of communicating.
51. A system as recited in claim 50, in which the network protocol
further allows communication between the motion control module and
at least one selectable software driver.
52. A system as recited in claim 50, in which the software system
comprises an application program.
53. A system as recited in claim 50, in which the software system
comprises server software.
54. A system as recited in claim 50, in which the selectable
software driver is capable of reading data from the motion control
device.
55. A system as recited in claim 50, in which the selectable
software driver is capable of reading digital input-output data
from the motion control device.
56. A system as recited in claim 50, in which the selectable
software driver is capable of reading analog input-output data from
the motion control device.
57. A system as recited in claim 50, in which the selectable
software driver is capable of reading motion related data from the
motion control device.
58. A system as recited in claim 50, in which the selected software
driver is capable of reading program related data from the motion
control device.
59. A system as recited in claim 50, in which the motion control
device is a program logic controller.
60. A system as recited in claim 50, where the motion control
device comprises a program logic controller.
61. A system as recited in claim 50, where the motion control
device is capable of communicating with a program logic
controller.
62. A system as recited in claim 50, in which the selected software
driver is capable of writing digital input-output data to the
motion control device.
63. A system as recited in claim 50, in which the selected software
driver is capable of writing analog input-output data to the motion
control device.
64. A system as recited in claim 50, in which the selected software
driver is capable of writing motion data to the motion control
device.
65. A system as recited in claim 50, in which the selectable
software driver is capable of causing the motion control device to
move an object.
66. A system as recited in claim 50, in which the selectable
software driver is capable of causing the motion control device to
perform an action.
67. A system as recited in claim 66, in which motion control device
comprises a program logic controller that is capable of performing
the action.
68. A system as recited in claim 66, in which the motion control
device is a program logic controller that is capable of performing
the action.
69. A system as recited in claim 66, in which the motion control
device is capable of communicating with a program logic controller
to cause the program logic controller to perform the action.
70. A system for communicating with at least one selectable motion
control device, comprising: a software system comprising a set of
module function calls, where the software system is capable of
commanding at least one motion control device to perform at least
one motion operation; a set of software drivers, where at least one
software driver is a selectable software driver and is associated
with one motion control device; and a motion control module for
commanding at least one motion control device based on at least one
selectable software driver and module function calls called by the
software system; a network protocol by which the motion control
module and at least one selectable software driver are capable of
communicating.
71. A system as recited in claim 70, further comprising selection
software capable of selecting at least one selectable software
driver using the network protocol.
72. A system as recited in claim 70, in which the network protocol
further allows communication between the application program and
the motion control module.
73. A system as recited in claim 70, in which the software system
comprises an application program.
74. A system as recited in claim 70, in which the software system
comprises server software.
75. A system as recited in claim 70, in which the selectable
software driver is capable of reading data from the motion control
device.
76. A system as recited in claim 70, in which the selectable
software driver is capable of reading digital input-output data
from the motion control device.
77. A system as recited in claim 70, in which the selectable
software driver is capable of reading analog input-output data from
the motion control device.
78. A system as recited in claim 70, in which the selectable
software driver is capable of reading motion related data from the
motion control device.
79. A system as recited in claim 70, in which the selected software
driver is capable of reading program related data from the motion
control device.
80. A system as recited in claim 70, in which the motion control
device is a program logic controller.
81. A system as recited in claim 70, where the motion control
device comprises a program logic controller.
82. A system as recited in claim 70, where the motion control
device is capable of communicating with a program logic
controller.
83. A system as recited in claim 70, in which the selectable
software driver is capable of writing digital input-output data to
the motion control device.
84. A system as recited in claim 70, in which the selectable
software driver is capable of writing analog input-output data to
the motion control device.
85. A system as recited in claim 70, in which the selectable
software driver is capable of writing motion data to the motion
control device.
86. A system as recited in claim 70, in which the selectable
software driver is capable of causing the motion control device to
move an object.
87. A system as recited in claim 70, in which the selectable
software driver is capable of causing the motion control device to
perform an action.
88. A system as recited in claim 87, in which motion control device
comprises a program logic controller that is capable of performing
the action.
89. A system as recited in claim 87, in which the motion control
device is a program logic controller that is capable of performing
the action.
90. A system as recited in claim 87, in which the motion control
device is capable of communicating with a program logic controller
to cause the program logic controller to perform the action.
91. A system for communicating with at least one motion control
device, comprising: a software system comprising a set of calls to
module functions, where the software system is capable of
commanding at least one motion control device to perform at least
one motion operation; a set of software drivers, where at least one
software driver is a selectable software driver and is associated
with at least one motion control device; a motion control module
for commanding at least one selectable motion control device based
on the module functions used by the software system and at least
one selectable software driver; a set of stream modules, where at
least one stream module is a selectable stream module and carries
data between at least one selectable software driver and at least
one motion control device in a data format associated with the at
least one motion control device; and a network protocol that allows
data to be transmitted between at least one selectable software
driver and the selectable stream module.
92. A system as recited in claim 91, in which the network protocol
further allows communication between the motion control module and
at least one selectable software driver.
93. A system as recited in claim 91, further comprising selection
software capable of selecting at least one selectable software
driver using the network protocol.
94. A system as recited in claim 91, further comprising selection
software capable of selecting at least one selectable stream using
the network protocol.
95. A system as recited in claim 91, further comprising a network
system that implements the network protocol to allow data to be
transmitted between the selectable stream module and at least one
selectable motion control device.
96. A system as recited in claim 91, in which the network protocol
further allows communication between the software system and the
module functions.
97. A system for communicating with at least one motion control
device, comprising: a set of software drivers, where at least one
software driver is associated with at least one motion control
device in the group of supported motion control devices and a
selected software driver is associated with at least one motion
control device; a motion control module for exposing module
functions for commanding at least one selected motion control
device based on the exposed module functions and at least one
selected software driver; a set of stream modules for transmitting
data to the supported motion control devices, where a selected
stream module carries data between at least one selected software
driver and at least one motion control device in a data format
associated with at least one motion control device; and a protocol
that allows data to be transmitted between at least one selected
software driver and the selected stream module.
98. A system as recited in claim 97, in which at least one of the
exposed module functions provides the capability to read data from
the at least one motion control device.
99. A system as recited in claim 97, in which at least one of the
exposed module functions provides the capability to write motion
data to the at least one motion control device.
100. A system as recited in claim 97, in which at least one of the
exposed module functions provides the capability to cause an action
to occur on at least one motion control device.
Description
RELATED APPLICATIONS
[0001] This is a continuation of U.S. patent application Ser. No.
10/316,451 filed on Dec. 10, 2002, which is a continuation of U.S.
patent application Ser. No. 10/021,669 filed on Dec. 10, 2001, now
U.S. Pat. No. 6,516,236, which is a continuation of U.S. patent
application Ser. No. 09/191,981 filed on Nov. 13, 1998, now
abandoned, which is a continuation of U.S. patent application Ser.
No. 08/656,421 filed on May 30, 1996, now U.S. Pat. No. 5,867,385,
which is a continuation-in-part of U.S. patent application Ser. No.
08/454,736 filed on May 30, 1995, now U.S. Pat. No. 5,691,897.
[0002] This application is also a continuation of U.S. patent
application Ser. No. 09/795,777 filed on Feb. 27, 2001, now U.S.
Pat. No. 6,513,058, which is incorporated by reference in its
entirety and which is a continuation of U.S. patent application
Ser. No. 09/205,627 filed on Dec. 3, 1998, now U.S. Pat. No.
6,209,037, which claims benefit of U.S. Provisional Patent
Application Ser. No. 60/067,466 filed on Dec. 4, 1997, and which is
a continuation of U.S. patent application Ser. No. 09/191,981 filed
on Nov. 13, 1998, now abandoned, which is a continuation of U.S.
patent application Ser. No. 08/656,421 filed on May 30, 1996, now
U.S. Pat. No. 5,867,385, which is a continuation-in-part of U.S.
patent application Ser. No. 08/454,736 filed on May 30, 1995, now
U.S. Pat. No. 5,691,897.
[0003] This application is also a continuation of U.S. patent
application Ser. No. 09/633,633 filed on Aug. 7, 2000, now U.S.
Pat. No. 6,941,543, which is incorporated by reference in its
entirety and which is a continuation of U.S. patent application
Ser. No. 09/191,981 filed on Nov. 13, 1998, now abandoned, which is
a continuation of U.S. patent application Ser. No. 08/656,421 filed
on May 30, 1996, now U.S. Pat. No. 5,867,385, which is a
continuation-in-part of U.S. patent application Ser. No. 08/454,736
filed May 30, 1995, now U.S. Pat. No. 5,691,897.
[0004] The contents of all related application listed above are
incorporated herein by reference.
TECHNICAL FIELD
[0005] The present invention relates to motion control systems and,
more particularly, to interface software that facilitates the
creation of hardware independent motion control software.
BACKGROUND OF THE INVENTION
[0006] The purpose of a motion control device is to move an object
in a desired manner. The basic components of a motion control
device are a controller and a mechanical system. The mechanical
system translates signals generated by the controller into movement
of an object.
[0007] While the mechanical system commonly comprises a drive and
an electrical motor, a number of other systems, such as hydraulic
or vibrational systems, can be used to cause movement of an object
based on a control signal. Additionally, it is possible for a
motion control device to comprise a plurality of drives and motors
to allow multi-axis control of the movement of the object.
[0008] The present invention is of particular importance in the
context of a mechanical system including at least one drive and
electrical motor having a rotating shaft connected in some way to
the object to be moved, and that application will be described in
detail herein. But the principles of the present invention are
generally applicable to any mechanical system that generates
movement based on a control signal. The scope of the present
invention should thus be determined based on the claims appended
hereto and not the following detailed description.
[0009] In a mechanical system comprising a controller, a drive, and
an electrical motor, the motor is physically connected to the
object to be moved such that rotation of the motor shaft is
translated into movement of the object. The drive is an electronic
power amplifier adapted to provide power to a motor to rotate the
motor shaft in a controlled manner. Based on control commands, the
controller controls the drive in a predictable manner such that the
object is moved in the desired manner.
[0010] These basic components are normally placed into a larger
system to accomplish a specific task. For example, one controller
may operate in conjunction with several drives and motors in a
multi-axis system for moving a tool along a predetermined path
relative to a workpiece.
[0011] Additionally, the basic components described above are often
used in conjunction with a host computer or programmable logic
controller (PLC). The host computer or PLC allows the use of a
high-level programming language to generate control commands that
are passed to the controller. Software running on the host computer
is thus designed to simplify the task of programming the
controller.
[0012] Companies that manufacture motion control devices are,
traditionally, hardware oriented companies that manufacture
software dedicated to the hardware that they manufacture. These
software products may be referred to as low level programs. Low
level programs usually work directly with the motion control
command language specific to a given motion control device. While
such low level programs offer the programmer substantially complete
control over the hardware, these programs are highly hardware
dependent.
[0013] In contrast to low-level programs, high-level software
programs, referred to sometimes as factory automation applications,
allow a factory system designer to develop application programs
that combine large numbers of input/output (I/O) devices, including
motion control devices, into a complex system used to automate a
factory floor environment. These factory automation applications
allow any number of I/O devices to be used in a given system, as
long as these devices are supported by the high-level program.
Custom applications, developed by other software developers, cannot
be developed to take advantage of the simple motion control
functionality offered by the factory automation program.
[0014] Additionally, these programs do not allow the programmer a
great degree of control over the each motion control device in the
system. Each program developed with a factory automation
application must run within the context of that application.
PRIOR ART
[0015] In the following discussions, a number of documents are
cited that are publicly available as of the filing date of the
present invention. With many of these documents, the Applicant is
not aware of exact publishing dates. The citation of these
documents should thus not be considered an admission that they are
prior art; the Applicant will take the steps necessary to establish
whether these documents are prior art if necessary.
[0016] As mentioned above, a number of software programs currently
exist for programming individual motion control devices or for
aiding in the development of systems containing a number of motion
control devices.
[0017] The following is a list of documents disclosing presently
commercially available high-level software programs: (a) Software
Products For Industrial Automation, iconics 1993; (b) The complete,
computer-based automation tool (IGSS), Seven Technologies A/S; (c)
OpenBatch Product Brief, PID, Inc.; (d) FIX Product Brochure,
Intellution (1994); (e) Paragon TNT Product Brochure, Intec
Controls Corp.; (f) WEB 3.0 Product Brochure, Trihedral Engineering
Ltd. (1994); and (g) AIMAX-WIN Product Brochure, TA Engineering
Co., Inc. The following documents disclose simulation software: (a)
ExperTune PID Tuning Software, Gerry Engineering Software; and (b)
XANALOG Model NL-SIM Product Brochure, XANALOG.
[0018] The following list identifies documents related to low-level
programs: (a) Compumotor Digiplan 1993-94 catalog, pages 10-11; (b)
Aerotech Motion Control Product Guide, pages 233-34; (c) PMAC
Product Catalog, page 43; (d) PC/DSP-Series Motion Controller C
Programming Guide, pages 1-3; (e) Oregon Micro Systems Product
Guide, page 17; (f) Precision Microcontrol Product Guide.
[0019] The Applicants are also aware of a software model referred
to as WOSA that has been defined by Microsoft for use in the
Windows programming environment. The WOSA model is discussed in the
book Inside Windows 95, on pages 348-351. WOSA is also discussed in
the paper entitled WOSA Backgrounder: Delivering Enterprise
Services to the Windows-based Desktop. The WOSA model isolates
application programmers from the complexities of programming to
different service providers by providing an API layer that is
independent of an underlying hardware or service and an SPI layer
that is hardware independent but service dependent. The WOSA model
has no relation to motion control devices.
[0020] The Applicants are also aware of the common programming
practice in which drivers are provided for hardware such as
printers or the like; an application program such as a word
processor allows a user to select a driver associated with a given
printer to allow the application program to print on that given
printer.
[0021] While this approach does isolates the application programmer
from the complexities of programming to each hardware configuration
in existence, this approach does not provide the application
programmer with the ability to control the hardware in base
incremental steps. In the printer example, an application
programmer will not be able to control each stepper motor in the
printer using the provided printer driver; instead, the printer
driver will control a number of stepper motors in the printer in a
predetermined sequence as necessary to implement a group of high
level commands.
[0022] The software driver model currently used for printers and
the like is thus not applicable to the development of a sequence of
control commands for motion control devices.
OBJECTS OF THE INVENTION
[0023] From the foregoing, it should be clear that one primary
object of the invention is to provide improved systems and methods
for moving objects.
SUMMARY OF THE INVENTION
[0024] The present invention may be embodied as a system for
communicating with at least one motion control device, the system
comprising a set of software drivers, a motion control component,
and a network protocol. At least one software driver is selectable
and associated with at least one motion control device. The motion
control component exposes component functions for commanding at
least one selected motion control device based on at least one
selected software driver and the exposed component functions. The
component functions exposed by the motion control component may be
used through the network protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
[0025] FIG. 1 is a system interaction map of a motion control
system constructed in accordance with, and embodying, the
principles of the present invention;
[0026] FIG. 2 is a module interaction map of a motion control
component of the system shown in FIG. 1;
[0027] FIG. 3 is an object interaction map of the component shown
in FIG. 2;
[0028] FIGS. 4 through 8 are scenario maps of the component shown
in FIG. 2;
[0029] FIG. 9 is an interface map of the component shown in FIG.
2;
[0030] FIG. 10 is a data map showing one exemplary method of
accessing the data necessary to emulate extended driver functions
using core driver functions;
[0031] FIG. 11 is a module interaction map of the driver portion of
the system shown in FIG. 1;
[0032] FIG. 12 is an object interaction map of the driver portion
shown in FIG. 11;
[0033] FIGS. 13 through 20 are scenario maps related to the driver
shown in FIG. 11;
[0034] FIG. 21 is an interface map for the driver shown in FIG.
11;
[0035] FIG. 22 is a module interaction map of the streams used by
the system shown in FIG. 1;
[0036] FIG. 23 is an object interaction map of the streams shown in
FIG. 22;
[0037] FIGS. 24 through 32 are scenario maps of the streams shown
in FIG. 22;
[0038] FIG. 33 is an interface map of the objects comprising the
stream shown in FIG. 22;
[0039] FIG. 34 is a module interaction map of the driver stub
portion of the system shown in FIG. 1;
[0040] FIG. 35 is an object interaction map of the driver stub
shown in FIG. 34;
[0041] FIGS. 36 through 38 are scenario maps of the driver stub
shown in FIG. 34;
[0042] FIG. 39 is an interface map of the driver stub portion shown
in FIG. 34;
[0043] FIG. 40 is a module interaction map of the driver
administrator portion of the system shown in FIG. 1;
[0044] FIG. 41 is an object interaction map of the driver
administrator shown in FIG. 40;
[0045] FIGS. 42 through 49 are scenario maps relating to the driver
administrator shown in FIG. 40;
[0046] FIG. 50 is an interface map of the objects that comprise the
driver administrator shown in FIG. 40;
[0047] FIG. 51 is a module interaction map of the driver
administrator CPL applet portion of the system shown in FIG. 1;
[0048] FIG. 52 is an object interaction map of the driver
administrator CPL applet shown in FIG. 51;
[0049] FIGS. 53 through 57 are scenario maps related to the driver
administrator CPL applet shown in FIG. 51;
[0050] FIG. 58 depicts a Module Interaction-Map showing all binary
modules that interact with the driver and how they interact with
one another;
[0051] FIG. 59 depicts an Object Interaction-Map which corresponds
to the module interaction map of FIG. 58 expanded to display the
internal C++ objects making up the language driver 44, and how
these objects interact with one another;
[0052] FIGS. 60-65 depict a number of Scenario Maps that display
the interactions taking place between the C++ objects involved
during certain processes;
[0053] FIG. 66 depicts an interface map that describes the
interfaces exposed by the language driver component 44, all data
structures used, and the definitions of each C++ class used;
and
[0054] FIG. 67 depicts a table illustrating how a typical database
employed by the language driver 44 may be constructed.
DETAILED DESCRIPTION OF THE INVENTION
[0055] Referring now to the drawing, depicted therein at 10 in FIG.
1 is a motion control system constructed in accordance with, and
embodying, the principles of the present invention. This system 10
comprises a personal computer portion 12 having a hardware bus 14,
a plurality of motion control hardware controllers 16a, 16b, and
16c, and mechanical systems 18a, 18b, and 18c that interact with
one or more objects (not shown) to be moved.
[0056] The personal computer portion 12 of the system 10 can be any
system capable of being programmed as described herein, but, in the
preferred embodiment, is a system capable of running the Microsoft
Windows environment. Such a system will normally comprise a serial
port in addition to the hardware bus 14 shown in FIG. 1.
[0057] The hardware bus 14 provides the physical connections
necessary for the computer 12 to communicate with the hardware
controllers 16. The hardware controllers 16 control the mechanical
system 18 to move in a predictable manner. The mechanical system 18
comprises a motor or the like the output shaft of which is coupled
to the object to be moved. The combination of the hardware
controllers 16a, 16b, and 16c and the mechanical systems 18a, 18b,
and 18c forms motion control devices 20a, 20b, and 20c,
respectively.
[0058] The hardware bus 14, hardware controllers 16, and mechanical
systems 18 are all well-known in the art and are discussed herein
only to the extent necessary to provide a complete understanding of
the present invention.
[0059] The personal computer portion 12 contains a software system
22 that allows an application user 24 to create software
applications 26 that control the motion control devices 20.
[0060] More particularly, based on data input by the user 24 and
the contents of the application program 26, the software system 22
generates control commands that are transmitted by one or more
streams such as those indicated at 28a, 28b, 28c, and 28d. The
streams 28 transmit control commands incorporating the hardware
specific command language necessary to control a given motion
control device to perform in a desired manner. As will be discussed
in more detail below, the streams 28 implement the communication
protocol that allows the control commands to reach the appropriate
motion control device 28 via an appropriate channel (i.e., PC bus,
serial port).
[0061] Using the system 22, the application program 26 is developed
such that it contains no code that is specific to any one of the
exemplary hardware controllers 16. In the normal case, the
application program 26, and thus the user 24 that created the
program 26, is completely isolated from the motion control devices
20. The user 24 thus need know nothing about the hardware specific
command language or communication protocol associated with each of
these devices 20; it may even be possible that the command language
of one or more of the hardware controllers 16 was not defined at
the time the application program 26 was created.
[0062] The software system 22 comprises a combination of elements
that allow the application program 26 to be completely isolated
from the hardware controllers 16. In the following discussion, the
framework of the software system 22 will be described in terms of a
method of moving an object and/or a method of generating control
commands. After this general discussion, each component of the
system 22 will be described in detail in a specific operating
environment.
I. Method of Generating Control Commands for Controlling a Motion
Control Device to Move an Object
[0063] Initially, it should be noted that, in most situations, the
method described in this section will normally but not necessarily
involve the labors of at least two and perhaps three separate
software programmers: a software system designer; a hardware
designer familiar with the intricacies of the motion control
device; and a motion control system designer. The application user
24 discussed above will normally be the motion control system
designer, and the roles of the software system designer and
hardware designer will become apparent from the following
discussion.
[0064] The software system designer develops the software system
22. The software system designer initially defines a set of motion
control operations that are used to perform motion control. The
motion control operations are not specifically related to any
particular motion control device hardware configuration, but are
instead abstract operations that all motion control device hardware
configurations must perform in order to function.
[0065] Motion control operations may either be primitive operations
or non-primitive operations. Primitive operations are operations
that are necessary for motion control and cannot be simulated using
a combination of other motion control operations. Examples of
primitive operations include GET POSITION and MOVE RELATIVE, which
are necessary for motion control and cannot be emulated using other
motion control operations. Non-primitive operations are motion
control operations that do not meet the definition of a primitive
operations. Examples of non-primitive operations include CONTOUR
MOVE, which may be emulated using a combination of primitive motion
control operations.
[0066] Given the set of motion control operations as defined above,
the software system designer next defines a service provider
interface (SPI) comprising a number of driver functions. Driver
functions may be either core driver functions or extended driver
functions. Core driver functions are associated with primitive
operations, while extended driver functions are associated with
non-primitive operations. As with motion control operations, driver
functions are not related to a specific hardware configuration;
basically, the driver functions define parameters necessary to
implement motion control operations in a generic sense, but do not
attach specific values or the like to these parameters. The SPI for
the exemplary software system 22 is attached hereto as Appendix
A.
[0067] The software system designer next defines an application
programming interface (API) comprising a set of component
functions. For these component functions, the software system
designer writes component code that associates at least some of the
component functions with at least some of the driver functions. The
relationship between component functions and driver functions need
not be one to one: for example, certain component functions are
provided for administrative purposes and do not have a
corresponding driver function. However, most component functions
will have an associated driver function. The API for the exemplary
software system 22 is attached hereto as Appendix B.
[0068] The overall software model implemented by the software
program 22 thus contains an API comprising component functions and
an SPI comprising driver functions, with the API being related to
the SPI by component code associated with the component
functions.
[0069] In order for the system 22 to generate the control commands,
at least two more components are needed: the application program 26
and at least one software driver such as the drivers indicated at
30a, 30b, and 30c in FIG. 1.
[0070] The software drivers 30 are normally developed by a hardware
designer and are each associated with a single motion control
device. The hardware designer writes driver code that dictates how
to generate control commands for controlling the motion control
device associated therewith to perform the motion control
operations associated with at least some of the driver
functions.
[0071] In the exemplary software system 22, the software drivers
30a, 30b, and 30c are associated with the motion control devices
20a, 20b, and 20c, respectively. As a software driver exists for
each of the motion control devices 20a, 20b, and 20c, these devices
20a, 20b, and 20c form a group of supported motion control
devices.
[0072] A careful review of the framework of the software system 22
as described above will illustrate that, of all the components of
this system 22, only the software drivers 30 are hardware
dependent.
[0073] The motion control system designer, normally also the user
24, develops the application program 26. The application program 26
comprises a sequence of component functions arranged to define the
motion control operations necessary to control a motion control
device to move an object in a desired manner. The application
program 26 is any application that uses the system 22 by
programming the motion control component 35. Applications may
program the system 22 either through OLE Automation or by using any
of the custom OLE interfaces making up the API.
[0074] As mentioned above, the component code associates many of
the component functions with the driver functions, and the driver
functions define the parameters necessary to carry out the motion
control operations. Thus, with appropriately ordered component
functions, the application program 26 contains the logic necessary
to move the object in the desired manner.
[0075] Once the application program 26 has been written and the
software drivers 30 have been provided, the user 24 selects at
least one motion control device from the group of supported motion
control devices 20a, 20b, and 20c. Using a driver administrator
module 32, the user 24 then selects the software driver associated
with the selected motion control device. This driver administrator
module 32 is used to install, uninstall, register, and setup each
stream.
[0076] As currently implemented, the driver administrator 32 allows
only one software driver to be selected. In future versions of the
software system 22, the driver administrator will allow the user to
select one or more software drivers.
[0077] The software system 22 thus generates control commands based
on the component functions contained in the application program 26,
the component code associated with the component functions, and the
driver code associated with the selected software driver 28.
[0078] As the control commands are being generated as described
above, they may be directly transmitted to a motion control device
to control this device in real time or stored in an output file for
later use. The software system 22 employs the streams 28 to handle
the transmission of the control commands to a desired destination
thereof.
[0079] In the exemplary system 22, the destinations of the control
commands may be one or more of an output file 34 and/or the
controllers 16. Other possible destinations include a debug monitor
or window or other custom output mechanism defined for a specific
situation. The software system designer, or in some cases the
hardware system designer, will write transmit stream code for each
stream 28 that determines how the control commands are to be
transferred to a given one of the control command destinations 16
and 34. Using the driver administrator 32, the user 24 selects one
or more of the control command destinations 16 and 34, and, later
when run, the system 22 transfers the control commands to the
selected control command destination 16 and/or 34 based on the
transmit stream code in the stream 28 associated with the selected
control command destination 16 and/or 34.
[0080] Many control command destinations such as 16 and 34 are
capable of transmitting data back to the system 22. Data
transmitted from a control command destination back to the system
22 will be referred to as response data. The software system
designer thus further writes data response stream code for each of
the streams 28a, 28b, and 28c that determines how response data is
transmitted from the controllers 16 to the system 22. The system 22
thus processes the response data sent by the controllers 16 based
on the data response stream code contained in the streams 28.
[0081] Referring again to FIG. 1, this Figure shows that the system
22 further comprises a motion control component 35 and a driver
stub module 36. The motion control component module 35 is the
portion of the software system 22 that relates the component
functions to the driver functions. The motion control component
module 35 thus contains the component code that makes the
association between the component functions contained in the
application program 26 and the driver functions.
[0082] The driver stub module 36 is not required to implement the
basic software model implemented by the system 22, but provides the
system 22 with significantly greater flexibility to accommodate
diverse motion control hardware configurations with minimal
effort.
[0083] More particularly, when the driver stub module 36 is
employed, the hardware designer need not develop driver code to
implement all of the driver functions; to the contrary, the
hardware designer must write driver code for implementing the core
driver functions but need not write driver code to implement the
extended driver functions. The software system designer provides
the motion control driver stub 36 with stub code that identifies
the combinations of core driver functions that are employed to
emulate the functionality of extended driver functions.
[0084] The motion control component 24 will determine for the
selected software driver 30 which extended functions, if any, the
selected driver 30 supports. For extended functions that are not
supported, referred to herein as non-supported extended driver
functions, the motion control component 35 refers to the driver
stub module 36 to determine the appropriate combination of core
driver functions to emulate the functionality of the non-supported
extended driver functions. The system 22 thus generates the control
commands necessary to implement the non-supported extended driver
functions using the appropriate combination of core driver
functions.
[0085] The process of determining when extended driver functions
need to be emulated can be optimized by providing the motion
control component 35 with a function pointer table that contains a
pointer to each of extended functions. When building the function
pointer table, the motion control component 35 checks the selected
driver module 30 to see if it supports each extended function. If
the selected driver module 30 supports the extended function, the
motion control component module 35 stores a pointer to the
function, implemented by the selected driver module 30, in the
table location corresponding to the extended function. In the event
that the selected driver module 30 does not support the extended
function, the motion control component module 35 stores a pointer
to the extended function implementation located in the driver stub
module 36. The driver stub module 36 implementation of the extended
function contains calls to a plurality of core functions
implemented by the selected driver module 30.
[0086] Therefore, the driver stub module 36 allows the motion
control system designer to use, with minimal time and effort by the
hardware designer, a working software driver 28 that contains
driver code to implement only the core functions. The software
driver 28 developed to implement the core driver functions can then
be improved by developing driver code to implement extended driver
functions as desired.
[0087] The use of driver code specifically designed to implement
extended driver functions is, in general, preferable to relying on
the driver stub module 36 to emulate the extended driver functions;
driver code specifically written to implement an extended driver
function will almost always obtain a more optimized implementation
of the driver function than the emulation of that driver function
with a combination of core driver functions.
[0088] Referring again for a moment to FIG. 1, this Figure
illustrates that the system 22 additionally comprises a driver
administrator CPL applet 38 and a DDE server 40. The driver
administration CPL applet 38 generates the user interface through
which the user 24 communicates with the driver administrator module
32. The DDE server 40 provides the software interface through which
the application program 26 communicates with the motion control
component module 35.
II. Motion Control Component
[0089] The motion control component 35 will now be described in
further detail with reference to FIGS. 2-10. The motion control
component 35 is used by every application programming the system 22
to perform motion control operations. The major set of the API is
implemented by this component. When operating, the motion control
component 35 interacts with the driver administrator 32, to get the
current driver, and the driver 30 and driver stub 36, to carry out
motion control operations. Applications, using system 22, only
interact with the motion control component 35.
[0090] This section describes the design of the motion control
component 35 in three main parts. First, all binary modules that
affect the component 35 are described along with their interactions
with the component 35. Next, the module interaction-map is drawn in
more detail to show the interactions between all C++ objects used
to implement the motion control component 35. Next, the object
interaction-map is tested by displaying the specific interactions
that take place during certain, key process that the component 35
is requested to perform.
[0091] The module interaction-map shown in FIG. 2 displays all
binary modules and their interactions with the motion control
component 35. As can be seen from the module interaction-map,
applications only communicate with the motion control component 35.
From this point, the component 35 coordinates all interactions
between the driver administrator 32, driver 30, and driver stub 36
components.
[0092] Breaking the module interaction-map and adding the
interactions taking place between all C++ objects used to implement
the motion control component 35, produces the object
interaction-map shown in FIG. 3.
[0093] Each object in the diagram is described as follows. The
CCmpntDisp object is the dispatch object used to dispatch exposed
interface methods. During the dispatch process, all raw data is
converted into the appropriate C++ form. For example, collections
of data passed between OLE components is usually packaged in a raw
block of memory. The CCmpntDisp object takes care of packing
outgoing data and unpacking incoming data. Data packing involves
converting the data between a raw and native C++ format.
[0094] The CDriverAdmin object is used to communicate directly with
the driver administrator component. All OLE related details are
encapsulated within this class.
[0095] The CDriverMgr object is used to control all unit mapping
taking place before calling the appropriate Driver function. The
CUnitMapper object is used to do the actual mapping between
units.
[0096] The CUnitMapper object is used to map units between the Part
Coordinate System (PCS) and the Machine Coordinate System (MCS).
Both directions of unit mapping are done by this object.
[0097] The CDriver object is used to build the SPI table containing
both core and extended Driver functions. Depending on the level of
driver support, the extended functions in the SPI table may point
to functions implemented in either the driver stub 36 or the driver
30.
[0098] The following discussion of FIGS. 4-8 describes all main
scenarios, or operations, that occur on the motion control
component 35. Each scenario-map displays all objects involved, and
the interactions that take place between them in the sequence that
they occur.
[0099] As shown in FIG. 4, before an application can use the motion
control component 35, it must create an instance of the object,
using the CoCreateInstance OLE function, and then initialize the
instance calling the exposed Initialize custom interface method
implemented by the component 35. FIG. 4 displays the sequence of
events that take place when the Initialize method is called.
[0100] During initialization, the following steps occur. First the
application must create an instance of the motion control component
35 by calling the standard OLE function CoCreateInstance. Once
loaded, the application must call the component 35's exposed
Initialize method. When first loaded, the component 35 loads any
registration data previously stored. Next, the component 35 directs
the CCmpntDisp to initialize the system. The CCmpntDisp directs the
CDriverAdmin to get the current driver(s) to use. The CDriverAdmin,
first, loads the driver administrator 32 using the standard OLE
CoCreateInstance function. Next, it initializes the driver
administrator. Then, it queries the driver administrator for the
driver(s) to use and their SPI support information. Finally, the
driver administrator returns the driver(s) and the support
information to the component 35, and releases all interfaces used
from the driver administrator component 32.
[0101] Once receiving the active driver(s) 30 and their support
information, the motion control component 35 passes the driver(s)
30 to the CDriverMgr and directs it to initialize the system.
During its initialization, the CDriverMgr initializes the
CUnitMapper. Also while initializing, the CDriverMgr initializes a
CDriver for each driver used. After initializing each CDriver, the
support information is used to build each SPI table inside each
CDriver object. When building the SPI table, all core and supported
extended SPI interfaces are queried from the driver. Also, when
building the SPI table, the CDriver queries all interfaces, not
supported by the driver 30, from the driver stub 36.
[0102] Referring now to FIG. 5, once the motion control component
35 is initialized, the application 26 may perform operations on it.
There are two types of operations that may take place on the
component 35: Operations that use core Driver functions, and
operations that use extended Driver functions. Even though the
difference between the two is completely invisible to the
application using the component 35, the internal interactions are
different between the two. The following discussion outline these
differences.
[0103] The following interactions take place when the component 35
performs an operation that uses core Driver functions only. First
the application must request the operation and pass all pertinent
parameters to the component 35. Next, the component 35 directs the
CCmpntDisp to carry out the operation. The CCmpntDisp then directs
the CDriverMgr to perform the operation and passes all pertinent
parameters to it. Before carrying out the operation, the CDriverMgr
uses the CUnitMapper to convert all units to the Machine Coordinate
System (MCS). Next, the CDriverMgr directs the CDriver object to
carry out the operation and passes the newly mapped parameters to
it. The CDriver object uses its internal SPI table to communicate
directly with the core Driver function implemented by the driver
component.
[0104] FIG. 6 shows the sequence of events that occurs when the
component 35 is directed to carry out an operation that happens to
use extended SPI not supported by the driver 30. The following
steps occur when the operation is requested.
[0105] First the application must request the operation and pass
all pertinent parameters to the component 35. Next, the component
35 directs the CCmpntDisp to carry out the operation. The
CCmpntDisp then directs the CDriverMgr to perform the operation and
passes all pertinent parameters to it. Before carrying out the
operation, the CDriverMgr uses the CUnitMapper to convert all units
to the Machine Coordinate System (MCS). Next, the CDriverMgr
directs the CDriver object to carry out the operation and passes
the newly mapped parameters to it. The CDriver object uses its
internal SPI table to communicate directly with the core Driver
function implemented by the driver component.
[0106] As briefly discussed above, when using the system 22, there
are several types of units and two different coordinate systems
used. The process of unit mapping involves converting measurements
between the Part and Machine coordinate systems. FIG. 7 illustrates
this process, and the following steps occur when the operation is
requested.
[0107] First the application must request the operation and pass
all parameters to the component 35. Note, all parameters are in the
PCS. Next, the component 35 directs the CCmpntDisp to carry out the
operation. The CCmpntDisp directs the CDriverMgr to carry out the
operation and passes the PCS parameters to it. The CDriverMgr takes
all measurements and uses the CUnitMapper to convert them to the
MCS. The newly mapped parameters are then passed to the Cdriver.
The CDriver directs either the driver or the driver stub component
to carry out the operation.
[0108] When the application is finished using the motion control
component 35 it directs the component 35 to free all of its
resources by calling its exposed Release method. This process is
depicted in FIG. 8. During the clean-up process, the following
steps occur.
[0109] First the application must direct the component 35 to
release all of its resources by calling its Release method. When
invoked, the component 35 passes the call on to the CCmpntDisp
object. The CCmpntDisp object directs the CDriverMgr to release any
resources it is using. The CDriverMgr directs each CDriver object
to release any of its resources, then deletes the CDriver objects.
First, the CDriver object releases any interfaces it is using from
the driver component. Then, the CDriver object releases any
interfaces it is using from the driver stub component.
[0110] FIG. 9 is an interface map related to the motion control
component 35. FIG. 10 is a data map showing how data relating to
the whether extended driver functions need to be emulated is
stored. Attached hereto as Appendix C is a document that describes
the actual OLE Interfaces exposed, the definitions of the data
structures used when passing data around, and the definitions of
each class used internally by the motion control component 35.
III. Software Drivers
[0111] The driver 30 is used by both the driver administrator 32
and the component 35. Its main purpose is to implement
functionality that generates motion control commands for the
specific hardware supported. For example, the AT6400 driver, used
to control the Compumotor AT6400 motion control hardware, generates
AT6400 command codes. During the initialization phase of the system
22, the driver administrator 32 communicates with each driver 30,
allowing the user to add, remove, or change the configuration of
the driver. When an application, using the system 22, is run, the
component 35 communicates with the driver 30 directing it to carry
out the appropriate motion control operations.
[0112] This section describes the complete design of a generic
driver 30. All drivers are designed from the base design described
in this manual. This section is divided into three parts. First, a
module interaction-map that describes all binary modules that
interact with the driver 30 is discussed. Next, the module
interaction-map is drawn as an object interaction-map, where all
the internals of the driver are exposed. In this map, all C++
objects, making up the driver, and their interactions are shown.
Next, several scenario-maps are drawn. Each scenario-map displays
the interactions taking place between the C++ objects involved
during a certain process. Finally, this section describes the
interfaces exposed by the driver component, all data structures
used, and the definitions of each C++ class used.
[0113] Referring now to FIG. 11, the module interaction-map
displays all binary modules and their interactions with the driver
30. There are two modules that interact directly with the driver:
the motion control component 35, and the driver administrator 32.
The driver administrator 32 queries and changes the driver settings
and the component 35 directs the driver to carry out motion control
operations, such as moving to a certain location in the system.
Shown at 42 in FIG. 11 is the standard Windows registration
database, referred to herein as the registry.
[0114] Breaking the module interaction-map down into more detail by
including the interactions taking place between all C++ objects
used to implement the driver, produces the object interaction-map.
The object interaction-map for the driver 30 is shown in FIG.
12.
[0115] Each object in the diagram is described as follows.
[0116] CDriverDisp is the dispatch object used to dispatch exposed
interface methods. During the dispatch process, all raw data is
converted into the appropriate C++ form. For example, collections
of data passed between OLE components is usually packaged in a raw
block of memory. The CDriverDisp object takes care of packing
outgoing data and unpacking incoming data. Data packing involves
converting the data between a raw and native C++ format.
[0117] The CStreamMgr object is responsible for managing the set of
streams registered with the driver. Streams, may be added, removed,
and enabled. Only enabled streams are sent data. The CLSID and
enabled status of each stream registered, is stored in the
registration database. When communicating to streams, the
CStreamMgr is used to send the command string to all enabled
streams.
[0118] The CCommandMgr object is used to build commands sent to the
stream, and extracting responses received from the stream. The
CCommandMgr is the controlling object that manages the CResponse,
CCommandList, and CStream objects.
[0119] The CCommandList object stores the complete list of commands
making up the motion control command language. Such commands may be
stored as text resources or in a text file.
[0120] The CCommand object builds command strings that are then
sent to the CStream. Each command built is a complete motion
control command string.
[0121] The CResponseList object builds CResponse objects that are
initialized with the parsing format for the expected response.
[0122] The CResponse object converts raw response strings, returned
by the CStream, and converts them into C++ data types. For example,
a response string containing position data may be converted into a
set of double values.
[0123] The CStream object is used to communicate directly with the
underlying stream component.
[0124] FIGS. 14-20 contain scenario maps that describe all main
scenarios, or operations, that occur on the driver 30. Each
scenario-map displays all objects involved, and the interactions
that take place between them in the sequence that they occur.
[0125] There are two types of operations that occur on the driver
30. First, the driver administrator 32 may initiate operations,
such as adding streams or configuring the driver. Next, the motion
control component 35 may initiate operations on the driver when an
application is actually running. The following discussion describes
each perspective, starting with the operations directed by the
Driver Administrator; all operations made on the driver by the
driver administrator are discussed in the order that they may occur
when using the driver.
[0126] Before a driver may be used, it must be registered in the
OLE system. In order to register a driver the driver administrator
first verifies that the module being registered is actually an
driver 30, then it calls the DLLRegisterServer exported function to
register the driver. Each module of the system 22 exports a
function called DLLGetModuleType. This function is used to verify
that the module is an driver 30 component. FIG. 13 displays the
interactions that take place when registering a driver.
[0127] During the registration process shown in FIG. 13, the
following steps occur. First, the driver administrator must load
the DLL, containing the stream component, verify that the module is
an driver 30. To do so, the driver administrator calls the
DLLGetModuleType function, exported by the driver. If the function
returns a value that contains the value XMC_DRIVER_MT in the high
byte, then the driver administrator proceeds and registers the
driver by calling its exported function, DLLRegisterServer. When
called, the implementation of the DLLRegisterServer writes all OLE
2.0 registration information to the Windows registration
database.
[0128] Referring now to FIG. 14, after the driver is registered,
the driver administrator can load the component 35 using the OLE
CoCreateInstance function. During the initialization process, the
driver loads all registration data and initializes both the
CDriverDisp and CStreamMgr C++ objects.
[0129] During initialization, the following steps occur.
[0130] Before loading the driver component, the driver
administrator must query the driver module for its CLSID. Calling
the driver's exported function, DLLGetCLSID, returns the CLSID.
Once it has the CLSID, the driver administrator may create an
instance of the driver by calling the standard OLE function
CoCreateInstance. When first loaded, the driver loads any
registration data previously stored. Next, the driver directs the
CDriverDisp object to initialize the system. When notified, the
CDriverDisp object initializes itself and then directs the
CStreamMgr to initialize itself. During its initialization, the
CStreamMgr loads all stream settings from the registration
database. For example, the CLSID and enabled state of all streams
previously registered with the driver, are loaded.
[0131] After initializing the driver, the driver administrator may
perform operations on it. For example, the driver administrator may
request the driver to add or remove a stream. FIG. 15 displays the
sequence of events occurring when the driver is requested to add a
new stream. When adding a stream, the following steps occur.
[0132] First the driver administrator directs the stream to add a
new stream and passes CLSID of the stream, to be added, to the
driver. The driver then passes the CLSID to the CDriverDisp object
and directs it to add the stream. The CDriverDisp object passes the
information on to the CStreamMgr and directs it to add the stream.
In the final step, the CStreamMgr assumes that the module is a
valid stream component 28 and adds the CLSID to the drivers set of
information in the registration database.
[0133] Another operation requested of the driver, after
initialization, is that of querying it for its current settings.
Before displaying information about the driver, like the name of
the hardware it supports, the driver administrator must query the
driver for the information. For example, FIG. 16 displays the
process of querying the driver for an enumeration of the streams
registered with it. When querying the driver for information, the
following steps occur.
[0134] First the driver administrator, calls the interface method
used to query the driver's stream enumeration. Next, the driver
directs the CDriverDisp to create the stream enumeration. The
CDriverDisp object then directs the CStreamMgr to prepare the
stream enumeration. The CStreamMgr checks the registration database
and makes sure its internal state is in sync with the data stored
in the registry. Next, it sets a lock that will cause all stream
management operations, such as adding or removing streams, to fail.
The CStreamMgr prepares the list of streams and loads them into
memory using the CStream object. The CStream object loads the
stream component using the OLE CoCreateInstance API.
[0135] After the driver administrator is done using the driver, it
must release the driver by calling its exposed Release method.
Calling this method, directs the driver to release all resources
used. FIG. 17 displays the process of releasing the driver
component. During the clean-up process, the following steps
occur.
[0136] First the driver administrator must direct the driver
component to clean itself up by calling its Release method. When
invoked, the driver component passes the call on to the CDriverDisp
object. The CDriverDisp object then directs the CStreamMgr to save
all data. The CStreamMgr saves all data, including the state of
each stream, in the registration database. Finally, the driver
saves all internal data in the registration database.
[0137] After a driver is successfully installed into the system 22
and configured using the driver administrator, it is ready for use
by the motion control component 35. The component 35 uses the
driver 30 when performing motion control operations requested from
the application using the component 35. The following discussion
describes the component 35 directed operations that can take place
on the driver.
[0138] Before using the driver, it must be initialized by the
component 35. This operation is different from the driver
initialization taking place on the driver when used by the driver
administrator because the system must be prepared for sending and
receiving commands. In order to prepare for the data communication,
the stream must be initialized and then opened. FIG. 18 describes
the initialization process. The following steps occur during the
initialization process.
[0139] First the component 35 must direct the driver to initialize
itself. This is usually a two step process. In the first step, the
component 35 creates and instance of the driver using the standard
OLE CoCreateInstance function. Next, the Initialize method, exposed
by the driver, is called to prepare the driver for data
transmissions. When the Initialize method is called, the driver
first loads any internal data stored in the registration database
42. Next, the driver directs the CDriverDisp to initialize the
internal system. The CDriverDisp then directs the CStreamMgr to
initialize the streams. Next, the CStreamMgr loads all data from
the registration database, including the set of all CLSID's and
enabled status' for all streams registered with the driver. Then
the CStreamMgr loads each enabled stream by creating a new CStream
object for each enabled stream. When creating each CStream object,
the CLSID for the underlying stream is passed to the CStream
object. When each CStream object is created and attached to a
stream component it loads the component 35 by calling the standard
OLE CoCreateInstance function. Once the CStreamMgr is done, the
CDriverDisp directs the CCommandMgr to initialize itself. During
its initialization process, the CCommandMgr initializes and loads
the CCommandList. Also, when the CCommandMgr is initializing, it
loads the CResponseList corresponding to the CCommandList.
[0140] Once the system is initialized, the motion control component
35 can direct the driver to carry out certain command operations.
Command operations are standard motion control operations such as
moving to a specific location in the system, or querying the system
for the current position. FIG. 19 describes the process of
commanding the driver to carry out a certain operation. When
commanding the driver to perform a certain operation the following
steps occur.
[0141] First, the component 35 directs the driver to perform the
operation, such as moving to a position or querying the system for
the current position. Next, the driver directs the CDriverDisp
object to perform the operation. The CDriverDisp object then
directs the CCommandMgr to build the appropriate command. Any
parameters related to the command are passed to the CCommandMgr.
For example, when directing the driver to move to a certain
position, the position information is passed to the CCommandMgr.
Next, the CCommandMgr requests the CResponseList to create a
CResponse object. The CResponseList looks up the response format
and uses it to create a new CResponse object that is returned to
the CCommandMgr. Then, the CCommandMgr directs the CCommandList to
create the command. Any parameters related to the command are
passed to the CCommandList. The CCommandList creates a new CCommand
object, looks up the raw command string, and passes it and the
command parameters to the CCommand object who then builds the
command string.
[0142] The CCommandMgr, then passes the CCommand object, returned
by the CCommandList, and the previously created CResponse object to
the CStreamMgr object. The CStreamMgr object is directed to process
the objects. The CStreamMgr passes the CCommand and CResponse
objects to all enabled CStream objects. The CStream object queries
the CCommand object for the full command string in raw text form.
The raw text command is passed to the stream component. Next, the
CStream object waits for the response, then reads the raw text
response into a buffer. The raw text response is then passed to the
CResponse object. Next the CRETONNE object is returned to the
CStreamMgr, who returns it to the CCommandMgr, who returns it to
the CDriverDisp object. Eventually the CResponse returns to the
CDriverDisp object, who then directs the CResponse to convert the
response into a generic C++ type. The generic type is returned to
the motion control component 35.
[0143] Once the component 35 is finished using the driver, the
driver must be released by calling its Release method. Releasing
the driver frees all resources used by the driver. FIG. 20
describes the process of releasing the driver. The following steps
occur when cleaning up and freeing all resources used by the
driver.
[0144] First, the component 35 must call the driver's Release
method. When called, the driver directs the CDriverDisp object to
release any resources used. The CDriverDisp then directs the
CStreamMgr to free any resources used. The CStreamMgr then frees
all active CStream objects. Each CStream object releases all stream
component interfaces used. Next the CDriverDisp directs the
CCommandMgr to free all of its resources. During its clean-up, the
CCommandMgr frees the CCommandList object. To complete its
clean-up, the CCommandMgr frees the CResponseList object.
[0145] Attached hereto as Appendix D is a document that describes
the actual OLE Interfaces exposed, the definitions of the data
structures used when passing data around, and the definitions of
each class used internally by the driver.
IV. Streams
[0146] This section describes the stream component 28 used as the
data transport layer between the driver 30 component and the
destination output location such as the motion control device 20
and/or the output file 34. For example, when using motion control
hardware that is connected to the PC Bus, the driver 30 Component
will communicate with the PC Bus stream component 28.
[0147] The design of a stream component 28 will be discussed in
three parts. First, a Module Interaction-Map describes the modules
that are involved, with respect to the stream, and how they
interact with one another. Next, the Object Interaction-Map breaks
the Module Interaction-Map down into a more detailed view that not
only displays the interactions occurring between modules, but also
the interactions taking place between the C++ objects within the
stream component 28. Then, the Object Interaction-Map is "tested"
by running it through several Scenario-Maps. Each Scenario-Map
displays the object interactions taking place during a certain
operation.
[0148] The Module Interaction-Map shown in FIG. 22 displays all
modules that interact with the stream component 28. Interactions
begin from two different perspectives. First, the driver
administrator 32 interacts with the stream component 28 when
installing, removing, and configuring the stream. Next, when used,
each driver 30 interacts with the stream while sending and
retrieving data to and from the destination. For example, when a
driver writes data to a text file stream, the stream takes care of
writing the data out to the file. Or, if the driver reads data from
a PC Bus stream, the stream does the actual read from the hardware
and passes the data back to the driver.
[0149] Drivers only communicate with streams that have been
specifically connected to the driver. Once connected, the stream is
used to communicate with the destination object, like the PC Bus,
serial I/O connection, text file, or debug monitor.
[0150] The stream component 28 shown in FIG. 22 is the object that
operates as the data transport layer for each driver. Each stream
has a different target that defines the type of the stream. The
following are the current stream targets. [0151] PC Bus/WinNT--This
Windows NT stream uses a Windows NT .SYS device driver to
communicate directly with the motion control hardware connected to
the PC Bus. [0152] PC Bus/Win95--This Windows 95 stream uses a
Windows 95 V.times.D to communicate directly with the motion
control hardware connected to the PC Bus. [0153] PC Bus/Win
3.1--This Windows 3.1 stream communicates directly with the motion
control hardware connected to the PC Bus. [0154] Serial--This
stream uses the COMM API to communicate with the motion control
hardware connected to the serial port. [0155] Text File--This
stream is write-only and sends all data to a text file. [0156]
Debug Monitor--This stream is write only and sends all data to the
debug monitor. [0157] Custom--This is a custom stream that sends
data to an unknown location.
[0158] Similar to the Module Interaction-Map, the Object
Interaction-Map displays interactions between modules. In addition,
this map, shows all interactions taking place between each C++
object within the stream component 28. FIG. 23 is the Object
Interaction-Map for the stream component 28.
[0159] Each object in the diagram is described as follows. The
CStreamDisp object is the dispatch object used to dispatch exposed
interface methods. During the dispatch process, all raw data is
converted into the appropriate C++ form. For example, collections
of data passed between OLE components is usually packaged in a raw
block of memory. The CStreamDisp object takes care of packing
outgoing data and unpacking incoming data. Data packing involves
converting the data between a raw and native C++ format.
[0160] The CRegistryMgr object takes care of managing all data
stored in the registration database. Since many streams of the same
type may exist at the same time, each stream is assigned a handle.
The handle assigned, is used by the stream to look up the location
it uses to load and store data in the registration database, much
as an library index is used to locate a library book.
[0161] All input and output is funnelled through the CIOMgr
manager. Management of input and output operations consists of
buffering data and controlling primitives used to transport data to
and from the target location.
[0162] The CIOHAL object is the input/output hardware abstraction
layer. With in this object lay all hardware dependent code such as
calls to inp and outp. Each different type of stream contains a
different implementation of this object.
[0163] Scenario-Maps are specialized Object Interaction-Maps that
display how each module and the objects inside the stream component
interact with one another during the operation described by the
map. The Scenario-Maps in FIGS. 24-32 are broken into two different
categories; those that are initiated by the driver administrator
32, and those that are initiated by the driver 30.
[0164] Operations directed by the driver administrator are usually
related to initializing, uninitializing, and configuring the
stream. The following sections describe all operations, directed by
the driver administrator, that take place on the stream.
[0165] Before a stream component can be used by anyone, it must be
registered in the Windows registration database. Registration is a
standard OLE 2.0 operation required in order to use any OLE 2.0
component, such as the stream component. FIG. 24 describes this
process. During the registration process, the following steps
occur.
[0166] First, the driver administrator must load the DLL,
containing the stream component, verify that the module is an
stream component 28. To do so, the driver administrator calls the
DLLGetModuleType function, exported by the stream. If the high byte
in the return value contains the value XMC_STREAM_MT, then the
driver administrator proceeds and registers the stream by calling
its exported function, DLLRegisterServer. When called, the
implementation of the DLLRegisterServer writes all OLE 2.0
registration information to the Windows registration database.
[0167] After the stream component is successfully registered, it is
ready for initialization. During initialization, the stream
component not only initializes itself, but also initializes any
device drivers used by registering the driver with the operating
system. For example, the Windows NT stream component registers the
Windows NT .SYS driver with Windows NT and starts the service. FIG.
25 describes this process. During initialization, the following
steps occur.
[0168] First the driver administrator must direct the stream to
initialize itself. When making this call, the name and location of
the driver used, and the handle of the stream are passed into the
method as arguments. Once directed to initialize itself, the stream
component calls the CStreamDisp and directs it to initialize the
system. The CStreamDisp object then directs the CRegistryMgr to
load all pertinent data for the stream using the handle passed to
it. The CRegistryMgr loads all data from the registration database.
After all information is loaded from the registry, the CStreamDisp
directs the CIOMgr to register the appropriate driver with the
operating system. The CIOMgr directs the CIOHAL to register the
driver, if appropriate. If running in Windows NT, the CIOHAL
registers the .SYS driver with the Windows NT operating system and
starts the driver. If running in Windows 95, the V.times.D
integrity is verified with a quick, dynamic, load and unload.
[0169] After initializing the stream component, it may be queried
for its current settings or directed to set new settings. Since
both operations are very similar, only changing settings will be
described. Stream settings include data such as: port addresses,
IRQ levels, file names, etc. Any data needed to communicate with
the output/input target are included in the stream settings. FIG.
26 describes the process of changing the streams settings. During
the setup process, the following steps occur.
[0170] First the driver administrator directs the stream to use the
data passed to change its internal data. Once directed, the stream
component passes the interface method invocation to the CStreamDisp
object. The CStreamDisp object then directs the CRegistryMgr to
store the new settings. The CRegistryMgr stores the new values in
the registration database.
[0171] When the driver administrator is done using a stream
component, it must clean up the resources used. FIG. 27 describes
this process. During the clean-up process, the following steps
occur. First the driver administrator must direct the stream
component to clean itself up by calling its Release method. When
invoked, the stream component passes the call on to the CStreamDisp
object. The CStreamDisp object then directs the CRegistryMgr to
save all data. All persistent data is saved to the registration
database by the CRegistryMgr.
[0172] Driver directed operations occur when each driver 30 uses
the stream component 28 connected to it. Remember, each stream
component is used as the data transport layer. Each driver uses the
stream to transfer the motion control command data, it generates,
to the output target. Streams are also used to transfer data back
to the driver when read operations occur. Only certain streams are
readable.
[0173] Before the driver can perform operations on the stream, the
stream must be initialized. Initialization occurs in two steps.
First the OLE stream component must be loaded, and then once it is,
the stream must be explicitly initialized. FIG. 28 describes the
second portion of the initialization process. The following steps
occur during the initialization process.
[0174] First the driver must invoke the Initialize methods exported
by one of the stream interfaces. When calling Initialize, the
driver passes to the stream, the stream handle. Next, the stream
passes the directive on to the CStreamDisp object for dispatching.
The CStreamDisp object first directs the CRegistryMgr to load all
settings stored in the location defined by the stream handle. The
CRegistryMgr reads in the data stored in the registry at the
handle. After the data is loaded, the CStreamDisp, directs the
CIOMgr to initialize itself. As part of its initialization, the
CIOMgr initializes the CIOHAL object that it is using.
[0175] Once a stream has been initialized, it must be opened.
Opening a stream places the stream in a state where it can pass
data between the driver and the target. FIG. 29 describes the
process of opening a stream. When opening a stream, the following
steps occur.
[0176] First the driver directs the stream to open itself, by
calling the Open exposed interface method. Once directed, the
stream passes the call on to the CStreamDisp object. Next, the
CStreamDisp object directs the CIOMgr to open the stream. At this
time, the CIOMgr prepares any buffers that will later be used when
transferring data through the stream. After the buffers are ready,
the CIOMgr directs the CIOHAL object to interact with the target
and open it. CIOHAL directly communicates with the target or with a
device driver and opens the stream. When operating with hardware
streams, the device driver, or Serial IO directly communicates with
the hardware and prepares it for operation.
[0177] After opening a stream, it is ready to perform data
transport operations. There are two main data transport operations
available: Reading data, and writing data. FIG. 30 describes the
process of writing data to the stream. When writing to the stream,
the following steps occur. First the driver directs the stream to
write data to the target and passes the data to the stream. Next,
the stream passes the data to the CStreamDisp object. The
CStreamDisp object passes the block of data to the CIOMgr and
directs it to write it to the target. The CIOMgr object either
passes the complete block of data to the CIOHAL object, or stores
the block in an internal buffer and then passes pieces of the
buffer to the CIOHAL object until the complete buffer is sent. The
CIOHAL object takes the data passed to it and either sends it
directly to the target, passes it to a device driver, or calls COMM
API to send the data to the Serial IO port. The device driver or
COMM API sends the data directly to the hardware controlled.
[0178] Certain streams, like the PC Bus and Serial IO streams,
return data after write operations occur on them. The data returned
may be specific to a previous request for data, or status
describing the success or failure of the previous write operation.
FIG. 31 describes the process of reading data from the stream. It
should be noted that not all streams are readable. Currently, the
only readable streams are the PC Bus and Serial streams. During the
operation of reading data from the target, the following steps
occur.
[0179] First the driver directs the stream to read data from the
target. The stream passes the call on to the CStreamDisp object.
The CStreamDisp object directs the CIOMgr to perform the read.
Depending on how the stream is implemented, the CIOMgr may either
make one call or multiple calls to the CIOHAL object. If multiple
calls are made, all data read is stored in CIOMgr internal buffers.
The CIOHAL object either directly communicates to the hardware,
uses the COMM API, or a device driver to read the data. If a device
driver or the COMM API are used, they directly communicate with the
hardware to read the data.
[0180] Once the driver is done using the stream, it must direct the
stream to clean-up all resources used. To do so, the driver calls
the standard Release method. FIG. 32 displays the sequence of
events taking place after the Release method is called. The
following steps occur when cleaning up and freeing all resources
used by the stream.
[0181] First the driver must call the stream's Release method.
Next, the stream directs the CStreamDisp object to release all
resources used. The CStreamDisp object then directs the CIOMgr to
free any resources used in buffers, etc. Next, the CIOMgr directs
the CIOHAL to free any resources used. During its clean-up and
depending on the type of stream, the CIOHAL will delete text files
used, close the debug monitor, shut-down the hardware, or direct
any device drivers to shut-down the hardware. If device drivers or
the COMM API are used, they direct the hardware to shut-down.
[0182] FIG. 33 depicts an interface map for the stream 28. Attached
hereto in Appendix E is a document that describes the actual OLE
Interfaces exposed, the definitions of the data structures used
when passing data around, and the definitions of each class used
internally by the stream.
V. Driver Stub Module
[0183] The driver stub module 36 is used to fill in the extended
Driver functions that the driver 30 is unable to support or
implement. By simulating the extended SPI, applications are able to
use a larger set of motion control functionality than would be
available if the application directly programmed the motion control
hardware. In order to implement the extended SPI, the driver stub
uses software algorithms that call core SPI interface methods
implemented by the driver 30. During the initialization of the
driver stub, the driver 30 to use is registered with the driver
stub.
[0184] This section describes all aspects of the driver stub 36 in
three basic parts. The first part of this section describes all
binary modules affecting the driver stub. Next, a more detailed
view, that includes all C++ objects used inside the driver stub, is
described. Then several processes that take place on the driver
stub are described.
[0185] The module interaction-map displays all binary modules and
their interactions with the driver stub 36. As can be seen from
FIG. 34, the driver stub is used by the component 35. More or less,
the driver stub acts as a helper to the component 35 by filling in
all extended Driver functionality possible.
[0186] By taking the module interaction-map in FIG. 34 and
displaying all interactions taking place with all C++ objects
implementing the driver stub, we produce what is called the object
interaction-map. FIG. 35 is the object interaction-map for the
driver stub 36 component.
[0187] Each object in the diagram is described as follows. [0188]
The CDriverStubDisp object is the dispatch object used to dispatch
exposed interface methods. During the dispatch process, all raw
data is converted into the appropriate C++ form. For example,
collections of data passed between OLE components is usually
packaged in a raw block of memory. The CDriverStubDisp object takes
care of packing outgoing data and unpacking incoming data. Data
packing involves converting the data between a raw and native C++
format. [0189] The CSPIMgr object is responsible for managing all
SPI issues such as managing the CSimpleDriver by directing it to
connect to the appropriate SPI core interfaces exposed by the
driver. [0190] The CSimpleDriver object is used to directly
communicate with the driver implementing the SPI core interfaces.
The CSimpleDriver only communicates with the core SPI interfaces
implemented by the driver.
[0191] The following discussion describes all main scenarios, or
operations, that occur on the driver stub 36. Each scenario-map
displays all objects involved, and the interactions that take place
between them in the sequence that they occur. All operations on the
driver stub originate from the motion control component 35. In
addition to the motion control component 35, the XMC Setup
Component interacts with the driver stub when installing the system
22. It should be noted that all scenarios below assume that the
driver stub 36 has already been registered in the OLE system.
Registering this component is the responsibility of the setup
application and setup component.
[0192] This discussion describes all operations made on the driver
stub by the motion control component 35. Each section is discussed
in the order that they may occur when using the driver.
[0193] As shown in FIG. 36, before using the driver stub 36, the
motion control component 35 must initialize it by creating an
instance of the driver stub, and then initializing the instance
created. Calling the standard OLE function CoCreateInstance
completes the first step. After an instance is created, the
component 35 must call the driver stub exposed Initialize interface
method. During initialization, the following steps occur.
[0194] The component creates an instance of the driver stub by
calling the standard OLE function CoCreateInstance. Once loaded,
the CLSID of the driver to use is passed to the driver stub when
calling its Initialize exposed interface method. When first loaded,
the driver loads any registration data previously stored. Next, the
component 35 passes the CLSID, of the driver to use, to the
CDriverStubDisp object and directs it to initialize the system. The
CDriverStubDisp object then directs the CSPIMgr to initialize
itself and passes the driver CLSID to it. The CSPIMgr passes the
CLSID to the CSimpleDriver and directs it to only query the core
SPI interfaces exposed by the driver. The CSimpleDriver loads an
instance of the driver then queries all core interfaces exposed by
the driver.
[0195] Once the driver stub is initialized, it is ready to perform
operations such as performing extended Driver functions. FIG. 37
describes the steps that occur when the component 35 directs the
driver stub to perform an extended SPI operation. The following
steps occur when the operation is requested.
[0196] First the component 35 must request the operation and pass
all pertinent parameters to the driver stub. Next, the driver stub
directs the CDriverStubDisp to handle the operation. The
CDriverStubDisp then directs the CSPIMgr to perform the SPI
extended function and passes the appropriate XMC_EXT_SPI identifier
as a parameter. The CSPIMgr calls the appropriate function
corresponding to the XMC_EXT_SPI identifier. The function simulates
the extended Driver function and calls the CSimpleDriver for core
operations. When directed, the CSimpleDriver performs SPI core
functions by directly calling the exposed interfaces implemented by
the driver.
[0197] When the motion control component 35 is finished using the
driver stub 36, it must release it by calling the exposed Release
method. Calling the Release method causes the driver stub to free
all the resources it uses. FIG. 38 displays this sequence of
events. During the clean-up process, the following steps occur.
[0198] First the component 35 must direct the driver stub to
release all of its resources by calling its Release method. When
invoked, the driver component passes the call on to the
CDriverStubDisp object. The CDriverStubDisp object then directs the
CSPIMgr to release any resources that it was using. The CSPIMgr
releases all resources including the CSimpleDriver object used.
When freed, the CSimpleDriver releases any interfaces used from the
driver.
[0199] FIG. 39 is an interface map of the driver stub module 36.
Attached hereto as Appendix F is a document that describes the
actual OLE Interfaces exposed, the definitions of the data
structures used when passing data around, and the definitions of
each class used internally by the driver.
VI. Driver Administrator Module
[0200] The driver administrator 32 is used from two different
perspectives. When the driver administrator Control Panel Applet 38
is used to configure the system, the applet directs the driver
administrator 32 to carry out the operations. The applet 38 simply
provides the user-interface, and the component 35 does the real
work of managing drivers and streams used with the system 22. Using
the driver administrator component with the control panel applet is
the first perspective on using the component 35.
[0201] In the second perspective, the motion control component 35
uses the driver administrator component to query for the current
set of enabled the driver 30. It should be noted that, currently,
only single driver operation is allowed. Clearly, the system 22 may
support multiple drivers that are virtualized. For example, if two,
four axis, drivers are installed, applications using the system
could act as though they were using an eight axis system.
[0202] This section describes the driver administrator 32 in three
main parts. First, all modules interacting with the driver
administrator component are described along with their
interactions. Next, the module interaction-map is expanded to
display all interactions taking place between the C++ objects used
to implement the driver administrator 32 Component. This
description is called the object interaction-map. Then, the object
interaction-map is tested by running it through several scenarios,
or scenario-maps. Each scenario-map displays the events and the
order in which they occur in a certain process taking place on the
driver administrator component.
[0203] The module interaction-map shown in FIG. 40 displays all
binary modules and their interactions with the driver administrator
32 Component. Both the driver administrator CPL 38 and the motion
control component 35 are the main modules that interact with the
driver administrator 32 Component.
[0204] The driver administrator CPL module 38 provides the
user-interface that allows the user to add, configure, and remove
drivers and streams in the system 22. The driver administrator 32
handles all driver and stream management. Even though the control
panel applet provides the user-interface, this module 32 does the
actual management work.
[0205] In addition, the driver administrator is used by the
component 35 to access the current driver(s) to use when carrying
out motion control operations. For example, if the AT6400 driver is
selected as the current driver when the component 35 queries the
driver administrator, the driver administrator returns the CLSID of
the AT6400 driver.
[0206] Taking the driver administrator 32, displayed in the module
interaction-map, and displaying all interactions occurring between
the C++ objects used to implement the administrator 34, produces
the object interaction-map therefor. The object interaction-map for
the driver administrator 32 is shown in FIG. 41.
[0207] Each object in the diagram is described as follows.
[0208] The CDriverAdminDisp object is the dispatch object used to
dispatch exposed interface methods. During the dispatch process,
all raw data is converted into the appropriate C++ form. For
example, collections of data passed between OLE components is
usually packaged in a raw block of memory. The CDriverAdminDisp
object takes care of packing outgoing data and unpacking incoming
data. Data packing involves converting the data between a raw and
native C++ format.
[0209] The CDriverInfoMap object is used to build the information
used by the driver administrator CPL 38 when displaying information
about each driver or stream.
[0210] The CModuleMgr object is responsible for managing all stream
and driver modules in the system. A list of all drivers registered
are stored persistently in the registration database by the
CModuleMgr. Each time a driver or stream is accessed the CModuleMgr
is used to get the module.
[0211] The CSimpleDriver object is used to directly communicate
with the driver component. All OLE specific details are
encapsulated within this object.
[0212] The CSimpleStream object is used to directly communicate
with the stream component. All OLE specific details are
encapsulated within this object.
[0213] FIGS. 42-49 describe all main scenarios, or operations, that
occur on the driver administrator 32. Each scenario-map displays
all objects involved, and the interactions that take place between
them in the sequence that they occur.
[0214] Referring now to FIG. 42, before using the driver
administrator component, it must be initialized. FIG. 42 describes
the process of initializing the driver administrator component from
either the driver administrator control panel applet or the motion
control component. During initialization, the following steps
occur.
[0215] First, either the control panel applet or the motion control
component must create an instance of the driver administrator
component by calling the standard OLE function CoCreateInstance.
Next, the exposed Initialize interface method must be called. When
the Initialize method is called, the driver administrator component
directs the CDriverAdminDisp to initialize the system. Next, the
CDriverAdminDisp directs the CModuleMgr to initialize itself and
any modules that it is managing. The CModuleMgr, first, loads all
information from the registration database. Then for each driver
registered, the CModuleMgr creates an instance of the driver by
calling the standard OLE function CoCreateInstance. Next, the
CModuleMgr calls each drivers Initialize method, passing to the
method the CLSID of the driver component to attach. The
CSimpleDriver attaches to the driver component by calling the
standard OLE function CoCreateInstance.
[0216] The driver administrator 32 can register both drivers and
streams. Registering drivers is very direct, since the driver
administrator manages the drivers registered in the system.
Registering streams, on the other hand, is more complex, since each
stream must be registered with a driver and the driver manages the
streams registered with it, not the driver administrator. The
following discussion describes the process of registering both
drivers and streams.
[0217] Registering a driver entails verifying that the module is
actually a driver, verifying that the driver can be loaded, and
storing the driver information in a persistent location. FIG. 43
describes this process. When registering a driver, the following
steps occur.
[0218] First, the driver administrator CPL passes the name of the
driver and directs the driver administrator component to register
it. Next, the driver administrator component passes the driver name
to the CDriverAdminDisp and directs it to register the module. The
CDriverAdminDisp directs the CModuleMgr to register the new driver.
The CModuleMgr creates a new CSimpleDriver and requests it to
register the driver. First the CSimpleDriver verifies that the
driver is valid by calling its DLLGetModuleType exported function.
If the function returns XMC_DRIVER_MT the CSimpleDriver then calls
the driver's exported function DLLRegisterServer to register the
module in the OLE system. Next the CLSID is queried from the module
by calling its exported DLLGetCLSID function. The CLSID returned is
then used to load the driver by calling the standard OLE function
CoCreateInstance. If the CSimpleDriver is successful, the
CModuleMgr stores the driver CLSID in the registration
database.
[0219] Registering a stream is similar to registering a driver, but
a little more complex, since each stream must be registered with a
specific driver. FIG. 44 displays the process of registering a
stream. When registering a stream, the following steps occur.
[0220] First, the driver administrator CPL passes the CLSID of the
driver and the filename of the stream to register with the driver,
to the driver administrator component. The driver administrator
component directs the CDriverAdminDisp to register the stream. The
CDriverAdminDisp object directs the CModuleMgr to register the
stream and passes the CLSID of the driver and the name of the
stream along to it. First, the CModuleMgr verifies that the CLSID
of the driver one of the registered drivers. If it is not, the
driver is registered as discussed above.
[0221] Next, the CModuleMgr creates a new CSimpleStream object and
directs it to verify and load the stream component. The
CSimpleStream first verifies that the module is actually an stream
component 28 by calling its exported DLLGetModuleType function. If
the function returns XMC_STREAM_MT, the CSimpleStream continues and
registers the stream component by calling its DLLRegisterServer
exported function. Finally, the CSimpleStream object queries the
new module for its CLSID by calling the module's exported
DLLGetCLSID function. The new CLSID is used, by the CSimpleStream,
to load the stream component using the standard OLE function
CoCreateInstance. If the CSimpleStream succeeds, the CLSID of the
stream is passed along to the CSimpleDriver who is directed to
register the stream. The CSimpleDriver passes the CLSID to the
driver component and directs it to register the stream.
[0222] The following discussion describes setting information in
either a driver or stream. When the user edits information in the
driver administrator control panel applet 38, the applet 38 directs
the driver administrator 32 to edit the settings for the stream or
driver being edited. The following discussion describes how this
configuration process works.
[0223] Editing the settings of a driver takes place when the user
changes the driver settings displayed in the driver administrator
CPL. Changing these settings causes the process described in FIG.
45 to occur within the driver administrator component. The
following steps occur when setting the driver configuration.
[0224] When driver settings are changed in the CPL 38, the driver
administrator CPL directs the driver administrator component to
make the appropriate changes to the driver corresponding to the
driver handle. A XMC_DRIVER_INFO structure is passed to the
component 35, describing the new values for the driver. The driver
administrator component takes the XMC_DRIVER_INFO structure and the
handle to the driver and passes the information to the
CDriverAdminDisp object, directing it to change the settings in the
driver. The CDriverAdminDisp object directs the CModuleMgr to edit
the driver corresponding to the driver handle. The CModuleMgr
locates the CSimpleDriver with the handle and directs it to change
its settings to those stored in the XMC_DRIVER_INFO structure. The
CSimpleDriver passes the XMC_DRIVER_INFO structure to the driver
component and directs it to change its settings.
[0225] As shown in FIG. 46, when the user edits stream settings in
the driver administrator CPL 38, the following steps occur.
[0226] After the user changes settings for the stream in the CPL,
the driver administrator CPL directs the driver administrator
component to change the stream's settings and passes a handle to
the driver containing the stream, a handle to the stream, and a
XMC_STREAM_INFO structure describing the new values. The driver
administrator component directs the CDriverAdminDisp object to
change the streams settings. The CDriverAdminDisp object directs
the CModuleMgr to change the settings of the stream corresponding
to the handle.
[0227] First, the CModuleMgr locates the driver corresponding to
the driver handle. Next, it requests the CSimpleDriver to change
the settings for the stream corresponding to the stream handle. The
CSimpleDriver searches for the stream corresponding to the stream
handle and directs it to change its settings to those stored in the
XMC_STREAM_INFO structure. The CSimpleStream directly communicates
with the stream component and directs it to change its settings to
those in the XMC_STREAM_INFO structure.
[0228] There are two different types of information that may be
queried from the driver administrator 32: the enumeration of all
drivers registered, and the driver information map. The motion
control component 35 uses the driver enumeration when selecting the
set of drivers to use and control during motion control operations.
The driver information map, on the other hand, is used by the
driver administrator CPL 38 to update the user-interface display
describing all drivers and streams registered in the system. The
following discussion describes the process of querying for both the
driver enumeration and the driver information map. Querying for the
driver enumeration occurs during the initialization of the motion
control component 35. When initializing, the component 35 must know
what drivers to use when performing motion control operations. The
driver administrator 32 Component is used for that very purpose.
Querying the driver enumeration just returns a pointer to the
IXMC_EnumDriver interface exposed by the driver administrator 32
Component. FIG. 47 displays the events that occur when using the
interface to get each driver in the enumeration. Using the
interface causes, the following steps occur.
[0229] First, the motion control component 35 queries the driver
administrator 32 Component for the next driver. Next, the driver
administrator 32 Component directs the CDriverAdminDisp to get the
next driver supported. The CDriverAdminDisp directs the CModuleMgr
to get the next driver. The CModuleMgr then directs the
CSimpleDriver to either return the CLSID or a pointer to the
Unknown interface for the driver, depending on the parameters of
the enumeration. If the CSimpleDriver is requested to return a
pointer to the IUnknown interface, the interface is queried from
the driver component.
[0230] Another set of information that may be queried from the
driver administrator 32 consists of the driver information map.
This data is used by the driver administrator CPL 38 when
displaying information describing the drivers and streams
registered in the system. As shown in FIG. 48, when querying the
system for the driver interface map, the following steps occur.
[0231] First, the driver administrator CPL 38 queries the driver
administrator 32 Component for the current driver information map.
When queried, the driver administrator component directs the
CDriverAdminDisp to create and load a CDriverInfoMap class. The
CDriverAdminDisp creates the CDriverInfoMap. Next, the
CDriverAdminDisp passes the CDriverInfoMap to the CModuleMgr and
directs it to load the information map. The CModuleMgr queries each
driver registered for its internal information. Each CSimpleDriver
communicates directly with the driver component and queries it for
all pertinent driver information. Next, the CModuleMgr queries each
driver for a list of all streams registered with the driver. Using
the stream enumeration, each CSimpleDriver creates an array of
CSimpleStream objects and returns the array to the CModuleMgr. For
each CSimpleStream object in each array, the CModuleMgr queries for
all pertinent stream information. Each CSimpleStream communicates
directly with the stream component and queries it for all
information describing the stream.
[0232] After the driver administrator CPL 38 or the motion control
component 35 are finished using the driver administrator 32, they
must release the component 35 to free any resources it was using.
FIG. 49 describes this process. When cleaning up after a call to
the Release method, the following steps occur.
[0233] First, either the driver administrator CPL 38 or the motion
control component 35 must direct the driver administrator 32
Component to release itself by calling its Release method. Next,
the driver administrator component directs the CDriverAdminDisp
object to free all resources used in the system. The
CDriverAdminDisp then directs the CModuleMgr to free any resources
that it is using. First, the CModuleMgr traces through all
CSimpleDriver objects, querying each for their CLSID and enabled
state. Next, each CSimpleDriver is freed. Each CSimpleDriver object
freed, frees all arrays of CSimpleStream objects registered with
it. When freed, each CSimpleStream object releases all interfaces
that it was using from the stream component. In its final clean-up,
each CSimpleDriver releases all interfaces that it was using from
the driver component. All CLSID and enabled state information is
stored persistently in the registration database.
[0234] FIG. 50 depicts an interface map for the driver
administrator 32. Also, attached hereto as Appendix G is a document
that describes the actual OLE Interfaces exposed, the definitions
of the data structures used when passing data around, and the
definitions of each class used internally by the driver
administrator 32 component.
VII. Driver Administrator CPL Applet
[0235] This document describes the design of the driver
administrator control panel applet 38 (CPL) that is used by the
user to add, configure, and remove both drivers 30 and stream
components 28 later used by the component 35 when directed to carry
out motion control operations. With regard to design, there are
three main types of "views" used to look at how the control panel
applet works.
[0236] First, a module interaction map shown in FIG. displays all
main executable and user-interactable items, or modules, that the
CPL uses and interacts with. For example, when a dialog is
displayed by the CPL executable, both the dialog and the CPL
modules are considered to interact with one another. Technically,
the dialog is not a module since it is a figment displayed on the
screen, but none the less, module interaction maps classify them as
such since they are key destination points for user-input.
[0237] Second, an object interaction map shown in FIG. 52 displays
all main objects making up the modules described in the module
interaction map. Objects consist of the actual instances of C++
classes defining each object. All interactions between the objects
are drawn out in this interaction map.
[0238] Finally, FIGS. 53-57 display a set of scenario maps are
drawn out using the object interaction map as a basis. Scenario
interaction-maps describe the interactions taking place during a
specific operation. Initialization, Adding a driver to the system,
and Viewing the support offered by a driver, are all examples of a
scenario interaction-map.
[0239] The design goals for the driver administrator 32 are the
following: [0240] 1. User-Interface separation--Implement all
user-interface elements used to control the driver administrator 32
Component. [0241] 2. Upgradable to OCX Client--Eventually each
driver and stream may implement all UI elements with an OCX that
then passes all input to the corresponding driver or stream. The
driver administrator CPL 38 must be designed in a way that is easy
to upgrade to become an OCX client. [0242] 3. Provide Stream
Independence--drivers 30 should not be required to use streams 28
in order to operate. The design of the driver administrator 32 must
make amends to ensure that it is not dependent on stream component
28 operations to operate. [0243] 4. Use Windows 95 UI--When ever
possible, Windows 95 UI elements should be used. For example,
TreeViews, ImageLists, Button Bars, Tab Dialogs and any other UI
elements should be put to use to ensure a Windows 95
look-and-feel.
[0244] The following discussion describes the module interaction
map for the control panel applet 38. A module is defined as either
an executable binary, an external data file, or a main
user-interface element used when interacting with the user. FIG. 51
is a drawing of all modules that interact with each other when
running the driver administrator control panel applet.
[0245] The driver administrator CPL 38 is a control panel applet.
And, a control panel applet is a special DLL that exports several
functions allowing the Windows Control Panel to communicate with
the applet.
[0246] The Driver Administrator Dialog is the main dialog that
appears when selecting the control panel applet icon from the
Windows Control Panel.
[0247] The Browse Dialog is used to query the user for a filename.
For example when adding a new stream or driver, the driver
administrator uses this dialog to ask the user for the location of
the new driver or stream to add.
[0248] The View Support Dialog displays the support provided by the
selected driver 30. Each driver may support a different set of
extended functionality. This dialog shows the user exactly how much
support is provided by each driver allowing them to determine which
functions within their application may not operate when using the
driver.
[0249] Unlike the Module Interaction-Map described above, the
Object Interaction-Map shown in FIG. 52 describes how the actual
instances of C++ objects interact with one another within each
module.
[0250] Other than showing that each dialog is managed by the
object, whose name is displayed in the dialog, the main difference
from the module IA-map are both the CComCPL and CDriverAdmin C++
objects. Both objects are described below.
[0251] As the description of each dialog class is fairly straight
forward and very similar to the dialog description above they will
not be described in this section. This section will describe all
other C++ objects.
[0252] The CComCPL is a C++ object that is generated by the
COMBuilder application from a template. It is used to handle all
Windows messages sent from the Control Panel Application.
[0253] The CDriverAdmin object is used to drive, control, and
manage the use of the driver administrator 32 Component. For
example, all OLE 2.0 interface management and data translation is
handled by this object. Data translation involves translating data
from a standard C++ format to a raw format that is handled easily
with the OLE 2.0 data transfer mechanisms.
[0254] Scenario Interaction-Maps are almost identical to object
interaction-maps but they only display the objects and interactions
taking part in a specific operation. Also, each interaction is
numbered by the sequence in which they occur while the operation is
running. The following discussion describes several key operations
that occur while running the driver administrator CPL 38
Applet.
[0255] Initialization occurs when the user first runs the CPL
Applet. During this process all other objects are initialized and
several modules are loaded. There are two steps that take place
during the initialization process: First the application is
initialized, and second the dialog is initialized with values
queried from the driver administrator 32 Component. The following
sections describe each.
[0256] Initializing the application, which is shown in FIG. 53,
occurs when the application is first run and the main dialog has
not yet been displayed. When initializing the application, the
following steps occur.
[0257] Through a Windows message, Windows notifies the CComCPL
object that the Control Panel Applet has just been loaded. CComCPL
then loads the CDriverAdminDialog and tells it to do any dialog
prepping before going modal. Next, CDriverAdminDialog loads any
settings stored in the Registration Database. For example, the
current window position and active tab may be stored in the
database. CDriverAdminDialog then Loads the CDriverAdmin class and
directs it to initialize itself. During initialization,
CDriverAdminDialog creates an instance of the driver administrator
32 and queries all interfaces that will be used.
[0258] Once the application is initialized, the default settings to
be displayed in the dialog must be set. These values are set when
the dialog is initialized, just before displaying it. FIG. 54
describes this process. During the process of initializing the
dialog, the following steps occur.
[0259] During the dialog preparation that occurs before the DoModal
call, CDriverAdminDialog queries the CDriverAdmin object for the
driver enumeration to be used when setting initial values to be
displayed in the dialog box. CDriverAdmin uses the driver
administrator 32 Component to query for the driver information map,
which is then passed back to the CDriverAdminDialog. Once receiving
the driver information map, the CDriverAdminDialog uses the
information to update all user-interface items related to either
drivers or streams.
[0260] Adding a driver to the system 22 can be broken down into two
steps. First, the module name must be added to the system. Next,
the driver administrator 32 main dialog must update itself to
reflect the new driver just added.
[0261] Adding a driver occurs when the user presses the "Add . . .
" button on the driver administrator 32's main dialog. FIG. 55
describes this process. When adding a new driver, the following
steps occur.
[0262] When adding a driver, first the user must press the "Add . .
. " button. After pressing the button, CDriverAdminDialog opens up
the common open file dialog. The user must enter in the filename of
the driver to add and close the dialog. CDriverAdminDialog then
passes the filename to the CDriverAdmin object and calls the
RegisterDriver method passing in the name of the module to register
as a driver. CDriverAdmin then passes the driver filename to the
driver administrator 32 Component and directs it to register the
driver in the system 22.
[0263] The process of updating the main dialog is identical to the
process of initializing the dialog discussed above.
[0264] Similar to the process of adding a new driver, removing a
driver involves both removing the driver from the system and then
updating the main dialog. Pressing the "Remove" button removes a
driver from the XMC software system. FIG. 56 describes this
process. The following steps occur when removing a driver.
[0265] To remove a driver, the user must first select the "Remove"
button. After pressing the button, the selected driver or parent
driver to the selected stream will be removed. CDriverAdminDialog
passes the XMC_HDRIVER of the driver to the CDriverAdmin and
directs it to remove the driver by calling its UnRegister method.
CDriverAdmin passes the XMC_HDRIVER to the driver administrator 32
Component and directs it to UnRegister the driver.
[0266] The process of updating the main dialog is identical to the
process of initializing the dialog discussed above.
[0267] Viewing Support involves viewing the level of support
implemented by the selected driver. FIG. 57 describes the process
of providing this information to the user via the View Support
Dialog. The following steps occur when viewing the support provided
by the driver.
[0268] First the user must select the "View Support" button on the
driver administrator main dialog. When selected, CDriverAdminDialog
queries CDriverAdmin for the driver support information.
CDriverAdmin passes the query on to the driver administrator 32
component who actually fills out the information. Once the queried
information is returned, the CDriverAdminDialog passes it on to
CViewSupportDialog. CViewSupportDialog initializes itself using the
driver support information.
[0269] Attached hereto as Appendix H is a document that describes
the actual OLE Interfaces exposed, the definitions of the data
structures used when passing data around, and the definitions of
each class used internally by the driver administrator 32.
VIII. Driver Administrator CPL Applet
[0270] This section contains a description of the driver
administrator control panel applet 38. When using the driver
administrator 32 to configure the motion control system, there are
two main items that the user will work with: drivers and streams.
Each driver 30 generates the hardware specific, control codes that
are then sent to the selected stream component 28. Streams
facilitate the data transport layer between the driver and the
control-code destination.
[0271] Depending on the current hardware setup, different streams
may be used. For example, if the hardware is connected to the PC
Bus, a PC Bus stream will be used to communicate to it. On the
other hand, if the hardware is connected through a serial cable to
a serial I/O Port, the serial stream will be used. Finally, all
hardware configurations may use the file stream. When using the
file stream, all control-codes are sent to the specified file that
can be downloaded to the hardware at a later time.
[0272] This section describes both drivers and streams, and how
each is configured. This section initially describes the driver
items and all property pages used to edit them. This section also
contains a description of the streams and their property pages.
Finally, this section describes the about box containing details on
the Software.
[0273] The main purpose of each driver is to generate the
hardware-specific control-codes directing the hardware to carry out
specific motion control actions. For example, such actions may
include querying the hardware for the current position or directing
the hardware to move to a predetermined location in the system. The
following discussion describes the property pages used to configure
each driver.
[0274] There are two types of properties affecting each driver.
First, a set of defaults may be set that are used by the motion
control component 35 as recommended values. The scaling and units
used are several example default values. In addition to setting
default values, if the driver supports more advanced configuration,
pressing the Advanced . . . button will display a dialog box used
to set the driver configuration. For example, if a driver does not
support streams, the advanced configuration dialog, provided by the
driver, will allow the user to set the I/O Port and IRQ
settings.
[0275] The properties affecting drivers 30 are as follows. [0276]
Scaling--Setting the scaling property affects the default scaling
used on all axes within the motion control system. The range for
scaling values is (0.0, 1.0]. Default setting may be overridden
when programming XMC by using the IXMC_StaticState interface.
[0277] Units--Setting the units property affects all coordinates
used when programming the system 22. [0278] The unit descriptions
are as follows: [0279] MM_ENGLISH--Inches are used as the base unit
for all coordinates MM_METRIC--Millimeters are used as the base
unit for all coordinates. [0280] MM_NATIVE--The native coordinates
defined by the hardware system are used. Coordinates used to
program XMC are mapped 1:1 to the hardware coordinates. [0281]
Advanced . . . --Pressing this button will display a dialog used to
edit any advanced properties for the driver that may be edited by
the user. In addition to allowing the user to set properties, each
driver property page displays the full names of both the hardware
supported and the hardware vendor who makes the hardware.
[0282] The buttons along the bottom of the windows work with the
selected driver or stream. The following discussion describes each
button and what it does.
[0283] Pressing the Make Default button selects the current driver
to be the default. If a stream is selected, its parent driver
becomes the default driver. The default driver is later used by the
motion control component 35
[0284] Selecting the Add . . . button, displays the Add Module
dialog. This dialog is used to add new drivers and streams to the
system 22. Once selected, the new driver or stream will be
displayed in the Driver tree view. When adding a stream, the stream
is added under the currently selected driver. To enable the stream,
you must select the enable check box located in the streams
property page.
[0285] Selecting the Remove button, removes the current driver or
stream selected. If a driver is removed all of its streams are also
removed.
[0286] Selecting the View Support . . . button displays a dialog
used to view the level of XMC support implemented by the driver.
For example, all API interfaces and subsequent methods are
displayed. If a lack of implementation within the driver prohibits
an API interface from operating, the driver stub 36 is used. If the
lack of implementation within the driver 30 cannot be replaced by
operations within the driver stub 36, the interface or method is
disabled.
[0287] The following are descriptions of each graphic found in the
XMC Support View Dialog. [0288] D--This graphic means that the
interface or method is implemented by the driver 30. [0289] S--This
graphic means that the interface or method is implemented within
the driver stub 36. [0290] X--This graphic means that the interface
or method is disabled because of a lack of implementation within
the driver 30.
[0291] Like the properties page, a debug page is also provided to
set all debugging settings for the driver. Each driver may specify
that all API calls used to control the driver are logged. The
logging settings only affect the current driver selected. The
Output field allows you to select the output stream where all debug
information is sent. When Streams is enabled, debug information is
sent to the specified text file. When Debug Monitor is enabled,
debug information is sent to the debug monitor if it is running.
Using Enable to enable a stream turns it on causing all debug
information generated to be sent to the stream. More than one
stream may be enabled at one time.
[0292] Stream Settings are available for each debug stream
supported. Text File allows the name of the text file may be set.
The Debug Monitor can only be enabled and disabled.
[0293] A stream is the transport layer used by the driver to pass
data to the destination location. The destination location may be
the actual motion control hardware or even a text file. Usually the
control language used by a hardware vendor is supported by several
different flavors of their motion control hardware. For example,
some vendors have both PC Bus based and Serial I/O based motion
control hardware that understand the same control language. In such
a case, the same driver would be used for each hardware setup but
it would communicate with different streams depending on the
specific hardware setup. Graphically, each stream is listed below
each driver that uses the stream.
[0294] This section describes the streams supported by the system
22 and how they are configured.
[0295] The PC Bus stream sends all data directly to a PC Bus based
motion control hardware system by writing to the specified I/O
Ports and IRQ's defined by the hardware. This section describes
both the properties and debug settings available for the PC Bus
Stream.
[0296] Stream properties only affect the currently selected stream.
The user is required to select certain settings, such as the I/O
Port and IRQ. Without setting these values, the PC Bus Stream will
not be able to communicate with the hardware. The properties
affecting PC Bus Streams are described below.
[0297] The I/O Port is the base port used to communicate with the
motion control hardware that the stream is to send data to.
[0298] The IRQ is the interrupt request level used by the
hardware.
[0299] Pressing the Advanced . . . button will display a dialog
allowing the user to edit more advanced stream options. For
example, if the stream supports a Port I/O map that the user can
edit, the port map would be displayed in this dialog. This button
is only enabled for streams supporting advanced features that the
user may edit.
[0300] When debugging an application program it may be useful to
see what codes are actually sent to the hardware. The Debug
Settings page for streams allows the user to enable and disable
both the Cmd and Bit Streams. The Cmd Stream is used to log all
command-codes sent to the hardware. If this level of detail does
not provide you with enough information, the Bit Stream may be
used. When enabled, the Bit Stream logs all values sent through
each hardware port. All values read from and written to each port
used by the hardware are logged. Note, when enabled, both streams
may significantly slow down the application programming the motion
control system.
[0301] Serial RS-232 Streams are used to send data from the driver
to motion control hardware connected to the computer through the
serial I/O port. Both property and debug settings only affect the
selected Serial RS-232 Stream. The following discussion describes
the available settings in each in detail.
[0302] All Serial RS-232 property settings must be set by the user
for they let the stream know what I/O port and communication
protocol to use when communicating with the hardware. The
properties affecting Serial RS-232 Streams are as described
below.
[0303] The Port is the serial port that the hardware is connected
to. COM1-COM4 are valid ports that can be used.
[0304] The Baud Rate is the speed of data transmission supported by
the hardware.
[0305] When Hardware is selected a more efficient, but less
compatible, communication protocol is used to communicate to the
hardware. If errors occur when this protocol is selected, use the
XON/XOFF communication protocol.
[0306] When the XON/XOFF communication protocol is selected a
simple and more compatible communication protocol is used.
[0307] Debug settings for the Serial RS-232 Stream are very similar
to those supported by the PC Bus Stream. Serial RS-232 Streams only
support command logging through the Cmd Stream and do not support
bit logging.
[0308] The Text File Stream is used to build control-code programs
for later use. Using this stream facilitates running the XMC
software in code-generation-mode. No motion control actions take
place when running in this mode. Instead, control-code programs may
be built and stored to file. Later, after programs are built and
saved, they may be downloaded to the motion control hardware and
run. The following discussion describes the property and debug
settings for the Text File Stream.
[0309] The main property set, when configuring a Text File Stream,
is the actual name and location of the file to use. Once set, the
stream is ready for use.
[0310] The following properties may be configured for the Text File
Stream:
[0311] Filename is the filename and location of the file used to
store all control-codes generated by the driver 30 selected.
Pressing the Browse . . . button displays a dialog allowing you to
graphically select the location and filename to use.
[0312] No debug settings are available for the Text File
Stream.
IX. Language Driver
[0313] FIG. 58 contains a module interaction map depicting a
language driver 44 and illustrating how that language driver 44
interacts with the streams 28, the driver administrator 32, the
motion control component 35, and the registry 42.
[0314] As with the software drivers 30 described above, one
language driver 44 is used for each of the motion control devices
20 of the group of supported motion control devices. The language
drivers 44 perform the same basic function as the software drivers
30 described above with reference to FIGS. 1 and 12-21. To the
software system 22, the language drivers 44 are accessed and
respond in the same manner as the software drivers 30; the
differences between the language drivers 44 and the software
drivers 30 are entirely internal.
[0315] The primary difference between these drivers 30 and 44 is
that the language drivers 44 use a database the key fields of which
are an index field, a command format field, and a response format
field. Each record or row in the database corresponds to a given
Driver function.
[0316] The purpose of the command and response format templates is
to formalize and simplify the process of constructing command data
strings and format data strings which contain commands and
parameters to be transmitted to the motion control devices 20. The
format templates define how, for a given SPI command, the software
system 22 communicates with a vendor specific hardware command
language associated with a given motion control device 20
associated with a given language driver 44. Accordingly, one
database containing command format templates and response format
templates will be created for each such language.
[0317] The command format field contains a command format template,
and the response format field contains a response format template.
Each of these templates comprises a sequence of data type
identifiers, macro identifiers, syntax characters, and/or ASCII
characters.
[0318] The index field contains a value unique to each Driver
function that facilitates the process of looking up the command and
response format templates associated with a given Driver
function.
[0319] The software system designer defines the data type
identifiers, macro identifiers, and syntax characters discussed
above. In general, the data type identifiers and syntax characters
are common to both the command format template and the response
format template.
[0320] The macro identifiers will normally correspond to macros
that are associated with either the command format templates or the
response format templates. The ASCII characters are defined by the
Driver function and the particular motion control device 20 with
which a given language driver 44 is associated.
[0321] An Excel spreadsheet may be used as an organizational tool
that facilitates creation of the database used by the language
driver 44. An example of a Excel spreadsheet that may be used for
this purpose is shown in FIG. 67. The spreadsheet shown in FIG. 67
is saved as a tab-delimited file and then copied into the SPI
database shown in FIG. 59.
[0322] The spreadsheet shown in FIG. 67 is simply an organizational
tool and will not be described herein in detail. But it should be
noted that the exemplary spreadsheet shown in FIG. 67 sets forth a
list of typical command and response data type identifiers, along
with descriptions thereof, and lists of command and response
macros. These will be supplemented by an additional STRUCT data
type that allows the programmer to define a data type that combines
the other primitive data types as necessary for a given
template.
[0323] The language drivers thus operate generally as follows. As
described above, the motion component 35 will call the driver
function implemented by the language driver 44 and, in many cases,
will pass parameters necessary to carry out that function. The
language driver 44 will use the index for that driver function to
look up the command format template and the response format
template associated with the appropriate driver function.
[0324] Using the command format template, the language driver 44
will construct a command data string containing ASCII characters.
The command data string carries the commands and parameters
necessary to implement the given driver function in a desired
manner on the motion control device 20 associated with the language
driver 44.
[0325] Similarly, the language driver 44 uses the response format
template to parse a response data string sent by the particular
motion control device 20 in response to the command data string.
The response format template thus allows the language driver 44 to
pass from the motion control device 20 to the motion control
component 35 any commands and/or parameters necessary to enable the
controlling application 26 to function as intended.
[0326] The following sets forth examples of the process of
generating a command data string and parsing a response data string
given a set of command and response format templates associated
with a single SPI.
EXAMPLE 1
[0327] The first example illustrates how the language driver 44
might deal with the Driver function IXMC_DrvExt_Test::Move.
TABLE-US-00001 Cmd Format: D%d,+:@[snd]GO%b+:@[snd] Rsp Format:
@[crlf]>@[rcv]@[crlf]>@[rcv] Driver function Call:
pXMCDrvExtTest->Move( 20.0, 30.0 )
[0328] This function call directs the motion control device to move
20 units in the x direction and 30 units in the y direction. The
driver communicates with the stream as follows:
[0329] Step 1. Perform the operation in the command format template
up to the first @ symbol. This builds a raw command string of
"D20.0,30.0:"
[0330] Step 2. After the first @ symbol is the send command, which
sends the string that was built in step 1. The language driver has
now reached the G in the command format template.
[0331] Step 3. After the send command, the language driver reads a
response from the stream to confirm that the command string was
received and processed correctly. The response string received from
the stream is as follows: "\r\n>".
[0332] Step 4. The language driver next uses the response format
template to parse the raw response string to verify operation and
extract data. The language driver then picks up at the G in the
command format template and constructs the next raw command string
of "GO11", leaving off at the last macro.
[0333] Step 5. The language driver, picking up at last macro in the
command format template, then sends the raw command string created
in step 4 to the stream, completing the command format
template.
[0334] Step 6. Again, after the send command the language driver
receives a response data string from the stream as follows:
"\r\n>".
[0335] Step 7. The language driver next parses the response data
string received in step 6.
EXAMPLE 2
[0336] The second example illustrates how the language driver 44
might deal with the Driver function IXMC_DrvExt_Test::SetVelocity.
TABLE-US-00002 Cmd Format: V%If,+:@[snd] Rsp Format:
@[crlf]>@[rcv] Driver function Call:
pXMCDrvExtTest->SetVelocity( NOP, 22.0 ) Explanation Set the
velocity of the y axis to 22.0. Raw Command String: "V,22.0:" Raw
Response String: "\r\n>" (expected)
EXAMPLE 3
[0337] The third example illustrates how the language driver 44
might deal with the Driver function TABLE-US-00003
IXMC_DrvExt_Test::GetVelocity. Cmd Format: GV%b+:@[snd] Rsp Format:
%d,+@[crlf]>@[rcv] Driver function Call:
pXMCDrvExtTest->GetVelocity( NOP, &dfY_Vel ) Explanation Get
the velocity set for the y axis. Raw Command String: "GV01:" Raw
Response String: ",44.0\r\n>" (expected) dfY_Vel = 44.0
EXAMPLE 4
[0338] The fourth example illustrates how the language driver 44
might deal with the Driver function IXMC_DrvExt_Test::Reset.
TABLE-US-00004 Cmd Format: !RESET:@[snd]MA0:MC0:LH0:@[snd] Rsp
Format: @[crlf]*VENDOR NAME - MODEL@[rcv]@[crlf]>@[rcv] Driver
function Call: pXMCDrvExtTest->Reset( ) Explanation Reset the
hardware. Raw Command String1: "!RESET:" Raw Response String1:
"\r\n*VENDOR NAME - MODEL" (expected) Raw Command String2:
"MA0:MC0:LH0:" Raw Response String2: "\r\n>" (expected)
[0339] While the language driver 44 is of particular importance in
the context of the software system 22 described above, this
technology may have broader application to any hardware in which
ASCII strings are employed to transmit commands to and receive
responses from hardware.
[0340] The language driver 44 will now be described in more detail.
The language driver 44 is used by both the driver administration 32
and the motion control component 35. Its main purpose is to
implement functionality that generates motion control commands for
the specific hardware supported.
[0341] For example, the AT6400 driver used to control the
Compumotor AT6400 motion control hardware, generates AT6400 command
codes. During the initialization phase of the system 22, the driver
administrator 32 communicates with each language driver 44,
allowing the user to add, remove, or change the configuration of
the driver 44. When an application using the system 22 is run, the
component 35 communicates with the language driver 35 directing it
to carry out the appropriate motion control operations.
[0342] Unlike the driver 30 described above, which communicates
with motion control devices 20 by directly sending binary codes,
the language driver 44 sends ASCII text to the stream 28, which
then sends the information on to the motion control device 20.
[0343] This section makes reference to a number of drawings to
describe the features implemented in the language driver 44: (a)
the Module Interaction-Map in FIG. 58 that displays all binary
modules that interact with the driver and how they interact with
one another; (b) an Object Interaction-Map (FIG. 59), which
corresponds to the module interaction map expanded to display the
internal C++ objects making up the language driver 44, and how
these objects interact with one another; (c) a number of Scenario
Maps (FIGS. 60-65) that display the interactions taking place
between the C++ objects involved during a certain process; (d) an
interface map that describes the interfaces exposed by the language
driver component 44, all data structures used, and the definitions
of each C++ class used; and (b) a table illustrating how a typical
database employed by the language driver 44 is constructed (FIG.
67).
[0344] The module interaction-map in FIG. 58 displays all binary
modules and their interactions with the Language Driver 44. There
are two modules that interact directly with the driver 44: the
Motion Control Component 35, and the Driver Administrator 32. The
driver administrator 32 queries and changes the drivers settings
and the component 35 directs the driver 44 to carry out motion
control operations, such as moving to a certain location in the
system.
[0345] Mores specifically, the module interaction-map shown in FIG.
58 contains the following modules: [0346] The Driver Administrator
module 32 is used to install, uninstall, register, and setup each
driver and stream module. [0347] The Motion Component is the motion
control component 35 used by applications 26. The component 35
communicates with the current driver 44 passed to it by the driver
administrator 32 to carry out motion control operations requested
by the application 26. [0348] The Language Driver 44 generates the
ASCII codes making up the hardware command language. A given
language driver 44 only communicates with a stream 28 that has been
specifically connected to that driver 44. Once connected, the
stream 28 is used to communicate with the destination object, such
as the PC Bus, serial I/O connection, text file, or debug monitor.
[0349] The Streams 28 are the actual objects that operate as the
data transport layer for each driver 44. Each stream 28 has a
different target that defines the type of the stream. [0350] The
Registry 42 is the standard Windows registration database.
[0351] The object interaction-map in FIG. 59 breaks the module
interaction-map shown in FIG. 58 down into more detail by including
the interactions taking place between all C++ objects used to
implement the driver 44.
[0352] Each object in the diagram is described as follows. [0353]
CDriverObject This is the main C++ object that implements all OLE
specific functionality including the function shells for all OLE
interfaces exposed by the object. [0354] CDrvCoreDispThis is the
C++ object used to dispatch all core SPI OLE interface functions to
their respective internal implementations. In addition to the
methods inherited from the CLangDrvCoreDisp object, this object
dispatches driver specific SPI, such as the core XMCSPI OLE
interface methods. [0355] CLangDrvCoreDisp All language driver core
functionality is dispatched through this object to its internal
implementation. For example, the generic language driver
implementation for initialization is dispatched through this object
to its implementation residing in the LANG_DRV basecode library.
[0356] CDrvExtDisp This is the C++ object used to dispatch all
extended SPI OLE interface functions to their respective internal
implementations. In addition to the methods inherited from the
CLangDrvExtDisp object, this object dispatches driver specific SPI,
such as the extended XMCSPI OLE interface methods. [0357]
CLangDrvExtDisp All language driver extended functionality is
dispatched through this object to its internal implementation. For
example, all stream handling is dispatched through this object to
its implementation residing in the LANG_DRV basecode library.
[0358] CCommandMgr This object is used to build commands sent to
the stream, and extracting responses received from the stream. The
CCommandMgr is the controlling object that manages the CCommand,
CResponse, and CCommandDatabase objects. [0359] CCommand The
CCommand object builds command strings that are then sent to the
CSimpleStream. Each command built is a complete motion control
command string. [0360] CResponse This object converts raw response
strings, returned by the CSimpleStream, and converts them into C++
data types. For example, a response string containing position data
may be converted into a set of double values. [0361]
CCommandDatabase This object stores the complete database of
commands making up the motion control command language. The
database may be represented as an actual external database (such as
a SQL database), a text file, or stored inside the driver as a
custom resource. Currently, the language driver only supports
databases stored as a custom resource within the driver module.
[0362] CSPlInfo This object makes up one database entry stored
within the CCommandDatabase object. [0363] CStreamMgr This object
is responsible for managing the set of streams registered with the
driver. Streams, may be added, removed, and enabled. Only enabled
streams actually send data to their targets. For example, only an
enabled PCBus stream will send data to the motion control card
plugged into the PCBus. [0364] CSimpleStream This object is used to
initialize, create, and communicate directly with the underlying
stream component. [0365] CDriverInfoMgr This object is responsible
for creating the CDriverInfo object. [0366] CDriverInfo This object
contains the complete set of state data making up the Language
driver 44. All driver settings and a list of all XMC Streams used
are stored within this object. Basic queries are routed directly to
this object. More complex operations are handled by one of the
various manager objects, who connect to this object, perform the
operation, and then disconnect from it. [0367] CRegistryMgr This
object is used to save and load the information, stored within the
CDriverInfo object, to and from the registration database. In
specific, contains the code called when the ICOM_PersistRegDB
interface is invoked. [0368] CRegistry This object performs all
registration database operations such as creating keys, saving
values, and querying values.
[0369] All main scenarios, or operations, that occur on the
Language Driver 44 will now be described with reference to FIGS.
60-66. Each scenario-map contained in these figures displays all
objects involved and the interactions that take place between them
in the sequence that they occur.
[0370] There are two types of operations that occur on the Language
driver 44. First, the Driver administrator 32 may initiate
operations, such as adding streams or configuring the driver. And
second, the Motion control component 35 may initiate operations on
the driver when an application is actually running.
[0371] Referring now to FIGS. 60-64, all operations made on the
driver 44 by the driver administrator 32 will be described. Each
figure is discussed in the order that it may occur when using the
driver 44.
[0372] Before a driver may be used by the XMC Motion Component, it
must be registered in the OLE system. As shown in FIG. 60, in order
to register a driver the driver administrator, first verifies that
the module being registered is actually an appropriate language
driver, then it calls the DLLRegisterServer exported function to
register the driver. Each module of the system 22 exports a
function called DLLGetModuleType. This function is used to verify
that the module is an appropriate driver component.
[0373] Next, the driver administrator can load the component using
the OLE CoCreateInstance function. During the initialization
process, the driver loads all registration data and initializes the
CDriverInfo and all C++ manager objects.
[0374] The following describes in detail each of the steps set
forth in FIG. 60.
[0375] 1. During initialization, the driver administrator must load
the DLL, containing the stream component, verify that the module is
an XMC Driver. To do so, the driver administrator calls the
DLLGetModuleType function, exported by the driver. If the function
returns a value that contains the value XMC_DRIVER_MT in the high
byte, then the driver administrator proceeds and registers the
driver by calling its exported function, DLLRegisterServer. When
called, the implementation of the DLLRegisterServer writes all OLE
2.0 registration information, needed to register the OLE component,
to the Windows registration database.
[0376] 2. Next, the driver administrator must query the driver
module for its CLSID. Calling the driver's exported function,
DLLGetCLSID, returns the CLSID. Once it has the CLSID, the driver
administrator may create an instance of the driver by calling the
standard OLE function CoCreateInstance.
[0377] 3. CoCreateInstance automatically initializes the component
by calling the ICOM_Base::Initialize method implemented by the
CDriverObject.
[0378] 4. The implementation of ICOM_Base::Initialize directs both
the CDrvCoreDisp to initialize itself.
[0379] 5. Within its initialization, the CDrvCoreDisp object
initializes each of its manager objects, starting with the
CcommandMgr.
[0380] 6. During its initialization, the CCommandMgr directs the
CCommandDatabase to load itself.
[0381] 7. To load the database, the CCommandDatabase object reads
in the database and builds the CSPlInfo list of database
elements.
[0382] 8. After initializing the CCommandMgr, the CDrvCoreDisp
object directs the CDriverInfoMgr object to create the CDriverInfo
object, that will later store the internal state of the Language
driver 44 component.
[0383] 9. The CDriverInfoMgr object creates the CDriverInfo object
and passes it back to the dispatch object. The pointer to this
object is later stored in the components state handle, when the
CDriverObject calls ICOM_Base2::SetStateHandle.
[0384] 10. Next, the CDrvCoreDisp object initializes the
CStreamMgr, that is used to perform all stream operations.
[0385] 11. Next, the CDrvCoreDisp object initializes the
CRegistryMgr, that is used to perform all registration database
operations.
[0386] 12. Finally, the CDriverObject initializes the CDrvExtDisp
object.
[0387] It should be noted that all initialization is initiated
through the COM Auto-Init mechanism. Auto-init occurs when creating
an object. When calling either CoCreateInstance, or calling the
IClassFactory::CreateInstance method, the internal COM
implementation calls the ICOM_Base::Initialize method. This method
triggers the complete initialization process described in this
section.
[0388] After initializing the driver, the driver administrator may
perform operations on it. For example, the driver administrator may
request the driver to add or remove a stream. FIG. 61 displays the
sequence of events occurring when the driver is requested to add a
new stream.
[0389] When adding a stream, the following steps occur:
[0390] 1. The driver administrator directs the driver to add a new
stream and passes the filename and CLSID of the stream, to be
added, to the driver.
[0391] 2. The driver then passes the filename and CLSID to the
CDriverObject object and directs it to add the stream by calling
its CLNGStreamMgmt::AddStream embedded C++ class method.
[0392] 3. The embedded C++ object, that implements the OLE
interface, directs the CDrvExtDisp object to add the stream,
passing it a handle of the component state data.
[0393] 4. The CDrvExtDisp object first typecasts the component
state data into a pointer to the CDriverInfo object.
[0394] 5. Next, the CStreamMgr, is connected to the CDriverInfo
object pointer, and directed to add a new stream.
[0395] 6. In order to add the new stream, the CStreamMgr, uses a
CSimpleStream to load and create the stream component.
[0396] 7. The CSimpleStream object first sets function pointers to
the DllGetCLSID, DGetModuleType and DllRegisterServer functions
exported by the component. Before loading the module, the
CSimpleStream, first makes sure that the module is actually an XMC
Stream by comparing its module type with the XMC_STREAM_MT module
type. If it is, the component is registered in the registration
database as a n OLE component.
[0397] 8. Using the DllGetCLSID queried in the previous step, the
CSimpleStream gets the components CLSID and calls CoCreateInstance
to load an instance of the OLE object.
[0398] 9. After the CSimpleStream completes, the CStreamMgr adds
the stream to the CDriverInfo's stream array.
[0399] Another operation requested from the driver, after
initialization, is that of querying it for its current settings.
Before displaying information about the driver, like the name of
the hardware it supports, the driver administrator must query the
driver for the information. FIG. 62 displays an exemplary process
of querying the driver for its driver settings.
[0400] When querying the driver for information, the following
steps are performed.
[0401] 1. The driver administrator, calls the interface method used
to query the driver's information and passes the call a pointer to
the XMC_DRIVER_INFO structure.
[0402] 2. The call is handled by the implementation of the OLE
interface method, implemented by on of the CDriverObject's embedded
C++ classes.
[0403] 3. The embedded C++ object, used to handle the interface,
directs either the CDrvCoreDisp or CDrvExtDisp object to carry out
the operation, and passes the object th handle to the component
state data.
[0404] 4. The dispatch object type casts the state handle to a
CDriverInfo object pointer. Once converted, the CDriverInfo object
is queried for the appropriate data.
[0405] Upon request, the driver may either save or load its entire
configuration to or from the registration database. This operation
is used by the XMC Driver Administration component who stores all
XMC configuration data in the registration database. FIG. 63
displays the sequence of events that take place when the XMC Driver
Administration component directs the driver to load its information
from the registry.
[0406] During the registration process, the following steps
occur.
[0407] 1. First, using the ICOM_PersistRegDB OLE interface, exposed
by the driver, the driver administrator directs the component to
load its configuration data.
[0408] 2. The CDriverObject's embedded object, used to handle all
ICOM_PersistRegDB calls, is invoked and performs the operation.
[0409] 3. Once invoked, the embedded object directs the
CDrvCoreDisp object to perform the load, and passes it a handle to
the components state data.
[0410] 4. The CDrvCoreDisp object, first typecasts the state handle
to a CDriverInfo object pointer.
[0411] 5. Next, the CRegistryMgr is connected to the CDriverInfo
pointer, and directed to load its contents to or from the
registration database.
[0412] 6. The CRegistryMgr loads all general driver information and
fills out the drivers XMC_DRIVER_INFO data structure, stored in the
CDriverInfo object.
[0413] 7. If the driver has any streams information stored, the
CRegistryMgr loads the stream information and fills out an
XMC_STREAM_INFO structure. The structure is then used to create a
new CSimpleStream object.
[0414] 8. When creating the stream, the CSimpleStream object first
queries and calls the DllGetModuleType exported function and
verifies that the module is in fact a stream component. If the
module is, the CSimpleStream then queries and calls the
DLLRegisterServer function exported by the component to register
the component.
[0415] 9. After registering the component, the CSimpleStream object
queries and calls the DllGetCLSID exported function to get the
components CLSID. Using the CLSID, CoCreateInstance is called to
create an instance of the OLE object.
[0416] 10. Once the CSimpleStream completes, the CRegistryMgr
connects a temporary instance of the CStreamMgr to the CDriverInfo
object pointer, and directs it to add the new stream.
[0417] 11. The CStreamMgr directly manipulates the CDriverInfo's
stream array to add the new stream. When added, a new instance of
the CSimpleStream object is created and attached to the
CSimpleStream passed to the CStreamMgr.
[0418] 12. When attaching itself to the stream, the new
CSimpleStream queries the IXMC_StreamInit interface, passed to it,
for all interfaces used it bump up the reference counts for the
component.
[0419] After the driver administrator is done using the driver, it
must release the driver by calling its exposed Release method.
Calling this method, directs the driver to release all resources
used. FIG. 64 displays the process of releasing the driver
component.
[0420] During the clean-up process, the following steps occur.
[0421] 1. First, either the XMC Driver Administrator, or the XMC
Motion Component call the final IUnknown::Release.
[0422] 2. When invoked, the IUnknown::Release method implemented by
the CDriverObject is called. After calling this method causes the
internal OLE reference count to go to zero, driver calls its
implementation of ICOM_Base::Uninitialize to clean up all resources
used.
[0423] 3. First, ICOM_Base::Uninitialize directs the CDrvExtDisp to
clean up any resources that it was using.
[0424] 4. Next, ICOM_Base::Uninitialize directs the CDrvCoreDisp
object to clean up any resources that it was using.
[0425] 5. Since the CDrvCoreDisp object contains instances of all
manager objects, it begins cleaning them up by first directing the
CCommandMgr to destroy any resources that it was using. Internally,
the CcommandMgr destroys the CCommandDatabase and all of its
contents.
[0426] 6. Next, the CDrvCoreDisp object implicitly destroys all
other manager objects by calling their destructors.
[0427] 7. And as a final step, the ICOM_Base::Uninitialize method
deletes the state handle containing a pointer to the CDriverInfo
object. When destroyed, the CDriverInfo object deletes each
CSimpleStream object, which in turn release their instance of the
XMC Stream component. Upon releasing the final instance of the XMC
Stream component, the component dll is freed from memory.
[0428] After a driver is successfully installed into the XMC system
and configured using the driver administrator, it is ready for use
by the XMC Motion Control Component. The component uses the driver
when performing motion control operations requested from the
application using the component. FIG. 65 describes the component
directed operations that can take place on the driver.
[0429] Before operating, the XMC Motion Component must query the
Driver administrator 32 component for its driver enumeration. The
enumeration returned is used to access all enabled drivers that are
directed to perform XMC SPI operations by the XMC Motion
Component.
[0430] Once the driver enumeration is acquired, the Motion control
component 35 can direct the enabled driver, or drivers, to carry
out certain command operations. Command operations are standard
motion control operations such as moving to a specific location in
the system, or querying the system for the current position. FIG.
65 describes the process of commanding the driver to carry out a
certain operation.
[0431] When commanding the driver to perform a certain operation,
the following steps occur.
[0432] 1. First, the motion component directs the driver to perform
the operation, such as moving to a position or querying the system
for the current position.
[0433] 2. The XMCSPI invocation is handled by the CDriverObject who
implements all OLE interfaces exposed by the component.
[0434] 3. The CDriverObject directs either the CDrvCoreDisp, or
CDrvExtDisp object to perform the operation, depending on whether
the operation is a core or extended XMCSPI. The component state
handle is passed to the dispatch object when called.
[0435] 4. The dispatch object then typecasts the state handle into
a CDriverInfo object pointer.
[0436] 5. Next, the dispatch object connects the CCommandMgr to the
CDriverInfo object pointer and directs it to carry out the
operation corresponding to the database index sent. The database
index corresponds to the XMCSPI called and is used to locate the
language database entry for that SPI call.
[0437] 6. The CCommandMgr searches the CCommandDatabase for the
index and builds a CCommand object corresponding to the XMCSPI
operation.
[0438] 7. Next, the CCommandMgr directly accesses the CDriverInfo
and passes the command string, built by the CCommand object, to all
enabled streams.
[0439] 8. Each enabled stream sends the ASCII text to its target.
For example, the PCBus steam sends its data to the motion control
card located on the PCBus. The text file stream, on the other hand,
sends its data to its associated text file.
[0440] 9. If directed, the CCommandMgr then queries the first
readable stream for the results of the commands sent to
it.sup.1.
[0441] 10. The CSimpleStream reads the raw response from the target
and returns it to the CCommandMgr.
[0442] 11. Once receiving the raw response, the CCommandMgr uses
the CResponse object to parse the raw response based on the
response format corresponding to the XMCSPI database entry. All
response parameters are returned back up the calling chain, and
eventually end up in the hands of the original caller, the XMC
Motion Component.
[0443] The clean-up initiated by the XMC Motion Component by
releasing the XMC Driver component is the same as that which occurs
when the Driver administrator 32 object releases the component.
[0444] The following discussion describes the actual OLE Interfaces
exposed, the definitions of the data structures used when passing
data around, and the definitions of each class used internally by
the driver.
[0445] The following diagram describes all interfaces exposed by
the driver specific to driver-component interpretability. FIG. 66
graphically displays the interfaces exposed by the component.
[0446] Other than the two standard interfaces exposed, such as
IUnknown and IClassFactory, there are three categories of
interfaces exposed by the component. The three categories are as
follows. [0447] COM: All interface names with the COM_prefix,
implement general COM functionality. For example, the ICOM_Base,
ICOM_Base2, ICOM_Persist2, and ICOM_PersistRegDB interfaces all
fall into this category. [0448] LNG: All interface names with the
LNG_prefix, implement general language driver functionality. For
example, the ILNG_DrvCore_Init, and the ILNG_DrvExt_StreamMgmt
interfaces fall into this category. [0449] XMC: All interfaces name
with the XMC_prefix, implement XMCSPI (driver) functionality.
[0450] The following sections describe the interfaces falling into
both the COM and LNG categories. All other interfaces are XMCSPI
specific and are used for the sole purpose of performing motion
control operations.
[0451] The following exposed methods in the ICOM_Base interface are
used when intializing and uninitializing the component. Each of
these methods call the hidden initialize and uninitialize interface
methods implemented by all of the component's interfaces.
TABLE-US-00005 DECLARE_INTERFACE_( ICOM_Base, IUnknown ) {
STDMETHOD ( Initialize )( THIS_LPVOID pInitInfo ) PURE; STDMETHOD (
Uninitialize )( THIS ) PURE; };
[0452] The ICOM_Base2 interface inherits from the ICOM_Base
interface and adds several methods used to manage the internal
component state handle. In addition, a method allows the user to
translate any HRESULT returned by the component into a human
readable text string. The following is a description of the
ICOM_Base2 interface. TABLE-US-00006 DECLARE_INTERFACE_(
ICOM_Base2, ICOM_Base ) { STDMETHOD ( SetStateData )(
THIS_COM_STATEHANDLE hState ) PURE; STDMETHOD ( GetStateData )(
THIS_LPCOM_STATEHANDLE phState ) PURE; STDMETHOD ( GetErrorString
)( THIS_HRESULT hr, LPSTR pszErr, DWORD dwMax ) PURE; };
[0453] The ICOM_Persist2 interface inherits from the IPersist
standard OLE interface and adds several methods used to query the
CLSID and module type. The following is a description of the
ICOM_Persist2 interface. TABLE-US-00007 DECLARE_INTERFACE_(
ICOM_Persist2, IPersist ) { STDMETHOD ( GetID )( THIS_LPDWORD pdwID
) PURE; STDMETHOD ( GetModuleType )( THIS_LPDWORD pdwMT ) PURE;
};
[0454] The ICOM_PersistRegDB interface implements similar
functionality to that provided by the IPersistFile standard OLE
interface. Instead of saving and loading data to and from a file,
the ICOM_PersistRegDB operates on the registration database. The
following is a description of the ICOM_PersistRegDB interface.
TABLE-US-00008 DECLARE_INTERFACE_( ICOM_PersistRegDB, IUnknown ) {
STDMETHOD ( IsDirty )( THIS ) PURE; STDMETHOD ( Load )( THIS_HKEY
hKey ) PURE; STDMETHOD ( Save )( THIS_HKEY hKey ) PURE; STDMETHOD (
Clear )( THIS_HKEY hKey ) PURE; };
[0455] The ILNG_DrvCore_Init interface is used to initialize the
language driver component. The following is a description of the
ILNG_DrvCore_Init interface. TABLE-US-00009 DECLARE_INTERFACE_(
ILNG_DrvCore_Init, IUnknown ) { STDMETHOD (Create)( THIS.sub.--
LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Destroy)( THIS ) PURE;
STDMETHOD (Setup)( THIS.sub.-- LPLNG_DRIVER_INFO pDI ) PURE;
STDMETHOD (Stat)( THIS.sub.-- LPLNG_DRIVER_INFO pDI ) PURE;
STDMETHOD (Register)( THIS ) PURE; STDMETHOD (UnRegister)( THIS )
PURE; STDMETHOD (IsRegistered)( THIS.sub.-- LPBOOL pbRegistered )
PURE; STDMETHOD (Enable)( THIS.sub.-- BOOL fEnable ) PURE;
STDMETHOD (IsEnabled)( THIS.sub.-- LPBOOL pbEnabled ) PURE; };
[0456] The ILNG_DrvExt_StreamMgmt interface is used to perform all
stream operations. The following is a description of the
LNG_DrvExt_StreamMgmt interface. TABLE-US-00010 DECLARE_INTERFACE_(
ILNG_DrvExt_StreamMgmt, IUnknown ) { STDMETHOD
(GetStreamEnumeration)( THIS_LPENUMUNKNOWN FAR *ppEnumStream )
PURE; STDMETHOD (GetStreamCount)( THIS_LPDWORD pdwCount ) PURE;
STDMETHOD (GetStreamInit)( THIS_XMC_STREAMID idStream,
LPXMCSTREAMINIT FAR *ppStreamInit ) PURE; STDMETHOD
(GetStreamInitAt)( THIS_DWORD dwldx, LPXMCSTREAMINIT FAR
*ppStreamInit ) PURE; STDMETHOD (AddStream)( THIS_LPXMCSTREAMINIT
pStreamInit ) PURE; STDMETHOD (RemoveStream)( THIS_LPXMCSTREAMINIT
pStreamInit, BOOL bDestroy ) PURE; STDMETHOD (RemoveStream)(
THIS_XMC_STREAMID idStream, BOOL bDestroy ) PURE; STDMETHOD
(RemoveAllStreams)( THIS_BOOL bDestroy ) PURE; STDMETHOD
(EnabledStreamsOnly)( THIS_BOOL bEnabledOnly, LPBOOL
pbOldEnabledOnly ) PURE; };
[0457] The following are the functions exported by the driver DLL.
TABLE-US-00011 XMC_DRIVER_MODULETYPE DLLGetModuleType( void );
LPCLSID DLLGetCLSID( void ); BOOL DLLRegisterServer( void ); BOOL
DLLUnRegisterServer( void );
[0458] The following discussion defines all structures,
enumerations, and defines used by the driver.
[0459] The XMC_DRIVER_MODULETYPE enumeration defines the type of
drivers available. Each driver must return its type when the user
calls the exported DLLGetModuleType function.
[0460] enum XMC_DRIVER_MODULETYPE TABLE-US-00012 { XMC_DRIVER_MT =
0x4000, XMC_DRIVER_MT_AT6400 = 0x4001, XMC_DRIVER_MT_DMC1000 =
0x4002, XMC_DRIVER_MT_DT2000 = 0x4003, XMC_DRIVER_MT_CUSTOM =
0x4004 };
[0461] The XMC_DRVCORE_CMD enumeration defines an identifier for
every command known to the XMC Driver. For example, every core
Driver function has a corresponding XMC_DRVCORE_CMD identifier.
This index is used to look up the string block for the command. The
definition of the enumeration is as follows. TABLE-US-00013 enum
XMC_DRVCORE_CMD { XMC_DCC_MOTION_MOVEABS, XMC_DCC_MOTION_KILL, :
};
[0462] The XMC_DRVEXT_CMD enumeration defines an identifier for
every extended command known to the XMC Driver. Even though the
identifiers exist, the driver may or may not implement the set of
commands. For example, every extended Driver function has a
corresponding XMC_DRVEXT_CMD identifier. This index is used to look
up the string block for the command (if the driver implements the
command). The definition of the enumeration is as follows.
TABLE-US-00014 enum XMC_DRVEXT_CMD { XMC_DCE_MOTION_MOVEREL, :
};
[0463] The LNG_PARAM_DATATYPE enumeration defines all types of data
blocks that may be parsed from response strings returned by stream
targets. TABLE-US-00015 typedef enum_LNG_PARAM_DATATYPE {
LNG_ADT_NOP, LNG_ADT_NOTYPE, LNG_ADT_NUMBER, LNG_ADT_STAT_STRING,
LNG_ADT_MEM_STRING } LNG_PARAM_DATATYPE;
[0464] The LNG_PARAM_DATA structure stores all types of data that
describe a parameter either built into a command, or parsed from a
response. TABLE-US-00016 struct LNG_PARAM_DATA { //---- Constructor
& Destructor ---- LNG_PARAM_DATA( void );
.about.LNG_PARAM_DATA( void ); //---- Data ---- LNG_PARAM_DATATYPE
adt; union { double df; LPTSTR psz; }; };
[0465] The LNG_DRIVER_INFO structure is used when setting up and
querying the state of the driver. TABLE-US-00017 typedef struct
_LNG_DRIVER_INFO { DWORD m_mt; LNG_DRIVERID m_ID; TCHAR m_szName[
LNG_DRIVER_NAME_LEN+1 ]; TCHAR m_szDescription[
LNG_DRIVER_DESC_LEN+1 ]; TCHAR m_szHWVendor[ LNG_DRIVER_NAME_LEN+1
]; } LNG_DRIVER_INFO;
[0466] Each XMC Driver is responsible for managing all streams
used. In order to manage each stream over time in a persistent
manner each driver and stream module implement the persistent
functionality exposed through the ICOM_PersistRegDB interface. When
the driver's implementation of ICOM_PersistRegDB::Save is called,
the data is saved to the registry in the following order.
TABLE-US-00018 XMCDriverAdminObject.100 |---- Drivers |---- dwCount
= <# of drivers> |---- XMCDrv_0 | |---- CLSID = {clsid} |
|---- dwFlags = <driver flags> | |---- dwID = <driver
ID> | |---- dwModuleType = XMC_DRIVER_MT_xxx | |----
szDescription = <user desc of the driver> | |---- Streams |
|---- Count = <# of streams> | |---- XMCStrm_0 | | |----
CLSID = {clsid} | | |---- dwID = <strm id> | | |----
dwModuleType = XMC_STREAM_MT_xxx | | |---- <stream specific
values> | | | |---- XMCStrm_<n> | |---- .sub.-- | |----
XMCDrv_<n> |---- .sub.--
[0467] It should be clear from the foregoing that the present
invention may be embodied in other specific forms without departing
from the essential characteristics thereof. The present embodiments
are therefore to be considered in all respects as illustrative and
not restrictive, the scope of the invention being indicated by the
appended claims rather than by the foregoing description; all
changes which come within the meaning and range of equivalency of
the claims are therefore intended to be embraced therein.
* * * * *