Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20020156872 A1
Publication typeApplication
Application numberUS 10/039,147
Publication dateOct 24, 2002
Filing dateJan 4, 2002
Priority dateJan 4, 2001
Also published asWO2002054184A2, WO2002054184A3
Publication number039147, 10039147, US 2002/0156872 A1, US 2002/156872 A1, US 20020156872 A1, US 20020156872A1, US 2002156872 A1, US 2002156872A1, US-A1-20020156872, US-A1-2002156872, US2002/0156872A1, US2002/156872A1, US20020156872 A1, US20020156872A1, US2002156872 A1, US2002156872A1
InventorsDavid Brown
Original AssigneeBrown David W.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Systems and methods for transmitting motion control data
US 20020156872 A1
Abstract
A system for transferring a service request between a client application and a motion control system using a communications network. The system comprises a client build module and a service request format module. The client build module builds a service request envelope for containing the service request. The service request is associated with a service performed by the motion control system. In addition, the service request envelope may be transmitted across the communications network. The service request format module extracts the service request from the service request envelope and transmits the service request to the motion control system.
Images(21)
Previous page
Next page
Claims(1)
What is claimed is:
1. A system for transferring a service request between a client application and a motion control system using a communications network, comprising:
a client build module for building a service request envelope for containing the service request, where
the service request is associated with a service performed by the motion control system, and
the service request envelope may be transmitted across the communications network;
a service request format module for extracting the service request from the service request envelope and transmitting the service request to the motion control system.
Description
    RELATED APPLICATIONS
  • [0001]
    This application claims priority of U.S. Provisional Patent Application Serial No. 60/260,261, which was filed on Jan. 4, 2001.
  • TECHNICAL FIELD
  • [0002]
    The present invention relates to systems and methods for transmitting motion control data and, more particularly, to systems and methods for facilitating the transmission of motion control data from a data source to a known or unknown client motion control device through a communications network.
  • BACKGROUND OF THE INVENTION
  • [0003]
    Motion control systems are often used in industrial settings to perform repetitive, well-defined tasks such as welding, parts assembly, and the like. Motion control systems have also been used in non-industrial settings in the form of toys, appliances, and the like for residential use.
  • [0004]
    The specific motion task to be performed by a given motion control system is defined by motion control data. Motion control data is a set of instructions conventionally written in a hardware dependent software language, but systems and methods now exist for creating hardware independent motion control data. In the following discussion, the term “application program” will be used to refer to a particular set of motion control data. The terms “application programmer” or “programmer” will be used to refer to the person who writes the application program.
  • [0005]
    Motion control systems typically employ a motion control device that converts the motion control data into physical movement. Often, the motion control device is connected to a general purpose computer that stores application programs and transfers these programs to the motion control device. In the following discussion, the person responsible for a given motion control device will be referred to as the system operator.
  • [0006]
    In both industrial and non-industrial settings, application programs are often written by the application programmer at a source location and then run on a motion control system at a remote location. In some situations, the application program is transferred from the source to the destination over a communications network such as the Internet.
  • [0007]
    From the perspective of the application programmer, the details of the motion control system can be either known or unknown. In addition, the application programmer may or may not know the details of the communications network over which the motion control data is transferred.
  • [0008]
    One scenario of particular relevance to the present invention is the situation in which an application programmer writes an application program for a given motion task where the programmer does not know or does not want to be limited to the details of a particular motion control system. In particular, the details of the software platform and motion control device(s) may be unknown to the programmer, or the system operator may wish to have the flexibility to change one or both of the software platform and motion control device in the future.
  • [0009]
    The need thus exists for systems and methods that facilitate the transmission of motion control data from a source to a motion control system over a communications network. The present invention is of particular significance when the details of the motion control system are unknown to the application programmer.
  • SUMMARY OF THE INVENTION
  • [0010]
    The present invention may be embodied as a system for transferring a service request between a client application and a motion control system using a communications network. The system comprises a client build module and a service request format module. The client build module builds a service request envelope for containing the service request. The service request is associated with a service performed by the motion control system. In addition, the service request envelope may be transmitted across the communications network. The service request format module extracts the service request from the service request envelope and transmits the service request to the motion control system.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0011]
    FIGS. 1A-C are block diagrams illustrating the basic environment in which the motion control server system of the present invention to be used;
  • [0012]
    [0012]FIG. 1 is a module interaction map depicting the interaction of the primary modules of one exemplary server system of the present invention;
  • [0013]
    [0013]FIG. 2 is a scenario map illustrating the service discovery process implemented by the server system of FIG. 1;
  • [0014]
    [0014]FIG. 3 is a scenario map illustrating the machine configuration process implemented by the server system of FIG. 1;
  • [0015]
    [0015]FIG. 4 is a scenario map illustrating the machine monitoring process implemented by the server system of FIG. 1;
  • [0016]
    [0016]FIG. 5 is a scenario map illustrating the machine control process implemented by the server system of FIG. 1;
  • [0017]
    [0017]FIG. 6 is a module interaction map depicting the interaction of the primary modules of a data format module portion of the server system of FIG. 1;
  • [0018]
    [0018]FIG. 7 is an interface map illustrating the interface of the data format module of FIG. 6;
  • [0019]
    [0019]FIG. 8 is an object interaction map illustrating the interaction of the modules of the data format module of FIG. 6;
  • [0020]
    [0020]FIG. 9 is a scenario map illustrating the schema activation process implemented by the data format module of FIG. 6;
  • [0021]
    [0021]FIG. 10 is a scenario map illustrating the schema data query process implemented by the data format module of FIG. 6;
  • [0022]
    [0022]FIG. 11 is a scenario map illustrating the schema data set process implemented by the data format module of FIG. 6;
  • [0023]
    [0023]FIG. 12 is a scenario map illustrating the schema adding process implemented by the data format module of FIG. 6;
  • [0024]
    [0024]FIG. 13 is a scenario map depicting the basic transfer of a service request from a client application and the server system of FIG. 1;
  • [0025]
    [0025]FIG. 14 is a scenario map depicting the use of packet processing to transfer a service request response from the server system of FIG. 1 to a client application;
  • [0026]
    [0026]FIG. 15 is a scenario map depicting one exemplary initial connection process implemented by the server system of FIG. 1;
  • [0027]
    [0027]FIG. 16 is a scenario map depicting one exemplary method call process implemented by the server system of FIG. 1;
  • [0028]
    [0028]FIG. 17 is a scenario map depicting another initial connection process implemented by the server system of FIG. 1;
  • [0029]
    [0029]FIG. 18 is a scenario map depicting another exemplary method call process implemented by the server system of FIG. 1;
  • [0030]
    [0030]FIG. 19 is a module interaction map depicting the interaction of the primary modules of a service request format module of the server system of FIG. 1;
  • [0031]
    [0031]FIG. 20 is a module interaction map depicting the interaction of the primary modules of the service request format module of the server system of FIG. 1;
  • [0032]
    [0032]FIG. 21 is a scenario map depicting the initialization process implemented by the service request format module of FIG. 20;
  • [0033]
    [0033]FIG. 22 is a scenario map depicting the service request transfer process implemented by the service request format module of FIG. 20; and
  • [0034]
    [0034]FIG. 23 is a scenario map depicting the clean-up process implemented by the service request format module of FIG. 20.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • [0035]
    The present invention may be embodied as a motion control server system comprising a number of modules. In the following discussion, the overall environment in which the present invention is typically used will first be described. Following that will be a detailed discussion of the interaction of the various modules that form one exemplary embodiment of the present invention. The exemplary embodiment operates in a number of scenarios, and a number of these scenarios will then be described. Finally, certain components of the exemplary motion control server system, and typical use scenarios for these components, will be described in further detail.
  • [0036]
    I. Overview of Motion Control Server System
  • [0037]
    Referring initially to FIGS. 1A of the drawing, depicted at 20 a therein is a motion control server system constructed in accordance with, and embodying, the principles of the present invention. The exemplary motion control server system 20 a is configured to transmit motion control data between a data source 22 and a motion control system 24 through a communications system 26. The motion control data is represented by an application program 28 comprising methods, function calls, and/or data.
  • [0038]
    The exemplary motion control server system 20 a comprises a service request format module 30 and a data format module 32. The service request format module 30 converts service requests (methods and/or function calls) of the application program 28 between a network service request format and a native service request format defined by the motion control system 24. The data format module 32 converts data sets transferred between the source 22 and the motion control system 24 between a network data format and a native data format defined by the motion control system 24.
  • [0039]
    [0039]FIGS. 1B and 1C indicate that some benefits of the present invention may be obtained by using either one of the service request format module 30 and the data format module 32. Depicted in FIG. 1B is an alternative exemplary motion control server system 20 b that employs only the data format module 32, while FIG. 1C depicts yet another exemplary motion control server system employing only the service request format module 30.
  • [0040]
    II. Exemplary Motion Control Server System
  • [0041]
    Referring now to FIG. 1, depicted at 20 therein is one preferred embodiment of a motion control server system of the present invention. The motion control server system 20 will be described herein in the context of one exemplary data source 22, motion control system 24, and communications system 26. However, the present invention may be embodied in forms appropriate for other data sources, motion control systems, and communications systems. In addition, the preferred motion control server system 20 comprises a number of optional modules that are not necessary to carry out the principles of the present invention in a basic form.
  • [0042]
    Two sets of terminology will be used with reference to the motion control server system 20. The first set is generic and is applicable to any environment in which a motion control server system of the present invention may be used. The second is specific to the exemplary motion control server system 20 and the data source 22, motion control system 24, and communications system 26 in connection with which the server system 20 is used. In the following discussion, the major elements will be initially identified using the generic terminology, with the specific terminology being identified in parenthesis. After this initial introduction, both sets of terminology will be used interchangeably.
  • [0043]
    The exemplary motion control server system (XMC Internet Connect system) 20 comprises both the service request format module (XMC SOAP Engine) 30 and data format module (XMC XML Engine) 32. In addition, the exemplary server system 20 comprises two optional modules: a data caching module (XMC SQL Store) 40 and method discovery module (XMC DynaDiscovery) 42. These components allow virtually any client application 28 to utilize the underlying motion control system 24 regardless of the client application's location, underlying hardware platform, or underlying software operating system.
  • [0044]
    These modules 30, 32, 40, and 42 are optimized to connect the data source (client machine or device) 22 to a motion services module (XMC Motion Services) 50 forming a part of the motion control system 24 over the communications system (Internet) 26. The XMC Motion Services module 50 is a hardware independent connection to the underlying motion control hardware system (not shown). The exemplary XMC Motion Services module 50 is described in detail in one or more of the following U.S. Pat. Nos. 5,691,897, 5,867,385, and 6,209,037 B1 and will not be described herein in further detail.
  • [0045]
    The exemplary XMC SOAP Engine module 30 is based on an industry standard technology referred to as SOAP (Simple Object Access Protocol). SOAP is an internet enabled communication protocol used to communicate in a platform and operating system independent manner with systems across the Internet. SOAP thus allows software applications to talk to one another in a manner that is independent of the communication connection or platform on which each application may be running. SOAP frees each application to run on the platform best suited for the application yet communicate with other systems as needed in a manner that connects all applications seamlessly. SOAP itself is based on two other industry standard technologies: HTML and XML. HTML defines an industry standard communication protocol for transferring data and instructions between applications connected to a network, while XML defines the structure of the data packets sent between such applications. SOAP, HTML, and XML are well-known and will not be described herein in further detail.
  • [0046]
    The XMC XML Engine module 32 is used to translate network (XML) data sets into native (motion control) operations that are defined by and run on the XMC Motion Service 50 (also referred to as the native system). In addition, the XMC XML Engine 32 is used to query data from the native system 50 and build XML data sets that are returned to the calling client application 28.
  • [0047]
    The XMC SQL Store module 40 is used to cache data queried from the XMC XML Engine 32 (or directly from the native XMC Motion Services module 50). The exemplary XMC SQL Store module 40 caches data in database module 44 (SQL database or other database such as Microsoft Access or Oracle, etc.).
  • [0048]
    The XMC DynaDiscovery module 42 is used to ‘discover’ the services supported by both the XMC XML Engine 32 and native XMC Motion Service module 50. The exemplary method discovery module 42 is based on the industry standard DISCO (Discovery of Web Services) protocol.
  • [0049]
    As noted in FIG. 1 above, there are also several other modules that optional may be used with or incorporated into the XMC Internet Connection server system 20. In particular, the server system 20 uses the motion services (XMC Motion Services) module 50, motion drivers (XMC Driver) 52, a process control (XMC OPC) module 54, a packet processing (ROPE) module 56, and a data management (Biztalk Server system 2000) module 58.
  • [0050]
    The XMC Motion Services module 50 controls the motion control device to perform operations such as querying data, setting data, and performing actions to occur (like live physical moves). As generally discussed above, the XMC Motion Services module 50 is a hardware independent technology that supports many different hardware based and software based motion controllers. The present invention may, however, be embodied without the motion services module 50 or its equivalent in a hardware dependent manner.
  • [0051]
    The motion services module 50 defines a group of supported motion control devices. One XMC Driver 52 is specifically written for each of the supported motion devices based on interfaces defined by the motion services module 50. The motion drivers 52 are known and will also not be described herein in detail.
  • [0052]
    The exemplary process control module 54 is a standard OPC (OLE for Process Control) server used to query and set data sets using the OPC protocols as defined by the OLE for Process Control Foundation.
  • [0053]
    The exemplary packet processing module 56 is a DLL module released by Microsoft and referred to as ROPE (Remote Object Proxy Engine). The ROPE module is specifically designed to build and parse SOAP data packets.
  • [0054]
    The exemplary data management module 58 is or may be the Microsoft BizTalk 2000 server. The Biztalk 2000 server is used to map data between XML Schemas, set up data agreements between companies, and manage data connections between organizations.
  • [0055]
    [0055]FIG. 1 further illustrates that the exemplary server system 20 employs a number of ‘schemas’ that are passed between modules. A ‘schema’ is a data format specification for XML data. Each schema determines how data following the protocol of the schema is organized. The exemplary server system 20 makes use of the following schemas: motion control (XMC) schemas 60, process control (OPC) schemas 62, database management (SQL) schemas 64, and third party schemas 66 such as the OMAC schema.
  • [0056]
    The XMC schemas are defined to support configuration data, system state data, motion meta program data, and actions defined by the XMC Motion Services module 50. The OPC Schema is an XML schema designed to support OPC servers. The SQL Schema is an XML schema designed to describe SQL data sets queried from a SQL database. The OMAC Schema is designed to support data sets developed by the OMAC group.
  • [0057]
    One of the functions of the Microsoft BizTalk Server system 2000 module 58 is to map between schemas. Many groups and organizations will develop various data schemas that meet their particular needs. The Microsoft BizTalk Server system 2000 module 58 is capable of mapping between the schemas developed by different groups and organizations.
  • [0058]
    III. Operational Scenarios
  • [0059]
    A. Service Discovery
  • [0060]
    Before a web service can be used, the services that service offers are determined or “discovered”. Before discovering what a single web service can do, the web server is queried to determine what the web services that it offers. In the exemplary server system 20, the optional method discovery module 42 is used to discover the services available from the motion services module 50 using one or more of a plurality of protocols such as the Dynamic Web Discovery (DISCO) protocol, SNMP, LDAP, and the like. The exemplary XMC DynaDiscovery module 42 uses the DISCO protocol because the DISCO protocol is based on XML, which allows a very thin client to use the discovery service.
  • [0061]
    [0061]FIG. 2 of the drawing illustrates the steps that occur when the exemplary server system 20 uses the method discovery module 42 to discover the services available from the motion services module 50. First, the client application (or machine or device) 28, queries the motion control server system 20 for the services provided. This request may go through the BizTalk Server 58 or directly to the SOAP enabled server module 30.
  • [0062]
    If the request goes to the BizTalk Server 58, the BizTalk Server 58 maps the request to the appropriate format supported by the SOAP enabled server 30 and passes the request on to the SOAP server 30. The BizTalk server 58 may also just pass the request straight through to the SOAP server if no mapping is needed.
  • [0063]
    Next, upon receiving the request, the XMC SOAP server 30 uses the ROPE module 56 to parse out the request. The XMC SOAP server module 30 could also use its own native parsing, but the use of the ROPE module 56 is preferred.
  • [0064]
    The XMC SOAP Server 30 next uses the XMC DynaDiscovery module 42 to determine what services are available on the local motion services module 50. Communication between the module 42 and the module 50 may be direct or may utilize an industry standard interface protocol such as a DCOM enabled connection; the interface protocol is schematically indicated by reference character 70 in FIG. 2.
  • [0065]
    Upon receiving the request, the XMC DynaDiscovery module 42 queries all modules that it ‘knows about’. Such modules typically include or define type libraries (TLB) 72 that define the offered services. The exemplary module 42 thus examines the Type Libraries 72 to ‘discover’ the services that they offer. Upon discovering the available services, the DynaDiscovery module 42 dynamically builds an SDL (Services Description Language) data set and returns it to the requesting SOAP server 30. When dynamic discovery is not used, the SDL file is a static file that resides on the SOAP enabled server.
  • [0066]
    After determining what services are available from the motion services module 50, the client application program 28 may perform any of the operations offered by the module 50. When working with motion systems, these operations usually fall into one of three categories: configuration, monitoring/diagnostic, and actions. Each of these actions will be discussed in more detail below.
  • [0067]
    B. Machine Configuration
  • [0068]
    Configuration operations are used to configure the underlying motion system. For example, servo gains, velocities and accelerations may be set when performing configuration situations.
  • [0069]
    Configuration settings are usually separated into two categories: Initialization and Live Settings. Initialization configuration properties are usually set once when the machine first initialized. Live settings are changed dynamically to affect how the machine operates. The scenario discussed applies to changing both types of configuration settings.
  • [0070]
    Referring now to FIG. 3, depicted therein is a scenario map depicting the process of making configuration settings.
  • [0071]
    First, the client application 28 sends the configuration change request (along with all data needed to make the change) to the server system 20. This request may be sent to a BizTalk Server 58 or directly to the XMC SOAP Server 30, depending on the Schema used.
  • [0072]
    If the configuration change request is sent to the BizTalk Server 58, the BizTalk server 58 maps the data received from original schema to one of the schemas supported on the SOAP enabled server system 20; the Biztalk server 58 then sends the request on to the XMC SOAP Engine server 30. Upon receiving the SOAP request, the XMC SOAP Engine 30 optionally but preferably uses the ROPE module 56 to parse the request.
  • [0073]
    Next, the XMC SOAP Engine 30 passes the request data to the XMC XML Engine 32. The XMC XML Engine 30 configures the underlying native system (in this case the XMC Motion Service 50). The XMC SOAP Engine 30 may communicate with the XMC XML Engine 32 either locally or across a DCOM connection 70.
  • [0074]
    Depending on the schema used in the request, the XMC XML Engine 32 either uses the XMC OPC Server 54 to configure the native system 50 or configures the XMC Motion Services 50 directly. The XMC XML Engine 32 may also use any other module to carry out the request as long as the XMC XML engine 32 has support for the external module's schema installed.
  • [0075]
    If the XMC OPC Server 54 is used, the XMC OPC server 54 then changes the configuration data as specified in the request made to it by the XMC XML Engine 32.
  • [0076]
    When requested, the XMC Motion Services 50 uses the current XMC Driver 52 to change the settings on the target motion hardware.
  • [0077]
    C. Machine Monitoring/Diagnostics
  • [0078]
    Monitoring/Diagnostic operations are used to query the system for information. For example when monitoring the system the current motor positions, velocities etc. may be monitored to see what the machine is doing. When performing diagnostic operations, the actual state of the machine (such as the programs that reside on the hardware) may be queried. This information may be displayed to the user running the client, used for immediate analysis, or stored for future analysis. Machine diagnostics is similar to monitoring the machine except that a higher level of data detail is usually queried. The following scenario applied to both monitoring and querying diagnostic information from the machine.
  • [0079]
    Referring now to FIG. 4, the following steps occur when monitoring (or querying diagnostic information from) the machine.
  • [0080]
    First the client application 28 queries the machine (one time, intermittently, or periodically) for the information required. The client application 28 may use one of various different schemas. The data, configured according to the schema used, is sent to XMC SOAP Engine 30 either directly or indirectly through the BizTalk Server 58.
  • [0081]
    If the BizTalk Server 58 receives the request, it either directs the request to the XMC SQL Store module 40 or directly to the XMC SOAP Engine 30, depending on the schema mapping used and whether or not data caching is used.
  • [0082]
    If data caching is enabled, the XMC SQL Store module 40 queries the SQL database 44 (or any other database used) for the data. To update the cache, the XMC SQL Store module 40 either directly queries the XMC XML Engine 32 or uses the XMC SOAP Engine 30 to query the XMC XML Engine 32 for the data to be cached.
  • [0083]
    When requested, the XMC SOAP Engine 30 uses the ROPE engine 56 to parse the request and then either directly queries data specified in the request from the XMC Motion Services module 50, or routes the request to the XMC XML Engine 32.
  • [0084]
    If used, the XMC XML Engine 32 determines the data schema used and then either routes the request to the XMC Motion Services module 50 either directly or indirectly through the XMC OPC Server 54. If the XMC OPC Server 54 is used, it directly queries the data from the XMC Motion Services. The XMC Motion Services module 50 then uses the XMC Driver 52 to query the data from the target motion hardware.
  • [0085]
    D. Action Operations (Machine Control)
  • [0086]
    Action operations cause the machine to do things such as run programs or make moves. For example, the machine may be directed to move to its home state. The scenario depicted in FIG. 5 describes the process of performing such control operations.
  • [0087]
    The following steps occur when performing a machine control operation.
  • [0088]
    First, the client application 28 requests the machine control operation to be performed and passes all parameter data needed. This request is sent to the SOAP Enabled Server 30 directly or indirectly through the BizTalk Server 58. The client application 28 may use one or more of various schemas to describe the operation to be performed.
  • [0089]
    If the BizTalk Server 58 is used, the BizTalk server 58 will, if necessary, map from the original schema used by the client application 28 to a different schema supported by the motion server system 20. Once properly mapped, the request is passed to the XMC SOAP Engine 30.
  • [0090]
    When requested, the exemplary XMC SOAP Engine uses the ROPE module 56 to parse the request and determine what service operation is to be performed. As discussed above, the use of the ROPE module 56 is not required but is preferred.
  • [0091]
    Next, the XMC SOAP Engine 30 sends the request to the XMC Motion Services module 50 for processing either directly or indirectly through the XMC XML Engine 32. As discussed above, this communication may be on a local machine or may occur across a DCOM connection 70 (or even to another SOAP Engine if appropriate). If used, the XMC XML Engine 32 connects with the XMC Motion Services module 50 to perform the requested machine control operations.
  • [0092]
    The XMC Motion Services module 50 uses the selected XMC Driver 52 to direct the target hardware to perform the desired machine control operations.
  • [0093]
    IV. Data Format Module
  • [0094]
    The data format, or XMC XML Engine, module 32 acts as a container for multiple schemas, both XMC XML and non-XMC XML Schemas. The XMC XML Engine thus forms a schema repository that is available to other components of the system 20 such as the service request format module 30 or the data management module 58.
  • [0095]
    Once enabled with several schemas, the XMC XML Engine 32 uses polymorphism to work with each schema in the same manner. Each schema itself is the definition of a data set used to either query or set motion configuration data and motion properties, or cause motion actions on the target machine.
  • [0096]
    This section describes the how the XMC XML Engine works internally was well as how it interacts with the modules around it in a software system.
  • [0097]
    A. XML Engine Module Interactions
  • [0098]
    The XMC XML Engine 32 is designed to be a ‘middle-ware’ component that translates data between a native system and XML. In the exemplary system 20, this translation is bi-directional. Translations from the XML data format to the data format of the native motion services module 50 are used to change configuration data and properties and to cause actions. Translations from the native data format of the motion services module 50 to XML data format are used when querying configuration data or properties.
  • [0099]
    [0099]FIG. 6 is a module interaction map illustrating the interaction of the XMC SOAP Engine 30 and the XMC XML Engine 32 when the SOAP Engine 30 calls methods on the XML Engine 32. The methods called allow the XMC SOAP Engine 30 to query and set data or cause other actions on the native system implemented by the XMC Motion Services module 50.
  • [0100]
    As noted above, the XMC XML Engine 32 may work with several native systems. FIG. 6 illustrates that the XMC XML Engine 32 also can work with the XMC OPC component 54 to query/set data sets using the OLE for Process Control data formats.
  • [0101]
    Even though only the XMC Soap Engine 30 is displayed as the only client, many other clients could use the XMC XML Engine 32. For example, a Microsoft BizTalk server 58 might be used to query specific data from the XMC XML Engine 32 and then map that data into a completely different schema, such as the OMAC data schema 66.
  • [0102]
    [0102]FIG. 6 illustrates that the exemplary XMC XML Engine module 32 interacts with the XMC SOAP Engine 30, the XMC Motion Services module 50, and the XMC OPC module 54. As generally discussed above, the XMC XML Engine module 32 is used to build data sets based on the active XML Schema 60. In addition, this engine 54 translates data sets received and enables requested operations, such as setting configuration or property data, to be performed by the native motion control system 24.
  • [0103]
    Referring now to FIG. 7, depicted at 80 therein is an interface map for the XMC XML Engine module 32. The exemplary XMC XML Engine module 32 implemented as a COM component that houses several objects. Each object exposes one or more OLE interfaces.
  • [0104]
    [0104]FIG. 7 illustrates that the XMC XML Engine module 32 houses two primary objects: the SchemaContainer object 82 and SchemaEnum objects 84. In addition, the XMC XML Engine 32 supports several default Schema objects 86, although an infinite number of external Schema objects can be supported. When querying and setting schema data, the SchemaContainer object 82 is used because it aggregates to the active Schema object. The SchemaEnum object 84 is used to enumerate across all Schema objects installed.
  • [0105]
    The SchemaContainer object 82 manages all Schema objects installed and is the main object used by the client applications 28. The container 82 stores all Schema objects 86, one of which is designated as the active schema. The SchemaContainer object 82 contains the IXMCSchemaContainer interface, the IXMCPersistSchemaContainer interface, and the IXMCSchema interface. The IXMCSchemaContainer interface is used to add/remove schema objects and get access to the schema enumeration. In addition, this interface allows the caller to activate one schema or another. The IXMCPersistSchemaContainer interface is used to persist all information with regard to the schema collection, including the active schema. The IXMCSchema interface is an aggregation of the active schema object's IXMCSchema interface.
  • [0106]
    The SchemaEnum object is responsible for enumerating across the set of installed schema objects and contains the IXMCEnumSchema interface. The IXMCEnumSchema interface is a standard COM enumeration interface.
  • [0107]
    The Schema objects are responsible for implementing the specific schema supported. To support a schema, the schema object is responsible for translating Native System data into the XML data set defined by the schema. In addition, XML data sets may be translated and used to change configuration and property settings in the native system. And finally, XML data sets may be translated and used to cause actions on the native system such as physical moves.
  • [0108]
    The Schema objects define the IXMCSchema interface and IPersist interface. The IXMCSchema interface allows clients to Set and Query data sets based on the XML schema supported.
  • [0109]
    The XMC XML Engine object interactions will now be described with reference to FIG. 8. In particular, FIG. 8 illustrates how the COM components making up the XMC XML Engine interact to service client requests with data supported by several different schemas.
  • [0110]
    As shown in FIG. 8, the Schema Container object 82 is the main object that manages all other objects. Client applications may interact with each object directly at times, but the Schema Container object 82 is one of the first that the client application will encounter.
  • [0111]
    The Schema Container object 82 gives the client application access to the Schema Enumerator object 84 used to enumerate across all schema objects 86 installed. Access to the Schema Enumerator object 84 is useful when working with several different schemas at the same time or when browsing the set of installed schemas. For example, if the Schema Container object 82 has schemas installed that support OPC, XMC and OMAC objects or data sets 86, the enumerator object 84 allows the calling application to enumerate across each of these objects 86.
  • [0112]
    From the Schema Container object 82, the client application may also install new Schemas 86 and set the active schema out of those installed. Specifying the one of the schema 86 as the active schema directs the Schema Container 82 to aggregate the IXMCSchema interface from the specified active schema object so that the active schema 86 may be used in future data query/set/action operations.
  • [0113]
    Specifying, selecting, or “activating” a schema is the process of directing the Schema Container to make a schema in a group of previously installed schema the active schema. The ‘active’ state means that the Schema Container 82 aggregates the specified schema's IXMCSchema interface so that all calls to the Schema Container 82 appears to be housing this object; in actuality, the Schema Container routs the interface to the actual schema object.
  • [0114]
    The process of “activating” a schema will now be described in further detail with reference to FIG. 9. Initially, the calling client application 28 using the XMC XML Engine 32 calls the Schema Container object 82 and directs the object 82 to specify one of the support schema as the active schema. A special ID, GUID, text name, or some other unique identifier may identify each schema. This identifier is used to tell the Schema Container which schema to activate.
  • [0115]
    Once notified, the Schema Container 82 uses its internal Schema Enumerator 84 to query for the specified schema. If the specified schema is not found an error is returned.
  • [0116]
    Upon finding the target schema, the Schema Container 82 aggregates the IXMCSchema interface of the activated Schema object 86, making it appear to the client application 28 that the Schema Container 82 actually implements the activated Schema object 86.
  • [0117]
    Once a schema 86 is activated, the client application 28 may choose to query data from the active schema. Such a query may be used to query all configuration settings on a machine or query the overall state of the machine. FIG. 10 illustrates the steps that take place when querying, data.
  • [0118]
    First, the client application 28 queries the Schema Container 82 for the data from the active Schema object. Upon receiving the request, the request actually routes directly to the active Schema object 86 through the aggregated IXMCSchema interface.
  • [0119]
    Based on the schema supported, the Schema object 86 queries the native system (in this case the XMC Motion Server 50) for all data needed to fill out the data request. The data required to fill out the data request is then packaged into an XML data packet as specified by the supported Schema. The XML data packet is then passed back to the calling client application 28.
  • [0120]
    In addition to querying data, the native system configuration and properties may also be set or actions may be performed. Setting data on the native system is very similar to the reverse of the querying process.
  • [0121]
    In particular, FIG. 11 illustrates the steps that occur when setting data on the native system.
  • [0122]
    First, the client application sends a ‘set’ request to the Schema Container 82, making sure to pass the XML data packet specifying the data to be set. Upon receiving the request, the call is routed directly to the active Schema object 86 through the aggregated connection to the active Schema's IXMCSchema interface. The Schema object then parses the XML data packet based on the Schema that it supports.
  • [0123]
    As data is parsed from the XML data packet (or upon completing the parsing), the Schema object 86 directs the native system (in this case the XMC Motion Server 50) to set all data items specified. If an action is requested, the Schema object 86 would parse the data packet pulling from it the data parameters to pass along to the native system 50 when directing it to perform the action requested. The action requested would be specified as part of the data packet. For example, an action identifier may be used to specify an operation to perform from a set of supported operations.
  • [0124]
    Upon completing the request, the system 20 returns the status (success or failure) of the operation to the client application 28.
  • [0125]
    To use schemas other than the set of default schemas supported by the XMC XML Engine 32, the client application must add new ones.
  • [0126]
    [0126]FIG. 12 illustrates the steps that occur when adding new schema support to the Schema Container. Initially, the client application must request the Schema Container 82 to add a new schema 86, making sure to specify the CLSID (or other identifier) of the schema and URL (or other location identifier) identifying the location of the new Schema object 86.
  • [0127]
    Upon receiving the request, the Schema Container 82 creates an instance of the new Schema object 86 and adds it to its list of supported schemas. When persisting its information, the Schema Container 82 saves the schema identifier and location so that it can later load the schema object.
  • [0128]
    B. Schema Examples
  • [0129]
    This section shows several example schemas, each of which would be supported by one or more Schema objects 86.
  • [0130]
    1. XMC Configuration Schema
  • [0131]
    The XMC configuration schema describes all data used to configure an XMC software system.
  • [0132]
    <?xml version=‘1.0’ encoding=‘UTF-8’?>
  • [0133]
    <!ELEMENT XMCConfiguration (Systems)>
  • [0134]
    <!ATTLIST XMCConfiguration Version CDATA #IMPLIED>
  • [0135]
    <!ELEMENT Systems (System+)>
  • [0136]
    <!ATTLIST Systems Count CDATA #IMPLIED>
  • [0137]
    <!ELEMENT System (DefUnits, DefMode, SecurityOptions, Drivers)>
  • [0138]
    <!ATTLIST System Number CDATA #IMPLIED>
  • [0139]
    <!ELEMENT DefUnits (#PCDATA)>
  • [0140]
    <!ELEMENT DefMode (#PCDATA)>
  • [0141]
    <!ELEMENT SecurityOptions (Security.control, Security.monitoronly)>
  • [0142]
    <!ELEMENT Security.control (#PCDATA)>
  • [0143]
    <!ELEMENT Security.monitoronly (#PCDATA)>
  • [0144]
    <!ELEMENT Drivers (Driver+)>
  • [0145]
    <!ATTLIST Drivers Count CDATA #IMPLIED>
  • [0146]
    <!ELEMENT Driver (Enabled, Filters, Properties, Streams)>
  • [0147]
    <!ELEMENT Filters (Filter*)>
  • [0148]
    <!ATTLIST Filters Count CDATA #IMPLIED>
  • [0149]
    <!ELEMENT Filter (Streams)>
  • [0150]
    <!ELEMENT Properties (Property*)>
  • [0151]
    <!ATTLIST Properties Count CDATA #IMPLIED>
  • [0152]
    <!ELEMENT Property (Name, Value)>
  • [0153]
    <!ELEMENT Streams (Stream*)>
  • [0154]
    <!ATTLIST Streams Count CDATA #IMPLIED>
  • [0155]
    <!ELEMENT Stream (Enabled, (Stream.PCBus|Stream.TextFile|Stream.DbgMon))>
  • [0156]
    <!ELEMENT Stream.PCBus (Port, PortSize)>
  • [0157]
    <!ELEMENT Stream.TextFile (FileName)>
  • [0158]
    <!ELEMENT Stream.DbgMon EMPTY>
  • [0159]
    <!ELEMENT FileName (#PCDATA)>
  • [0160]
    <!ELEMENT Name (#PCDATA)>
  • [0161]
    <!ELEMENT Value (#PCDATA)>
  • [0162]
    <!ELEMENT Enabled (#PCDATA)>
  • [0163]
    <!ELEMENT Port (#PCDATA)>
  • [0164]
    <!ELEMENT PortSize (#PCDATA)>
  • [0165]
    2. XMC Meta Programs Schema
  • [0166]
    The XMC Meta Program schema describes data making up a meta program which is a hardware independent motion control program.
  • [0167]
    <?xml version=‘1.0’ encoding=‘UTF-8’?>
  • [0168]
    <!ELEMENT XMCMetaProject (Programs)>
  • [0169]
    <!ATTLIST XMCMetaProject Version CDATA #IMPLIED>
  • [0170]
    <!ELEMENT Programs (Program*)>
  • [0171]
    <!ATTLIST Programs Count CDATA #IMPLIED>
  • [0172]
    <!ELEMENT Program (Name, Commands)>
  • [0173]
    <!ATTLIST Program SystemNum CDATA #IMPLIED>
  • [0174]
    <!ELEMENT Commands (Command*)>
  • [0175]
    <!ATTLIST Commands Count CDATA #IMPLIED>
  • [0176]
    <!ELEMENT Command (Name, Parameters)>
  • [0177]
    <!ELEMENT Parameters (Parameter*)>
  • [0178]
    <!ATTLIST Parameters Count CDATA #IMPLIED>
  • [0179]
    <!ELEMENT Parameter (#PCDATA)>
  • [0180]
    <!ATTLIST Parameter Type CDATA #IMPLIED>
  • [0181]
    <!ELEMENT Name (#PCDATA)>
  • [0182]
    3. XMC System State Schema
  • [0183]
    The XMC System State schema is used to query/set all aspects of the motion control system.
  • [0184]
    <?xml version=‘1.0’ encoding-‘UTF-8’?>
  • [0185]
    <!ELEMENT XMCState (Configuration, Axes, Programs, RawData, ErrorStatus)>
  • [0186]
    <!ATTLIST XMCState Version CDATA #IMPLIED>
  • [0187]
    <!ELEMENT Configuration (Config.ActiveCFGFile, Config.ActiveMPFFile)>
  • [0188]
    <!ELEMENT Config.ActiveCFGFile (#PCDATA)>
  • [0189]
    <!ELEMENT Config.ActiveMPFFile (#PCDATA)>
  • [0190]
    <!ELEMENT Axes (Axis+)>
  • [0191]
    <!ATTLISTAxes CountCDATA #IMPLIED>
  • [0192]
    <!ELEMENT Axis (CommandedData, ActualData, HomingData, Limits, State)>
  • [0193]
    <!ATTLIST Axis Index CDATA #IMPLIED>
  • [0194]
    <!ELEMENT CommandedData (Commanded.MotionProfile,
  • [0195]
    Commanded.Position)>
  • [0196]
    <!ELEMENT ActualData (Actual.MotionProfile,
  • [0197]
    Actual.MotorPosition,
  • [0198]
    Actual.EncoderPosition)>
  • [0199]
    <!ELEMENT Commanded.MotionProfile (MotionProfile)>
  • [0200]
    <!ELEMENT Homing.MotionProfile (MotionProfile)>
  • [0201]
    <!ELEMENT Actual.MotionProfile (MotionProfile)>
  • [0202]
    <!ELEMENT HomingData (Homing.MotionProfile,
  • [0203]
    Homing.FinalVelocity)>
  • [0204]
    <!ELEMENT Homing.FinalVelocity (#PCDATA)>
  • [0205]
    <!ELEMENT MotionProfile (Velocity, Acceleration, Deceleration)>
  • [0206]
    <!ELEMENT Velocity (#PCDATA)>
  • [0207]
    <!ELEMENT Acceleration (#PCDATA)>
  • [0208]
    <!ELEMENT Deceleration (#PCDATA)>
  • [0209]
    <!ELEMENT Commanded.Position (#PCDATA)>
  • [0210]
    <!ELEMENT Actual.Position (#PCDATA)>
  • [0211]
    <!ELEMENT Actual.MotorPosition (#PCDATA)>
  • [0212]
    <!ELEMENT Actual.EncoderPosition (#PCDATA)>
  • [0213]
    <!ELEMENT RawData (RawData.Programs , RawData.Configuration)>
  • [0214]
    <!ELEMENT RawData.Programs (#PCDATA)>
  • [0215]
    <!ATTLIST RawData.Programs DataSize CDATA #IMPLIED>
  • [0216]
    <!ELEMENT RawData.Configuration (#PCDATA)>
  • [0217]
    <!ATTLIST RawData.Configuration DataSize CDATA #IMPLIED>
  • [0218]
    <!ELEMENT Limits (Limits.IsHit_HWCCW,
  • [0219]
    Limits.IsHit_HWCW,
  • [0220]
    Limits.IsHit_SWCCW,
  • [0221]
    Limits.IsHit_Home,
  • [0222]
    Limits.IsHit_SWCW,
  • [0223]
    Limits.SWCCWPos,
  • [0224]
    Limits.SWCWPos)>
  • [0225]
    <!ELEMENT State (IsMoving, IsHoming, IsFaulted)>
  • [0226]
    <!ELEMENT IsMoving (#PCDATA)>
  • [0227]
    <!ELEMENT IsHoming (#PCDATA)>
  • [0228]
    <!ELEMENT IsFaulted (#PCDATA)>
  • [0229]
    <!ELEMENT ErrorStatus (Error.Internal, Error.Source)>
  • [0230]
    <!ELEMENT Error.Internal (Error)>
  • [0231]
    <!ELEMENT Error.Source (Error)>
  • [0232]
    <!ELEMENT Error (#PCDATA)>
  • [0233]
    <!ATTLIST Error ErrorCode CDATA #IMPLIED>
  • [0234]
    <!ELEMENT Programs (Program+)>
  • [0235]
    <!ATTLIST Programs Count CDATA #IMPLIED
  • [0236]
    ActiveProgram CDATA #IMPLIED>
  • [0237]
    <!ELEMENT ActiveProgram (#PCDATA)>
  • [0238]
    <!ELEMENT Program (Name)>
  • [0239]
    <!ATTLIST Program IsRunning CDATA #IMPLIED
  • [0240]
    Index CDATA #IMPLIED>
  • [0241]
    <!ELEMENT Name (#PCDATA)>
  • [0242]
    4. XMC OPC Schemas
  • [0243]
    In addition to the XMC specific schemas previously described, non XMC schemas may also be supported. This section shows OLE for Process Control schemas designed for motion. The XMC OPC schema is actually an OPC schema designed for XMC data that is formatted specifically for an OPC server.
  • [0244]
    <?xml version=‘1.0’ encoding=‘UTF-8’?>
  • [0245]
    <!ELEMENT Server (Groups)>
  • [0246]
    <!ATTLIST Server Version CDATA #IMPLIED>
  • [0247]
    <!ELEMENT Groups (Group+)>
  • [0248]
    <!ATTLIST Groups Count CDATA #IMPLIED>
  • [0249]
    <!ELEMENT Group (Type, UpdateRate, Items)>
  • [0250]
    <!ELEMENT Type (#PCDATA)>
  • [0251]
    <!ELEMENT UpdateRate (#PCDATA)>
  • [0252]
    <!ELEMENT Items (Count, Item+)>
  • [0253]
    <!ATTLIST Items Count CDATA #IMPLIED>
  • [0254]
    <!ELEMENT Item (ID , Description , DataType , Data)>
  • [0255]
    <!ELEMENT ID (#PCDATA)>
  • [0256]
    <!ELEMENT Description (#PCDATA)>
  • [0257]
    <!ELEMENT DataType (#PCDATA)>
  • [0258]
    <!ELEMENT Data (#PCDATA)>
  • [0259]
    <!ELEMENT Count (#PCDATA)>
  • [0260]
    V. Service Request Format Module
  • [0261]
    This section contains further description of the SOAP (Simple Object Access Protocol), how SOAP is implemented in the context of the data server system 20, and how to setup the service request format module 30 in the context of the XMC SOAP Engine.
  • [0262]
    To request an operation in another application, the client application sends an HTML ‘POST’ instruction containing an XML ‘SOAP Envelope’. The XML Soap Envelope defines the operation to be performed.
  • [0263]
    Referring initially to FIG. 13, depicted therein is the basic HTML Soap request as implemented using the data server system 20 of the present invention. To operate over a communications network 24 such as the Internet, the data server system 20 must be capable of receiving Internet/Web requests. FIG. 1 illustrates this capability by an Internet information application programming interface (IIAPI) 74. FIG. 13 illustrates that the interface 74 is defined by an information server module 76; in the exemplary system 20, the information server module 76 is formed by a Microsoft Internet Information Server (IIS) based server installed with the XMC SOAP Engine 30.
  • [0264]
    Upon receiving a request, the information server module 76 passes the request to the XMC Soap Engine 30, which in turn performs the requested motion operation. Once complete, the Server responds with a HTML header and XML ‘SOAP Envelope’ that describes the results of the operation.
  • [0265]
    In addition to using basic HTML, a data packet processing technology is available from Microsoft Corporation called ‘Remote Object Proxy Engine’ or ROPE. ROPE performs all basic tasks of generating the HTML/XML SOAP data packets sent to the server system 20 when requesting operations. In addition ROPE parses the responses retrieved from the server system 20. While optional, the use of the ROPE technology is preferred.
  • [0266]
    [0266]FIG. 14 illustrates the process of using ROPE technology for parsing of packets sent to and retrieved from the server system 20. ROPE builds and sends the same HTML ‘POST’ instruction with the same SOAP Envelope containing the XML data describing the requested operations and any parameters used.
  • [0267]
    When making a SOAP request, a particular sequence of steps must be performed to carry out the request. This sequence of steps forms what will be referred to herein as the “SOAP Pipeline”. The SOAP Pipeline will be described below from two different perspectives. In the first, the pipeline is described making a SOAP request just using basic HTML on the client side. The second scenario describes making a SOAP request using the Microsoft ROPE technology.
  • [0268]
    A. SOAP Request Using Basic HTML
  • [0269]
    SOAP requests are available to any client application that supports HTML and XML. This section describes the specific steps taking place when making a basic HTML based SOAP request.
  • [0270]
    Initial connection is not required, but is helpful in that establishing an initial connection informs the client machine about the services available on the SOAP Server. If the client is informed in advance about the services that are available, the initial connection step is not necessary.
  • [0271]
    Referring now to FIG. 15, the HTML Connect process will be described in further detail.
  • [0272]
    When making the initial connection, following steps take place.
  • [0273]
    First, the client must build a standard HTML ‘GET’ header used to query the ‘services.xml’ file that contains the ‘Services Description’. This is often referred to as the SDL or Services Description Language and is an XML based document that describes the operations available on the SOAP enabled server. The file containing the Service Description Language document may be given any name but must be an XML file.
  • [0274]
    Next, the client must send the HTML request to the server to query the server for the XML services file. Upon receiving the request, the server returns the services description (the contents of the services.xml file) to the client. The client may then parse the services description to ‘learn’ what services are supported by the SOAP server (including the method and parameter names and types).
  • [0275]
    Once the client 22 has identified the services available on the SOAP server 30, the client 22 is ready to make method calls directing the server to perform the supported operations.
  • [0276]
    [0276]FIG. 16 illustrates the process of making an HTML Method Call. The client must first build a standard HTML ‘POST’ header specifying the host and ‘SoapAction’, where the SoapAction includes both the location of the ‘*.SOD’ file and the service requested. The SOD file describes the actual COM component that will be used to carry out the operation, whereas the service requested is the method exposed by that component.
  • [0277]
    Next, the client application 28 must build the SOAP envelope that describes the service requested. Using XML, the envelope is built to describe the method and all parameter data used to perform the service request.
  • [0278]
    The client then sends the request to the SOAP enabled server system 20, making sure to send the request to the location where the XMC SOAP Engine 30 is installed. Upon receiving the request, information server module 76 routes the SOD based request to the XMC SOAP Engine 30 for processing.
  • [0279]
    On the Server side, the XMC SOAP Engine 30 uses the ROPE module 56 to load and parse the SOD file to get the component object to use for the request. In addition, the ROPE module 56 is used to parse the actual XML contained within the request that describes the SOAP operation to be performed (i.e. method name and parameters).
  • [0280]
    The XMC SOAP Engine 30 then actually makes the call to the component method passing all parameters sent via the previous SOAP call.
  • [0281]
    Next, the XMC SOAP Engine 30 again uses the ROPE module 56 to build the response packet, making sure to build into the packet the results of the component method call. If any data is to be returned (as in the case of querying the component, such as with the XMC XML Engine 32), the data is packed into the response SOAP envelope using the ROPE module 56.
  • [0282]
    The ROPE module then sends the response SOAP envelope back to the client application 28. Upon receiving the response, the client application 28 may parse the HTML and XML to get the response results and queried data, if any.
  • [0283]
    The previous sections have described communicating to a SOAP enabled motion control server system 20 using native HTML. One skilled in the art will recognize that, in both the general GET and POST operations, the client was required to build the header and SOAP request Envelope as well as parse the SOAP response envelope. The next section describes how using the ROPE module 56 simplifies significantly these steps because the ROPE module 56 handles all parsing and envelope building programmer.
  • [0284]
    The Remote Object Proxy Engine (ROPE) was designed specifically to build and parse SOAP envelopes. In addition, ROPE takes care of sending each packet to the server as well as receiving responses from the server. This section describes the same SOAP pipeline but from the perspective of using ROPE instead of native HTML.
  • [0285]
    When using ROPE, the initial connection between the client application 28 and the server system 20 is required, for this connection identified for the ROPE module 56 what services are available on the SOAP enabled server system 20.
  • [0286]
    [0286]FIG. 17 illustrates the steps that occur when making the initial connection using ROPE.
  • [0287]
    First, using the SOAPPackager object, the client application 22 loads the service description by passing the services description file (‘services.xml’) URI to the LoadServiceDescription method. Internally, the SOAPPackager object builds the “get” request and sends this request to the SOAP enabled server system 20. This is the same get request described in the native HTML initial connection.
  • [0288]
    Upon receiving the request, the information server module 76 responds by sending back the contents of the services.XML file.
  • [0289]
    The SOAPPackager object is then used on the client side to parse out the listener information, which is the URI of the services.SOD file on the server module 76. At this point, the SOAPPackager object has all the information necessary to determine what services are available on the server, along with the specific format of each service.
  • [0290]
    Once the initial connection is made, the client application 22 is able to use the ROPE 56 to invoke services (make method or service request calls) on the SOAP enabled server system 20.
  • [0291]
    As shown in FIG. 18, the following steps occur when invoking services using the ROPE module 56.
  • [0292]
    Using the SOAPPackager object, the local copy of the service description is loaded (this is the same one previously loaded but cached by ROPE). The SOAPPackager object is then used to build the payload for the service that is to be called by specifying the ‘method name’ of the service. In addition, the SOAPPackager object is used to add the parameter data for the method call, if any such parameter data is required.
  • [0293]
    Using the Wire Transfer object, the standard SOAP headers are added to build the actual HTML header and SOAP envelope that will eventually be sent. This is the same HTML ‘POST’ header and SOAP envelope described above with calling methods using native HTML.
  • [0294]
    The Wire Transfer object is then used to send the header and SOAP envelope containing the service request to the server system 20, thereby requesting the that the server system 20 instruct the motion control system 24 to perform the contained service request.
  • [0295]
    Upon receiving the request, information server module 76 detects the SOD based request and routes the request to the XMC SOAP Engine 30. The XMC SOAP Engine 30 uses the local ROPE module 56 to parse the COM component name from the SOD file as well as parse out the service request information from the XML SOAP envelope contained in the original request.
  • [0296]
    Next, the XMC SOAP Engine 30 calls the method on the XMC Motion Server 50 as requested by the service request contained in the original SOAP envelope.
  • [0297]
    All results from the service request (method) invocation and all return data are packed into a response SOAP envelope built by the ROPE module 56. The response SOAP envelope is the returned to the client application 22 by the ROPE module at the XMC SOAP Engine 30. The client application 22 then uses the SOAPPackager object to parse the response SOAP envelope and make available to the client application 22 all return parameters contained in the response SOAP envelope.
  • [0298]
    A close comparison of the steps discussed with reference to FIGS. 16 and 17 indicates that the use of the ROPE module 56 eliminates many of the native HTML based SOAP steps by generating and parsing the SOAP envelope for the programmer.
  • [0299]
    With the foregoing understanding of how the client application 28 interacts with the SOAP enabled server system 20, the construction and operation of the server system 20 will now be described in detail.
  • [0300]
    The XMC SOAP Engine 30 builds on SOAP technology to obtain the data server system 20 that is enabled for motion-based application. In particular, the exemplary XMC SOAP Engine 30 extends information server module 76 to support SOAP requests and routes each request appropriately to the method on the component implementing the service requested. The following sections describe how the XMC SOAP Engine 30 performs these tasks to support SOAP requests.
  • [0301]
    The XMC SOAP Engine 30 handles SOAP requests received through the Internet 26. Such requests may originate from any client application 22 or may actually be routed to the XMC SOAP Engine 30 from a BizTalk server 58.
  • [0302]
    In particular, the XMC SOAP Engine 30 interacts with several modules in the system 20 as will be described below with reference to FIG. 19.
  • [0303]
    Similar to any other SOAP client, the Microsoft BizTalk server 58 may send SOAP requests to the XMC SOAP Engine 30 as well to request data that as necessary to fill out data within supported schemas. For example, a BizTalk server 58 may be used to map an OMAC schema 62 to an XMC schema 60. When filling out the data in the OMAC schema 62, the BizTalk server 58 may query data from the XMC SOAP Engine 30 to fill out the end data mapping.
  • [0304]
    In addition, other clients may talk to the XMC SOAP Engine 30 via the Internet as previously discussed in the sections above describing the SOAP Pipeline.
  • [0305]
    To fulfill SOAP requests, the XMC SOAP Engine 30 works with both the XMC XML Engine 32 and with the XMC Motion Server 50. Data queries and configuration settings are made using the XMC XML Engine 32, and service requests are carried out directly by the XMC Motion Server 50 or indirectly through the XMC XML Engine 32.
  • [0306]
    The exemplary XMC SOAP Engine 30 comprises several objects. These objects work together to perform each requested SOAP operation. In addition, the XMC SOAP Engine 30 uses the XMC Motion Server 50 to eventually carry out the actual service request, either directly or using the ROPE module 56.
  • [0307]
    The exemplary XMC SOAP Engine 30 is a standard extension module for the Microsoft Internet Information module 74. As such, the XMC SOAP Engine 30 exposes the GetExtensionVersion, HttpExtensionProc, and TerminateExtension functions. These functions are called by module 74 on each request.
  • [0308]
    Referring now to FIG. 20 of the drawing, that figure shows that the XMC SOAP Engine 30 comprises a CsoapApp object 90, a GetExtensionVersion module 92, an HTTPExtension module 94, a TerminateExtension module 96, a Thread Pool 98 comprising one or more worker threads 98a, and a CsoapRequest module 100.
  • [0309]
    The CSoapApp object 90 manages each of the extension DLL entry points and routes each request appropriately to either the thread pool 98 or the CSoapRequest object 100. In addition, the CsoapApp object 90 is responsible for creating and destroying the worker thread pool 98.
  • [0310]
    The CSoapRequest object 100 is responsible for managing the data describing the actual service request. A new object is created for each service request and passed to a worker thread 98 a for processing.
  • [0311]
    The thread pool 98 is a collection of threads 98 a each of which is used to process one service request.
  • [0312]
    As generally described above, the ROPE DLL module 56 is used to parse each SOAP envelope and also to build the response SOAP envelopes that are sent back to the client application 28.
  • [0313]
    As generally discussed above, the XMC Motion Server 50 and XMC XML Engine 32 are used to carry out the requested operations (i.e. data query, configuration setting, or motion action).
  • [0314]
    Before the XMC SOAP Engine 30 can be used, it must be initialized. Initialization occurs on the first request when information server module 76 first loads the extension DLL.
  • [0315]
    The following steps occur during the XMC SOAP Engine Initialization. Upon receiving the first service request, the information server module 76 loads the extension DLL and calls the GetExtensionVersion module or function 92. Upon receiving this call, the CSoapApp object 90 creates the thread pool 98.
  • [0316]
    When processing a service request, the XMC SOAP Engine 30 creates a CSoapRequest object 100 and passes it to one of the threads 98 a in the thread-pool 98 for processing. The thread 98 a then in turn directs the specific motion operations to occur on the XMC Motion Server 50.
  • [0317]
    Referring now to FIG. 22, the following steps occur when the XMC SOAP Engine 30 processes a SOAP request.
  • [0318]
    First, upon receiving the SOAP service request, the information server module 76 calls the HttpExtensionProc 94, passing along all information about the service request. Inside the function call, the CSoapApp object 90 is used to process the request.
  • [0319]
    When called, the CSoapApp object 90 creates a CSoapRequest object 100 and passes to it the service request information. Next, the CSoapApp object 90 passes the new CSoapRequest object 100 to a free thread 98 a in the thread pool 98 and directs the thread 98 a to start processing the request. To process the request, the worker thread 98 a first accesses the CSoapRequest object 100 passed thereto by the CsoapApp object 90.
  • [0320]
    Next, the worker thread 98 a uses the ROPE module 56 to parse the response and get the PROGID of the designated component to be used to carry out the request.
  • [0321]
    The designated object or component specified by the request is accessed from either the XMC Motion Server 50 or the XMC XML Engine 32, and the appropriate method is called based on the SOAP request. Once the method completes, the result and any data returned is packed into a SOAP response envelope and sent back to the client application 28.
  • [0322]
    Upon termination of the motion control server system 20, the information server module 76 shuts down the XMC SOAP Engine 30. During this process, the XMC SOAP Engine 30 frees all resources used. This clean-up process will now be described in further detail with reference to FIG. 23.
  • [0323]
    Initially, upon termination of the motion control server system 20, the information server module 76 terminates the extension DLL by calling its TerminateExtension function 96. When called, the CSoapApp object 90 destroys the worker thread pool 98.
  • [0324]
    The following discussion will describe how to setup the XMC Soap Engine 30 to run with Microsoft Internet Information Server 76 on a Windows 2000 system. The requirements for the setup process are a Windows NT 2000 Server with NTFS formatted hard drives and Microsoft Internet Information (IIS), version 5.0 or above. Internet Explorer 5.0 or above is recommended but is not required.
  • [0325]
    This section describes how to configure (IS for use with the XMC Soap Engine. To setup IIS, a virtual directory is created where the XMC SOAP engine 30 is to run. When creating the virtual directory, the following settings should be followed:
    Application Low (IIS Service) Run the programs in the virtual
    Protection directory (ie the XMC SOAP
    Engine and all COM components
    that it uses) with the
    IWAM_<machname> user
    account access level.
    Read Access Enable Turn on read access so that data
    files (ie the service.xml and
    service.sod files) can be read.
    Execute Scripts & Executables Allow scripts and executables to
    Permissions run (ie the XMC Soap Engine and
    all COM objects that it uses).
    Directory Defaults (Anonymous, Use the default directory security
    Security Integrated Windows settings.
    authentication)
  • [0326]
    Next, the XMC Soap Engine IIS Extension is installed and several NT services are prepared to run with the XMC Soap Engine 30. The following sections describe each of these tasks. Please note that the virtual directory must be placed on an NTFS file system and the services.xml and services.sod files must be granted both Read and Execute access.
  • [0327]
    To setup the XMC Soap Engine ISAPI Extension, the ‘Configuration . . .’ button is selected from the ‘Properties’ page for the virtual directory. On the ‘App Mappings’ tab, select the ‘Add’ button to add a new mapping.
  • [0328]
    Browse for the location of the XMCSOAP.DLL and enter the location into the ‘Executable’ field. Make sure the location of the XMC Soap Engine 30 is the full path of the file on a Local hard drive; the access level at which the engine 30 runs does not have network access. Next, enter ‘*.sod’ as the ‘Extension’. Both the ‘All Verbs’ and ‘Script engine’ check boxes should be selected.
  • [0329]
    This mapping associates the *.sod file extension to the XMC Soap Engine ISAPI Extension DLL. Once mapped, the XMC Soap Engine ISAPI Extension DLL is called by IIS each time IIS encounters a file with the extension sod from within the virtual directory.
  • [0330]
    Both the IIS Admin Service and World Wide Web NT services must have ‘interact with use’ access. To enable each service with this access level, open the ‘Computer Management’ console by selecting the ‘Start|Programs|Administrative Tools|Computer Management’ menu item. From the console, select the ‘Services and Applications|Services’ tree item.
  • [0331]
    Next for both the ‘IIS Admin Service’ and ‘World Wide Web’ services, the following steps are performed. First, the service is opened by double clicking. The ‘Log on’ tab is then selected. The ‘Local system account’ radio button is next selected. Finally, the ‘Allow service to interact with the desktop’ check box is selected, just below the ‘Local system account’ radio button
  • [0332]
    Since the XMC Soap Engine uses several COM components and NT services. Each of these services should be configured in the following manner to allow proper interaction with the XMC Soap Engine 30.
  • [0333]
    Using DCOMCNFG.EXE the COM security level on all components as well as on the specific components used by the XMC Soap Engine shall be configured by making the following default properties using DCOMCNFG.EXE:
    Setting Value Description
    Enable Distributed COM on this Yes This will allow the NT
    computer services to talk COM objects.
    Enable COM Internet Services No Not used.
    on this computer
    Default authentication level Connect
    Default impersonation level Identity
  • [0334]
    In addition, the following default security settings should be made using DCOMCNFG.EXE:
    Setting Value Description
    Default Access None set For extra security, these
    Permissions will only be set on the
    specific servers.
    Default Launch IUSR_<machinename> Internet Web User
    Permissions (browsing the site)
    Default Launch IWAM_<machinename> IIS Process access level.
    Permissions (cont.)
  • [0335]
    Each XMC Motion executable must be configured using the DCOMCNFG.EXE utility as well. In particular, the following XMC binaries must be configured: XMCSRVC.EXE and XMCDBGWN.EXE.
  • [0336]
    All other XMC modules (which are DLLs) will run under the IIS Process security access level.
  • [0337]
    For each of the executables listed above, the following security settings should be made using the DCOMCNFG.EXE utility.
    Setting Value Description
    Default Access IWAM_<machinename> Internet Web User
    Permissions (browsing the site).
    Default Launch IUSR_<machinename> Internet Web User
    Permissions (browsing the site)
  • [0338]
    As a final security check, each and every EXE and DLL used by the XMC Soap Engine (including the XMC Soap Engine) must have both Read and Execute file permissions. All server files MUST be installed on a local hard drive for they will be accessed from within the IIS Process, which does not have network access.
  • [0339]
    Similar to the IIS Admin Service and World Wide Web service, the XMC Service must be configured to ‘Allow service to interact with the desktop’.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4159417 *Oct 28, 1977Jun 26, 1979Rubincam David PElectronic book
US4199814 *Oct 12, 1977Apr 22, 1980Digitcom, Inc.Computer numerical control machine tool
US4800521 *Sep 21, 1982Jan 24, 1989Xerox CorporationTask control manager
US4809335 *Oct 24, 1985Feb 28, 1989Rumsey Daniel SSpeech unit for dolls and other toys
US4815011 *Jan 26, 1987Mar 21, 1989Fanuc Ltd.Robot control apparatus
US4829419 *Dec 14, 1977May 9, 1989Hyatt Gilbert PMicrocomputer control of machines
US4840602 *Dec 2, 1987Jun 20, 1989Coleco Industries, Inc.Talking doll responsive to external signal
US4897835 *May 12, 1989Jan 30, 1990At&E CorporationHigh capacity protocol with multistation capability
US4912650 *Jul 7, 1987Mar 27, 1990Fanuc Ltd.Off-line control execution method
US4923428 *May 5, 1988May 8, 1990Cal R & D, Inc.Interactive talking toy
US4937737 *Aug 31, 1988Jun 26, 1990International Business Machines CorporationProcess transparent multi storage mode data transfer and buffer control
US4987537 *May 31, 1988Jan 22, 1991Nec CorporationComputer capable of accessing a memory by supplying an address having a length shorter than that of a required address for the memory
US5005134 *Apr 26, 1988Apr 2, 1991Fanuc Ltd.Numerical control apparatus with simultaneous function execution
US5005135 *Mar 22, 1989Apr 2, 1991Cincinnati Milacron, Inc.Dynamic correction of servo following errors in a computer-numerically controlled system and fixed cycle utilizing same
US5020021 *Jan 10, 1986May 28, 1991Hitachi, Ltd.System for automatic language translation using several dictionary storage areas and a noun table
US5095445 *Aug 22, 1990Mar 10, 1992Canon Kabushiki KaishaData communication system capable of communicating on-line with communication terminal equipment of a plurality of types
US5120065 *Feb 8, 1991Jun 9, 1992Hasbro, IncorporatedElectronic talking board game
US5126932 *Apr 5, 1990Jun 30, 1992Siemens Corporate Research, Inc.Method and apparatus for executing a program in a heterogeneous multiple computer system
US5291416 *Mar 8, 1991Mar 1, 1994Software Algoritms IncorporatedEvent feedback for numerically controlled machine tool and network implementation thereof
US5382026 *Mar 17, 1994Jan 17, 1995Hughes Aircraft CompanyMultiple participant moving vehicle shooting gallery
US5390304 *Sep 28, 1990Feb 14, 1995Texas Instruments, IncorporatedMethod and apparatus for processing block instructions in a data processor
US5390330 *Feb 11, 1993Feb 14, 1995Talati; Kirit K.Control system and method for direct execution of software application information models without code generation
US5392207 *Aug 20, 1993Feb 21, 1995Allen-Bradley Company, Inc.Programmable motion controller with graphical programming aid
US5400345 *Mar 6, 1992Mar 21, 1995Pitney Bowes Inc.Communications system to boundary-scan logic interface
US5402518 *Jul 22, 1992Mar 28, 1995Pcvoice, Inc.Sound storage and sound retrieval system having peripheral with hand operable switches
US5405152 *Jun 8, 1993Apr 11, 1995The Walt Disney CompanyMethod and apparatus for an interactive video game with physical feedback
US5412757 *Nov 26, 1991May 2, 1995Kabushiki Kaisha ToshibaFuzzy control system
US5413355 *Dec 17, 1993May 9, 1995Gonzalez; CarlosElectronic educational game with responsive animation
US5491813 *Nov 18, 1994Feb 13, 1996International Business Machines CorporationDisplay subsystem architecture for binding device independent drivers together into a bound driver for controlling a particular display device
US5493281 *Jul 29, 1994Feb 20, 1996The Walt Disney CompanyMethod and apparatus for remote synchronization of audio, lighting, animation and special effects
US5511147 *Jan 12, 1994Apr 23, 1996Uti CorporationGraphical interface for robot
US5596994 *May 2, 1994Jan 28, 1997Bro; William L.Automated and interactive behavioral and medical guidance system
US5600373 *Jun 27, 1996Feb 4, 1997Houston Advanced Research CenterMethod and apparatus for video image compression and decompression using boundary-spline-wavelets
US5604843 *Dec 23, 1992Feb 18, 1997Microsoft CorporationMethod and system for interfacing with a computer output device
US5607336 *Jul 18, 1995Mar 4, 1997Steven LebensfeldSubject specific, word/phrase selectable message delivering doll or action figure
US5608894 *Oct 19, 1994Mar 4, 1997Fujitsu LimitedExecution control system
US5617528 *Feb 6, 1995Apr 1, 1997Datacard CorporationMethod and apparatus for interactively creating a card which includes video and cardholder information
US5618179 *Nov 14, 1994Apr 8, 1997Atari Games CorpoorationDriver training system and method with performance data feedback
US5623582 *Jul 14, 1994Apr 22, 1997Immersion Human Interface CorporationComputer interface or control input device for laparoscopic surgical instrument and other elongated mechanical objects
US5625820 *Jul 3, 1996Apr 29, 1997International Business Machines CorporationSystem managed logging of objects to speed recovery processing
US5625821 *Aug 12, 1991Apr 29, 1997International Business Machines CorporationAsynchronous or synchronous operation of event signaller by event management services in a computer system
US5636994 *Nov 9, 1995Jun 10, 1997Tong; Vincent M. K.Interactive computer controlled doll
US5704837 *Mar 25, 1994Jan 6, 1998Namco Ltd.Video game steering system causing translation, rotation and curvilinear motion on the object
US5707289 *Oct 6, 1995Jan 13, 1998Pioneer Electronic CorporationVideo game system having terminal identification data
US5724074 *Feb 6, 1995Mar 3, 1998Microsoft CorporationMethod and system for graphically programming mobile toys
US5733131 *Jul 29, 1994Mar 31, 1998Seiko Communications Holding N.V.Education and entertainment device with dynamic configuration and operation
US5734373 *Dec 1, 1995Mar 31, 1998Immersion Human Interface CorporationMethod and apparatus for controlling force feedback interface systems utilizing a host computer
US5737523 *Mar 4, 1996Apr 7, 1998Sun Microsystems, Inc.Methods and apparatus for providing dynamic network file system client authentication
US5739811 *Sep 27, 1995Apr 14, 1998Immersion Human Interface CorporationMethod and apparatus for controlling human-computer interface systems providing force feedback
US5746602 *Feb 27, 1996May 5, 1998Kikinis; DanPC peripheral interactive doll
US5752880 *Nov 20, 1995May 19, 1998Creator Ltd.Interactive doll
US5754855 *May 12, 1997May 19, 1998International Business Machines CorporationSystem and method for managing control flow of computer programs executing in a computer system
US5764155 *Apr 3, 1996Jun 9, 1998General Electric CompanyDynamic data exchange server
US5766077 *May 22, 1996Jun 16, 1998Kabushiki Kaisha BandaiGame apparatus with controllers for moving toy and character therefor
US5772504 *Sep 10, 1996Jun 30, 1998Konami Co., Ltd.Driving game machine
US5855483 *Mar 10, 1997Jan 5, 1999Compaq Computer Corp.Interactive play with a computer
US5867385 *May 30, 1996Feb 2, 1999Roy-G-Biv CorporationMotion control systems
US5873765 *Jan 7, 1997Feb 23, 1999Mattel, Inc.Toy having data downloading station
US5889670 *Jan 11, 1996Mar 30, 1999Immersion CorporationMethod and apparatus for tactilely responsive user interface
US5889672 *Jun 3, 1998Mar 30, 1999Immersion CorporationTactiley responsive user interface device and method therefor
US5890963 *Sep 30, 1996Apr 6, 1999Yen; WeiSystem and method for maintaining continuous and progressive game play in a computer network
US5907704 *Oct 2, 1996May 25, 1999Quark, Inc.Hierarchical encapsulation of instantiated objects in a multimedia authoring system including internet accessible objects
US5907831 *Apr 4, 1997May 25, 1999Lotvin; MikhailComputer apparatus and methods supporting different categories of users
US5914876 *Jun 5, 1996Jun 22, 1999Mitsubishi Denki Kabushiki KaishaNumerical controller having expanded control word set
US6012961 *May 14, 1997Jan 11, 2000Design Lab, LlcElectronic toy including a reprogrammable data storage device
US6020876 *Apr 14, 1997Feb 1, 2000Immersion CorporationForce feedback interface with selective disturbance filter
US6028593 *Jun 14, 1996Feb 22, 2000Immersion CorporationMethod and apparatus for providing simulated physical interactions within computer generated environments
US6031973 *Jun 16, 1997Feb 29, 2000Seiko Epson CorporationRobot and its controller method
US6038603 *Mar 25, 1997Mar 14, 2000Oracle CorporationProcessing customized uniform resource locators
US6046727 *Feb 9, 1999Apr 4, 2000Immersion CorporationThree dimensional position sensing interface with force output
US6057828 *Jan 16, 1997May 2, 2000Immersion CorporationMethod and apparatus for providing force sensations in virtual environments in accordance with host software
US6061004 *May 29, 1998May 9, 2000Immersion CorporationProviding force feedback using an interface device including an indexing function
US6065365 *Feb 23, 1998May 23, 2000Case CorporationControl lever assembly
US6070010 *Mar 31, 1998May 30, 2000International Business Machines CorporationSystem and method of local data alignment for stack memory
US6078308 *Jun 18, 1997Jun 20, 2000Immersion CorporationGraphical click surfaces for force feedback applications to provide user selection using cursor interaction with a trigger position within a boundary of a graphical object
US6078968 *Dec 17, 1997Jun 20, 2000Vicom Systems, Inc.Platform-independent communications protocol supporting communications between a processor and subsystem controller based on identifying information
US6080063 *Jan 6, 1997Jun 27, 2000Khosla; VinodSimulated real time game play with live event
US6169540 *Jun 17, 1997Jan 2, 2001Immersion CorporationMethod and apparatus for designing force sensations in force feedback applications
US6173316 *Apr 8, 1998Jan 9, 2001Geoworks CorporationWireless communication device with markup language based man-machine interface
US6191774 *Sep 22, 1999Feb 20, 2001Immersion CorporationMouse interface for providing force feedback
US6195592 *Mar 23, 1999Feb 27, 2001Immersion CorporationMethod and apparatus for providing tactile sensations using an interface device
US6201996 *May 29, 1998Mar 13, 2001Control Technology CorporationaObject-oriented programmable industrial controller with distributed interface architecture
US6209037 *Dec 3, 1998Mar 27, 2001Roy-G-Biv CorporationMotion control systems using communication map to facilitating communication with motion control hardware
US6216173 *Feb 3, 1998Apr 10, 2001Redbox Technologies LimitedMethod and apparatus for content processing and routing
US6219032 *Dec 13, 1995Apr 17, 2001Immersion CorporationMethod for providing force feedback to a user of an interface device based on interactions of a controlled cursor with graphical elements in a graphical user interface
US6219033 *Mar 30, 1998Apr 17, 2001Immersion CorporationMethod and apparatus for controlling force feedback interface systems utilizing a host computer
US6233545 *Mar 3, 1998May 15, 2001William E. DatigUniversal machine translator of arbitrary languages utilizing epistemic moments
US6243078 *Feb 18, 1999Jun 5, 2001Immersion CorporationPointing device with forced feedback button
US6246390 *Jun 6, 1997Jun 12, 2001Immersion CorporationMultiple degree-of-freedom mechanical interface to a computer system
US6247994 *Feb 11, 1998Jun 19, 2001Rokenbok Toy CompanySystem and method for communicating with and controlling toy accessories
US6519594 *Mar 1, 1999Feb 11, 2003Sony Electronics, Inc.Computer-implemented sharing of java classes for increased memory efficiency and communication method
US6523171 *Nov 29, 1999Feb 18, 2003International Business Machines CorporationEnhanced source code translator from procedural programming language (PPL) to an object oriented programming language (OOPL)
US6528963 *May 30, 2001Mar 4, 2003Samsung Electronics Co., Ltd.Robot and method for controlling motor speed of the robot
US6542925 *Feb 21, 2001Apr 1, 2003Roy-G-Biv CorporationGeneration and distribution of motion commands over a distributed network
US6546436 *Mar 30, 1999Apr 8, 2003Moshe FainmesserSystem and interface for controlling programmable toys
US6571141 *May 4, 2000May 27, 2003Roy-G-Biv CorporationApplication programs for motion control devices including access limitations
US6678713 *Apr 29, 1998Jan 13, 2004Xerox CorporationMachine control using a schedulerlock construct
US6889118 *Nov 27, 2002May 3, 2005Evolution Robotics, Inc.Hardware abstraction layer for a robot
US20040019683 *Jul 25, 2002Jan 29, 2004Lee Kuo ChuProtocol independent communication system for mobile devices
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7330473 *Sep 4, 2002Feb 12, 2008Rockwell Automation Technologies, Inc.System and methodology providing network data exchange between industrial control components
US7392391 *Sep 12, 2002Jun 24, 2008International Business Machines CorporationSystem and method for secure configuration of sensitive web services
US7451215 *Apr 12, 2007Nov 11, 2008Honeywell International Inc.OPC server redirection manager
US7512906Jun 4, 2002Mar 31, 2009Rockwell Automation Technologies, Inc.System and methodology providing adaptive interface in an industrial controller environment
US7539724Nov 18, 2002May 26, 2009Rockwell Automation Technologies, Inc.Instant messaging for event notification and exchanging data in an industrial controller environment
US7571221 *Apr 3, 2002Aug 4, 2009Hewlett-Packard Development Company, L.P.Installation of network services in an embedded network server
US7606890Oct 20, 2009Rockwell Automation Technologies, Inc.System and methodology providing namespace and protocol management in an industrial controller environment
US7761880 *Sep 27, 2006Jul 20, 2010International Business Machines CorporationDynamically extending XML-based service through client
US7853645Dec 14, 2010Roy-G-Biv CorporationRemote generation and distribution of command programs for programmable devices
US7904194Mar 8, 2011Roy-G-Biv CorporationEvent management systems and methods for motion control systems
US7953769 *May 31, 2011Computer Associates Think, Inc.XML data packaging system and method
US7970801 *Jun 28, 2011Computer Associates Think, Inc.Data packaging system and method
US8000814May 4, 2005Aug 16, 2011Fisher-Rosemount Systems, Inc.User configurable alarms and alarm trending for process control system
US8027349Sep 27, 2011Roy-G-Biv CorporationDatabase event driven motion systems
US8060834Nov 15, 2011Fisher-Rosemount Systems, Inc.Graphics integration into a process configuration and control environment
US8073557Dec 6, 2011Roy-G-Biv CorporationMotion control systems
US8086955Nov 3, 2006Dec 27, 2011Fisher-Rosemount Systems, Inc.Methods and apparatus for modifying process control data
US8102869Jun 29, 2009Jan 24, 2012Roy-G-Biv CorporationData routing systems and methods
US8112766Feb 7, 2012Ricoh Company, Ltd.Multi-threaded device and facility manager
US8127241May 4, 2005Feb 28, 2012Fisher-Rosemount Systems, Inc.Process plant user interface system having customized process graphic display layers in an integrated environment
US8132127Mar 25, 2009Mar 6, 2012Rockwell Automation Technologies, Inc.System and methodology providing adaptive interface in an industrial controller environment
US8135481May 18, 2010Mar 13, 2012Fisher-Rosemount Systems, Inc.Process plant monitoring based on multivariate statistical analysis and on-line process simulation
US8185219Feb 9, 2010May 22, 2012Fisher-Rosemount Systems, Inc.Graphic element with multiple visualizations in a process environment
US8271105Sep 18, 2012Roy-G-Biv CorporationMotion control systems
US8312060 *Nov 3, 2006Nov 13, 2012Fisher-Rosemount Systems, Inc.Methods and apparatus for accessing process control data
US8321546Nov 27, 2012Ricoh Company, Ltd.Integrating discovery functionality within a device and facility manager
US8533239May 16, 2011Sep 10, 2013Ca, Inc.Data packaging system and method
US8825183Mar 22, 2010Sep 2, 2014Fisher-Rosemount Systems, Inc.Methods for a data driven interface based on relationships between process control tags
US8850507Jan 6, 2014Sep 30, 2014Convergent Media Solutions LlcMethod and apparatus for browsing using alternative linkbases
US8875215Jan 6, 2014Oct 28, 2014Convergent Media Solutions LlcMethod and apparatus for browsing using alternative linkbases
US8881039May 5, 2009Nov 4, 2014Fisher-Rosemount Systems, Inc.Scaling composite shapes for a graphical human-machine interface
US8893212Jan 6, 2014Nov 18, 2014Convergent Media Solutions LlcMethod and apparatus for browsing using alternative linkbases
US8898722Jan 6, 2014Nov 25, 2014Convergent Media Solutions LlcMethod and apparatus for browsing using alternative linkbases
US8914840Jan 6, 2014Dec 16, 2014Convergent Media Solutions LlcMethod and apparatus for browsing using alternative linkbases
US9143839 *Nov 6, 2012Sep 22, 2015Convergent Media Solutions LlcMethod and apparatus for browsing using multiple coordinated device sets
US9413852Dec 21, 2012Aug 9, 2016Rockwell Automation Technologies, Inc.Time-stamping of industrial cloud data for synchronization
US9438648Nov 22, 2013Sep 6, 2016Rockwell Automation Technologies, Inc.Industrial data analytics in a cloud platform
US20030084350 *Sep 12, 2002May 1, 2003International Business Machines CorporationSystem and method for secure configuration of sensitive web services
US20030154308 *Feb 13, 2002Aug 14, 2003Infowave Software, Inc.General purpose compression proxy system and method for extensible markup language (XML) documents
US20030172110 *Dec 10, 2002Sep 11, 2003Oracle International CorporationMethods and apparatus for invoking a document style server operation using an operation name in a SOAPAction header
US20030191824 *Apr 3, 2002Oct 9, 2003Raghav RaoInstallation of network services in an embedded network server
US20040006610 *Jul 5, 2002Jan 8, 2004Anjali Anagol-SubbaraoArchitecture and method for configuration validation web service
US20040201600 *Dec 14, 2001Oct 14, 2004Microsoft CorporationMethods and system for providing an XML-based interface description language
US20070061786 *Nov 3, 2006Mar 15, 2007Ling ZhouMethods and apparatus for modifying process control data
US20070130572 *Nov 3, 2006Jun 7, 2007Stephen GilbertMethods and apparatus for accessing process control data
US20070156862 *Dec 27, 2006Jul 5, 2007Tsutomu YamadaComputer system
US20070198709 *Apr 12, 2007Aug 23, 2007Anthony Miologos, Esq.OPC server redirection manager
US20080077709 *Sep 27, 2006Mar 27, 2008International Business Machines CorporationDynamically extening xml-based service through client
US20080155541 *Dec 21, 2006Jun 26, 2008Ricoh Company, Ltd.Multi-threaded device and facility manager
US20080168440 *Jan 10, 2007Jul 10, 2008Ricoh Corporation Ltd.Integrating discovery functionality within a device and facility manager
US20090157199 *Oct 2, 2008Jun 18, 2009Brown David WMotion Control Systems
US20090157807 *Feb 23, 2009Jun 18, 2009Brown Stephen JSystem and/or method for generating a script relating to a medical task involving motion with a device
US20110169832 *Jul 14, 2011Roy-G-Biv Corporation3D Motion Interface Systems and Methods
US20110219040 *Sep 8, 2011Computer Associates Think, Inc.Data packaging system and method
US20130073738 *Nov 6, 2012Mar 21, 2013Richard ReismanMethod and Apparatus for Browsing Using Multiple Coordinated Device Sets
US20140107847 *Jun 7, 2013Apr 17, 2014Delta Electro-Optics (Wujiang) Ltd.Operating method and operating system for a pcb drilling-milling machine using different motion control products
EP1959638A2 *Dec 5, 2007Aug 20, 2008Ricoh Company, Ltd.Integrating discovery functionality within a device and facility manager
EP1959638A3 *Dec 5, 2007Aug 27, 2008Ricoh Company, Ltd.Integrating discovery functionality within a device and facility manager
EP2293203A1 *May 4, 2005Mar 9, 2011Fisher-Rosemount Systems, Inc.Methods and apparatus for querying process control data
WO2011133905A1 *Apr 22, 2011Oct 27, 2011OyunStudyosu Ltd. Sti.Social groups system and method
Classifications
U.S. Classification709/219, 709/203, 709/231
International ClassificationG06F15/173, G06F, G06F15/16, H04L29/06, H04L29/08
Cooperative ClassificationH04L29/06, H04L67/02, H04L69/329, H04L29/08846, H04L67/125, G06F9/541, H04L67/28, G06F9/547, H04L67/16
European ClassificationB82Y30/00, H04L29/06, H04L29/08N15, H04L29/08N1
Legal Events
DateCodeEventDescription
Apr 8, 2002ASAssignment
Owner name: ROY-G-BIV CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROWN, DAVID W.;REEL/FRAME:012792/0997
Effective date: 20020114