`
`-5‘,
`.
`%/@se?3
`
`8
`
`MOTION CONTROL SYSTEMS
`
`TECHNICAL FIELD
`
`The present invention relates to motion
`
`to
`control systems and, more particularly,
`interface software that facilitates the creation
`
`of hardware independent motion control software.
`
`BACKGROUND OF THE INVENTION
`
`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.
`While the mechanical system comonly
`
`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.
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`ROY—G—BIV CORPORATION
`
`EXHIBIT 2010-5
`
`ABB V ROY—G—B|V
`
`TRIAL |PR2013—0O062
`
`
`
`
`
`present invention should thus be determined based
`
`on the claims appended hereto and not the
`
`following detailed description.
`
`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.
`
`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.
`
`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.
`
`Companies that manufacture motion control
`
`devices are,
`
`traditionally, hardware oriented
`
`companies that manufacture software dedicated to
`
`the hardware that they manufacture. These
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`
`
`J
`
`.
`
`software products may be referred to as low level
`
`programs.
`
`Low level programs usually work
`
`directly with the motion control comand 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.
`
`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.
`
`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
`
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`
`
`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.
`
`As mentioned above, a number of software
`
`programs currently exist for programing
`
`individual motion control devices or for aiding in
`
`the development of systems containing a number of
`
`10
`
`motion control devices.
`
`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) QpenBatch 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.
`
`The following list identifies documents
`
`related to low—level programs:
`
`(a) Compumotor
`
`Digiplan 1993-94 catalog, pages 10-11;
`
`(h)
`
`Aerotech Motion Control Product Guide, pages 233-
`
`34;
`
`(c)
`
`PMAC Product Catalog, page 43;
`
`(d) PC/DSP-
`
`Series Motion Controller C Programming Guide,
`
`15
`
`20
`
`25
`
`30
`
`
`
`
`
`pages 1-3;
`
`(e) Oregon Micro Systems Product Guide,
`
`page 17;
`
`(f) Precision Microcontrol Product Guide.
`
`The Applicants are also aware of a software
`
`model referred to as WOSA that has been defined by
`
`Microsoft for use in the Windows programing
`
`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
`
`10
`
`Backgrounder: Delivering Enterprise Services to
`The WOSA model
`
`the Windows-based Desktop.
`
`isolates application programmers from the
`
`complexities of programing to different service
`
`providers by providing an API layer that is
`
`independent of an underlying hardware or service
`
`15
`
`and an SPI layer that is hardware independent but
`
`service dependent.
`
`The WOSA model has no relation
`
`to motion control devices.
`
`The Applicants are also aware of the comon
`
`20
`
`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
`
`25
`
`30
`
`given printer to allow the application program to
`
`print on that given printer.
`
`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 comands.
`
`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.
`
`10
`
`15
`
`20
`
`OBJECTS OF THE INVENTION
`
`From the foregoing, it should be clear that
`
`one primary object of the invention is to provide
`
`improved methods and devices for moving objects.
`
`Another more specific object of the present
`
`invention is to obtain methods and apparatus for
`
`designing and deploying motion control devices in
`
`which these methods and apparatus exhibit a
`
`favorable mix of the following characteristics:
`
`_ (a) allow the creation of high—level motion
`
`control programs that are hardware independent,
`
`but offer programmability of base motion
`operations;
`
`(b) hide the complexities of programing for
`
`multiple hardware configurations from the high-
`
`25
`
`level programmer;
`
`(C) can easily be extended to support
`
`additional hardware configurations; and
`
`(c)
`
`transparently supports industry standard
`
`high—level programming environments.
`
`30
`
`SUMMARY OF THE INVENTION
`
`The present invention is,
`
`in one form, a
`
`method of moving an object comprising the steps of
`
`
`
`
`
`developing a high—level motion control application
`
`program comprising a sequence of component
`
`functions that describe a desired object path,
`
`correlating these component functions with driver
`
`functions, selecting a software driver for the
`
`specific hardware configuration being controlled,
`
`generating control commands from the driver
`
`functions and the software driver associated with
`
`the hardware configuration being controlled, and
`
`controlling a motion control device based on the
`
`control data to move the object along the desired
`
`object path.
`
`In another form,
`
`the present invention is a
`
`method of generating a sequence of control
`
`commands for controlling a motion control devices
`
`to move an object along a desired path. An
`
`application program comprising a series of
`
`component functions defines a sequence of motion
`
`steps that must be performed by the motion control
`
`device to move the object along the desired path.
`
`The component functions contain code that relates
`
`the component-34-functions to driver functions.
`
`The driver functions are associated:$;g%£é§:;a::f1a*”‘
`
`_
`
`software drivers containing driver code for
`
`implementing the motion steps on a given motion
`
`control device.
`
`The control commands are
`
`generated based on the application program and the
`
`driver code associated with a given motion control
`device.
`
`The use of component functions that are
`
`separate from driver functions isolates the
`
`programmer from the complexities of programing to
`
`a specific motion control device. This
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`
`
`arrangement also allows a given application
`
`program to be used without modification for any
`
`motion control device having a software driver
`
`associated therewith.
`
`The driver functions are grouped into core
`
`driver functions and extended driver functions.
`
`All software drivers must support
`
`the core driver
`
`functions;
`
`the software drivers may also support
`
`one or more of the extended driver functions,
`
`although this is not required.
`
`Where the software drivers do not support the
`
`extended driver functions,
`
`the functionality
`
`associated with the extended driver functions can
`
`normally be simulated using some combination of
`
`core driver functions.
`
`In this case,
`
`the method
`
`of the present invention comprises the steps of
`
`determining which of the extended driver functions
`
`are not supported by the software driver and,
`
`where possible, substituting a combination of core
`
`driver functions.
`
`In some cases,
`
`the
`
`functionality of an extended driver function
`
`cannot be emulated using core driver functions,
`
`and this functionality is simply unavailable to
`
`the programmer.
`
`The use of core driver functions to emulate
`
`extended driver functions provides functionality
`
`where none would otherwise exist, but the
`
`preferred approach is to provide a software driver
`
`10
`
`15
`
`20
`
`25
`
`that supports each of the extended driver
`
`30
`
`functions. When an extended driver function is
`
`supported and not emulated,
`
`the task being
`
`performed will normally be accomplished more
`
`quickly and accurately.
`
`
`
`
`
`Additionally,
`
`to simplify the use of emulated
`the method of the
`
`extended driver functions,
`
`present invention further comprises the steps of
`
`determining which,
`
`if any, extended driver
`
`functions are not supported by the software driver
`
`for a given hardware configuration, developing a
`
`function pointer table of both unsupported
`
`extended driver functions and supported extended
`
`driver functions, and consulting the table each
`
`10
`
`time an extended driver function is called to
`
`15
`
`20
`
`determine whether that extended driver function
`must be emulated.
`In this manner,
`the process of
`
`calling the sequence of core driver functions
`employed to emulate the unsupported extended
`
`driver functions is optimized.
`
`_
`
`As the control commands are generated as
`
`described above,
`
`they may be used to control a
`
`motion control device in real time or they may be
`the
`
`stored in a file for later use. Preferably,
`
`method of the present invention comprises the step
`
`of providing a number of streams containing stream
`code.
`Each stream is associated with a
`
`destination of control commands, and the stream
`
`25
`
`code of a given stream dictates how the control
`commands are to be transferred to the destination
`
`associated with that given stream.
`
`The user is
`
`'thus provided the opportunity to select one or
`more streams that dictate the destination of the
`
`control comands.
`
`30
`
`To help isolate the programer from hardware
`
`specific complexities,
`
`the method of the present
`
`invention may comprise the additional
`
`administrative steps such as selecting a driver
`
`
`
`
`
`-10-
`
`associated with a particular motion control device
`
`and/or translating units required to define the
`
`motion control system into the particular system
`
`of units employed by a given motion control
`
`device.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG.
`
`1 is a system interaction map of a
`
`motion control system constructed in accordance
`
`10
`
`with, and embodying,
`
`the principles of the present
`
`invention;
`
`FIG.
`
`2 is a module interaction map of a
`
`motion control component of the system shown in
`
`/9 7
`
`M
`
`FIG. 1;
`
`15
`
`FIG.
`
`3 is an object interaction map of the
`
`component shown in FIG. 2;
`
`FIGS. 4;§$ggL$3E8 are scenario maps of the
`
`component shown in FIG. 2;
`FIG.
`
`9 is an interface map of the component
`
`20
`
`shown in FIG. 2;
`
`FIG. 10 is a data map showing one exemplary
`
`method of accessing the data necessary to emulate
`
`extended driver functions using core driver
`
`functions;
`
`25
`
`FIG.
`
`11 is a module interaction map of the
`
`driver portion of the system shown in FIG. 1;
`FIG.
`
`12 is an object interaction map of the
`
`a%;
`driver portion sh wn in FIG.
`H! 1871719’ 1‘laM~
`FIGS.
`l3;£%r%u§h!20‘are scenario maps related
`to the driver shown in FIG. 11;
`
`30
`
`FIG.
`
`21 is an interface map for the driver
`
`shown in FIG. 11;
`
`//
`
`10
`
`
`
`
`
`-11-
`
`‘Z’ 1/4
`
`FIG. 22 is a module interaction map of the
`
`streams used by the system shown in FIG. 1;
`
`FIG. 23 is an object interaction map of the
`
`streams shownAigdf}§igfi§fi5,,;[and.‘
`FIGS.
`2% shreuéh~32 are scenario maps of the
`streams shown in FIG. 22;
`
`FIG.
`
`33 is an interface map of the objects
`
`comprising the stream shown in FIG. 22;
`FIG.
`
`34 is a module interaction map of the
`
`10
`
`driver stub portion of the system shown in FIG. 1;
`FIG.
`
`35 is an object interaction map of the
`
`driver stub show? i
`FIG. 34;
`FIGS. 36}ehrg§§h 38 are scenario maps of the
`3
`
`driver stub shown in FIG. 34;
`
`15
`
`FIG.
`
`39 is an interface map of the driver
`
`stub portion shown in FIG. 34;
`
`FIG. 40 is a module interaction map of the
`
`driver administrator portion of the system shown
`
`in EIG. 1;
`
`20
`
`FIG.
`
`41 is an object interaction map of the
`
`driver administrator shown in IG. 40;
`
`FIGS. 42 qa4%4 *Z§%§§:°§%énario maps
`relating to the driver administrator shown in
`FIG. 40;
`
`25
`
`FIG.
`
`50 is an interface map of the objects
`
`that comprise the driver administrator shown in
`
`FIG. 40;
`FIG.
`
`51 is a module interaction map of the
`
`driver administrator CPL applet portion of the
`
`30
`
`system shown in FIG. 1;
`FIG.
`
`52 is an object interaction map of the
`
`driver administrator CPL applet shown in FIG. 51;
`
`11
`
`
`
`
`
`_12_
`
`41’
`
`54 amw‘
`FIGS. 53fbéreugh~57 are scenario maps related
`to the driver administrator CPL applet shown in
`FIG. 51.
`
`12
`
`
`
`
`
`-13-
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`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.
`
`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.
`
`__ 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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`devices 20a, 20b, and 20c, respectively.
`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
`
`13
`
`
`
`
`
`-14-
`
`extent necessary to provide a complete
`
`understanding of the present invention.
`
`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.
`
`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 comunication
`
`protocol that allows the control commands to reach
`
`the_appropriate motion control device 28 via an
`
`appropriate channel (i.e.,
`
`PC bus,
`
`serial port).
`
`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
`
`In the normal case,
`
`the
`
`16.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`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
`
`Ql
`
`14
`
`
`
`
`
`-15-
`
`defined at the time the application program 26 was
`created.
`
`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
`
`the framework of the software system
`discussion,
`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 Comands for
`
`Controlling a Motion Control Device to Move an
`
`Object
`
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`will become apparent from the following
`discussion.
`
`The software system designer develops the
`
`software system 22.
`
`The software system designer
`
`initially defines a set of motion control
`
`15
`
`
`
`
`
`-16-
`
`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.
`
`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.
`
`Given the set of motion control operations as
`
`the software system designer next
`defined above,
`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.
`
`10
`
`15
`
`20
`
`25
`
`are associated with primitive operations, while
`
`30
`
`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
`
`16
`
`
`
`
`
`-17-
`
`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.
`
`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.
`
`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 34 functions.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`/,//’
`
`17
`
`
`
`
`
`-18-
`
`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.
`
`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.
`
`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.
`
`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 34. Applications may
`
`program the system 22 either through OLE
`
`Automation or by using any of the custom OLE
`
`interfaces making up the API.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`18
`
`
`
`
`
`Q
`
`C
`
`-19-
`
`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.
`
`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.
`
`the driver
`As currefigly implemented,
`administrator&&4—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
`
`10
`
`15
`
`20
`
`25
`
`drivers.
`
`The software system 22 thus generates control
`
`commands based on the component %4~functions
`
`contained in the application program 26,
`
`the
`
`30
`
`component—%+ code associated with the component 34
`functions, and the driver code associated with the
`selected software driver 28.
`
`As the control commands are being generated
`
`as described above,
`
`they may be directly
`
`19
`
`
`
`
`
`‘x
`
`-20-
`
`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.
`
`In the exemplary system 22,
`
`the destinations
`
`of the control commands may be one or more of an
`Other
`
`output file 34 and/or the controllers 16.
`
`10
`
`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
`
`15
`
`stream 28 that determines how the control comands
`
`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
`
`20
`
`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 comand destination 16
`
`25
`
`and/or 34.
`
`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
`
`30
`
`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
`
`20
`
`
`
`
`
`-21-
`
`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.
`
`Referring again to FIG. 1,
`
`this Figure shows
`
`that the system 22 further comprises a motion
`35
`control componentN%4-and a driver sépb module 36.
`The motion control component module,§t~is the
`portion of the software system 22 that relates the
`
`10
`
`component-$4-functions to the driver functions.
`The motion control component moduleigé thus
`contains the component 34.code that makes the
`
`association between the component 34.functions
`
`contained in the application program 26 and the
`
`15
`
`driver functions.
`
`20
`
`25
`
`30
`
`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 accomodate
`
`diverse motion control hardware configurations
`
`with minimal effort.
`
`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.
`
`P P
`
`??PE’
`
`«Q52
`
`21
`
`
`
`
`
`-22-
`
`The motion control component 24 will
`
`determine for the selected software driver 30
`
`which extended functions,
`
`driver 30 supports.
`
`Foriggégfiagfgnctions that are
`
`i
`
`an ,
`
`the selected
`
`5
`
`not supported, referred to herein as non-supported
`
`the motion control
`extended_§§iver functions,
`componentkkk-refers to the driver stub module 36
`to determine the appropriate combination of core
`
`driver functions to emulate the functionality of
`
`10
`
`the non-supported extended driver functions.
`
`The
`
`system 22 thus generates the control comands
`
`necessary to implement the non-supported extended
`
`driver functions using the appropriate combination
`of core driver functions.
`
`15
`
`The process of determining when extended
`
`driver functions need to be emulated can be
`
`optimized33y'providing the motion control
`—componentA24-with a function pointer table that
`contains a pointer to each of extended functions.
`
`20 When building the function pointer table,
`the
`motion control componentigé checks the selected
`driver module 30 to see if it supports each
`
`extended function.
`
`If the selected driver module
`
`25
`
`30
`
`the motion
`30 supports the extendedsgunction,
`control component module’@4-stores a pointer to
`the function,
`implemented by the selected driver
`
`in the table location corresponding to
`module 30,
`the extended function.
`In the event that the
`
`selected driver module 30 does not support the
`
`the motion control component
`extendfig_function,
`moduleR&& stores a pointer to the extended
`function implementation located in the driver stub
`module 36.
`The driver stub module 36
`
`22
`
`
`
`
`
`-23-
`
`implementation of the extended function contains
`
`calls to a plurality of core functions implemented
`
`by the selected driver module 30.
`
`the driver stub module 36 allows
`Therefore,
`Q
`.
`S
`_
`<v%Hstx,q
`.
`_
`_
`_
`flnétzxn
`the hardware designfir ti use, with minimal
`time
`'\
`ta.»
`and effortfbé working software driv r 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
`
`10
`
`improved by developing driver code to implement
`extended driver functions as desired.
`
`The use of driver code specifically designed
`
`to implement extended driver functions is,
`
`in
`
`general, preferable to relying on the driver stub
`
`15
`
`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
`
`20
`
`driver function with a combination of core driver
`
`functions.
`
`Referring again for a moment to FIG. 1,
`
`this
`
`Figure illustrates that the system 22 additionally
`
`comprises a driver administrator CPL applet 38 and
`
`25
`
`a DDE server 40.
`
`The driver