1 Scope

This specification was created by a joint working group of the OPC Foundation and VDW. It defines an OPC UA Information Model to interface and exchange data with Computerized Numerical Control (CNC) systems.

OPC Foundation

The OPC Foundation defines standards for online data exchange between automation systems. They address access to current data (OPC DA), alarms and events (OPC A&E) and historical data (OPC HDA). Those standards are successfully applied in industrial automation.

The new OPC Unified Architecture (OPC UA) unifies the existing standards and brings them to state-of-the-art technology using service-oriented architecture (SOA). Platform-independent technology allows the deployment of OPC UA beyond current OPC applications only running on Windows-based PC systems. OPC UA can also run on embedded systems as well as Linux / UNIX based enterprise systems. The provided information can be generically modelled and therefore arbitrary information models can be provided using OPC UA.

German Machine Tool Builders’ Association (VDW)

The VDW, based in Frankfurt/Main, represents the interests of the German machine tool industry. In this context VDW is interested in increasing the innovation and competitive capacity of machine tool builders and manufacturers of CNC systems by reducing the expenses for linking CNC Systems with other applications. This should be achieved by standardization of CNC interfaces.

2 Reference documents

OPC 10000-1, OPC Unified Architecture - Part 1: Overview

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-9, OPC Unified Architecture - Part 9: Alarms and Conditions

DIN IEC 61131-3:2009-12, Programmable Controllers – Part 3: Programming languages

OPC 10030, UA Companion Specification for ISA-95 Common Object Model

3 Terms, definitions, and conventions

3.1 Use of terms

Defined terms of OPC UA specifications, types and their components defined in OPC UA specifications and in this specification are highlighted with italic in this document.

3.2 Abbreviations and symbols

3.3 Conventions used in this document

3.3.1 Conventions for Node descriptions

Node definitions are specified using tables (See Table 1)

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. In Table 2 examples are given.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a NodeId of a TypeDefinitionNode, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding TypeDefinitionNode. The symbolic name of the NodeId is used in the table.

The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another of this document points to their definition.

If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex, i.e. containing components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in 3.3.2.1. Therefore those containing components are not explicitly specified; they are implicitly specified by the type definitions.

3.3.2 NodeIds and BrowseNames

3.3.2.1 NodeIds

The NodeIds of all Nodes described in this document are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The namespace for this specification is defined in Annex A. The NamespaceIndex for all NodeIds defined in this specification is server specific and depends on the position of the namespace URI in the server namespace table.

Note: This specification does not only define concrete Nodes, but also requires that some Nodes have to be generated, for example one for each device type available in the frame application. The NodeIds of those Nodes are server-specific, including the Namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined by this specification, because they are not defined by this specification but generated by the Server.

3.3.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is server specific and depends on the position of the namespace URI defined in this specification in the server namespace table.

If the BrowseName is not defined by this specification, a namespace index prefix like ‘0:EngineeringUnits’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this specification. Table 39 provides a list of namespaces used in this specification.

3.3.3 Common Attributes

3.3.3.1 General

For all Nodes specified in this specification, the Attributes named in Table 3 shall be set as specified in the table.

3.3.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 4 shall be set as specified in the table.

3.3.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 5 shall be set as specified in the table.

3.3.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 6 shall be set as specified in the table.

4 General information to CNC systems and OPC UA

4.1 Introduction to CNC systems

4.1.1 General

CNC systems are used to control machine tools and machining centers. The CNC system is mainly responsible for generating a relative movement between a tool (e.g cutting tool) and a workpiece. Therefore, the CNC system implements functionality to provide setpoints to a machine tool’s drives that realize the generated movement physically.

CNC systems are in most cases executed in combination with Programmable Logic Controllers (PLC). Whereas the CNC is responsible for the tool path generation, the PLC implements auxiliary functionality (mostly logical operations like activating lubrication at a certain time) and controls the peripheral devices.

CNC systems as a whole consist of several hardware and software components as illustrated in Figure 1.

Computerized Numerical Control Kernel (CNC kernel): The CNC kernel realizes the core functionality of a CNC system. It implements functionality to generate the axes movement for machining workpieces based on a geometrical and technological description given in a CNC part program. Therefore it provides software functions for decoding, interpreting and processing data of a CNC part program, for path planning and setpoint generation considering given constraints and depending on the system’s realization for positioning the machine’s axes.

