MOTION CONTROL COMPONENT
`WOSA API/SPI SPECIFICATION
`
`Revision:
`Author:
`Date:
`Document:
`Description:
`
`First Draft
`Dave Brown
`Tuesday, April 12, 1994
`\\rgbsrvr 2’~d\data\rgb\cmpnt \motion\prj\doc\ana\smallbp.doc
`This doc-~ment describes the summary business plan for the Motion Control WOSA API/SPI working
`model and specification.
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BIV Corporation. All rights reserved.
`
`A J~ EXHIBIT ]-J~
`
`Depon~~
`
`WWW.DEPOBOOK.COM
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120632
`
`

`
`Motion Control Component Specification
`
`This is a preliminary, release of the documenk~lion, l! nm. be changed subst nt llv. prior ~ final connnercial release.. "~s. documenl is
`prox ideal tbr discussion puq~oses only in strict confidence and subject to the non-disclosure a~eemeut executed be~veen ROY-G-BIV
`Corporation and Compumotor, a division of Parker Ha~mifin on April 6. 1994.
`
`RO~’-G-BIV, ~:OS.-VXMC, M(’API, aud MCSPI are trademar~ ofROY-G-BIV C(ul~oration.
`
`Microsoft. Microsoft Vismd C++, Microsoft Visual Basic. ~VIN32_ and Microsoft Excel 5.0 are registered trademar~ and
`~~do~vs NT, ~’IN32s, ~’1N32c, and OLE are Irade=narks of Microsolt Cuq~oration.
`
`Borl~tl and Borland C++ ~e trademarks of Borland International. Inc.
`
`Printed m the United S~ates of_~nefica.
`
`ROY-G-BIV Corporation Confidential.
`994 ROY-G-BIV Corporation. All Rights Reserved,
`
`411911994 7:48:00 PM
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120633
`
`

`
`Motion Control Component Specification Table of Contents
`
`1.0 OVERVIEW .....................................................................................................................................
`
`1.1 DEFINITIONS ........................................................................................................................................
`
`2.0 PROJECT VISION ..........................................................................................................................
`
`4
`
`4
`
`6
`
`2. l PROJECT GOAL ....................................................................................................................................
`2.2 PROYECT BENEF1TS ...............................................................................................................................
`2.3 SOFTW.~RE MODEL ..............................................................................................................................
`2.4 PROJECT STRATEGY. ............................................................................................................................
`2. 4.1 Prqjecr Phases. ............................................................................................................................
`11
`
`3.0 ~EVELOPMENT ...........................................................................................................................
`
`6
`6
`7
`8
`.9
`
`11
`3.1 DESIGN GO.~S ..................................................................................................................................
`11
`3.2 TARGET PLATFORMS ..........................................................................................................................
`12
`3.3 FOL~DATION SOFTWA~ TECHNOLOGY USED .....................................................................................
`12
`3.3.] OLE 2.0 .....................................................................................................................................
`12
`3.3.2 gZV32 .......................................................................................................................................
`14
`3.4 SOFTW.~E MODEL ............................................................................................................................ 15
`3.5 SCEN.~K) MAPS ................................................................................................................................
`3.5.1 hlitialization ¢(’ore 3ICqPI) ......................................................................................................
`
`3.5.2 &~n’o T mmg (Extemted 3 ICSPI) ...............................................................................................
`3.5.3 3[ovinN Absolute (Core 31C,5~I) .................................................................................................
`3.5.4 Move Relative with 17sual Basic Application .............................................................................
`3.6 VISUAL BASIC SUPPORT .....................................................................................................................
`3.6.1 I isual Basic Example ................................................................................................................
`
`3.7 MC~I INTERFACES ..........................................................................................................................
`3. 7 1 IContponentEm, lntetTt;~ce ..........................................................................................................
`3.7. 2 I.l [otion( :ontrol httet~/bce ...........................................................................................................
`3. 7.3 IDigitagO h~terlhce ...................................................................................................................
`3.7. 4 L4nolog[O h~teg[bce ...................................................................................................................
`3.8 MC SPI INTERFACES ..........................................................................................................................
`3.8. 1 lI)twCore 3 lotionComrol Interface ...........................................................................................
`3.8.2 II)t~’Core DigitalIO b~tetfwe ...................................................................................................
`3.8. 3 IDm,Core=4 redo,giG bttetJbce ...................................................................................................
`
`17
`18
`19
`20
`20
`21
`21
`21
`22
`22
`23
`24
`24
`25
`
`3.8. 4 ID~’Ext 3Iotio~K~ontrol bttet;/iwe ................................................................................................
`26
`3.8 5 ID~’vExt{ 7_Motio,(2mtrol h~wrfiwe ..........................................................................................
`
`4.0 MARKETING ................................................................................................................................
`
`4,1 STRATE(W. .......................................................................................................................................
`4.2 MATERIALS .......................................................................................................................................
`4.3 METHODS ..........................................................................................................................................
`
`5.0 INTEGRATION .............................................................................................................................
`
`27
`27
`28
`
`28
`
`ROY-G-BIV Corporation Confidential.
`© 1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`411911994 7:48:00
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120634
`
`

`
`Motion Control Component Specification 1.0 Overview
`
`1.0 Overview
`Tiffs document describes the WOSA APIiSPI software model and specification, otheiavise known as tile
`WOSA extension for Motion Control or WOSA!XMC. \vhich is a software model used by software
`applicalions to control motion control hardware. The model gives each application a hardware
`independent motion control solution. In addition to hardware independence, the model is easily
`extensible for uew motiou control hardware.
`
`The goal of this document is to create a foundation for a standardized motion control software model.
`Font main sections, described below, outline the goals of tlle model, how it is to be implemented, and how
`it will be introduced to the market. The main seclions are the folloxdng:
`
`Project Vision - Included in this section are tile overall projecl goal, a high-level description of tile
`software model designed to fidfill that goal. and the plmmed path to bring the developed software to
`market.
`
`Development Plan - This section discusses tile softavare design in detail. Included in tiffs section are
`descriptions of the main objects iu the systenl, how they, iuteract wilh each other, and the OLE 2.0
`interfaces tile?- support, which include specifications for both the motion control application progrmnnffng
`interface called MCAPI and the motion control service provider interface called MCSPL
`
`Marketing Plan - In this section, tile overall marketing plan is discnssed, ~hich includes describing the
`marketing strate~-, the methods of marketing to be nsed. mid the marketing materials needed for each
`method.
`
`Integration Plan - Tiffs section discusses the lnethods used to integrate the model with both new motion
`control hardware ~ endors, and new lnotion control application developers.
`
`1.1 Definitions
`WOSA - Windows Open Service Architecture - this is tile Microsoft opeu service model supported by
`Microsoft Windows to allow third part3.: vendors a method of consisteutly extending Microsoft Windows.
`
`WOSA/XMC - WOSA extension for Motion Control - this is tile extension for Microsoft Windows used
`to manipulate and conlfol Motion Control hardware.
`
`MCAPI - Motion Control Application Progrannning Interfitce - tiffs is tile specific set of functions called
`by appfications using Motion Control. The Motion Component provides the majoriV of the MCAPI
`fimctions, \vhich are all hardware independent. Se\ eral functions in tile MCAPI. used to access tile
`current drker environment, are provided by the Motion Control Dri~ er Administrator.
`
`MCSPI - Motion Control Service Provider Intel~lce - this is the specific set of fimctions called by the
`Motion Component supporting the MCAPI. Each MCSPI software driver is hardware dependeni for it
`directly communicates wilh a specific hardware implementation usi ng the ha rdware implementations
`motion control language and commnnication registers or ports.
`
`Motion Driver Administrator - The Motion Drix er Administrator is all independent Windows
`application used to install/remove Motion Device Drivers. The user may also toggle API diagnostic
`logging, for debugging, through the Motion Driver Administrator. In addition to providing drix er
`management se~ices to the user. the administrator is used by all applications, using thc WOSA/X~IC
`software, to access the current Motion Device Driver enviromnent. This en~ ironment is later used in
`co~[iunction ~ilh the Molion Component to conlrol specific molion control hard,rare. Tile enx iromnenl
`creation fimclions make up a sumll subset of the MCAPI mentioned above.
`
`ROY-G-BIV Corporation Confidential.
`1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`4/19/1994 7:48:00 PM
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120635
`
`

`
`Motion Control Component Specification 2.0 Project Vision
`
`Motion Component - All applicatious using the WOSAiXMC soflxvare model couununicate directly with
`the Motion Component. The Motion Colnponent is a hardware indepeudent implementation of the
`motiou control abstraction specified b3 the MCAPI. Both the fimctions supported bv the Motioll
`Component and those supported by the Motion Driver Administrator together make up the MCAPI.
`
`Motion Driver - The Motion Driver is the actual hardxxare dependent software driver that uses the motion
`coutrol command lan~mge to commnnicate with the motion control hardware that supports it, Evely
`Motion Driver supports a set of functions called core functions. These are primitive fimctions required by
`all motion applications. The core functions are a subset of the MCSPI. The remaining set of MCSPI
`fimctions are called extended functions and are not required to be implemented
`
`Motion Driver Stab - The Motion Driver Stub is a seconda~’ Motion Driver supplied to support all
`MCSPI extended fimctions not supported by the Motion Dri\ er. A software algorithm is used to
`implement the functionally’ that doesn’t exist in the underlying motion control hardware.
`
`ROY-G-BIV Corporation Confidential
`~ 1994 ROY-G-BI\ (’oq~oration .All ~-ights reser\ed
`
`4119/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120636
`
`

`
`Motion Control Component Specification 2.0 Project Vision
`
`2.0 Project Vision
`Tiffs section describes the overall vision of lhe motion colnponent, a high level description of the software
`model, and an overall strategy to bring the prqject to market.
`
`2.1 Project Goa/
`The overall goal of the MCAPIAMCSPI WOSA extension for Motion Control (WOSA/XMC) model is to
`create and standardize a hardware independent, software inlerface used to manipulate motion control
`hardware in the motion control industry.
`
`Such a solution will broadeu the motion control software market from applicatious that only support one
`specific harehvare vendor’s motion control implementation to that of all hardware vendor’s’supporting the
`
`model. This will vastly increase the value of the motion control soft, rare built on the software model.
`
`In order to fidfill this vision, the model must be easv to integrate into motion control applications. An
`easy application integration path will be provided by snpporting currenl popular soffivare development
`tools such as Microsoft Visual C++, Borland C++, and any high-level language or macro langmage
`snpporting OLE 2.0 Antomation such as Microsoft Visual Basic 3.0 or Microsoft Excel 5.0.
`
`2.2 Project Benefits
`There are several benefits of the WOSAiXMC software model that will help hardware vendors
`implementing motion control hardware, software developers crealing motion control software
`applications, and end users operating motion control software applications. The benefits for each are
`described in this section.
`
`Hardware Vendors - Hard~are vendors who want to add support for Windows 3.1. Windows NT. and
`filtnre versions of Windows. to their motion control hardware will benefit from nmch lower development
`costs. In order to become a participant in the WOSA/XMC software model, each hardware vendor ueed
`olflv create a Motion Driver that supports the MCSPI. ffa hardware vendor has several different
`hardware inlplelnentations, again they otdv need to create MCSPI Drivers for each one. Each hardware
`vendor will save the effort of developing both the Motion Component and the Motion Driver
`Administrator which both provide the hard~are independent solution to applications.
`
`Soft,rare Developers - Soft,rare developers will benefit by having a hardware independent solution for
`motion control. Instead of focnsing on the intricacies of a particular hardware implementation, the
`sofiware developer will be freed to focus on the actual motion control problem at hand.
`
`End Users - End users will benefit for now they will have a hardware independent motion control
`solution to nm their morion control applicatious on. If one particular implementation of hardware is not
`optimal for their application, they can easily plug in a different hardware implementation that implements
`more motion control hardware fimctionalit). \~ithout ha~ing to purchase a differen! sofl~vare application
`for the new hardware.
`
`ROY-G-BIV Corporation Confidential.
`1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`4/19/1994 7:48:00 PM
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB0012063 7
`
`

`
`Motion Control Component Specification 2.0 Project Vision
`
`2.3 Software Model
`The general WOSAiXMC nlodel consists of four main cntilies which include the Hardware
`Adnlinistrator. the hardware independent Motion Component supporting the MCAPI. the hardware
`dependent Motion Control drix er supporlmg die MCSPI. and finally the applications that run use the
`Motion Component to solve molion control problems. As yon will see iu section 3.0 Dm-elopment, tile
`model below is a high-level model describing the lnain entities in it and how they interact. Users can
`easily plug-n-play hardware device drivers in and out of the syistenl, without affecting the software
`running on the model.
`
`! C++ Application ! i ~ \
`
`API Layer
`
`\\
`
`"~--~.
`
`~. ~ Driver Adm|mstrator
`
`~"~on Conlrol App Prig Interface IMC.~,PI)
`
`MOTION COMPONENT
`
`l
`
`O
`
`-~--
`
`Motion~ntml Self’ice Provider ,,’lleffa~e {MCS P’,
`
`\
`
`MOTION
`
`Hardware
`
`Motion~ontrol
`Hardware
`Implementation #1
`
`M~ion Control
`Hardware
`Implementation #2
`
`’
`
`_~t__
`Motion Control
`Hardware
`Implementation #3
`
`Figure 1 General W©SA API/SPI Model known as WOSA/XMC
`
`Applications directly communicate ~ith tile Driver Adnmustrator and Motion Component. Tile MCAPI
`provides the communication link between tile applications and the Driver Administrator and Motion
`Component. The Driver Administrator is used by the application to access the correct driver state data
`which is then passed on to the Motion Colrtponent for all fitrtller motion control interaction. From the
`applications perspective, all motion interaction is independent of the actnal hardware implementation
`carrvingout the requested actiol~s. For example, ifthe Applicatiou wants to reqnest the motion hardware
`to trine the servo settings, it invokes one of the Motion Component’s fimctions to do so. Tile application
`docsn’t need to know what hardware is being mued. In some ca~es, the hardwarc may not cven snpport
`seta-o tuning. When ever an MCSPI fimction is not supported directly by the hardware, as in the Tumng
`example, the Motion Colnponent calls Ilte Motion Dri\ er Slub which then allelnpls to carD: out the
`fimctionalit~’ reqnested by’ calling required, core MCSPI fimctions located in the Motion Driver.
`All MCSPI’supporting Motion Drk ers are reqnired to impleulent a core set of fimctions to participate in
`the WOSA/XMC model. Depending on the hard,rare support for motion control fimctionality, many
`Motion Drivers will support some or all of tile extended interface snpported by the Motion Driver Stub.
`increasing motion control efficiency.
`
`ROY-G-BIV Corporation Confidential
`t994 ROY-G-BIV Corporation All rights reser\ed
`
`4/19/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120638
`
`

`
`Motion Control Component Specification 2.0 Project Vision
`
`For example, consider tile following scenario:
`
`Application
`
`Call (,MCAP]) ContourQ
`
`¯ MCAPI
`
`\’\Call (MCSPI) Contour0
`
`MCSPI Stub
`
`MCSPI ]
`
`B.
`
`Application ] ~ CAPI) Contour0
`
`Call (MCSPl Stub) ContourQ/
`
`’~ Call (MCSPI) Contour0,
`@
`"\but it is not supported by driver
`"
`
`J~-" -~ r -~S.~"-
`~
`_
`
`@Since the Hardware supports
`"7 Countour Moves. the MCSPI
`directs the hardware to ca~
`out "[he contour move.
`
`¯
`Hardware
`
`MCSPI Stub, calls ~MCSPI)
`core function Move() "to make
`the contour move.
`
`MCSP! can’ies out each
`tmove requested by the
`
`:~yCSPl Stub.
`¯
`Hardware
`
`Figure 2 MCAPI, MCSPI, and MCSPI Stub Interaction
`
`As shown in diagram A of Fi~tre 2 above, tile Application calls the MCAPI Contour ( fimction to
`perform a contour motion. Tile MCAPI ill turn. calls tile MCSPI driver’s Contour ( ) fimction. Since
`the hardware driven by this particular MCSPI implelnents contour moves, the MCSPI fimction sends the
`appropriate hardware lan~lage statements to the hardware telling it to perform tile contour move. On the
`other hand. ill diagram B of Fi~=re 2 above, when tile MCAPI Contour ( ) fimction calls the MCSPI
`driver Coat ou r ( ) fimction, the MCSPI notifies the MCAPI that it cannot perform the operation because
`it is not supported by the hardware. After being notified of the hardware deficiency, the MCAPI calls the
`MCSPI driver Stub to perform the requested action through a less efficient software algorithm. The
`MCAPI calls the MCSPI driver Stub’s Contour ( ) fimction which follows the contour path and
`incrementally calls the MCSPI’s Hove~d~s ( ) fimction which is a core fimction.
`
`Every MCSPI supporting Motion Control driver nmst support the core MCSPI fi~nctions in order to
`participate in the WOSA/XMC model. Core fimctions are all fimctions absolutely necessary to sohe a
`motion control problem. Hardware initialization. Moving, and Stopping. are a fe’w examples of core
`motion comrol fimctions. In addition to supporting a core fimctions, the MCSPI may snpport several or
`all of the extension fimctious. Extension fimctious are all fimctions that can be performed by sequenciug
`together core fimctions to can.-y oat the requested action, For example. Contour ( I CurveTrace ( ),
`and Hovei~el ( ) are extension fimctions for each requested action can be performed tln’ough a software
`algofithln that uses core fimctions to carry out the action on the motion control hardware. Of course the
`software solution of an action provided by the MCSPI driver Stub will me nmch less efficient than one
`directly supported the motion control hards~are. The core and extension MCSPI are discussed in more
`detail in 3.0 Development.
`
`2.4 Project Strategy
`Tile overall prqject strategy is to create tile WOSA/XMC soft~are ill a ~va) thai not onl) largets each of
`the various evoh’ing Windox~ s platforms, but does so in a way that encourages hardware vendors to
`pallicipate ill standardization process. Particular target Windows platforms ~’ill help entice each
`hardware vendor to participate. The following are the planned target enviromuents tbr the model:
`
`¯ Version 1.0 targets Windows NT 3. l/Daytona and Windows 3.1 through WlN32s.
`¯ Version 1.5 targets Wmdmvs 4.0/Chicago.
`¯ Version 2.0 targets Windows NT 4.0!Cairo.
`
`But having access to tile final software making up tile MCAPI/MCSPI WOSA/.~MC model is not enough
`to entice each hardware vendor to participate in the open forum. Participating hardware vendors will be
`
`ROY-G-BIV Corporation Confidential
`1994 RO’Y-G-BIV Corporation .MI righL,; reserved
`
`4/19!94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120639
`
`

`
`Motion Control Component Specification
`
`2.0 Project Vision
`
`able to learn and integrale pre-release software making up the model. In addition participants are
`encouraged to actively gi~e feedback oft ilDproveIDelltS fiecessal.-y for the model to better work with their
`implementation of motion control hard~ are.
`
`Corporation
`
`Initial Specification ~. Hardware
`
`~- .... ~/ Hardware
`--- .,~!~~ _..~------------~. )
`...... _~’~ Hardware
`
`WOSA!NMC,
`MCAPI,
`MCSPI
`Deft ni tion
`
`Manage
`WOSA,XMC.
`MCAPl,
`MCSPI
`evolution.
`
`Develop
`WOSA,~MC
`MCAPI for
`Windos NT
`~nd W n32s.~
`
`2.4.1 Project Phases
`There are several planned phases m the WOSAiXMC soft,rare model. Before describing e~ch individual
`phase an overall phase cycle is described. Figure 3 describes the general evohltion of each phase in the
`WOSA/XMC model evohltion: As a rough outline, the general phase cycle begins with the feature
`specification for the target version of the sofm’are. Next. through interaction with all participants iu the
`foninL the specification will begin to evoh’e and
`eventually solidify. Once the specification
`becomes relatively solid, development of the
`software begins. Pre releases are passed out to
`all participants who in turn should respond with
`any bug reports fonnd in the software. After the
`software development reaches a code freeze, a
`stnlcmred testing process begins. All the while.
`participants are encouraged to send in
`improvement and bug reports. After the
`structured testing is completed, the software
`will be ready for a final release. And. after the
`final release, a post-mortem process is starled to
`evaluate the overall phase and decide how to
`improve it before the next phase begins. The
`following describes each of the three planned
`phases:
`
`Improvemen~ New
`
`Version 1.0 Specification
`
`~ Small modificati~3ns~
`~ ~
`
`~
`
`Pre-Alpha Release
`DHver Administralor,
`
`Develop MCSP[
`suppo~1ing d6w~.
`
`Integrate WOSA:~C
`softie ~to motion
`
`applications.
`
`MCSPI
`supporting
`drive~ s ~br
`Windes NT.
`
`Structuled
`Testing,
`Bug lixes.
`
`MCAPI, and MCSPI drivet~,
`
`MCAPI, and MCSPI
`drivers fnr Windows NT 3.1.
`
`Phase I.
`During this phase x~e plan to collaborate with
`several key motion control hardware vendors to
`improve and integrate version 1.0 of the WOSA
`extension for Motion Control, The target
`software platforms are both Windows NT
`3. l!Daytona and Windows 3.1 through
`WIN32s. At this time. the participating
`hardware vendors should both participate in the
`MCAPI and MCSPI evolution and start
`integrating the software model into their current
`motion control software applications. If
`possible, hardwarc vendors will also be
`encouraged to integrate current software drivers
`into ones supporting the MCSPI.
`
`r
`
`~
`
`Beta Release
`Driver Administrator,
`MCAPI, and MCSPI
`drivers for ]¢Vindows NT 3. I.
`
`Application Bern-Test
`
`,~ ppliclion Marketing
`
`Main enan~ Dit e _
`MCAPL andMCSPI
`Re e~ses !
`drivers for W ndows NT 3.1.
`
`, ..........
`
`Distribution
`
`Phase II.
`Duriug this phase we plaD to open the fonnn to
`~nore hardware vendors and several application
`developers specializing in the lnotion control
`industry. Again, feedback from all participants
`u’ill be ilnporlant in order to evohe the MCAPI
`and MCSPI towards a standard At this time.
`version 1.5 of the model will come to fi’uition with filll bacM~ard compatibility to x ersion 1.0. This
`
`comm~ication, etc.
`
`Figure 3 General Phase Cycle
`
`versiofi will add suppor! for an additional target software platform. Windows 4.0 or otherwise knowu as
`
`Chicago.
`
`ROY-G-BIV Corporation Confidential
`1994 ROY-G-BIV (iorporalion)dl rigjhls reser~ ed
`
`4!19!94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120640
`
`

`
`Motion Control Component Specification 2.0 Project Vision
`
`Phase III.
`During this phase we plan to continue opening up the fonun to hardware vendors and application
`developers. Feedback from all participants will continue to shape the MCAPI and MCSPI which should
`be l~aidy stable by this time. Version 2.0 will be created in this phase and support will be added for
`Windows NT 4.0 known as Cairo. At this time Client/Server remote access will also be added to the
`model.
`
`ROY-G-BIV Corporation Confidential
`1994 R¢)Y-G-BIV Corlx~ration .MI ]’i~ls reser\ed
`
`lO
`
`4/19/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120641
`
`

`
`Motion Control Component Specification 3.0 Development
`
`3.0 Development
`This section describes the design goals, target sofmare platforms, software design, and interface
`specifications of lhe WOSA/XMC sofl\~are model.
`
`3.1 Design Goals
`The following are the design goals to the WOSA/XMC so~vare model:
`
`1. Hardware independent software solution for motion control.
`2. Easily integrated into high level languages such as Visnal Basic and Excel’s App Basic.
`3. Binal3 compatibiliD- on the Wiudows NT, Windows 3.1, and Chicago platforms.
`4. Full OLE 2,0 support and enabling,
`5. Easily extensible for new hardware and ncw hardware features.
`6, Optimal performance on all platforms supported
`
`Of the above goals, the top two are critical to create a path toward standardizing WOSA/XMC solution for
`motion control applications. A hardware independent solution will open up the motion control market,
`and giving high level laugamges ea~.’ access to the model will help it proliferate in the broadened market.
`
`3.2 Target Platforms
`Cnrrenflv there are four lnain target platforms, of which two exist today. Windows 3.1, Windows NT 3.1
`are target platfol’ms currently’ ont in the market. Chicago, a fim~re release of wiqdows will be a critical
`target platform for it will change the so~vare model provided by snpporting a deep integration of OLE
`2.0. Finally, Cairo. a fi~ture version of Windoxvs NT 3.1 will be targeted. Cairo, will bring NT up to date
`with the ch-anges ilnplemented in Chicago. See fi~re 4 for a description of the planned target order for
`each software entity in the WOSA/XMC model.
`
`Motion Control
`Driver Administrator
`W ndows Nr’D~vtvna
`
`(\VIN3~Z OLE2.0)
`
`Molioo Component
`I]~ICAPI)
`Windov, s NTiDaytona
`(WIN32~OLE2.0)
`
`Motion Control Driver
`Stub
`Windu~vs NT.Daylona
`~WIN32,OLE2.0)
`
`Molion Control Driver
`
`(MCSPI)
`Windo,,~ s NT!Day’~oua
`Wh~dov, s 3.1
`(W1N32iOLE2.0)
`(~ IN 32s, t~OLE2.0)
`
`Window~ 3.1
`(W~32siOLE2.0)
`
`Windows 3 1
`(W]N32s, Or E2.0)
`
`Windows 3.1
`(WIN32sA.)I.E2.0)
`
`Chicago
`(WIN32iOLEZ0)
`
`Chicago
`
`Chicago
`
`(WIN32ii)LE2,i3)
`
`(WIN3~iOLE2.0)
`
`Cairo
`
`(WIN32iOLE2.0)
`
`Cairo
`(W1N32..OLE2.0)
`
`Cairo
`(WIN32’OL]E2.01
`
`Chicago
`~ WIN3 2/OLE2.0"~
`
`Cairo
`t WIN32/OLE2.0)
`
`Figure 4 WOSAJXMC Target Platforms
`
`NOTE: Currently the PC Bus is the assumed motion control hardware target. Since the WOSA/XMC model supports
`Windows NT, other hardware busses can be easily integrated into the overall model.
`
`ROY-G-BIV Corporation Confidential.
`1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`11
`
`4/19/1994 7:48:00 PM
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY RGB00120642
`
`

`
`Motion Control Component Specification 3.0 Development
`
`3.3 Foundation Software Technology Used
`There are two foundation software teclmologies that the WOSA/XMC software model is built on. Both
`technologies are fifirlv uexx and have been included m the latest released of both Windows 3.1 and
`Window NT 3.1. In specific, lhe technologies are OLE 2.0 and WIN32. This section describes whal each
`technolo~" is and what tile benefits are to using them.
`
`3.3.10LE 2.0
`
`OLE, which stands for Objecl Linking and Embedding. is a component based technoloD’ that uses
`standardized software interfaces to communicate ~vith software entities in an object orieuted way, Each
`software entit): or component is all object. AS ill most object oriented languages, each OLE object has data
`and methods that operate on the data. Althongh. OLE is a little different that standaM object oriented
`languages such as C++ or Smalltalk in that only Interfaces .or groups of standardized functions, are
`exposed to software that comnmnicates with the object, No data is exposed, Data is only manipulated
`within the imenmls of the object, This model decouples the software component from tl~e application
`using it, which makes the component lnore reusable in other applications,
`
`Microsoft is making a significant effort to adopt the OLE Colnponent Object Model in future versions of
`Wiudows. For example, Chicago, the next major release of Windows. will contain OLE extensively
`throughout its operating system. According to fl~e mare message prqjected at a recent Microsoft Strategy
`seminar, OLE is tile future of Windows.
`
`Several benefits to building the WOSA/XMC model on top of OLE 2.0 technology are lisled below:
`
`*
`
`Future versions of the Windows and Windows NT operating systems are lnoving towards
`completely supporting OLE 2.0 technology’. Eventually Windows operating systems. ~vill be
`completel3 implemented \vith OLE technolog). For example. Chicago has complete OLE
`2.0 support and Cairo a future of Windows NT will be completely implemented using OLE
`technology,
`¯ By snpporting OLE 2.0 it will be milc