MOTION CONTROL SYSTEMS

Abstract: A system for motion control in which an application is developed that is independent from the actual motion control hardware used to implement the system. The system comprises a software system that employs an application programming interface (26) comprising component functions and a service provider interface comprising driver functions. A system programmer (24) writes an application that calls the component functions. Code associated with the components relates these functions to the driver functions. A hardware designer (16a) writes driver code that implements the driver functions on a given motion control hardware product. The driver functions (38) are separated into core and extended driver functions. All software drivers implement the core driver function, while the software drivers need not contain code for implementing the extended driver functions. If the software driver does not contain code to implement an extended driver function, the functionality of the extended driver function is obtained through a combination of core driver functions.

Description: MOTION CONTROL SYSTEMS TECHNICAL FIELD 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 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 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 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 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 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. 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 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 programming individual motion control devices or for aiding in the development of systems containing a number of 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) 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. 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. 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 M 5 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. The Applicants are also aware of the common programming practice in which drivers are 10 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. 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 15 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. 20 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 From the foregoing, it should be clear that one primary object of the invention is to 25 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 30 independent, but offer programmability of base motion operations; (b) hide the complexities of programming for multiple hardware configurations from the high-level programmer; (c) can easily be extended to support additional hardware configurations; and (c) transparently supports industry standard high-level programming environments. 35 >. 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 functions to driver functions The driver functions are associated with, or contain, 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 programming to a specific motion control device This 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 emulεted 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 that supports each of the extended driver 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 extended driver functions, the method of the 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 time an extended driver function is called to 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 \ m 5 a motion control device in real time or they may be stored in a file for later use. Preferably, the 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 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 10 one or more streams that dictate the destination of the control commands. To help isolate the programmer from hardware specific complexities, the method of the present invention may comprise the additional administrative steps such as selecting a driver 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 15 device. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a system interaction map of a motion control system constructed in accordance with, and embodying, the principles of the present invention; 20 FIG. 2 is a module interaction map of a motion control component of the system shown in FIG. 1 ; FIG. 3 is an object interaction map of the component shown in FIG. 2; FIGS. 4 through 8 are scenario maps of the component shown in FIG. 2; FIG. 9 is an interface map of the component shown in FIG. 2; 25 FIG. 10 is a data map showing one exemplary method of accessing the data necessary to emulate extended driver functions using core driver functions; 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 driver portion shown in FIG. 11 ; FIGS. 13 through 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 ; 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 shown in FIG. 22; FIGS. 24 through 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; *"' 35 FIG. 34 is a module interaction map of the driver stub portion of the system shown in FIG. 1 ; FIG. 35 is an object interaction map of the driver stub shown in FIG. 34; FIGS. 36 through 38 are scenario maps of the driver stub shown in FIG. 34; 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 FIG 1 , FIG 41 is an object interaction map of the driver administrator shown in FIG 40, FIGS 42 through 49 are scenario maps relating to the driver administrator shown in FIG 40, 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 system shown in FIG 1 , FIG 52 is an object interaction map of the driver administrator CPL applet shown in FIG 51 , FIGS 53 through 57 are scenario maps related to the driver administrator CPL applet shown in FIG 51 , FIG 58 depicts a Module Interaction-Map showing all binary modules that interact with the driver and how they interact with one another, 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, FIGS 60-65 depict a number of Scenario Maps that display the interactions taking place between the C++ objects involved during certain processes, 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 FIG 67 depicts a table illustrating how a typical database employed by the language driver 44 may be constructed 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 V r, 5 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 10 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 15 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. The hardware bus 14, hardware controllers 16, and mechanical systems 18 are ail well- known in the art and are discussed herein only to the extent necessary to provide a complete 20 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 25 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). 30 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; 35 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. 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 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 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 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 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 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 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. 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 35. Applications may program the system 22 either through OLE Automation or by using any of the custom OLE interfaces making up the API. 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 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 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 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 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 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 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 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 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 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 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 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 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 Refernng 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 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 This section describes the design of the motion control component 35 in three mam 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 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 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 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 The CDπverAdmin object is used to communicate directly with the driver administrator component All OLE related details are encapsulated within this class The CDπverMgr 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 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 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 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 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 CoCreatelnstance 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 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 CoCreatelnstance 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 CDπverAdmin to get the current drιver(s) to use The CDπverAdmin, first, loads the driver administrator 32 using the standard OLE CoCreatelnstance function Next, it initializes the driver administrator Then, it queries the driver administrator for the drιver(s) to use and their SPI support information Finally, the driver administrator returns the drιver(s) and the support information to the component 35, and releases all interfaces used from the driver administrator component 32 Once receiving the active drιver(s) 30 and their support information, the motion control component 35 passes the dπver(s) 30 to the CDπverMgr and directs it to initialize the system During its initialization the CDnverMgr initializes the CUnitMapper Also while initializing, the CDπverMgr 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 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 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 CDnverMgr to perform the operation and passes all pertinent parameters to it Before carrying out the operation, the CDnverMgr uses the CUnitMapper to convert all units to the Machine Coordinate System (MCS) Next, the CDnverMgr 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 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 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 CDnverMgr to perform the operation and passes all pertinent parameters to it Before carrying out the operation, the CDnverMgr uses the CUnitMapper to convert all units to the Machine Coordinate System (MCS) Next, the CDnverMgr 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 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 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 CDnverMgr to carry out the operation and passes the PCS parameters to it The CDnverMgr takes all measurements and uses the CUnitMapper to convert them to the MCS The newly mapped parameters are then passed to the Cdnver The CDriver directs either the driver or the driver stub component to carry out the operation 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 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 CDπverMgr to release any resources it is using The CDnverMgr 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 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 heieto 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 The driver 30 is used by both the driver administrator 32 and the component 35 Its mam 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 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 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 Break g 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 Each object in the diagram is described as follows CDnverDisp 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 CDnverDisp object takes care of packing outgoing data and unpacking incoming data Data packing involves converting the data between a raw and native C++ format 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 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, CCommandϋst, and CStream objects 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 The CCommand object builds command strings that are then sent to the CStream Each command built is a complete motion control command string The CResponseϋst object builds CResponse objects that are initialized with the parsing format for the expected response 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 The CStream object is used to communicate directly with the underlying stream component Figures 14-20 contain scenario maps that describe all mam 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 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 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 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 Referring now to Figure 14, after the driver is registered, the driver administrator can load the component 35 using the OLE CoCreatelnstance function During the initialization process the driver loads all registration data and initializes both the CDnverDisp and CStreamMgr C++ objects During initialization, the following steps occur 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 CoCreatelnstance When first loaded, the driver loads any registration data previously stored Next, the driver directs the CDnverDisp object to initialize the system When notified the CDnverDisp 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 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 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 CDnverDisp object and directs it to add the stream The CDnverDisp 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 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 First the driver administrator, calls the interface method used to query the driver's stream enumeration Next, the driver directs the CDnverDisp to create the stream enumeration The CDnverDisp 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 CoCreatelnstance API 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 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 CDnverDisp object The CDnverDisp 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 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 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 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 CoCreatelnstance 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 CDπverDisp to initialize the internal system The CDnverDisp 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 CoCreatelnstance function Once the CStreamMgr is done, the CDnverDisp 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 CResponseϋst corresponding to the CCommandList 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 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 CDnverDisp object to perform the operation The CDnverDisp 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 CResponseϋst to create a CResponse object The CResponseϋst 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 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 CDnverDisp object Eventually the CResponse returns to the CDnverDisp 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. 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. 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 CResponseϋst object. 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 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. 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. 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. 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. 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 differed target that defines the type of the stream. The following are the current stream targets. 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. PC Bus/Win95 - This Windows 95 stream uses a Windows 95 VxD to communicate directly with the motion control hardware connected to the PC Bus. PC Bus/Win 3.1 - This Windows 3.1 stream communicates directly with the motion control hardware connected to the PC Bus. Serial - This stream uses the COMM API to communicate with the motion control hardware connected to the serial port. Text File - This stream is write-only and sends all data to a text file. Debug Monitor - This stream is write only and sends all data to the debug monitor Custom - This is a custom stream that sends data to an unknown location 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 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 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 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 The CIOHAL object is the input/output hardware abstraction layer With in this object lay all hardware dependent code such as calls to mp and outp Each different type of stream contains a different implementation of this object 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 Operations directed by the driver administrator are usually related to initializing, unmitializing, and configuring the stream The following sections describe all operations, directed by the driver administrator, that take place on the stream 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 O component, such as the stream component FIG 24 describes this process During the registration process, the following steps occur 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 After the stream component is successfully registered, it is ready for initialization Dunng 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 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 VxD integrity is verified with a quick, dynamic, load and unload 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 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 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 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 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 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 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 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 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. 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. 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. 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. 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. 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 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 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 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 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 Each object in the diagram is described as follows The CDπverStubDisp 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 CDπverStubDisp object takes care of packing outgoing data and unpacking incoming data Data packing involves converting the data between a raw and native C++ format The CSPIMgr object is responsible for managing all SPI issues such as managing the CSimpleDπver by directing it to connect to the appropriate SPI core interfaces exposed by the driver The CSimpleDπver object is used to directly communicate with the driver implementing the SPI core interfaces The CSimpleDπver only communicates with the core SPI interfaces implemented by the driver 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 ail 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 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 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 CoCreatelnstance 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 The component creates an instance of the driver stub by calling the standard OLE function CoCreatelnstance 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 CDnverStubDisp object and directs it to initialize the system The CDπverStubDisp object then directs the CSPIMgr to initialize itself and passes the driver CLSID to it The CSPIMgr passes the CLSID to the CSimpleDπver and directs it to only query the core SPI interfaces exposed by the driver The CSimpleDπver loads an instance of the driver then queries all core interfaces exposed by the driver 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 First the component 35 must request the operation and pass all pertinent parameters to the driver stub Next, the driver stub directs the CDnverStubDisp to handle the operation The CDnverStubDisp 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 CSimpleDπver for core operations When directed, the CSimpleDπver performs SPI core functions by directly calling the exposed interfaces implemented by the driver 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 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 CDnverStubDisp object The CDnverStubDisp 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. 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 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 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 This section describes the driver administrator 32 in three mam 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 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 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 In addition, the driver administrator is used by the component 35 to access the current drιver(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 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 Each object in the diagram is described as follows The CDπverAdminDisp 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 CDπverAdminDisp object takes care of packing outgoing data and unpacking incoming data Data packing involves converting the data between a raw and native C++ format The CDπverlnfoMap object is used to build the information used by the driver administrator CPL 38 when displaying information about each driver or stream 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 The CSimpleDriver object is used to directly communicate with the driver component All OLE specific details are encapsulated within this object The CSimpleStream object is used to directly communicate with the stream component All OLE specific details are encapsulated within this object 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 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 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 CoCreatelnstance Next, the exposed Initialize interface method must be called When the Initialize method is called, the driver administrator component directs the CDπverAdminDisp to initialize the system Next, the CDπverAdminDisp 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 CoCreatelnstance 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 CoCreatelnstance 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. 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. 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 CoCreatelnstance. If the CSimpleDriver is successful, the CModuleMgr stores the driver CLSID in the registration database. 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. 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. 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 CoCreatelnstance. 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. 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 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 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 As shown in FIG 46, when the user edits stream settings in the driver administrator CPL 38, the following steps occur 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 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 corresoonding 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 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. 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 lUnknown interface for the driver, depending on the parameters of the enumeration. If the CSimpleDriver is requested to return a pointer to the lUnknown interface, the interface is queried from the driver component. 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. 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 CDriverlnfoMap class. The CDriverAdminDisp creates the CDriverlnfoMap. Next, the CDriverAdminDisp passes the CDriverlnfoMap 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. 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. 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. 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 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. 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. 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. 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. The design goals for the driver administrator 32 are the following: 1. User-Interface separation - Implement all user-interface elements used to control the driver administrator 32 Component. 2. Upgradable to OCX Client - Eventually each driver and stream may implement all Ul 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. 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. 4. Use Windows 95 Ul - When ever possible, Windows 95 Ul elements should be used. For example, TreeViews, ImageLists, Button Bars, Tab Dialogs and any other Ul elements should be put to use to ensure a Windows 95 look-and-feel. 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. 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. The Driver Administrator Dialog is the main dialog that appears when selecting the control panel applet icon from the Windows Control Panel. 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. 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. 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. Other than showing that each dialog is managed by the object, whose name is displayed in the dialog, the main difference from the module lA-map are both the CComCPL and CDriverAdmin C++ objects. Both objects are described below. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. The process of updating the main dialog is identical to the process of initializing the dialog discussed above. 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. 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. The process of updating the main dialog is identical to the process of initializing the dialog discussed above. 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. 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. 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 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. 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. 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. 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. 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. The properties affecting drivers 30 are as follows. 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. Units - Setting the units property affects all coordinates used when programming the system 22. Th e unit descriptions are as follows: MM_ENGLISH - Inches are used as the base unit for all coordinates MM_METRIC - Millimeters are used as the base unit for all coordinates. 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. 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. 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. 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 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. Selecting the Remove button, removes the current driver or stream selected. If a driver is removed all of its streams are also removed. 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. The following are descriptions of each graphic found in the XMC Support View Dialog. D - This graphic means that the interface or method is implemented by the driver 30. S - This graphic means that the interface or method is implemented within the driver stub 36. X - This graphic means that the interface or method is disabled because of a lack of implementation within the driver 30. 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. 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. 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. This section describes the streams supported by the system 22 and how they are configured. 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. 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. The I/O Port is the base port used to communicate with the motion control hardware that the stream is to send data to. The IRQ is the interrupt request level used by the hardware. 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. 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. 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 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 The Port is the serial port that the hardware is connected to COM1 - COM4 are valid ports that can be used The Baud Rate is the speed of data transmission supported by the hardware 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 When the XON/XOFF communication protocol is selected a simple and more compatible communication protocol is used 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 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 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 The following properties may be configured for the Text File Stream 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 No debug settings are available for the Text File Stream IX LANGUAGE DRIVER 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 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 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 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 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 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 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 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 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 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. 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. 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. 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. 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 The first example illustrates how the language driver 44 might deal with the Driver function IXMC_DrvExt_Test::Move. Cmd Format: D%d,+:@[snd]GO%b+:@[snd] Rsp Format: @[crlf]>@frcv]@[crlf]>@[rcv] Driver function Call: pXMCDrvExtTest->Move( 20.0, 30.0 ) 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: 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:" 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. 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>". 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 "G011", leaving off at the last macro. 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. Step 6. Again, after the send command the language driver receives a response data string from the stream as follows: "\r\n>". Step 7. The language driver next parses the response data string received in step 6. EXAMPLE 2 The second example illustrates how the language driver 44 might deal with the Driver function IXMC_DrvExt_Test::SetVelocity. Cmd Format: V%lf,+:@[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 The third example illustrates how the language driver 44 might deal with the Driver function 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 The fourth example illustrates how the language driver 44 might deal with the Driver function IXMC_DrvExt_Test::Reset. Cmd Format: !RESET:@[snd]MA0:MC0:LH0:@[sπd] Rsp Format: . @[crlf]*VENDOR NAME - MODEL@[rcv]@[crlf]>@[rcv] Driver function Call: pXMCDrvExtTest->ResetO Explanation Reset the hardware. Raw Command Stringl : "IRESET." Raw Response Stringl : "\r\n*VENDOR NAME - MODEL" (expected) Raw Command String2: "MA0:MC0:LH0:" Raw Response String2: "\r\n>" (expected) 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. 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. 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. 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. 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). 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. Mores specifically, the module interaction-map shown in FIG. 58 contains the following modules: The Driver Administrator module 32 is used to install, uninstall, register, and setup each driver and stream module. 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. 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. 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. The Registry 42 is the standard Windows registration database. 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. Each object in the diagram is described as follows. 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. CDrvCoreDisp This 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 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 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 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 CCommandMgrThis 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 CCommand The CCommand object builds command strings that are then sent to the CSimpleStream Each command built is a complete motion control command string 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 CCommandDatabase This object stores t e 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 CSPIInfo This object makes up one database entry stored within the CCommandDatabase object 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 CSimpleStreamThis object is used to initialize, create, and communicate directly with the underlying stream component CDπverinfoMgr This object is responsible for creating the CDπverlnfo object CDπverlnfo 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 CRegistryMgr This object is used to save and load the information, stored within the CDπverlnfo object, to and from the registration database In specific, contains the code called when the ICOM_PersιstRegDB interface is invoked CRegistry This object perform&all registration database operations such as creating keys, saving values, and querying values 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 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 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 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 Next, the driver administrator can load the component using the OLE CoCreatelnstance function During the initialization process, the driver loads all registration data and initializes the CDπverlnfo and all C++ manager objects The following describes in detail each of the steps set forth in FIG 60 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 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 CoCreatelnstance 3 CoCreatelnstance automatically initializes the component by calling the ICOM_Base Initialize method implemented by the CDπverObject 4 The implementation of ICOM_Base Initialize directs both the CDrvCoreDisp to initialize itself 5 Within its initialization, the CDrvCoreDisp object initializes each of its manager objects, starting with the CcommandMgr 6 During its initialization, the CCommandMgr directs the CCommandDatabase to load itself 7 To load the database, the CCommandDatabase object reads in the database and builds the CSPIInfo list of database elements 8 After initializing the CCommandMgr, the CDrvCoreDisp object directs the CDπverlnfoMgr object to create the CDnverinfo object, that will later store the internal state of the Language driver 44 component 9 The CDπverlnfoMgr object creates the CDnverinfo object and passes it back to the dispatch object The pointer to this object is later stored in the components state handle, when the CDπverObject calls ICOM_Base2 SetStateHandle 10 Next, the CDrvCoreDisp object initializes the CStreamMgr, that is used to perform all stream operations 11 Next, the CDrvCoreDisp object initializes the CRegistryMgr, that is used to perform all registration database operations 12 Finally, the CDπverObject initializes the CDrvExtDisp object It should be noted that all initialization is initiated through the COM Auto-lnit mechanism Auto-mit occurs when creating an object When calling either CoCreatelnstance or calling the ICIassFactory Createlnstance method the internal COM implementation calls the ICOM_Base::lnitialize method. This method triggers the complete initialization process described in this section. 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. Figure 61 displays the sequence of events occurring when the driver is requested to add a new stream. When adding a stream, the following steps occur: 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. 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. 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. 4. The CDrvExtDisp object first typecasts the component state data into a pointer to the CDriverlnfo object. 5. Next, the CStreamMgr, is connected to the CDriverlnfo object pointer, and directed to add a new stream. 6. In order to add the new stream, the CStreamMgr, uses a CSimpleStream to load and create the stream component. 7. The CSimpleStream object first sets function pointers to the DIIGetCLSID, DIIGetModuleType and DIIRegisterServer 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. 8. Using the DIIGetCLSID queried in the previous step, the CSimpleStream gets the components CLSID and calls CoCreatelnstance to load an instance of the OLE object. 9. After the CSimpleStream completes, the CStreamMgr adds the stream to the CDriverlnfo's stream array. 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. When querying the driver for information, the following steps are performed. 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 2 The call is handled by the implementation of the OLE interface method, implemented by on of the CDπverObject's embedded C++ classes 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 4 The dispatch object type casts the state handle to a CDriverlnfo object pointer Once converted, the CDriverlnfo object is queried for the appropriate data 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 During the registration process, the following steps occur 1 First, using the ICOM_PersιstRegDB OLE interface, exposed by the driver, the driver administrator directs the component to load its configuration data 2 The CDπverObject's embedded object, used to handle all ICOM_PersιstRegDB calls, is invoked and performs the operation 3 Once invoked, the embedded object directs the CDrvCoreDisp object to perform the load, and passes it a handle to the components state data 4 The CDrvCoreDisp object, first typecasts the state handle to a CDriverlnfo object pointer 5 Next, the CRegistryMgr is connected to the CDriverlnfo pointer, and directed to load its contents to or from the registration database 6 The CRegistryMgr loads all general driver information and fills out the drivers XMC_DRIVER_INFO data structure, stored in the CDriverlnfo object 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 8 When creating the stream, the CSimpleStream object first queries and calls the DIIGetModuleType 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 9. After registering the component, the CSimpleStream object queries and calls the DIIGetCLSID exported function to get the components CLSID. Using the CLSID, CoCreatelnstance is called to create an instance of the OLE object. 10. Once the CSimpleStream completes, the CRegistryMgr connects a temporary instance of the CStreamMgr to the CDriverlnfo object pointer, and directs it to add the new stream. 11. The CStreamMgr directly manipulates the CDriverlnfo'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. 12. When attaching itself to the stream, the new CSimpleStream queries the IXMC_Streamlnit interface, passed to it, for all interfaces used it bump up the reference counts for the component. 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. During the clean-up process, the following steps occur. 1. First, either the XMC Driver Administrator, or the XMC Motion Component call the final IUnknown::Release. 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 3. First, ICOM_Base::Uninitialize directs the CDrvExtDisp to clean up any resources that it was using. 4. Next, ICOM_Base::Uninitialize directs the CDrvCoreDisp object to clean up any resources that it was using. 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. 6. Next, the CDrvCoreDisp object implicitly destroys all other manager objects by calling their destructors. 7. And as a final step, the ICOM_Base::Uninitialize method deletes the state handle containing a pointer to the CDriverlnfo object. When destroyed, the CDriverlnfo 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. 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. 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. 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. When commanding the driver to perform a certain operation, the following steps occur 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. 2. The XMCSPI invocation is handled by the CDriverObject who implements all OLE interfaces exposed by the component. 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. 4. The dispatch object then typecasts the state handle into a CDriverlnfo object pointer. 5. Next, the dispatch object connects the CCommandMgr to the CDriverlnfo 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. 6. The CCommandMgr searches the CCommandDatabase for the index and builds a CCommand object corresponding to the XMCSPI operation. 7. Next, the CCommandMgr directly accesses the CDriverlnfo and passes the command string, built by the CCommand object, to all enabled streams. 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. 9. If directed, the CCommandMgr then queries the first readable stream for the results of the commands sent to it 1 . 10. The CSimpleStream reads the raw response from the target and returns it to the CCommandMgr. 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. 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. 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. 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. Other than the two standard interfaces exposed, such as lUnknown and ICIassFactory, there are three categories of interfaces exposed by the component. The three categories are as follows. 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. LNG: All interface names with the LNG_ prefix, implement general language driver functionality. For example, the ILNG_DrvCore_lnit, and the ILNG_DrvExt_StreamMgmt interfaces fall into this category. XMC: All interfaces name with the XMC_ prefix, implement XMCSPI (driver) functionality. 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. 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. DECLARE_INTERFACE_( ICOM_Base, lUnknown ) { STDMETHOD ( Initialize )( THIS_ LPVOID plnitlnfo ) PURE; STDMETHOD ( Uninitialize )( THIS ) PURE; }; 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. 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. }; 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. DECLAREJNTERFACE ICOM_Persist2, IPersist ) { STDMETHOD ( GetID )( THIS_ LPDWORD pdwID ) PURE; STDMETHOD ( GetModuleType )( THIS_ LPDWORD pdwMT ) PURE; }; 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. DECLARE_INTERFACE_( ICOM_PersistRegDB, lUnknown ) { STDMETHOD ( IsDirty )( THIS ) PURE; STDMETHOD ( Load )( THIS_ HKEY hKey ) PURE; STDMETHOD ( Save )( THIS_ HKEY hKey ) PURE; STDMETHOD ( Clear )( THIS_ HKEY hKey ) PURE; }; The ILNG_DrvCore_lnit interface is used to initialize the language driver component. The following is a description of the ILNG_DrvCore_lnit interface. DECLAREJNTERFACE ILNG_DrvCore_lnit, lUnknown ) { STDMETHOD (Crβate)( THIS_ LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Destroy)( THIS ) PURE; STDMETHOD (Setup)( THIS_ LPLNG_DRIVERJNFO pDI ) PURE; STDMETHOD (Stat)( THIS_ LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Register)( THIS ) PURE; STDMETHOD (UnRegister)( THIS ) PURE; STDMETHOD (lsRegistered)( THIS_ LPBOOL pbRegistered ) PURE; STDMETHOD (Enable)( THIS_ BOOL fEnable ) PURE; STDMETHOD (lsEnabled)( THIS_ LPBOOL pbEnabled ) PURE; }; The ILNG_DrvExt_StreamMgmt interface is used to perform all stream operations. The following is a description of the LNG_DrvExt_StreamMgmt interface. DECLARE_INTERFACE_( ILNG_DrvExt_StreamMgmt, lUnknown ) { STDMETHOD (GetStreamEnumeration)( THIS_ LPENUMUNKNOWN FAR "ppEnumStream ) PURE; STDMETHOD (GetStreamCount)( THIS_ LPDWORD pdwCount ) PURE; STDMETHOD (GetStreamlnit)( THIS_ XMC_STREAMID idStream, LPXMCSTREAMINIT FAR *ppStreamlnit ) PURE; STDMETHOD (GetStreamlnitAt)( THIS_ DWORD dwldx, LPXMCSTREAMINIT FAR *ppStreamlnit ) PURE; STDMETHOD (AddStream)( THIS_ LPXMCSTREAMINIT pStreamlnit ) PURE; STDMETHOD (RemoveStream)( THIS_ LPXMCSTREAMINIT pStreamlnit, BOOL bDestroy ) PURE; STDMETHOD (RemoveStream)( THIS_ XMC_STREAMID idStream, BOOL bDestroy ) PURE; STDMETHOD (RemoveAIIStreams)( THIS_ BOOL bDestroy ) PURE; STDMETHOD (EnabledStreamsOnly)( THIS_ BOOL bEnabledOnly, LPBOOL pbOldEnabledOnly ) PURE; }; The following are the functions exported by the driver DLL XMC_DRIVER_MODULETYPE DLLGetModuleType( void ), LPCLSID DLLGetCLSID( void ), BOOL DLLRegιsterServer( void ), BOOL DLLUnRegιsterServer( void ), The following discusion defines all structures, enumerations, and defines used by the driver 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 enum XMC_DRIVER_MODULETYPE { XMC_DRIVER_MT = 0x4000, . XMC_DRIVER_MT_AT6400 = 0x4001 , XMC_DRIVER_MT_DMC1000 = 0x4002, XMC_DRIVER_MT_DT2000 = 0x4003, XMC_DRIVER_MT_CUSTOM = 0x4004 }, 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 enum XMC_DRVCORE_CMD { XMC_DCC_MOTION_MOVEABS, XMC_DCC_MOTION_KILL, }, 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 enum XMC_DRVEXT_CMD { XMC_DCE_MOTION_MOVEREL, }; The LNG_PARAM_DATATYPE enumeration defines all types of data blocks that may be parsed from response strings returned by stream targets. 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; The LNG_PARAM_DATA structure stores all types of data that describe a parameter either built into a command, or parsed from a response. struct LNG_PARAM_DATA { // — Constructor & Destructor — LNG_PARAM_DATA( void ); ~LNG_PARAM_DATA( void ); // — Data — LNG_PARAM_DATATYPE adt; union { double df; LPTSTR psz; }; }; The LNG_DRIVER_INFO structure is used when setting up and querying the state of the driver, 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; Each XMC Driver is responsible for managing all streams used. In order to manage each stream overtime in a persistent manner each driver and stream module implement the persistent functionality exposed through the ICOM_PersistRegQB interface. When the driver's implementation of ICOM_PersistRegDB::Save is called, the data is saved to the registry in the following order. XMCDriverAdminObject.100 | — Drivers — dwCount = <# of drivers> — XMCDrv_0 | — CLSID = {clsid} dwFlags = <driver flags> I — dwID = <driver ID> — dwModuleType = XMC_DRIVER_MT_xxx — szDescription = <user desc of the driver> — Streams | — Count = <# of streams> - XMCStrm ) | — CLSID = {clsid} | — dwID = <strm id> | — dwModuleType = XMC_STREAM_MT_xxx | — <stream specific values> - XMCStrm <n> - XMCDrv <n> 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. XMC Motion Control XMCSPI Reference Revision: Third Draft Author: Dave Brown Date: Wednesday, Feb 22, 1995 Description: This document is the XMCAPI reference describing all functions, standard OLE interfaces, and custom OLE interfaces making up the XMCAPI. Revision History: 4 /15/9 (DB) - First Draft: Initial writing. 7/1/94 (DB) - Second Draft: Split design off small business plan, incorporated suggestions. 2 22 95 (DB) - Third Draft - Split XMCAPI reference off design guide. ROY-G-BIV Corporation Confidential © 19ΘS ROY-G-BIV Corporation. All rights reserved. XMC Motion Control XMCSPI Reference 1.0 Overview 1.0 Overview The XMCSPI is the Service Provider Interface (SPI) implemented by every XMC Driver. This layer of software, used by the XMC Motion Component, controls the specific motion control hardware corresponding to the current XMC Driver. Four categories of custom OLE 2.0 interfaces make up the complete XMCSPI layer. Out of the four categories, all XMC Drivers are required to implement one category of interfaces called core interfaces. Implementing the other three interface categories, called extended interfaces, is recommended, but not required to participate in the XMC software model. Implementing all extended interfaces is recommended for it makes the current driver-hardware interaction more precise and more efficient. Since not all hardware will support all extended interfaces, implementing them is not required. This manual describes all core and extended interfaces making up the complete set of XMCSPI custom OLE interfaces. Chapter 2.0 XMCSPI Interface Categories discusses the purpose of each category and lists the interfaces that fall in each. Chapter 3.0 extends this discussion by describing each interface and the methods they contain. ROY-G-BIV Corporation Confidential 3/15/95 - - XMC Motion Control XMCSPI Reference 2.0 XMCSPI Interface Categories 2.0 XMCSPI Interface Categories This section describes the categorical grouping of the OLE interfaces found in the XMCSPI. Both standard and custom OLE interfaces are used in the XMCSPI. OLE 2.0 requires the implementation of all interfaces listed in Section 2.1 Standard OLE Interfaces. XMC requires the implementation of all interfaces listed in section 2.1 Care Interfaces. 2.1 Standard OLE Interfaces The following standard OLE interfaces must be supported by each Motion Control Driver. For more information on each interface, see section 2.0 Standard OLE Interfaces m the XMCAPI Reference manual. Standard Interfaces IClassFactory lUnknown 2.2 Core Interfaces (Core) Any absolutely essential functions to motion control problems are in the core set of functions. All motion control XMCSPI drivers must implement these core functions. None of these functions are not allowed to use user-interface objects. The following custom OLE 2.0 interfaces are in the core set of XMCSPI functions: Custom Core Interfaces IXMC_DrvCore_AnalogIO IXMC_DrvCore_DιgιtalIO IXMC_DrvCore_Dynaιtu.cState IXMC_DrvCore_Encoder IXMC_DrvCore_Enu IncerfaceSupport; IXMC_DrvCore_IO (Abstract) IXMC_DrvCore_Lunιts IXMC_DrvCore_Motion-;- * (Dependent) IXMC_DrvCore_Servo IXMC_DrvCore_StaticState IXMC_DrvCore_Stepper NOTE: The IXMC_DrvCore_Servo interface is only required if the motion control hardware controlled by the dnver has servo motor support The same follows for the IXMC_DrvCore_Stepper interlace with stepper motors Abstract interfaces are only used by other interfaces as an inheritance base. For example, since the IXMC_DrvCore_DιgιtalIO interface inherits from the IXMC_DrvCore_IO interface, its lmDlementation contains all methods in both interfaces. See section 2 7 1 Inheritance Relationships for more information on inheritance relationships between interfaces Dependent interfaces are only used after the interfaces they are dependent on have performed certain operations. For example, the IXMC_DrvCore_Motιon interface is dependent on either the IXMC_DrvCore_Servo or the IXMC_DrvCore_Stepper interfaces initializing the motion system. See section 2.7.2 Dependency Relationships for more information on dependency relationships between interfaces. 2.3 Extended Interface Categories All non-core interfaces in the XMCSPI fall into one of the three extended interface categories XMC Drivers are not required to implement any of the extended XMCSPI functions A stub driver, called the XMC Driver Stub, implements all extended interfaces, not suppoπed by the ROY-G-BIV Corporation Confidential 3/15/95 β 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 2.0 XMCSPI Interface Categories current driver, that can be emulated using a software algorithm which calls core functions. For more information on how the XMC Driver Stub is used, see Section 7 0 Driver Administrator Component. Driver Relationship in the XMC User Guide manual Implementing extended interfaces directly in the driver can improve the precision and efficiency of the operation, for the driver implementation has more direct control over the motion control hardware than the XMC Motion Control Component. Even greater precision and performance improvements occur when the driver can direct the motion control hardware to directly perform a procedure defined in one of the extended interfaces. 2.3.1 Extended Interfaces (Ext) This set of functions consists of all πon core functions that do not use user-interface objects such as dialog boxes or message boxes. The following custom OLE 2.0 interfaces are in the set of extended XMCSPI functions Custom Ext Interfaces IXMC_DrvExt_Counter IXMC_DrvExt_Debug (Private) IXMC_DrvExt_Dynanu.cState IXMC_DrvExt_Encoder IXMC_DrvExt Interrupt IXMC_DrvExt_IO (Abstract) IXMC_DrvExt_Joystιck IXMC_DrvExt_L.jii-.ts IXMC_DrvExt_Motιon (Dependent) IXMC_DrvExt_StatιcState IXMC_Drv£xt_T-_me r 2.3.2 Extended UI Interfaces (ExtUI) This XMCSPI set consists of all extended XMCSPI functions that require user-interface objects such as dialog boxes or message boxes. For example, when an application requests to tune the servo motors, special input may be needed from the user to complete the process Because tuning the servo motors is not a required motion control function and may need input from the user, it is in the Extended UI XMCSPI set of functions The following custom OLE 2.0 interfaces are in the extended user-interface set of XMCSPI functions Custom ExtUI Interfaces IXMC_DrvExtαi_AnalogIO IXMC_OrvExtUI_Base IXMC_DrvExtUI_DιgitalIO IXMC_DrvExtUI_Dynam-.es tate IXMC_DrvExtUI_Servo IXMC_DrvExtU:_StatιcState 2.3.3 Extended Code Generation Interfaces (ExtCG) These XMCSPI functions consist of all methods used for code generation only Most core and extended methods generate code also generate code when the XMC software is run in code- generation mode But, where core and extended functions may also be used in real-time and mixed modes, code-generation functions cannot Code-generation functions are only used when running in code-generation mode ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 2.0 XMCSPI Interface Categories The following custom OLE 2.0 interfaces are in the set of code-generation XMCSPI functions: Custom ExtCG interfaces IXMC_DrvExtCG_Progra.nFlo IXMC_DrvExtCG_Operator IXMC_DrvExtCG_Program IXMC_DrvEκtCG_ProgramMgmt IXMC_DrvExtCG_Subroutine IXMC_DrvExtCG_Variable 2.4 Vendor Specific Interfaces (ExtVS) These functions are not part of the set of XMCSPI interfaces. No XMCAPI interface methods call these functions for they are provided by each vendor as a pass-through method giving vendors access to new hardware features not yet supported by the XMC software model. Each implementation of vendor specific custom OLE Interfaces depend on the needs of the hardware vendor. Applications may communicate directly with these interfaces, but in doing so, they automatically become dependent on the specific Motion Control Driver and therefore become hardware-dependent. But, allowing vendor-specific functions to exist gives the software model a flexible way to evolve. For example, if one hardware vendor adds a new feature to their motion control hardware, not provided by any other vendors, they may gain access to the new feature by adding a vendor specific SPI interface to their driver and then directly programming to the SPI interface from within the application. Of course, other drivers will not work with applications that call the hardware dependent SPI interface, for they will not implement the interface. As the feature becomes more useful over time, other hardware vendors will probably add the feature to their hardware. After the feature gains a critical mass of suppoπ within the companies suppoπing the XMC software model, the feature will be added to the XMC software model by becoming a part of both the XMCSPI and XMCAPI. For more information on vendor specific interfaces, see the appropriate XMC Motion Control Extension manual describing the specific XMC Driver which includes a reference for each hardware-dependent driver interface. 2.5 Interface Map The following table displays all Motion Control Driver, XMCSPI interfaces and the categoπes they fall in: Core Ext ExtUI ExtCG "DCMCDrvCore "LXMCDrvExt "KMCDrvExtUI "IXMCDrvExtCG " AnaloglO AnaloglO AnaloglO* Base Counter Counter* Debug (Private) DigitallO DigitallO DigitallO DigitallO* DvnamicState DynamicState DynamicState StaticState Stat cState Stat c tate Stepper Stepper* Timer Timer* ROY-G-BIV Corporation Confidential 3/15/95 β 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 2.0 XMCSPI Interface Categories Operator Program ~ ProgramFlow ProgramMgmt Subroutine Variable * These interfaces generate code implicitly Calling methods, that immediately cause an action on the hardware when run in real-time mode, generate code when run in code-generation mode. 2.6 Interface Relationships This section describes how closely coupled XMCSPI interfaces relate to one another. There are two ways interfaces relate to one another. Interfaces can inherit from each other and can be dependent on one another. The following sections describe these relationships and the mterfaces using them. 2.6.1 Inheritance Relationships C-→ inheritance is used to combine two interfaces m such a way that the deπved interface "inherits" all method definitions in the base interface. Only the method definitions within the base interface are inherited. The resulting interface contains implementations of all methods in both the derived and the base interface. The following are the inheritance relationships found in the XMCSPI Inheritance Tree IXMC_DrvCore_IO I I IXMC_DrvCore_DιgιtalIO I IXMC_DrvCore_AnalogIO IXMC_DrvExtUI_Base I I IXMC_Drv£xtUI_AnalogIO I IXMC_DrV£xtU:_DιgιtalIO I IXMC_DrvExtUI_Dyna ιcState I IXMC_DrvExtUI_Servo I IXMC_DrvExtU:_S tat-.cState 2.6.2 Dependency Relationships Unlike inheritance relationships, depenαeπcy relationshiDS are between two interface implementations When an interface is dependent on another interface, it needs the interface to perform an operation before it can continue one of its own operations For example, the IXMC_DrvCore_Motιoπ interface is dependent on the IXMC_DrvCore_Stepper interface initialization routine Before using the IXMC_DrvCore_Motιoπ interface, the IXMC_DrvCore_Stepoer interface must be used to initialize the stepper system The following are the dependency relationships found in the XMCSPI Dependency Tree IXMC_DrvCore_Motιon — I ( deDenαent on ) IXMC_DrvE^t_Motιor I I I - I v i IXMC_DrvCore_StepDer IXMC DrvCore Servo ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Moϋon Control XMCSPI Reference 3.0 XMCSPI Reference 3.0 XMCSPI Reference 3.1 XMC Core Interfaces (Core) Core functions are the lowest level primitive motion control functions implemented by all hardware vendors that software cannot duplicate in an algorithm that uses other methods, such as those in the Motion Control Driver Stub. This section describes each custom OLE 2.0 interface widiin the set of core interfaces. 3.1.1 IXMC_DrvCore_AnalogIO Interface The IXMC_DrvCore_AnalogIO interface inherits from the IXMC_DrvCore_IO interface and implements all of its methods. This interface take care of initializing the analog I/O system used. All I O work is carried out by the IXMC_DrvCore_IO interface. inheritance IXMC_DrvCore_IO I I IXMC_DrvCore AnaloglO Configuration (*pDrvCore_AnalogIO) ->Initialize() 3.1.2 IXMC_DrvCore_DigitalIO Interface Similar to the IXMC_DrvCore_AπaiogIO interface, the IXMC_DrvCore_DigitaIIO interface is also inherits from the IXMC_DrvCore_IO interface. The IXMC_DrvCore_DigitalIO interface takes care of initializing the digital I/O system, and the rXMC_DrvCore_IO interface takes care of all oώer operations. inheritance IXMC_DrvCσre_IO I - * - I IXMC_DrvCore_DigitalIO Configuration (*pDrvCore_DigitalIO) ->Initialize () ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.1.3 IXMC_DrvCore_DynamicState Interface The IXMC_DrvCore_DyπamicState interface manages the overall state of the motion control system. Included in its management tasks are initializing and shutting down the system. The current state information may be queried or changed at any time after the system is initialized. State Information typedef struct _XMC_DY AMICSTATEINFO { XMC_STATICSTATE 'pXMCDC; double dfActualPosition; double dfCommandedPosition; double dfActualVelocity; double dfCoπrmandedVelocity; double dfPositionError; double dfAcceleration; double dfDeceleration; HRESULT hErrorStatus; XMC_OP_MODE operatingMode; XMC AXIS_DATA *pLeft imitData; XMC_AXIS_DATA *pRightLimitData; } XMC_DYNAMICSTATEINFO; Configuration (*pDrvCore_DynSt) ->Reset() (*pDrvCore_DynSt) ->Initialize 0 (*pDrvCore_DynSt) ->ShutDown() QueryingAttributes (*pDrvCore_DynSt) ->GetErrorStatus 0 (*pDrvCore_DynSt) ->GetState () Setting Attributes (*pDrvCore_DynSt) ->ClearErrors () (*pDrvCore_DynSt) ->SetState () 3.1.4 IXMC_DrvCore_Encbder Interface The IXMC_DrvCore_Encoder interface implements several optimized functions used to query positions. Calling the LXMC_DrvCore_DynamicState::GetState() method will also collect the position information, but at the expense of collecting all other current state data. The methods specified by this interface only collect the data requested. Querying Attributes ( *pDrvCore_Motion) ->GecPositionActual ( ) ( *pDrvCore_Motion) ->GetPositionErro ( ) NOTE: Currently, this interface is classified as a core set of XMCSPI, but it may be changed to an extended set of XMCSPI instead. ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation... All Rights Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.1.5 IXMC_DrvCore_EnumIπterfacεSupport Interface The IXMC_DrvCore_EπumIπterfaceSupport interface is used to query a list of interfaces meeting the specific search criteria set with the LXMC_DrvCore_EnumInterfaceSupport::SetSearchCriteria() method.. Inheritance IEnumX I I IXMC_DrvCore_EnumInterf aceSupport Setting Attributes ( *pDrvCσre_EnumIFace) ->SetSearchCriteria 0 3.1.6 IXMC_DrvCore_IO Interface This interface consists of all digital input and output related functions. The following methods are available from each Motion Control Driver in the IXMC_DrvCore_DigitalIO interface: Configuration ( *pDrvCore_IO) ->Initialize ( ) Actions (*pDrvCore_IO)->Read() (*pDrvCore_IO)->Write() 3.1.7 LX C_DrvCore_Limits Interface The IXMC_DrvCore_Limits interface is used to set software limits for a set of axes. When setting limit values, two arrays containing AXIS_DATA elements are used to transfer the settings to the method. Setting Attributes ( *pDrvCore_Lιmits ) ->SetLinu.tPositιons ( ) NOTE: Currently, this interface is classified as a core set of XMCSPI, but it may be changed to an extended set of XMCSPI instead. ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.1.8 IXMC_DrvCore_Motion Interface This IXMC_DrvCore_Motion interface is a dependant interface in that it may only be used after either the IXMC_DrvCore_Stepper or IXMC_DrvCore_Servo interfaces are used to initialize the system. All primitive motion control functions that are absolutely necessary to solve motion control software problems are placed in this interface. Also, each function in this set should be a primitive that can not be duplicated through a software algorithm built on top of other primitive functions. The following methods are available from each Motion Control Driver in the IXMC_DrvCore_MotioπCoπtrol interface- Querying Attributes ( *pDrvCore_Motion) ->GetCoιπ*nandedPosition ( ) ( *pDrvCore_Motion) ->GetActualPosition ( ) ( *pDrvCore_Motion) ->GetCommandedVelocity ( ) ( *pDrvCore_Motion) ->GetActualVelocity ( ) Setting Attributes ( *pDrvCore_Motion) ->SetVelocity { ) ( *pDrvCore_Motion) ->SetPosition ( ) Actions (*pDrvCore_Motion)->Kill() (*pDrvCore_Motion) ->MoveAbs () (*pDrvCore_Motion)->MoveContinous () (*pDrvCore_Motion)->Stop() 3.1.9 LXMC_DrvCore_Servo Interface The DXMC_DrvCore_Servo interface handles all operations specific to servo motors. All motion operations are performed by the DCMC_DrvCorε_Motioπ interface. The following methods are in the IXMC_DrvCore_Servo interface: Dependency IXMC DrvCore Motion I IXMC_DrvCore_Servo Configuration CpDrvCore_Servo ) ->Initialize ( ) ( "pDrvCore Servo) ->Tune ( ) ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. - 7? - XMC Motion Control XMCSPI Reference - ** ° XMCSPI Reference 3.1.10 IXMC_DrvCore_StaticState Interface The LXMC_DrvCore_StaticState interface manages all static state information defining the system. Like the current state mformation, the device context information may be queried at any time after the system is initialized. But, unlike the current state information, the device context information is only set during the initial setup of the system. State Information typedef struct _XMC_STATI STATEINFO ( double dfEncoderCountsPerRevolution; double dfMMPerRevolution; mt cbAx is Count ; int cbAxisMax; XMCMOTORTYPE motorType ; } XMC_STATICSTATEINFO; Querying Attributes (*pDrvCore_StatSt)->GetState() Setting Attributes ( *pDrvCore_StatSt ) ->SetState ( ) 3.1.11 IXMC_DrvCore_Stepper Interface The rXMC_DrvCore_Stepper interface handles all operations specific to stepper motors. All motion operations are performed by the LXMC_DrvCore_Motιoπ interface. The following methods are in the IXMC_DrvCore_Stepper interface: Dependency IXMC DrvCore Motion IXMC_D rvCo r e_S t eppe r Configuration .: * (*pDrvCore_Stepper) ->Inιtιalιze () 3.2 XMC Extended Interfaces (Ext) Extended interfaces contain methods that are not required These interfaces are either duolicated by the Motion Control Driver Stub or contain functionality not essential in most motion control problems. However, implementing these interfaces will optimize the performance of the motion control system for a particular set of hardware This section describes all extended interfaces within XMCSPI 3.2.1 IXMC_DrvExt_Counter Interface The IXMC_DrvExt_Couπter interface is used to operate a counter implemented by the motion control hardware. Querying Attributes ( *pDrvExt_Counter ) ->GetCounter ( ) Actions ("pDrvExt^ounter) ->EnableInterrupt () ('pDrvExt_Counter) ->Reset() (*pDrvExt_Counter) ->Start () (*pOrvExt_Counter) ->Stop () ROY-G-BIV Corporation Confidential 3 15 9S © 1995 ROY-G-BIV Coraoration. All Riahts Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Refβr-ence 3.2.2 IXMCJDrvExt_Debug Interface (Private) The IXMC_Dr-vEx t_Debug interface is a private interface used by the Motion Control Component, if available. When implemented, the interface is used when debugging the Motion Control Driver. Setting Attributes ( *pDrvExt_Debug) ->SetRawDataInDumpFile ( ) ( *pDrvExt_Debug) ->SetRa DataOutDumpFile ( ) (*pDrvExt_Debug) ->SetXMCSPI ogFile 0 Actions ( *pDrvExt_Debug) ->EnableRawDataDump ( ) ( *pDrvExt_Debug) ->EnableXMCSPILoggιng ( ) 3.2.3 LXMC_DrvExt_DynamicState Interface The IXMC_DrvEx t_DynamicState interface manages the extended, dynamic state of the motion control system. The extended current state information may be queried or changed at any time after the system is initialized. State Information typedef struct XMC EXTDYNAMICSTATEINFO { DWORD dwSupportedPoperties; XMC_EXTSTATICSTATEINFO • pExtXMCDC; double dfLimitDeceleration; double dfJogVelocityHigh; double dfJogVelocityLo ; double dfJoystickVelocityHigh; double dfJoysticJVelocityLo ; double dfFee Rate; POS_DATA *pHomePosition; POS_DATA • pZeroPσsition; POS_DATA *pLιmιtSWFwdPosιtιon; POS_DATA *pLιιταtSWB dPosιtιon; double dfLimitDeceleration; BOOL bJoystick; BOOL bAxisScaling; BOOL bPathScalmg; BOOL bDataCapture; BOOL bFeedRate; BOOL blnterpolation; BOOL bLi itSW; BOOL bLimitHW; BOOL blODataCapture; XMC EXTDYNAMICSTATEINFO; Querying Attributes ( • pDrvCore_DynSt) ->GetState () Setting Attributes CpDrvCore DynSt ) ->SetState ( ) ROY-G-BIV Co oration Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.2.4 IXMC_DrvExt_DigitaIIO Interface The LXMC_Drv£xι_DigitalIO interface handles all extended IO functionaiy. Actions (*pDrvExt_DigitalIO) ->EnableInputFunctions 0 (*pDrvExt~DigitalIO) ->EnableOutputFunctιons 0 SettingAttributes (*pDrvExt_DigitalIO) ->SetInputFunction() (*pDrvExt_DigitalIO)->SetInputDebounceTime () (*pDrvExt_DigitalIO)->SetInputActiveLevel () (*pDrvExt_DigitalIO) ->SetOutputFunction() (*pDrvExt_DigιtalIO) ->SetOutputActiveLevel () (*pDrvExt_DigitalIO) ->SetOutputStates () 3.2.5 IXMC_DrvExt_EncoderInterface The rXMC_DrvExt_Encoder interface is used to manipulate encoders in the motion control system. Setting Attributes ( *pDrvExt_Encoder) ->SetOutputAbsPosition ( ) C*pDrvExt_Encoder) ->SetOutputRelPosition ( ) 3.2.6 EKMC_DrvExt_Interrupt Interface The IXMC_DrvExι_Interrupt interface is used to set, get, and enable interrupt handlers Querying Attributes ( *pDrvExt_Int ) ->GetHandler ( ) Setting Attributes ( pDrvExt_Int ) ->SetHandler ( ) Actions ( *pDrvExt_Int ) ->Enable ( ) 3.2.7 IXMC_DrvExt_IO Interface This interface consists of all digital input and ouφut related functions. The following methods are available from each Motion Control Driver in the IXMC_DrvExt_DigitaIIO interface:- Actions ( "oDrvExt IO) ->EnableDataCapture ( ) ; ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G.BiV.CorDorιtlon*All 1 BiohtsiRβsβrved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.2.8 IXMC_DrvExt_ Joystick Interface The IXMC_DrvExt_Joystick interface is used to eπabie and disable a hardware joystick. When enabled, ail other motion operations are disabled. The following methods are in this interface: Setting Attributes ( *pDrvExt_Joystick) ->SetVelocityHigh ( ) ( *pDrvExt_Joystick) ->SetVelocityLo ( ) ( » pDrvExt_Joystick) ->SetupElectronιcs ( ) Actions ( *pDrvExt_Joystick) ->Enable ( ) 3.2.9 LXMC_DrvExt_Limits Interface The IXMC_DrvE t_Limits interface is used to manipulate both hardware and software limits. The following methods are in this interface: Querying Attributes ( *pDrvExt_Limits ) ->GetSof areLimitPositions ( ) Setting Attributes ( *pDrvExt_Limιts ) ->SetSof twareLimitPositions ( ) ( *pDrvExt_Limits ) ->SetDeceleration ( ) Actions ( *pDrvExt_Limits ) ->EnableHardwareLιmits ( ) ( *pDrvExt_Limits ) ->EnableSof twareLimits ( ) 3.2.10 LXMC_DrvExt_Motion Interface This interface consists of extra motion control functions that may or may not be implemented by the motion control hardware. If a hardware implementation is unavailable for a particular function, the Motion Component calls die Motion Control Dnver Stub, which implements the functionality in software. The following methods are available from either the Motion Conσol Driver or the Motion Control Driver Stub in the IXMC_DrvExt_MotioπCoπtrol interface: Querying Attributes ( *pDrvExt_Motion ) ->GetFeedRate { ) ( *pDrvExt_Motιon) ->GetAxιsScalmg ( ) CpDrvExt_Motιon ) ->GetPathScalιng ( ) ( *pDrvExt_Motιon) ->GetMaxAcceleratιon ( ) { *pDrvExt_Motιon ) ->GetMaxDeceleratιon ( ) CpDrvExt_Motιon) ->GetMaκVelocιt { ) ( *pDrvExt_Motιon) ->GetHome Position ( ) ( *pDrvExt_Motιon) ->IsDataCaptureOn ( ) ( *pDrvExt_Motιon) ->IsFeedRateOn ( ) ( *pDrvExt_Motιon) ->IsAxιsScalmgOn ( ) ( *pDrvExt_Motιon) ->IsPat ScaiιngOn ( ) ( *pDrvExt_Motιon) ->IsInterpolatιonOn ( ) Setting Attributes ( *pDrvExc_Motιon ) ->Se JogVelocityHigh ( ) ( -pDrvEx*;_Motιon) ->Set JogVelocityLow ( ) ( *pOrvExt_Motιon ) ->SetFeedRate ( ) ( *pDrvExt_Motιon) ->SetAxιsScalιn ( ) ( -pDrvExt_Motιon) ->SetPathScalιng ( ) ( *pDrvExt_Motιon) ->SetMaxAcceleratιon ( ) ( *pDrvExt_Motιon) ->SetMaxDeceleratιon ( ) ( -pDrvExc_Motιon) ->SetMaxVelocιty ( ) ( *pDrvExt_Motion) ->SetZeroPosιtιon ( ) ( *pDrvExt_Motιon) ->SetHomePositιon ( ) ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Cor oration. All Rl? h *s Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference Action (*pDrvExt_Motιon) ->EnableFeedRate () (*pDrvExt_Motιon) ->EnableInterpolatιon () (*pDrvExt_Motιon)->EnableAxιsScalιng() (*pDrv£xt:_Motιon) ->EnablePathScalιng() (*pDrvExt_Motιon) ->GoHome 0 (*pDrvExt_Motιon) ->GoZero() (*pDrvExt_Motιon) ->MoveRel () Geometric Moves (*pDrvExt_Motιon) ->Arc() (*pDrvExt_Motιon) ->Path() 3.2.11 IXMC_DrvExt_StaticState Interface The IXMC_DrvExt_StaticState interface manages all extended static state information defining the system. Like the current state information, the device context information may be queried at any time after the system is initialized. But, unlike the current state information, the device context information is only set during the initial setup of the system. State Information typedef struct _XMC_EXTSTATICSTATEINFO { DWORD d SupportedProperties ; double dfAxisScalmgFactor; double dfPathScalmgFactor; double dfMaxAcceleration; double dfMaxDeceleration; double dfMaxVelσcity; ) XMC_EXTSTATICSTATEINFO; Querying Attributes ( *pDrvCore_DC ) ->GetState ( ) Setting Attributes ( *pDrvCore_DC ) ->SetState ( ) 3.2.12 IXMC_DrvExt_Timer Interface The IXMC_DrvExt_Timer interface is used to manipulate a timer on the motion control hardware. Querying Attributes (*pDrvExt_Tιmer) ->GetTιme () (*pDrvExt_Tιmer) ->GetDelay () (*pDrvExt_Tιmer) ->GetResolutιon() Setting Attributes ( *pDrvExt_Tιmer ) ->Se cDela ( ) Actions ( » pDrvExt_Tιmer) ->DoDelay( ) (*DDrvEχt;_Tι er) ->EnableInterrupt () ( • pDrvExt_Tι er:) ->Reset 0 ( *pDrvExt_Tιmer) ->Start 0 ( • pDrvExt_Tιmer) ->Stop() (*ρDrvExt_Tιmer)->TrιggerInterrupt () ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.3 XMC Extended Ul Interfaces (ExtUI) All extended UI custom OLE 2.0 interfaces use user-interface resources such as dialog boxes or windows to interact with the user. Some interfaces may gather information from the user, where others may just display information. 3.3.1 IXMC_DrvExtUI_AnalogIO Interface The IXMC_DrvExtUI_AπalogIO interface allows the user to interactively view and set the parameters used when initializing the analog IO system. Inheritance IXMC DrvCore IO I IXMC_DrvCore_DigitalIO 3.3.2 IXMC_DrvExtUI_AnalogIO Interface The -XMC_DrvExtUI_AπalogIO interface allows the user to interactively view and set the parameters used when initializing the analog IO system. Inheritance IXMC_DrvExtσi_Base I I IXMC_DrvExtαi_AnalogIO 3.3.3 LXMC_DrvExtUI_Base Interface The IXMC_DrvExtUI_Base interface is an abstract base derived off by all other Extened UI interfaces. The two methods defined in this interface, implemented by the deriving interface, are used to initialize and view data. Configuration CpDrvExtUI_Base ) -initialize 0 { *pDrvExtϋI_Base — >View ( ) 3.3.4 IXMC_DrvExtUI_DynamicState Interface The IXMC_DrvExtUI_DynamicState interface allows the user to interactively view and set all dynamic parameters used in the motion control system. Inheritance IXMC_DrvExcϋI_Base I I IXMC_DrvExtUI_Dyna ιcState 3.3.5 IXMC_DrvExtUI_StaticState Interface The IXMC_DrvExtUI_StaticState interface allows the user to interactively view and set all static system parameters used when initializing the motion control system. Inheritance IXMC DrvExtϋl Base IXMC DrvExtUI S taticState ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Cor orati n. All Ri hts Reserved. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.3.6 IXMC_DrvExtUI_DigitalIO Interface The LXMC_DrvExtUI_DigitaIIO interface allows the user to interactively view and set the parameters used when initializing the digital IO system. Inheritance IXMC DrvExtUI Base IXMC Drv£xtϋI_DigιtalIO 3.3.7 IXMC_DrvExtUI_Servo Interface The LXMC_DrvExtUT_Servo interface aliows the user to interactively view and set the servo system parameters. Also, the interface allows the user to interactively tune the PID settings used. Inheritance IXMC_DrvExtUI_Base I I IXMC_DrvExtσi_Servo Configuration (*pDrvExt_Motion) ->Tune () 3.4 XMC Extended Code Generation Interfaces (ExtCG) Code generation interfaces are used by the Motion Control Component to generate the appropriate vendor-specific control-codes used to create a motion control program. Unlike other interface supported by each Motion Control Driver, the code-generation interfaces are never used in real¬ time mode. NOTE: Currently, the implementations of all code generation interfaces are a direct mapping of the Motion Control Component code generation interfaces and are under investigation. 3.4.1 LXMC_DrvExtCG_Operator Interface The IXMC_DrvExtCG_Operator interface is used to generate general program code such as boolean, logical, simple conditional, and mathematical operators. The following methods are in the interface: Bitwise CpDrvExtCGjDp) ->BιtAnd() CpDrvExtCGjDp) ->BιtNθt () (*pDrvExtCG_Op) ->BιtOr() (*?DrvExtCG_Op) ->3ιtShif L() (*pDrvEκtCG_Op)->3ιtShiftR() (*pDrvExtCG_Op)->BιtXOr ( ) Logical ( • pDrvExtCG_Op) ->And ( ) CpDrvExtCG_Op) ->No 0 ( *pDrvExtCG_Op ) ->Or ( ) Mathematical ('pDrvExtCG_Op) ->Add () (*?DrvExtCG_Op)->Bι () (*pDrvExtCG_Op) ->Dι () (*pDrvExtCG_Op) ->Le tParen () (*pDrvExtCG_Op)->Mul () (*pDrvExtCG_Op) ->RιghtParen () (-pDrvExtCG_Op) ->Sqr () ( ♦ pDrvExtCG_Op) ->Sub ( ) ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporations AH Ri hts Reserved; XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference Trigonometric ( *pDrvExtCG_Op) ->ACos ( ) ( *pDrv£xtCG_Op) ->ASin ( ) ( *pDrvExtCG_Op) ->ATan ( ) ( *pDrvExtCG_Op) ->Cos ( ) ( *pDrvExtCG_Op) ->Sin ( ) ( *pDrvExtCG_Op) ->Tan ( ) Labels/Striπgs/Comments (*pDrvExtCG_Op) ->ASCIIChar() (*pDrvExtCG_Op)->Comment () (*pDrvExtCG_Op)->DeclarLabel() (*pDrvExtCG_Op) ->String{) Conditional (*pDrvExtCG_Op) ->Equal () (*pDrvExtCG_Op)->GreaterThan() (*pDrvExtCG_Op) ->GreaterThan£qual() (*pDrvExtCG_Op) ->LessThan() (*pDrvExtCG_Op) ->LessThanEqual () (*pDrvExtCG_Op) ->NotEqual() 3.4.2 IXMC_DrvExtCG_Program Interface The IXMC_DrvExtCG_Program interface is used to generate a program shell using the appropriate vendor-specific control-codes. The following methods are in the interface: Programmming ( *pDrvExtCG_Prog) ->Def ine ( ) ( *pDrvExtCG_Prog) ->End ( ) ( *pDrvExtCG_Prog ) ->Exit { ) ( *pDrvExtCG_Prog) ->Sleep ( ) 3.4.3 LXMC_DrvExtCG_ProgramFlo Interface The IXMC_DrvExtCG_ProgramFlbw interface is used to generate program flow code. Loops and if/then statements are several examples of contitional code generated. The following methods are in the interface: If/Else ( *pDrvExtCG_ProgFlow) ->IfOpen ( ) ( *pDrvExtCG_ProgFlow) ->I Close ( ) ( *pDrvExtCG_ProgFlow) ->Else ( ) ( *pDrvExtCG_ProgFlow) ->EndIf ( ) While ( pDrvExtCG_ProgFlow) ->WhileOpen () (*pDrvExtCG_ProgFlow) ->WhileCΪose () (-pDrvExtCG_ProgFlow) ->EndWhile ( ) Repeat (-pDrvExtCG_ProgFlow) ->Repea () ( pDrvExtCG_ProgFlow) ->UntilOpen () (*pDrvExtCG_ProgFlow)->UntilCΪose() Loops {•pDrvExtCG_ProgFlo ) ->Loop() (-pDrvExtCG_ProgFlow) ->EndLoop() Misc. (*PDrvExtCG_ProgFlo ) ->Break() (•PDrvExtCG ProgFlow) ->GoTo () ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Cor oration;. All Ri hts Reserved;.. XMC Motion Control XMCSPI Reference 3.0 XMCSPI Reference 3.4.4 IXMC_DrvExtCG_ProgramMgmt Interface The LXMC_DrvExtCG_ProgramFlow interface is used to generate program flow code. Loops and if/then statements are several examples of contitional code generated. The following methods are in the interface: Programming (*pDrvExtCG_ProgMgm )->Run() (*pDrvExtCG_ProgMg t) ->Stop() Output (*pDrvExtCG_ProgMgmt) ->EnableOutput () (*pDrvExtCG_ProgMgmt) ->SetOutput () 3.4.5 LXMC_DrvExtCG_Sufaroutine Interface The EXMC_DrvExtCG_Subroutine interface is used to generate subroutines and calls to subroutines. The following methods are in the IXMC_DrvExtCG_Subroutiπe interface: General (*pDrvExtCG_Sub)->Define () (*pDrvExtCG_Sub) ->Call () (*pDrvExtCG_Sub) ->End() 3.4.6 LXMC_DrvExtCG_Variable Interface The rXMC_DrvExtCG_VariabIe interface is used to define and assign values to variables. The following methods are included in the interface: Definition ( *pDrvExtCG_Var) ->Define ( ) Assignment ( *pDrvExtCG_Va ) ->AssignNuιtιeric ( ) ( *pDrvExtCG_Var).«->AssιgnBinary ( ) ( *pDrvExtCG VarF->AssignString ( ) ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Ri hts Reserved.. XMC Motion Control XMCSPI Reference Appendix A Appendix A A.1 Reviewer Feedback All feedback is important in order to evoive the specification into a standard software model for motion control hardware. Please, at a minimum, respond to the following issues: 1. Which areas, ideas, or concepts within the specification seem confusing to you? 2. Are there any main features missing from the specification that you would find useful? 3. Are there any specific scenario-maps you would like to see in the next revision? 4. Are there any specific C or C++ code examples you would like to see? 5. Are there any specific Visual Basic code examples you would like to see? A.1.1 Correspondence If possible, please send all feedback over email to the following address: Dave Brown ROY-G-BIV Corporation CompuServe: 72103 -2235 Internet: 72103-2235@compuserve.com Otherwise, if you do not have access to email, please mail all correspondence to the following address: Dave Brown ROY-G-BIV Corporation P.O. Box 1278 White Salmon, WA. 98672 ROY-G-BIV Corporation Confidential 3/15/95 5 R - - ts R XMC Motion Control XMCAPI Reference Revision: Third Draft Autnor: Oave Brown Date: Wednesday. Feb 22. 1995 Description: This document is tne XMCAPI reference descπbing all funαioπs, standard OLE interfaces, and custom OLE interfaces making up the XMCAPI Revision History: 4/15/94 (DB) - First Draft: Initial wπting 7/1/94 (DB) - Second Draft: Sø t design off small business plan, incorporated suggestions 2/22/95 (DB) - Third Draft - Split XMCAPI reference off design guide. ROY-G-BIV Corporation Confidential © 1995 ROY-G-BIV Corporation. All rights reserved. XJWC Motion Control XMCAPI Reference 1.0 Overview 1.0 Overview To use XMC, applications call the methods defined by the XMCAPI OLE interfaces to perform the motion control services needed. The full XMCAPI comprises a set of OLE interfaces corresponding with common objects found in a motion control system. For example, a motion control system may contain servo and stepper motors, encoders, limit switches, and a joystick. Within the XMCAPI are interfaces co espσnding to each of these objects. The full XMCAPI contains implementations of both standard OLE 2.0 interfaces and a rich set of custom OLE interfaces designed specifically for motion control. This reference manual describes all OLE interfaces in the XMCAPI. Each section discussing an interfaces starts with a description of the interface and how it is used. Next, ail functions in the interface are listed by catagory. Chapter 2.0 Standard OLE Interfaces, describes all standard interfaces exposed in the XMCAPI. Next, Chapter 3.0 XMC Driver Administrator, discusses both the standard and custom interfaces exposed by the Driver Administrator that make up a small portion of the XMCAPI. Finally, Chapter 4.0 XMC Motion Control Component, discusses the standard and custom interfaces exposed by the Motion Control Component. The Motion Control Component implements and exposes the majority of the XMCAPI. Together, the Motion Control Component and the Driver Administrator implement and expose the full set of interfaces defined by the XMCAPI. ROY-G-BIV Corporation Confidential 3/15/95 <D 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 2.0 Standard OLE interfaces 2.0 Standard OLE Interfaces Several standard OLE interfaces must be supported when following the OLE software modei. Both the lUnknown and IClassFactory interfaces are examples of required interfaces. The IDataObject interface is used when transferring or caching data. The IDispatch is provided to support OLE Automation between processes. This section describes all standard OLE interfaces used by the Driver Administrator, Motion Control Component, and Motion Control Drivers. 2.1 1ClassFactory Interface The IClassFactory interface is used to create an instance of an object and return to the caller a pointer to an interface. General (*pCF)->CreateIn.5tance() (*pCF) ->LockServer{) 2.2 IDispatch Interface The IDispatch interface is used to support OLE Automation. Normally, this interface is used by the OLE Automation engine, not the C/C-*-t- application developer. General ( *pDisp) ->GetIDsOfNames ( ) ( *pDisp) ->GetTypeInfo ( ) ( *pDisp) ->GetTypeInfoCount ( ) CpDisp) ->Invoke ( ) 2.3 lEnumX Interface The IEnumX interface is a generic OLE interface that other enumeration interfaces always mneπt from. This interface is used to create and move through an enumeration of data. The LXMC_EnumIπterface interface inherits from IEnumX to implement the interface support querying functionality. General ( • pEnum)->Nexc() (-pEnum) ->Skιp{) (-pEnum)->Reset() (-pEnum) ->Clone () 2.4 lUnknown Interface The lUnknown interface is a standard OLE interface exposed by all OLE objects. In a way it is a common base interface. General (-punk) ->QueryInterface ( ) ( -punk) ->AddRef{) {-πUnkl ->Reiease () ROY-G-BIV Corporation Confidential 3/15/95 O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 3.0 XMC Driver Administrator 3.0 XMC Driver Administrator The Driver Administrator, which implements a small subset of the XMCAPI set of functions, is used by both the user and the Motion Conσol Component. It is used by the user to add new Motion Control Drivers, configure existing drivers, and remove old ones. Later when an application uses the Motion Conσol Component, the component queries the Driver Administrator for the current driver to use. NOTE: OLE 2.0 interfaces are used to implement all functions in the XMCAPI. The following OLE 2.0 interfaces are custom OLE interfaces in the XMCAPI supported by the Driver Administrator. IXMC DriverAdmin 3.1 Standard OLE Interfaces The following standard OLE interfaces are supported by the Driver Administrator. For more information on each interface, see section 6.0 Standard OLE Interfaces. IClassFaccory IDispatch lUnknown 3.2 Custom OLE Interfaces The following custom interface is a pan of the XMCAPI and an extension to the OLE 2.0 software model. 3.2.1 LXMC_DriverAdmin This interface is used to manipulate and query the Driver Administrator settings. The Driver Administrator application, run by thfr user. manipulates the administrator's settings. And, the Motion Conσol Component queries the administrator for a pointer to the current driver to use. Querying Attributes ( "pXMCDr Admin) ->Geτ*.SeleccedDrιvers ( ) { -pXMCDrvAdmin) ->IsDιagnosτ:ιcTes-;-.ngOn ( ) ( -pXMCDrvAdmin) ->IsAPILoggιngOn ( ) ( -pXMCDrvAdmin) ->IsC*ndJ-.oggιngOn ( ) ( -pXMCDrvAdmin) ->IsBι-;LoggιngOn ( ) Setting Attributes ( -pXMCDrvAαmin) ->SetA?IScream ( ) ( -pXMCDrvAαmin) ->SecC-"icS cre_-m ( ) ( • pXMCDrvAdmin) ->Sec3-.r;Scream ( ) Actions (-pXMCDrvAdmin) ->EnaoieA?I oggιnσ() ! -pXMCDrvAαmin) ->EnaDieC.**ιd oggι.ιg( ) ( 'pXMCDrvAdmin) ->EnableBιεLoggιr.g() ( •pXMCDrvAαmin) ->EnableDiagnoscics ( ) ' OXMCDrvAcmin) ->Vιewlr.cerfaceSuDpor- ( ) ROY-G-BIV Corporation Confidential 3/15/95 <0 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 3.0 XMC Driver Administrator 3.2.1 IXMC_Enuπ_Driver The IXMC_EnumDriver interface is used by the XMC Motion Conσol Component when building the interface enumeration describing the level of XMC support provided by each driver. This interface inherits from the standard IEnumX OLE interface. ROY-G-BIV Corporation Confidential 3/16/95 <D 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component 4.0 XMC Motion Control Component The Motion Conσol Component, which implements the majority of the XMCAPI set of functions, is used by applications. As a complete set. the OLE interfaces in the XMCAPI are separated into the four categories below. 1. Standard - Standard OLE interfaces. 2. Motion Control - Custom OLE interfaces used for motion conσol and code generation. 3. Code Generation - Custom OLE interfaces used for code generation only. 4. Diagnostic - Custom OLE interfaces used for debugging the system. XMCAPI interfaces follow the standard OLE 2.0 COM Object software model. The following OLE 2.0 interfaces make up the XMCAPI set of functions implemented by d e Motion Coπσol Component: Standard IClassFactory IDacaObject IDispacch IEnumX " ~ lUnknown — Motion Control IXMC_Counrer IXMC_Display IXMC_DynamάcStax:e IXMC_Encoder IXMC_EnumInter£ace IXMC_IO IXMC_Joystick IXMC_ imics IXMC_Motion IXMC_StaticStace IXMC Timer Code Generation IXMC_Operator IXMC_Program ""IXMC_ProgramFlow IXMC_ProgramMgm*; IXMC_Subroucine IXMC /ariable Diagnostic IXMC_Error IXMC_Debug 4.1 Standard OLE Interfaces The following standard OLE interfaces are supported by the Motion Conσol Component. For more information on each interface, see section 6.0 Standard OLE Interfaces. IClassFaczory IDacaOb-j ect; IDispaccn IEnumX lUnknown ROY-G-arv Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component 4.2 Custom OLE Interfaces • Moϋon Control The general set of interfaces is made up from all main motion conσol interfaces. Most interfaces resemble objects found within the motion conσol system. 4.2.1 IXMC_Counter Interface The IXMC_Couπter interface allows the programmer to manipulate a hardware counter. Actions (*pCouncer) ->Advise() (*pCount:er)->AcrachEncoder() (*pCouncer)->DecaciιEncoder() ('pCouncer)->Enable() (*pCouncer)->Reaet () (*pCouncer) ->UnAdvιse() QueryingAttributes (*pCouncer)->GetCounc () 4.2.2 IXMC_DynamicState Interface The IXMC_DynamicState interface manages high level system tasks, such as initialization, and allows the user to get all state information describing the motion coπσol system. When queried, other interfaces use an internal pointer to the IXMC_DyπamicState interface to retrieve state values, which are returned to the caller. The following metJiod≤ make up the IXMC_DynamicState interface: Configuration (*pDynSt) ->InitializeEx() ( *pDynSt ) ->Intιalize ( ) CpDynSt) ->Reset () ( *pDynS ) ->ShutDown ( ) Querying Attributes ( *pDynSt ) ->AreHardware ιmιtsOn ( ) ( -pDynSt ) ->AreSorcwareLimitsOn ( ) ( -pDynSt) ->GetAcceleratιon ( ) ( ♦ pDynSC) ->GetActualPosιcιon() ( *pDynS ) ->GetActualVelocιcy ( ) -(*pDynSt) ->GecCommandedPosιt:ιoπ ( ) CpDynSt) ->GetCommandedVelocιc {) ( -pDynS ) ->GetCounc ( ) ( -pDynSC ) ->GecDeceleratιon ( ) ( -pDynS ) ->GeεErrorStacus ( ) CpDynSt) ->GecHomePosιcιon ( ) CpDynSt) ->Get£ncoderResolutιon ( ) ( -pDynS ) ->Gec JogVelocicyHigh ( ) ( -pDynSc) ->GecJogVelocιcy ow ( ) ( -pDynSC) ->GecJoystιckVelocιtyHιgh ( ) ( -pDynSt) ->GecJoyscιckVeloc cyLow( ) (-pDynSC) ->GecJoyscιc)Acceleracιon ( ) ( -pDynSt) ->Get;Joysτ;ιckDeceleracιon ( ) ( -pDynSc) ->GecLιmιtDeceleracιon ( ) (-pDynSC) ->GecSofcware ιmιcPosι*;ιons ( ) (-pDynSC) ->GecMapMode () CpDynSt) ->GecPosιcιon() ( -pDynSC) ->GecTιmerTιc ( ) ( -pDynSc) ->GecUnιcs ( ) (-pDynSC) ->GetVelocιc ( ) ( -pDynSc) ->GetZeroPosιcιon ( ) ( -pDynSt) ->IsCouncerOn ( ) ( -pDynSc) ->IsInMot;ιon ( ) ( -pDynSC) ->IsIncerpolacιonOn ( ) ROY-G-BIV Corporation Confidential 3/15/95 © 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component (*pDynSt) ->IsJoy3C * .--k0n() (*pOynSc) ->IaMotionOn() CpDynSc) ->IsPosιcιonErrorCorrect:ionθn() ('pDynSt) ->IsTιmerOn() ( ♦ pDynSt) ->l3lOOucpucθn() ('pDynSC) ->l3l0Inpuc0n() Setting Attributes (*pDynSt)->Clear£rrors() Actions CpDynSt ) ->GetCS ( ) ( *pDynSC ) ->ReleaseCS ( ) 4.2.3 IXMC_Encoder Interface The IXMC_Eπcoder interface is used when working with encoder hardware. Once initialized, a pointer to an IXMC_Encoder interface may be attached to an IXMC_Motioπ interface which allows them to work together. Once attached, the IXMC_Motioπ interface uses the IXMC_Encoder interface position related functions, like setting the home position or querying the current position. Querying Attributes ( *pEncoder) ->GetErrorStatus ( ) ( *pEncoder ) ->GetHomePos-.tιon ( ) ( 'pEncoder ) ->GetPosirιon ( ) ( *pEncoder) ->GetZeroPosicιon ( ) (*pEncoder) ->GetResolutιon ( ) Setting Attributes ('pEncoder)->SetHo ePosition() ('pEncoder)->SetHo ePosιtιonEx() ( • pEncoder)->SetZeroPosιt-.on0 (*pEncoder)->SetZeroPos-.tιonEx() (*p£ncoder)->SetResolutιon() 4.2.4 IXMC_EnumInterface,^nterface The IXMC_EnumInterface interface is used to access the list of the XMCAPI interface names and a description of their implementations. For example, if the motion control hardware or software driver rDntroliing the hardware do not suppoπ code generation, all code generation interfaces in the enumeration would be listed as "NOT IMPLEMENTED". Knowing what interfaces are and are not supported allow particular programs to decide what dπvers are actually capable of running with the application. This interface inherits from the standard IEnumX OLE interface. Inheritance IEnumX I 1 IXMC Enuitilnterracs ROY-G-BIV Corporation Confidential 3/15/95 O 1995 ROY-G-BIV Corporation. All Rignts Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component 4.2.5 IXMC O Interface This interface is used by applications to manipulate both digital and analog I O suppσπ located on the motion control hardware. The following methods are available from the Motion Component in the IXMC_IO interface: Configuration CpIO) -initialize ( ) ( *pIO) ->InitιalizeE ( ) Querying Attrributes ( *pIO) ->GetErrorStatus ( ) ( *pIO) ->IsIntputEnabled { ) ( *pIO) ->IsOutput£nabled ( ) Actions CpIO)->Advise() ("pIO)->AttachMocion() (*pIO) ->DetachMotion() (*pIO)->EnableInpu () !*pIO) ->EnableOutput () CpIO)->Read() CpIO)->UnAdvιse() CpIO)-> nte() 4.2.6 IXMC_ Joystick Interface The IXMC_Joystick interface is used to manipulate a hardware joystick. When the joystick is enabled, all instances of the IXMC_Motioπ interface will be disabled. Querying Attributes ( *p JS ) ->GetAcceleratιon ( ) ( *p JS ) ->GetDeceleratιon ( ) ( *p JS ) ->GetErrorStatus ( ) ( -pJS) ->GetVelocιtyHigh ( ) ( *pJS) ->GetVelocι»tyLow ( ) CpJS ) ->IsEnabled ( ) Setting Attributes — pJS) ->SetAcceleration() (*pJS) ->SetDeceleratj.on() (-pJS) ->SetVelocιtyHιgh() ("pJS) ->SetVelσc_.cyLow{) CpJS) ->SetZero 0 Actions CpJS) ->ActachAnalogIO( ) ;*pJS) ->Actach ιmιcs() (*pJS) ->Decac AnalogIO() ( -pJS) ->DecachL--mxcs ( ) CpJS) ->Enable{) 4.2.7 IXMC_Limits Interface The IXMC_Liπuts interface is used to set software limit positions. The IXMC Limits. IXMC_Joystick, and IXMC_Motion interfaces work together to implement the software limits. Querying Attributes ! " P im) ->GecErrorStacus ( ) ( *pL-.m) ->Get xm-.cPosι-;j.ons ( ) ( -p im) ->GetDeceleratιon ( ) ! • pLim) ->AreSof tware i iT-sOn ( ) ROY-G-BIV Corporation Confidential 3 15/95 O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component ( *pLιrrt) ->AreHardwareLu*ut5θn ( ) Setting Attributes ( *pLim) ->Set ιrnιtPosιtιon3 ( ) { "pLim) ->SetDeceleracιon ( ) Actions (*pL--m) ->EnableSofcwareLimics () (*pLun) ->EnableHardwareLιmιts () 4.2.8 IXMC_Motion Interface The IXMC_Motion interface is used to perform movement operations. Most functions are passed an array of AXIS_DATA specifying the appropπate axis data. Configuration CpMotion) -i itialize ( ) ( *pMotιon) ->Tune ( ) ( "pMotion) ->Tune£x ( ) Querying Attributes ("pMotion)->GetAcceleratιon(! CpMotion) ->GetDeceleracιon() CpMotion)->GetErrorStatus () (*pMotιon)->GetVelocιty{) (*pMotιon)->GetPosιtιon() (*pMotιon) ->Getϋnιts () (*pMotιon) ->IsMotιonOn() (*pMotιon)->IsInterpolatιonOn() Setting Attributes (*pMotιon)->AttachEncoder() ( *pMotιon) ->Attach u**ιts ( ) ("pMotion) ->Detac Encoder() CpMotion) ->DetachLιmιts {) (*pMotιon)->SetAcceleratιon() ('pMotion)->SetDeceleratιon() ("pMotion)->SetPαsιtιon() (*pMotιon) ->SetVelocιc () ("pMotion)->SetJogVelocιtyHιgh() (*pMotιon) ->SecJogVelocιty o () Actions (*pMotιon) ->Advιse () ("pMotion) ->CreatePath() (*pMotιon)->EnableInterpolacιon() ("pMotion) ->EnableMotιon() CpMocion) ->EnablePo≤ιcιon£rrorCorrectιon() (-pMotion) ->GoHome () ("pMocxon) ->GoZero () ('pMotion) ->Jo () CpMotion) ->Kιll() ( 'pMotion) ->MoveAbs () ('pMotion) ->MoveConcinous ( ) ( 'pMotion) ->MoveRes ( ) ("pMotion) ->Stop() (*pMocιon) ->TraceArc (! ( *pMocιon) ->TracePath() ('pMotion) -XJnAdvise(; ROY-G- β lV Corporation Confidential 3/15 9S O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference -i.O XMC Motion Control Component 4.2.9 IXMC_StaticState Interface The IXMC_StaticState interface manages ail static data in the motion control system, such as scaling factors, maximum velocities and maximum accelerations. The following methods make up the IXMC_StaticState interface: Configuration CpStatSt ) ->InitializeEx ( ) CpStacSt) ->Intιalιze ( ) Querying Attributes ( *pStatSt ) ->GetAxisScaling ( ) ( 'pStatSt ) ->GetMaxAcceleratιon ( ) ( *pStatSt ) ->GetMaxDeceleracιon ( ) ( 'pStatSt ) ->GetMaxVelocιty ( ) ( *pStatSt ) ->GetPathScalιn ( ) ( *pStatSt ) ->GetOperatιngMode ( ) Setting Attributes ( *pStatSt ) ->SetAxisScaling ( ) ( 'pStatSt ) ->SetMaxAcceleratιon ( ) ( *pStatSt ) ->SetMaxDeceleratιon ( ) ( 'pStatSt ) ->SetMaxVelocιty ( ) ( *pStatSt ) ->SetPathScaling ( ) ( *p5tatSt ) ->SetOperatιngMoαe ( ) Actions CpStatSt ) ->CommιtState ( ) CpStatS ) ->EnableScalmgFactors ( ) CpStatSt) ->GetState 0 ( 'pStatSt ) ->ReleaseState ( ) 4.2.10 IXMC_Timer Interface The IXMC_Timer interface allows the programmer to manipulate a hardware timer. Querying Attributes CpTimer) ->GetDelay ( ) ( *pTι er ) ->Get£rrorStatus ( ) ( *pTi-mer) ->GetElapsedTιme ( ) _CpTιmer) ->GetResolutιon ( ) ( *pTιmer ) ->IsInDelay ( ) Setting Attributes ( "pTimer ) ->SetDelay ( ) Actions ( *pTιmer) ->Advιse ( ) ( *pTι*ner ) ->DoDelay ( ) ( "pTimer) ->Enaole ( ) ( -pTimer) ->Resec ( ) ( -pTimer) ->Start ( ) CpTimer) ->Stop ( ) ( "pTimer) ->ϋnAdvιse ( ) 4.3 Custom OLE Interfaces - Code Generaϋon Unlike the set of general interfaces, that may either run in either real-time or generating code modes, the code generation interfaces are only used when generating code. When used in conjunction with other general interfaces, complete motion control programs may be generated. This section discusses each of the code generation interfaces. ROY-G- β lV Corporation Confidential 3/15/95 O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component 43.1 DCMC_Operator Interface The IXMC_Opera.or interface contains general program statement generating functions including bitwise operations, mathematical operations, logical operations, and general conditional operations. The following functions are in the rXMC_Operator interface: Constants CE_PI Bitwise CpOper) ->BitAnd ( ) CpOper) ->BicNo ( ) CpOper) ->BitOr ( ) ( *pOper ) ->BitShif t ( ) ( *pOpe ) ->BitShif R ( ) CpOper) ->BitXOr ( ) Logical CpOper)->And() CpOper)->Not() CpOper)->Or() Mathematical CpOper)->Add() CpOper) ->Bit0 CpOper)->Div() (*pOper)->Lef Paren() CpOper)->Mult() (*pOper)->RightParen() CpOper)->Sqrt0 CpOper)->Sub() Trigonometric CpOper) ->ACos () CpOper) ->ASin ( ) CpOper) ->ATan ( ) CpOper) ->Cos ( ) CpOper) ->Sin ( ) .5 ( *pOper) ->Tan ( ) Labels/Strings/Comments -CpOper ) ->ASCIIChar ( ) ( *pOpe ) ->Coιπment ( ) ( -pOper ) ->DeclLabel ( ) CpOper) ->String ( ) Conditional (*pOper) ->Equal () (*pOρer)->GreacerThan() ( *pOper) ->GreaterThaπEqual () ('pOper) ->LessThan() (*pOper)->LessThanEqual () (*pOpe ) ->NotEqual () 4.3,2 IXMCJProgram Interface The IXMC_Program interface is used to generate the general program shell. Several other program flow functions like causing the program to sleep for a specified amount of time are also included. The following methods make up the interface: Program Flow ( • pProg)->Combine() ('pProg) ->Define() ( *pProg) ->Download() ROY-G-BIV Corporation Confidential 3/16/95 O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component CpProg) ->End ( ) CpProg) ->Exie ( ) ( -pProg) ->RenderAsText ( ) CpProg) ->Run ( ) CpProg) ->Sleep ( ) CpProg) ->Stop ( ) 43.3 IXMC_ProgramFIow Interface The IXMC_ProgramFlow interface is used to generate code used to control the flow of a program. Methods are available to generate if-else and general looping statements. The following methods are in the IXMC_ProgramFlow interface: If/Else (*pProgFlow)->IfOpen() ("pProgFlow)->IfClose() (-pProgFlow) ->Else() (*pProgFlo )->EndIf() While ("pProgFlow)->WhileOpen() ('pProgFlow)->WhileClose() (*pProgFlow)->EndWhile () Repeat ('pProgFlow) ->Repeat() {'pProgFlow)->ϋntilOpen() ('pProgFlow)->ϋntilClose () Loops ('pProgFlow) ->Loo () ('pProgFlow)->EndLoop() Misc. CPProgFlow) ->Brea ( ) ( 'pProgFlow) ->GoTo ( ) 4.3.4 IXMC_ProgramMgmrinterface The IXMC_ProgramMgmt interface is used when working with programs on a high level. Running and saving programs are a few operations included in this interface. The following methods make up the interface: Program Management CpProgMg t ) ->Download ( ) ( *pProgMgm ) ->Upload ( ) ( *pProgMgmt ) ->SetOucpu ( ) ( •pProgMςrm ) ->OpenOutput ( ) ( -pProgMgmt) ->CloseOutput ( ) ( *pProgMgmc ) ->FlushOutput ( ) ROY-G-BIV Corporation Confidential " ' "a TaJS-T O 1995 ROY-G-BIV Corporation. All Rights Reserved. XMC Motion Control XMCAPI Reference 4.0 XMC Motion Control Component 4.3.5 IXM C_Subroutiπe Interface The IXMC_Subroutiπe interface is used to generate and subroutines and calls to subroutines generated. The following methods are in the IXMC_Subroutiπe interface: General CpSub) ->Define ( ) CpSub) ->End ( ) CpSub) ->Call O 4-3.6 IXMC_Variable Interface The IXMC_Variabie interface is used to define and assign values to variables. The following methods are included in the interface: Definition CpVar) ->Define ( ) Assignment ( *pVar ) ->AssignNumeric ( ) ( *pVar ) ->A-jsigi-Binary ( ) ( *pVar) ->AssignStrin ( ) 4.4 Custom OLE Interlaces - Diagnostic Diagnostic interfaces may be used by the application developer when debugging the system. The methods in the interface provide the user with logs of information generated when running the XMC software model. Logs may be created for XMCAPI calls, and all information flowing in and out of specified ports. 4.4.1 rXMC_Erτor Interface The rXMC_Error interface is provided to give the application developer a consistant method of displaying and logging all XMC errors based on the HRESULT value returned by functions that fail. The following methods are in jtte interface- Setting Attributes ( *pError) ->SetOutput ( ) Actions ( *pError ) ->Display ( ) CpError) ->Log ( ) ( *pErro ) ->StringFromHRESULT ( ) 4.4.2 IXMC_Debug Interface The IXMC_Debug interface gives the application developer control over several log files that may be generated to help debug an application using the XMC software model. The following methods are in the interface: Setting Attributes (-pDebug)->SetXMCAPILogFile() (*pOebug) ->SetXMCAPIStrea () Actions (-pDebug) ->EnableXMCAPI ogging() ('pDebug)->EnableDιagnostιcs () ROY-G-BIV Corporation Confidential 3 16/95 <0 1995 ROY-G-BIV Corporation. All Rights Reserved. Motion Control Component Specification Appendix A Appendix A A.1 Reviewer Feedback All feedback is important in order to evolve the specification into a standard software model for motion control hardware. Please, at a minimum, respond to the following issues: 1. Which areas, ideas, or concepts within the specification seem confusing to you? 2. Do you see any unresolved issues, other than those listed above? 3. Are there any main features missing from die specification that you would find useful? 4. Are there any specific scenario-maps you would like to see in the next revision? 5. Are there any specific C or C++ code examples you would like to see? 6. Are there any specific Visual Basic code examples you would like to see? A. .1 Correspondence If possible, please send all feedback over email to the following address: Dave Brown ROY-G-BIV Corporation CompuServe : 72103 ,2235 Internet: 72103-2235@compuserve.com Otherwise, if you do not have access to email, please mail all correspondence to the following address: Dave Brown ROY-G-BIV Corporation P.O. Box 1278 White Salmon, WA. 98672 ROY-G-BIV Corporation Confidential 3/15/95 O 1995 ROY-G-BIV Corporation. All Rights Reserved.

Claims: I claim: 1. A method of moving an object in a desired manner, comprising the steps of: defining a set of motion control operations, where each motion control operation is either a primitive operation that is necessary to perform motion control and that cannot be simulated using other motion control operations or a non-primitive operation that does not meet the definition of a primitive operation; defining a core set of core driver functions, where each core driver function is associated with one of the primitive operations; defining an extended set of extended driver functions, where each extended driver function is associated with one of the non-primitive operations; defining a set of component functions; providing component code for each of the component functions, where the component code associates at least some of the component functions with at least some of the driver functions; developing a set of software drivers, where (i) each software driver is associated with one motion control device in a supported group of motion control devices and (ii) each software driver comprises driver code for implementing the motion control operations associated with at least some of the driver functions; providing an application program comprising a series of component functions, where the application program defines the motion steps necessary to move the object in the desired manner; selecting one motion control device from the group of supported motion control devices; attaching the object to the selected motion control device; selecting from the set of software drivers the software driver associated with the selected motion control device; generating control commands based on the component functions of the application program, the component code associated with the component functions, and the driver code associated with the selected software driver; and operating the selected motion control device based on the control commands to move the object in the desired manner. 2. A method as recited in claim 1 , in which the step of providing the set of software drivers comprises the step of developing driver code to implement all of the core driver functions. 3. A method as recited in claim 2, in which the step of developing the set of software drivers further comprises the step of developing driver code to implement at least some of the extended driver functions. 4. A method as recited in claim 3, in which: non-supported extended driver functions are extended driver functions having no driver code associated therewith; and the step of generating control commands comprises the step of generating the control commands based on the driver code associated with a combination of the core driver functions to emulate the plurality of incremental motion steps associated with at least some of the non-supported extended driver functions. 5. A method as recited in claim 4, in which the step of generating the control commands further comprises the steps of: developing an extended function pointer table that maps the non-supported extended driver functions to the combination of core driver functions employed to emulate the non-supported extended functions; and generating the control commands further based on the contents of the stub table. 6. A method as recited in claim 5, in which the extended function pointer table contains pointers for both supported and non-supported extended driver functions, where the pointers for the supported extended driver functions point to driver code for implementing the supported extended driver functions and the pointers for the non-supported extended driver functions point to the combination of core driver functions that emulate the non-supported extended functions. 7. A method as recited in claim 1 , further comprising the step of: determining a first unit system employed by the software drivers; wherein the step of generating the control commands further comprises the step of converting a second unit system employed by the application program into the first unit system. 8. A method as recited in claim 1 , further comprising the steps of: providing a plurality of destinations of control commands; providing a plurality of streams, where each stream contains transmit stream code that determines how the control commands are to be transferred to at least one of the destinations of control commands; selecting at least one of the destinations of control commands; and transferring the control commands to the selected destination of control commands based on the transmit stream code contained by the stream associated with the selected destination of control commands. 9. A method as recited in claim 8, in which certain of the destinations of control commands generate response data, the method further comprising the steps of: providing response stream code for the streams associated with the destinations of control commands that generate response data; and processing the response data based on the response stream code. 10. A method of moving an object in a desired manner, comprising the steps of: defining a first set of first driver functions and a second set of second driver functions, where each first driver function is associated with an incremental motion step performed by motion control devices and each second driver function is associated with a plurality of such incremental motion steps; providing a plurality of software drivers, where each software driver comprises driver code and is associated with one motion control device selected from a group of supported motion control devices; providing an application program comprising a sequence of program instructions; selecting a motion control device from the supported group of motion control devices; mounting the object on the selected motion control device; selecting the software driver associated with the selected motion control device; generating control commands based on the application program, the first and second driver functions, and the driver code associated with the selected software driver; and operating the selected motion control device based on the control commands to move the object in the desired manner. 11. A method as recited in claim 10, in which the step of providing the set of software drivers comprises the step of developing driver code to implement all of the first driver functions. 12. A method as recited in claim 11 , in which the step of developing the set of software drivers further comprises the step of developing driver code to implement at least some of the second driver functions. 13. A method as recited in claim 12, in which: non-supported second driver functions are second driver functions having no driver code associated therewith; and the step of generating control commands comprises the step of generating the control commands based on the driver code associated with a combination of the first driver functions to emulate the plurality of incremental motion steps associated with at least some of the non-supported second driver functions. 14. A method as recited in claim 13, in which the step of generating the control commands further comprises the steps of: developing an extended function pointer table that maps the non-supported extended driver functions to the combination of core driver functions employed to emulate the non-supported extended functions; and generating the control commands further based on the contents of the stub table. 15. A method as recited in claim 14, in which the extended function pointer table contains pointers for both supported and non-supported extended driver functions, where the pointers for the supported extended driver functions point to driver code for implementing the supported extended driver functions and the pointers for the non-supported extended driver functions point to the combination of core driver functions that emulate the non-supported extended functions. 16. A method as recited in claim 10, further comprising the step of: determining a first unit system employed by the software drivers; wherein the step of generating the control commands further comprises the step of converting a second unit system employed by the application program into the first unit system. 17. A method of generating a sequence of control commands for controlling a motion control device to perform a given series of motion steps based on an application program defining the given series of motion steps, the method comprising the steps of: defining a set of motion control operations, where each motion control operation is either a primitive operation that is necessary to perform motion control and that cannot be simulated using other motion control operations or a non-primitive operation that does not meet the definition of a primitive operation; defining a core set of core driver functions, where each core driver function is associated with one of the primitive operations; defining an extended set of extended driver functions, where each extended driver function is associated with one of the non-primitive operations; defining a set of component functions; providing component code for each of the component functions, where the component code associates at least some of the component functions with at least some of the driver functions; developing a set of software drivers, where (i) each software driver is associated with one motion control device in a supported group of motion control devices and (ii) each software driver comprises driver code for implementing the motion control operations associated with at least some of the driver functions; selecting one motion control device from the group of supported motion control devices; selecting from the set of software drivers the software driver associated with the selected motion control device; and generating control commands based on the application program, the component code, and the driver code associated with the selected software driver. 18. A method as recited in claim 17, in which the step of providing the set of software drivers comprises the step of developing driver code to implement all of the core driver functions. 19. A method as recited in claim 18, in which the step of developing the set of software drivers further comprises the step of developing driver code to implement at least some of the extended driver functions. 20. A method as recited in claim 19, in which: non-supported extended driver functions are extended driver functions having no driver code associated therewith; and the step of generating control commands comprises the step of generating the control commands based on the driver code associated with a combination of the core driver functions to emulate the plurality of incremental motion steps associated with at least some of the non-supported extended driver functions. 21. A method as recited in claim 20, in which the step of generating the control commands further comprises the steps of: developing an extended function pointer table that maps the non-supported extended driver functions to the combination of core driver functions employed to emulate the non-supported extended functions; and generating the control commands further based on the contents of the stub table. 22. A method as recited in claim 21 , in which the extended function pointer table contains pointers for both supported and non-supported extended driver functions, where the pointers for the supported extended driver functions point to driver code for implementing the supported extended driver functions and the pointers for the non-supported extended driver functions point to the combination of core driver functions that emulate the non-supported extended functions. 23. A method as recited in claim 17, further comprising the step of: determining a first unit system employed by the software drivers; wherein the step of generating the control commands further comprises the step of converting a second unit system employed by the application program into the first unit system. 24. A method as recited in claim 17, further comprising the steps of: providing a plurality of destinations of control commands; providing a plurality of streams, where each stream contains transmit stream code that determines how the control commands are to be transferred to at least one of the destinations of control commands; selecting at least one of the destinations of control commands; and transferring the control commands to the selected destination of control commands based on the transmit stream code contained by the stream associated with the selected destination of control commands. 25. A method as recited in claim 24, in which certain of the destinations of control commands generate response data, the method further comprising the steps of: providing response stream code for the streams associated with the destinations of control commands that generate response data; and processing the response data based on the response stream code. 26. A method of generating a software driver for allowing a software system to control a hardware system to perform a desired operation based on an application program defining the desired operation, the method comprising the steps of: defining at least one driver function for implementing the desired operation; defining a command format template and a response format template for each driver function; generating command data strings based on the command format template and the application program; and parsing response data strings based on the response format template and the application program. 27. A method as recited in claim 17, in which the step of generating the control commands further comprises the steps of: defining a command format template and a response format template for each driver function; generating command data strings based on the command format template and the application program; and parsing response data strings based on the response format template and the application program.

Inventors: BROWN DAVID W, CLARK JAY S, BROWN, DAVID, W., CLARK, JAY, S.
Applicants: ROY G BIV CORP, ROY-G-BIV CORPORATION
Application year: 1996
Main classification: G05B19
IPC codes: G05B15, G05B19, G06F9