Programmable Logic Controller (PLC): The PLC handles all logical operations of a CNC system. It is closely coupled with the CNC kernel and enables to realize complex process sequences that involve different actors and sensors of the machine next to the machine’s drives. The PLC may also realize monitoring and safety functions and processes input signals from certain devices or the user interface. PLC programs are often implemented according to IEC 61131-3.

CNC-PLC-Interface: The CNC-PLC-Interface links the CNC kernel and the PLC. Both modules have to be synchronized and therefore are closely coupled. The CNC-PLC-Interface is often realized as shared memory to allow high performing data exchange.

Machine Interface: The Machine Interface allows applications to exchange data with a CNC system. Thus, the CNC system can be configured, operated and monitored. The Machine Interface is used primarily by the User Interface (UI) but additionally by other applications like engineering and production management systems. Many CNC systems offer more than one Machine Interface connection point so that different communication mechanisms or protocols can be used at a time.

(Graphical) User Interface (UI): The UI, mostly realized as graphical user interface (GUI) is a software application that allows operators and commissioning engineers to interact with the CNC system and therefore to configure, operate and monitor the CNC system as well as the complete machine tool. The UI is connected to the Machine Interface of the CNC system. It may be executed on the same system platform than the CNC or on a separate device.

Fieldbus Interface: The peripheral devices and the drives of a machine tool are connected to the CNC system by a fieldbus. For that reason both CNC and hardware device provide a Fieldbus Interface for connecting one with another. Most fieldbus systems allow to communicate data in a cyclical, time deterministic behaviour, as well as in an asynchronous mode.

Drives and Motors: The drive unit, consisting of drive and motor, realizes physically the desired tool path, generated by the CNC kernel. The drive implements among others feedback controllers for current, velocity and mostly for position, as well. Generated setpoints are used for controlling the motor. The drive itself is connected to the CNC by a fieldbus to realize a time deterministic communication behaviour.

I/O-Modules and Actors, Sensors, Input Devices: Apart from the drives, other peripheral devices (actors, sensors and input devices) are connected directly or through I/O-Modules to the CNC by a fieldbus.

Machine tools and machining centers can constitute complex systems regarding their kinematic structure. To cope with this complexity CNC systems provide the possibility to fragment the control task by using a software construct organizing kinematic chains and additional moving machine tool components like tool changers. So called “channels” are responsible for controlling smaller portions of the machine tool kinematic and its additional components. In general, all axes within a channel are interpolated in common.

4.1.2 CNC Data

A CNC system provides data through the Machine Interface for external application systems like UIs, SCADA and engineering systems among others. This data has its origin within the CNC system itself or is collected from the drives and peripheral devices. All available data can be divided into the following categories:

Parameter: Configuration data of the CNC system, hardware devices and communication mechanisms. Parameters do not have any requirements regarding communication behaviour.

State data: States of the hardware devices, CNC kernel and PLC. States may be built within the PLC system itself by summarizing data.

Command data: Setpoint values and commands that are communicated from the Machine Interface to the CNC system as well as from the CNC system to the hardware devices. The first do not have requirements regarding the communication behaviour, the latter are communicated cyclically from the CNC system to the appropriate devices.

Process data: Actual values of the hardware devices. Values are communicated cyclically from the appropriate devices to the CNC system.

Alarms: Events of the CNC System, e.g. by the CNC kernel, the PLC, but as well by the UI, informing about errors or other notifications.

Files: Files are transferred from the Machine Interface to the CNC kernel or the PLC, maybe as well to the drives and peripheral devices holding configuration data (e.g. tool parameters) or process information in form of part programs or similar.

4.1.3 Production Network

CNC systems may be integrated in a network comprising various systems for controlling and supervising the production. Hence CNC systems may be connected next to UI and engineering software applications to different systems like

MES,

ERP systems,

PDA/MDA systems,

diagnosis and condition monitoring applications,

further external UI applications, e.g. smart device applications or similar.

A CNC system can be integrated into a production network using the appropriate interface, mostly the Machine Interface. Due to the diversity of systems and system manufacturers standardized interfaces could reduce efforts for linking these systems. This Information Model aims at achieving precisely this objective.

4.1.4 Restrictions

The focus of the “OPC UA Information Model for CNC systems” is on data that is situated within the CNC kernel but not within the PLC of a CNC system. This results out of the main objective of this Information Model to standardize an interface that provides and enables to access clearly defined raw data. Hence this Information Model addresses applications like UIs, PDA/MDA systems, diagnosis and monitoring applications, but not necessarily MES or ERP systems as the two latter ones mostly need summarized data.

For PLC data and in a wider context for MES and ERP data, please refer to suitable standards and OPC UA companion standards like OPC 30000 (PLCopen) or OPC 10030 (ISA 95).

4.2 Introduction to OPC Unified Architecture

4.2.1 General

The main use case for OPC standards is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC DA provides functionality to browse through a hierarchical namespaces containing data items and to read, write and to monitor these items for data changes. The classic OPC standards are based on Microsoft COM/DCOM technology for the communication between software components from different vendors. Therefore classic OPC server and clients are restricted to Windows PC based automation systems.

OPC UA incorporates all features of classic OPC standards like OPC DA, A&E and HDA but defines platform independent communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose.

The OPC UA network communication part defines different mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security, access control and reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers.

The OPC UA Information Model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed.

The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines eight classes of Nodes to represent AddressSpace components. The classes are Object, Variable, Method, ObjectType, VariableType, DataType, ReferenceType and View. Each NodeClass has a defined set of Attributes.

This specification makes use of three essential OPC UA NodeClasses: Objects, Methods and Variables.

Objects are used to represent components of a system. An Object is associated to a corresponding ObjectType that provides definitions for that Object.

Methods are used to represent commands or services of a system.

Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them. An example for Properties of Objects is the Version Property of the CncInterfaceType.

DataVariables represent the contents of an Object. DataVariables may have component DataVariables. This is typically used by Servers to expose individual elements of arrays and structures. This specification uses DataVariables to represent parameters, state data, process and command data, for example ActSpeed of a Object of CncSpindleType.

4.2.2 Graphical Notation

OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualized. Figure 2 shows the symbols for the six NodeClasses used in this specification. NodeClasses representing types always have a shadow.

Figure 3 shows the symbols for the ReferenceTypes used in this specification. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubtype Reference. The most important References like HasComponent, HasProperty, HasTypeDefinition and HasSubtype have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol.

Figure 4 shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubtype Reference. The Object_A has the components Variable_1, Variable_2 and Method_1.

To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType like for ObjectType_Y in the example. The instance Nodes used to describe an ObjectType are instance declaration Nodes.

To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol.

4.3 Use Cases

This companion standard is meant to be used for CNC data interfaces. It allows to access data provided by a CNC system, namely parameters, state data, process and command data, alarm notifications and files. Access covers both read and write access. Thus, the following use cases may be covered:

Setup: The CNC data interface provides data that can be used for setting up a production system controlled by a CNC. This refers first of all to production commissioning data (e.g. job description, tool data etc.) but implies to a certain extent as well CNC configuration data (e.g. axis parameters, cycle time etc.), as needed for engineering.

Operation: The CNC data interface may be used for operating a production system controlled by a CNC and therefore serves as a connection point for user interfaces.

Observation: The CNC data interface may be used for observing a production system controlled by a CNC and therefore serves as a connection point for monitoring and diagnosis applications and for user interfaces.

Figure 5 shows the use case diagram.

5 Information Model Overview

5.1 Modelling concepts

The main objective of this companion standard is to have an Information Model that results in a clearly defined and structured CNC data interface. That means that both data items and its composition are specified. Manufacturer and use case specific extensions shall be possible.

Regarding the data elements standard OPC UA Variable types shall be used as far as possible. There are two main categories of data items present: unit based items (e.g. position data in mm or inch) and items without unit (e.g. state data). Unit based items shall be realized as AnalogItemTypes, other data as DataItemTypes. Units shall be used as described in OPC 10000-8.

Regarding the structure of the CNC data interface it is intended to realize flat hierarchies. However, multiple referencing of Objects shall be used for exposing the assignment of components within the hardware or software system.

ObjectTypes shall be derived as far as possible from hardware and software components of a CNC system.

5.2 Model Overview

Based on the modelling concepts this chapter introduces the “OPC UA Information Model for CNC Systems”.

This Information Model provides the ObjectTypes as illustrated in Figure 6. There are ObjectTypes that are used as structuring elements of the CNC data interface (e.g. CncAxisListType) and ObjectTypes to define grouping elements related to hardware and software components of a CNC system (e.g. CncAxisType). Furthermore, this Information Model specifies EventTypes for alarm reporting (e.g. CncAlarmType).

The overall structure of the CNC data interface is illustrated in Figure 7. CncInterface represents the entry point to the CNC data interface. It contains next to the instances of the above mentioned ObjectTypes several Properties for specifying the data interface (e.g. Version, VendorName). One main objective of this Information Model is to provide first of all a fast and easy access to all components managed by the CNC data interface. Out of this reason there are lists provided by the CncInterface Object (e.g. CncAxisList) to allow accessing components without knowing about their affiliation within the logical structure of a machine tool or a CNC system (e.g. independent from their channel affiliation all axes can be accessed via the CncAxisList Object). However, logical structures are additionally modeled by using Hierarchical References (organizes). For instance, a CNC channel of type CncChannelType holds References to all axes and spindles that are assigned to this specific channel, see Figure 7.

The CncInterface Object is furthermore responsible for the alarm and event handling of the CNC data interface. It generates events of type CncAlarmType and CncMessageType for providing error and information messages.

Instances of CncChannelType can generate events of type CncMessageType for providing information messages.

FileSystem represents the entry point to the file system of the CNC data interface. It is subordinated to the CncInterface Object.

Figure 8 and Figure 9 serves as an example for this companion standard. The shown Information Model is built up for a three axis machine tool and a multi channel machine tool. For the sake of clarity only the ObjectTypes and its References are presented but not its Variables or Properties. For further information, the ObjectTypes are described in detail in chapter 6.

6 OPC UA ObjectTypes

6.1 CncInterfaceType

6.1.1 General

This OPC UA ObjectType represents a CNC Interface. CncInterfaceType is the entry point to the CNC data interface. It is mainly used for structuring the interface. But additionally this ObjectType holds Properties characterizing this interface (Version, VendorName etc.), as well as References to the specified EventTypes. There are two different types of events generated by an instance of CncInterfaceType: events of type CncMessageType and of type CncAlarmType.

Events of type CncAlarmType are used to provide CNC error messages.

Events of type CncMessageType are used to provide messages that are not an alarm but a non-critical information, e.g. a user created message out of the CNC part program.

CncInterfaceType is formally defined in Table 7.

6.1.2 ObjectType Definition

The CncInterfaceType is formally defined in Table 7.

6.1.3 ObjectType Description

6.1.3.1 CncAlarm

CncInterfaceType may generate events of type CncAlarmType to provide error messages.

6.1.3.2 CncMessage

CncInterfaceType may generate events of type CncMessageType to provide general CNC information messages.

6.1.3.3 CncAxisList

Group of CNC axis objects.

Adds child <CncAxis>.

6.1.3.4 CncChannelList

Group of CNC channel objects.

Adds child <CncChannel>.

6.1.3.5 CncSpindleList

Group of CNC spindle objects.

Adds child <CncSpindle>.

6.1.3.6 FileSystem

Entry point to system’s file directory.

6.1.3.7 CncTypeName

Type or model name of the CNC that is represented by Information Model.

6.1.3.8 Fix

Manufacturer specific version of CNC interface considering changes in implementation (Bug Fix).

6.1.3.9 VendorName

Name of CNC system vendor. Format and content may be chosen by vendor.

6.1.3.10 VendorRevision

Vendor revision of CNC interface. Format and content may be chosen by vendor.

6.1.3.11 Version

CNC interface version - corresponds to the version of this OPC UA companion standard and has to be presented in the same format (e.g. 1.03) so that an OPC UA Client can evaluate the version programmatically.

6.2 CncAxisListType

6.2.1 General

This OPC UA ObjectType serves as a structuring element. Objects of type CncAxisListType comprise all axes that are subordinated to a CncInterface. It is formally defined in Table 8.

Objects of type CncAxisListType may generate events of type GeneralModelChangeEventType. These events are used to inform about changes in the Information Model related to an instance of CncAxisListType.

6.2.2 ObjectType Definition

The CncAxisListType is formally defined in Table 8.

6.2.3 ObjectType Description

6.2.3.1 GeneralModelChangeEvent

CncAxisListType may generate events of type GeneralModelChangeEventType defined in OPC 10000-3 to inform Clients when CncAxis Objects have been added or removed from a CncAcisListType instance.

6.2.3.2 NodeVersion

The optional Property NodeVersion shall be present if the Server emits GeneralModelChangeEvents for the Object of type CncAxisListType. The NodeVersion Property and the relation to GeneralModelChangeEvents are defined in OPC 10000-3.

6.2.3.3 CncAxis

CNC axis object.

6.3 CncSpindleListType

6.3.1 General

This OPC UA ObjectType serves as a structuring element. Objects of type CncSpindleListType comprise all spindles that are subordinated to a CncInterface. It is formally defined in Table 9.

Objects of type CncSpindleListType may generate events of type GeneralModelChangeEventType. These events are used to inform about changes in the Information Model related to an instance of CncSpindleListType.

6.3.2 ObjectType Definition

The CncSpindleListType is formally defined in Table 9.

6.3.3 ObjectType Description

6.3.3.1 GeneralModelChangeEvent

CncSpindleListType may generate events of type GeneralModelChangeEventType defined in OPC 10000-3 to inform Clients when CncSpindle Objects have been added or removed from a CncSpindleListType instance.

6.3.3.2 NodeVersion

The optional Property NodeVersion shall be present if the Server emits GeneralModelChangeEvents for the Object of type CncSpindleListType. The NodeVersion Property and the relation to GeneralModelChangeEvents are defined in OPC 10000-3.

6.3.3.3 CncSpindle

CNC spindle object.

6.4 CncChannelListType

6.4.1 General

This OPC UA ObjectType serves as a structuring element. Objects of type CncChannelListType comprise all channels that are subordinated to a CncInterface. It is formally defined in Table 10.

Objects of type CncChannelListType may generate events of type GeneralModelChangeEventType. These events are used to inform about changes in the Information Model related to an instance of CncChannelListType.

6.4.2 ObjectType Definition

The CncChannelListType is formally defined in Table 10.

6.4.3 ObjectType Description

6.4.3.1 GeneralModelChangeEvent

CncChannelListType may generate events of type GeneralModelChangeEventType defined in OPC 10000-3 to inform Clients when CncChannel Objects have been added or removed from a CncChannelListType instance.

6.4.3.2 NodeVersion

The optional Property NodeVersion shall be present if the Server emits GeneralModelChangeEvents for the Object of type CncChannelListType. The NodeVersion Property and the relation to GeneralModelChangeEvents are defined in OPC 10000-3.

6.4.3.3 CncChannel

CNC channel object.

6.5 CncComponentType

6.5.1 General

This OPC UA ObjectType represents a CNC component. A CNC component may be a hardware or software component of a CNC system (e.g. an axis or a channel). CncComponentType serves as a basis for all components that are accessible through this interface, e.g. CncDriveType or CncChannelType are derived from this ObjectType, and therefore is an abstract type. CncComponentType holds elements that are common for all components of a CNC system. It is formally defined in Table 11.

6.5.2 ObjectType Definition

The CncComponentType is formally defined in Table 11.

6.5.3 ObjectType Description

There are currently no components subordinated to this ObjectType. However, this Subtype may have components in the future or can be used for manufacturer specific rules or components.

6.6 CncChannelType

6.6.1 General

This OPC UA ObjectType represents a CNC channel with all its necessary elements. All Objects of Type CncChannelType are listed in the CncChannelList of the CncInterface Object.

Additionally to data that is relevant for a CNC Channel, CncChannelType organizes Objects of type CncAxisType and CncSpindleType. That is to indicate which components are currently administrated by this channel.

Objects of CncChannelType may generate two kinds of events: Events of type CncMessageType and of type GeneralModelChangeEventType.

Events of Type CncMessageType are used to provide channel specific messages that are not an alarm but an uncritical information, e.g. a user created message out of the CNC part program.

Events of type GeneralModelChangeEventType are used to inform about changes in the Information Model. Examples for the need of a model change event:

A CNC channel can administrate a different set of components during runtime, meaning that an axis or a spindle can change its channel affiliation during runtime of the CNC system; for instance this may be the case if one spindle is used in combination with different axis groups.

Spindles allow different kind of operation modes, for instance a spindle can change its mode of operation from speed to position control and therefore has to be represented once as spindle (CncSpindleType) and once as rotational axis (CncAxisType).

Instances of CncChannelType provide the position of the channel’s tool center point in different coordinate systems. Therefore, the following definitions have to be considered:

Tool carrier zero point: The tool carrier zero point is a reference point on the tool carrier as illustrated in Figure 10.

Tool center point: The tool center point of tools for milling operations is usually the intersection of the tool centerline and the lowest positioned cutting tip (edge). For turning operations the tool center point is an imaginary tool point of the cutting insert, because most tools have a cutting edge with a built-in radius. The tool center point of point-to-point tools, such as drills, is the extreme tip of the tool, as measured along the Z axis. Figure 11 and Figure 12 illustrate some common tool center points.

Machine tool coordinate systems: This companion standard refers to two coordinate systems (see Figure 13 for illustration):

Base coordinate system: The base coordinate system (BCS) is a coordinate system defined by the machine tool manufacturer. It has its origin within the machine tool’s zero point M.

Workpiece coordinate system: The workpiece coordinate system (WCS) is a user defined coordinate system and allows considering the clamping position and orientation of a workpiece. It has its origin within the workpiece zero point W.

The coordinate systems are built based on the right-hand-rule, illustrated in Figure 14.

Figure 15 shows an overview for the CncChannelType. It is formally defined in Table 12.

6.6.2 ObjectType Definition

The CncChannelType is formally defined in Table 12.

6.6.3 ObjectType Description

6.6.3.1 CncMessage

CncChannelType may generate events of type CncMessageType to provide channel specific information messages (for instance triggered out of CNC part program).

6.6.3.2 GeneralModelChangeEvent

CncChannelType may generate events of type GeneralModelChangeEventType defined in OPC 10000-3 to inform Clients when CncSpindle or CncAxis Objects have been added or removed from a CncChannelType instance.

6.6.3.3 NodeVersion

The optional Property NodeVersion shall be present if the Server emits GeneralModelChangeEvents for the Object of type CncChannelType. The NodeVersion Property and the relation to GeneralModelChangeEvents are defined in OPC 10000-3.

6.6.3.4 CncAxis

CNC axis object.

6.6.3.5 CncSpindle

CNC spindle object.

6.6.3.6 ActFeedrate

Feedrate actual value.

6.6.3.7 ActJogIncrement

Active JOG increment, i.e. a position increment that is executed with each user jog command. Usually, there are predefined increments given (1/10, 1/100, 1/1000 position increment in the selected physical unit), but a continuous jog mode and a jog mode with variable increment are possible, too. A continuous jog mode is indicated with a jog increment value of -1, all other jog increments are given as real increments in the appropriate units.

6.6.3.8 ActGFunctions

Array of active G functions; there can be several G functions active at a time (modal and non-modal G functions).

6.6.3.9 ActMainProgramFile

Path of active CNC main program.

6.6.3.10 ActMainProgramFileOffset

File offset of active CNC main program file (corresponds to the number of line feeds).

6.6.3.11 ActMainProgramName

Name of active CNC main program.

6.6.3.12 ActMainProgramLine

Line number of active CNC main program (usually defined as N<Number>).

6.6.3.13 ActMFunctions

Array of active M functions: there can be several M functions active at a time (modal and non-modal M functions).

6.6.3.14 ActModalOffsetFunction

Active zero offset function (usually G54, G55, G56 or G57; G53 repeals zero offsets).

6.6.3.15 ActOperationMode

Channel’s active mode of operation. See 7.2.6 for further description of possible states.

6.6.3.16 ActOverride

Axis override actual value.

6.6.3.17 ActProgramBlock

Block of lines containing the previous, actual and subsequent lines of a CNC part program.

6.6.3.18 ActProgramFile

Path of active CNC part program file (main or subprogram).

6.6.3.19 ActProgramFileOffset

File offset of active CNC part program file (main or subprogram).

6.6.3.20 ActProgramLine

Line number of active CNC part program (main or subprogram).

6.6.3.21 ActProgramName

Name of active CNC part program (main or subprogram).

6.6.3.22 ActProgramStatus

Active channel program status. See 7.2.5 for further description of possible states.

6.6.3.23 ActStatus

Active status of channel. See 7.2.4 for further description of possible states.

6.6.3.24 BlockMode

Block mode status (true in case of block mode is active, else false). With block mode active, individual program blocks are processed one by one. Each step has to be triggered by the operator.

6.6.3.25 CmdFeedrate

Feedrate setpoint value.

6.6.3.26 CmdOverride

Override setpoint value.

6.6.3.27 DryRunFeed

Test federate.

6.6.3.28 FeedHold

Feed status (true in case of feed hold active, else false).

6.6.3.29 Id

Unique numeric channel identifier.

6.6.3.30 PosTcpBcsA

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.31 PosTcpBcsB

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.32 PosTcpBcsC

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.33 PosTcpBcsX

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.34 PosTcpBcsY

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.35 PosTcpBcsZ

Actual position of the tool center point in machine’s Cartesian base coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point.

6.6.3.36 PosTcpWcsA

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.37 PosTcpWcsB

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.38 PosTcpWcsC

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.39 PosTcpWcsX

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.40 PosTcpWcsY

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.41 PosTcpWcsZ

Actual position of the tool center point in machine’s Cartesian workpiece coordinate system. The tool center point is the reference point on a tool how it is considered by the CNC’s tool compensation function. If there is no tool present, the tool center point is the tool carrier zero point. Hence, the position corresponds to the position programmed in the CNC part program.

6.6.3.42 ToolId

ID of active tool that has been selected (e.g. calling “T1” in the CNC part program). Returns an empty string, if no tool is present.

6.7 CncDriveType

6.7.1 General

This OPC UA ObjectType represents a CNC drive. It serves as a basis for all drive component Objects that are accessible through this interface, e.g. CncAxisType and CncSpindleType are derived from this ObjectType, and therefore is an abstract type. CncDriveType holds elements that are common for all drive Objects of a CNC system. It is formally defined in Table 13.

6.7.2 ObjectType Definition

The CncDriveType is formally defined in Table 13.

6.7.3 ObjectType Description

6.7.3.1 ActChannel

NodeId of the channel object (CncChannelType) that administrates this drive to expose drive’s channel affiliation. ActChannel remains empty in case of drives without channel affiliation.

6.7.3.2 ActLoad

Drive load actual value.

6.7.3.3 ActPower

Drive power actual value.

6.7.3.4 ActTorque

Drive torque actual value.

6.7.3.5 CmdTorque

Drive torque setpoint value.

6.7.3.6 IsInactive

Drive inactive state (true in case of inactive drive, else false).

6.7.3.7 IsVirtual

Virtual axis (no hardware present; true in case of virtual axis, else false).

6.8 CncAxisType

6.8.1 General

This OPC UA ObjectType represents a CNC axis. CNC axes can be subordinated to channels. They can change channel affiliation during runtime. For that reasons Objects of type CncAxisType may be referenced by Objects of CncChannelType to inform about their current channel affiliation. At the same time all axis Objects of a CNC system must be subordinated to the CncAxisList regardless of their channel affiliation.

Figure 16 shows an overview for the CncAxisType. It is formally defined in Table 14.

6.8.2 ObjectType Definition

The CncAxisType is formally defined in Table 14.

6.8.3 ObjectType Description

6.8.3.1 ActStatus

Actual axis state.

6.8.3.2 IsReferenced

Axis reference state (true in case of successfully referenced axis, else false).

6.8.3.3 IsRotational

Axis type (true in case of rotational axis, in case of linear type or other false).

6.8.3.4 PosDirect

Axis position values referring to axis' direct measurement system.

6.8.3.5 PosIndirect

Axis position values referring to axis' indirect measurement system.

6.8.3.6 ZeroOffset

Active axis zero offset.

6.9 CncSpindleType

6.9.1 General

This OPC UA ObjectType represents a CNC spindle. CNC spindles can be subordinated to channels. They can change channel affiliation during runtime. For that reasons Objects of type CncSpindleType may be referenced by Objects of CncChannelType to inform about their current channel affiliation. At the same time all spindle Objects of a CNC system must be subordinated to the CncSpindleList regardless of their channel affiliation.

Figure 17 shows an overview for the CncSpindleType. It is formally defined in Table 15.

6.9.2 ObjectType Definition