7 OPC UA ObjectTypes

7.1 MotionDeviceSystemType ObjectType Definition

7.1.1 Overview

The MotionDeviceSystemType provides a representation of a motion device system as an entry point to the OPC UA device set. At least one instance of a MotionDeviceSystemType must be instantiated in the DeviceSet. This instance organises the information model of a complete robotics system using instances of the described ObjectTypes. The MotionDeviceSystemType is formally defined in Table 11.

7.1.2 MotionDeviceSystemType definition

The components of the MotionDeviceSystemType have additional subcomponents which are defined in Table 12.

A motion device system may consist of multiple motion devices, controllers, and safety systems. References are used to describe the relations between those subsystems. Examples are described in Annex B.

The ComponentName property provides a user writeable name provided by the vendor, integrator, or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC 10000-100.

MotionDevices is a container for one or more instances of the MotionDeviceType.

Controllers is a container for one or more instances of the ControllerType.

SafetyStates is a container for one or more instances of the SafetyStatesType.

7.2 MotionDeviceType ObjectType Definition

7.2.1 Overview

The MotionDeviceType describes one independent motion device, e.g. a manipulator, a turn table, or a linear axis. Examples are described in Annex B.

A MotionDevice shall have at least one axis and one power train. The MotionDeviceType is formally defined in 7.2.2

7.2.2 MotionDeviceType definition

The components of the MotionDeviceType have additional subcomponents which are defined in Table 14.

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC 10000-100.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC 10000-100.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. It contains typically an identifier in a branch, use case or user specific naming scheme. This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used. A use case could be to build up a location-oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used. This property is defined by ComponentType defined in OPC 10000-100.

The DeviceManual property allows specifying an address of the user manual for the device. It may be a pathname in the file system or a URL (Web address). This property is defined by ComponentType defined in OPC 10000-100.

The ComponentName property provides a user writeable name provided by the vendor, integrator, or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC 10000-100.

FlangeLoad provides data for the load at the flange or mounting point of the motion device.

The variable MotionDeviceCategory provides the kind of motion device defined by MotionDeviceCategoryEnumeration based on ISO 8373 (10.1).

The Variable TaskControlReference provides a NodeId pointing to the instance of TaskControlOperationType defined in 7.15, which controls this motion device in combination with the loaded program.

Description of ParameterSet of MotionDeviceType:

Variable OnPath: The variable OnPath is true if the motion device is on or near enough the planned program path such that program execution can continue. If the MotionDevice deviates too much from this path in case of errors or an emergency stop, this value becomes false. If OnPath is false, the motion device needs repositioning to continue program execution.

Variable InControl: The variable InControl provides the information if the actuators (in most cases a motor) of the motion device are powered up and in control: "true". The motion device might be in a standstill.

Variable SpeedOverride: The SpeedOverride provides the current speed setting in percent of programmed speed (0 - 100%).

Axes is a container for one or more instances of the AxisType (7.3).

PowerTrains is a container for one or more instances of the PowerTrainType.

AdditionalComponents is a container for one or more instances of any other ObjectType (any subtype of 0:BaseObjectType). The listed components are installed at the motion device, e.g. an IO-board.

NOTE: Components like motors or gears of a motion device are placed inside the power train object and not inside this AdditionalComponents container. The intention of this folder is to integrate devices which are defined in companion specifications that use OPC 10000-100 ComponentType. From this specification, only instances of AuxiliaryComponentType and DriveType can be used in this container.

7.3 AxisType ObjectType Definition

7.3.1 Overview

The AxisType describes an axis of a motion device. It is formally defined in Table 15.

7.3.2 AxisType definition

The components of the AxisType have additional subcomponents which are defined in Table 16.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. It contains typically an identifier in a branch, use case or user specific naming scheme. This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used. The AssetId of the AxisType provides a manufacturer-specific axis identifier within the control system. This property is defined by ComponentType defined in OPC 10000-100.

The MotionProfile property provides the kind of axis motion as defined by the AxisMotionProfileEnumeration (10.2)

AdditionalLoad provides data for the load that is mounted on this axis, e.g., a transformer for welding.

The Requires reference provides the relationship of axes to power trains. For complex kinematics this does not need to be a one-to-one relationship, because more than one power train might influence the motion of one axis. This reference connects all power trains to an axis that must be actively driven when only this axis should move and all other axes should stand still.

Virtual axes that are not actively driven by a power train do not have this reference. The InverseName is IsRequiredBy.

Description of ParameterSet of AxisType:

Variable ActualPosition: The ActualPosition variable provides the current position of the axis and may have limits. If the axis has physical limits, the EURange property of the AnalogUnitType shall be provided.

Variable ActualSpeed: The ActualSpeed variable provides the axis speed. Applicable speed limits of the axis shall be provided by the EURange property of the AnalogUnitType.

Variable ActualAcceleration: The ActualAcceleration variable provides the axis acceleration. Applicable acceleration limits of the axis shall be provided by the EURange property of the AnalogUnitType.

7.4 PowerTrainType ObjectType Definition

7.4.1 Overview

A power train typically consists of one motor and gear to provide the required torque. Often there is a one-to-one relation between axes and power trains, but it is also possible to have axis coupling and thus one power train can move multiple axes and one axis can be moved by multiple power trains. One power train can have multiple drives, motors, and gears when these components move logically the same axes, for example in a master/slave setup. Examples are described in Annex B. The PowerTrainType represents instances of power trains of a motion device and is formally defined in

Table 17.

7.4.2 PowerTrainType definition

The ComponentName property provides a user writable name provided by the vendor, integrator, or user of the device. The ComponentName may be a default name given by the vendor.

The ComponentName of the PowerTrainType provides a manufacturer-specific power train identifier within the control system.

This property is defined by ComponentType defined in OPC 10000-100.

<MotorIdentifier> indicates that a power train contains one or more motors represented by MotorType instances.

The IsConnectedTo ReferenceType defined in 8.6 is intended to provide the relationship between a motor and a gear of a power train.

<GearIdentifier> indicates that a power train may contain one or more gears represented by GearType instances.

The IsConnectedTo ReferenceType defined in 8.6 is intended to provide the relationship between a motor and a gear of a power train.

Moves is a reference to provide the relationship of power trains to axes. For complex kinematics this does not need to be a one-to-one relationship, because a power train might influence the motion of more than one axis. This reference connects all axis to a power train that that move when only this power train moves and all other powertrains stand still. The InverseName is IsMovedBy.

HasSlave is a reference to provide the master-slave relationship of power trains which provide torque for a common axis. The InverseName is IsSlaveOf.

7.5 MotorType ObjectType Definition

7.5.1 Overview

The MotorType describes a motor in a power train. It is formally defined in Table 18.

7.5.2 MotorType definition

The components of the MotorType have additional subcomponents which are defined in Table 19.

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC 10000-100.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC 10000-100.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

A use case could be to build up a location-oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC 10000-100.

IsDrivenBy is a reference to provide a relationship from a motor to a drive, which can be a multi-slot-drive or single slot drive. The TypeDefinition of the reference destination as BaseObjectType provides the possibility to point to a slot of a multi-slot-drive or a motor-integrated-drive. If this reference points to a physical drive (and not a drive slot) it should point to an DriveType.

Annex B.10 shows different possibilities of usage.

Description of ParameterSet of MotorType:

Variable BrakeReleased: The BrakeReleased is an optional variable used only for motors with brakes. If BrakeReleased is TRUE the motor is free to run. FALSE means that the motor shaft is locked by the brake.

Variable MotorTemperature: The MotorTemperature provides the temperature of the motor. If there is no temperature sensor the value is set to “null”.

Variable EffectiveLoadRate: EffectiveLoadRate is expressed as a percentage of maximum continuous load. The Joule integral is typically used to calculate the current load, i.e.:

7.6 GearType Definition

7.6.1 Overview

The GearType describes a gear in a power train, e.g. a gear box or a spindle. It is formally defined in Table 20.

7.6.2 GearType definition

In case of a one-to-one relation between powertrains and axes, gear ratio and pitch may reflect the relation between motor and axis velocities. This is not possible when axis coupling is involved because different ratios for all motor-axis combinations may be needed. Additionally, there could be a nonlinear coupling between the load side of the gear box and the axis. Thus, GearRatio and Pitch only reflect the properties of the physical gear box and it may not be possible to use these values to transform between axis and motor movements.

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC 10000-100.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC 10000-100.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. It contains typically an identifier in a branch, use case or user specific naming scheme. This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used. A use case could be to build up a location-oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used. This property is defined by ComponentType defined in OPC 10000-100.

GearRatio is the transmission ratio of the gear expressed as a fraction as input velocity (motor side) by output velocity (load side).

Pitch describes the distance covered in millimetres (mm) for linear motion per one revolution of the output side of the driving unit. Pitch is used in combination with GearRatio to describe the overall transmission from input to output of the gear.

Calculation formula:

7.7 SafetyStateType ObjectType Definition

7.7.1 Overview

SafetyStateType describes the safety states of the motion devices and controllers. One motion device system is associated with one or more instances of the SafetyStateType.

The SafetyStateType was modelled directly in the MotionDeviceSystemType for the following reasons:

The manufacturers of systems have different concepts where safety is functional located, e.g. the hardware and software implementation.

The safety state typically applies to the entire robotic system. If multiple safety state instances are implemented in robotic systems, these can be represented by individual instances of the SafetyStateType and associated with the controller by reference.

The safety state is for informational purpose only and not intended for use with functional safety applications as defined in IEC 61508.

The SafetyStateType is formally defined in Table 21.

7.7.2 SafetyStateType definition

The ComponentName property provides a user writable name provided by the vendor, integrator, or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC 10000-100.

EmergencyStopFunctions is a container for one or more instances of the EmergencyStopFunctionType. The number and names of emergency stop functions is vendor specific. When provided, this object contains a list of all emergency stop functions with names and current state. See description of EmergencyStopFunctionType for examples of emergency stop functions.

ProtectiveStopFunctions is a container for one or more instances of the ProtectiveStopFunctionType. The number and names of protective stop functions is vendor specific. When provided, this object contains a list of all protective stop functions with names and current state. See description of ProtectiveStopFunctionType for examples of protective stop functions.

Description of ParameterSet of SafetyStateType:

The OperationalMode variable provides information about the current operational mode. Allowed values are described in OperationalModeEnumeration (10.4).

The EmergencyStop variable is TRUE if one or more of the emergency stop functions in the robot system are active, FALSE otherwise. If the EmergencyStopFunctions object is provided, then the value of this variable is TRUE if one or more of the listed emergency stop functions are active.

The ProtectiveStop variable is TRUE if one or more of the enabled protective stop functions in the system are active, FALSE otherwise. If the ProtectiveStopFunctions object is provided, then the value of this variable is TRUE if one or more of the listed protective stop functions are enabled and active.

7.8 EmergencyStopFunctionType ObjectType Definition

7.8.1 Overview

According to ISO 10218-1:2011 Ch.5.5.2 Emergency stop, the robot shall have one or more emergency stop functions. This shall be done with the help of the EmergencyStopFunctionType is defined in Table 23.

7.8.2 EmergencyStopFunctionType definition

The Name of the EmergencyStopFunctionType provides a manufacturer-specific emergency stop function identifier within the safety system. The only named emergency stop function in the ISO 10218-1:2011 standard is the "Pendant emergency stop function". Other than that, the standard does not give any indication on naming of emergency stop functions.

The Active variable is TRUE if this emergency stop function is active, e.g. that the emergency stop button is pressed, FALSE otherwise.

7.9 ProtectiveStopFunctionType ObjectType Definition

7.9.1 Overview

According to ISO 10218-1:2011 Ch.5.5.3 the robot shall have one or more protective stop functions designed for the connection of external protective devices. This type is formally defined in Table 24

7.9.2 ProtectiveStopFunctionType definition

The Name of the ProtectiveStopFunctionType provides a manufacturer-specific protective stop function identifier within the safety system.

The Enabled variable is TRUE if this protective stop function is currently supervising the system, FALSE otherwise. A protective stop function may or may not be always enabled, e.g. the protective stop function of the safety doors is typically enabled in automatic operational mode and disabled in manual mode. On the other hand, for example, the protective stop function of the teach pendant enabling device is enabled in manual modes and disabled in automatic modes.

The Active variable is TRUE if this protective stop function is active, i.e. that a stop is initiated, FALSE otherwise. If Enabled is FALSE then Active shall be FALSE.

Examples

The table below shows an example with a door interlock function. In this example, the door is only monitored during automatic modes. During manual modes, the operators may open the door without causing a protective stop.

The next example shows how the three-position enabling device normally found on teach pendants is processed. In this case it does not matter if the enabling device is pressed or not during automatic modes, while in manual modes, a protective stop is active if the enabling device is released or fully pressed.

7.10 OperationStateMachineType Definition

The OperationStateMachineType provides an abstract state machine for operation. The state machine can be used for entities whose states can be represented by Idle, Ready or Executing and which can be started and stopped.

At the system and task control levels, concrete state machine types are derived from the OperationStateMachineType. The states of these state machines can be further enhanced with Substate machines.

The overview of the state machine with all transitions is shown in Figure 19.

Figure 20 shows the OPC UA representation of the OperationStateMachineType, the transitions between the states have not been shown for the sake of simplicity. The OperationStateMachineType is formally defined in Table 65.

The states of the OperationStateMachineType are described in Table 28.

The component Variables of the OperationStateMachineType have additional Attributes defined in Table 30.

The Variable LastTransitionReason provides the reason for the LastTransition. The EnumValue and ValueAsText of this 0:MultiStateValueDiscreteType are described in Table 29. This specification does not define an explicit error state. The LastTransitionReason indicates if a state change was caused due to an error.

The component Variables of the OperationStateMachineType have additional Attributes defined in Table 30.

LastTransitionReason EnumValues 1 and 2 describe where an operation was initiated, which reasoned the last transition. External means that the operation was initiated by a control station, which is not part of the robot system, e.g a cell PLC. Direct means that the operation was initiated by a control station, which is part of the robot system, e.g. the teach pendant.

The Variable PossibleStopModes is an array of EnumValueType, which contains a list of supported stop modes (see Table 31).

The Variable ConfiguredDefaultStopMode is an integer, which contains the value of the configured stop mode for this system. This shall be one of the values in the PossibleStopModes array.

The Variable LastTransition, inherited from the FiniteStateMachineType, is defined as mandatory in the OperationStateMachineType.

The transitions of the OperationStateMachineType are described in Table 33.

The components of the OperationStateMachineType have additional references which are defined in Table 69.

The component Variables of the OperationStateMachine have additional Attributes defined in the table below.

7.10.1 Start Method

The signature of this Method is specified below.

Signature

	Start (
	[out]	0:Int32	Status
	);

The Start Method is called by a Client to start execution of the entity which is represented by the state machine.

The possible Method result codes are formally defined in Table 37.

The Start Method representation in the AddressSpace is formally defined in table below.

7.10.2 Stop Method

The signature of this Method is specified below.

Signature

	Stop (
	[in]	0:Int64 	StopMode
	[out]	0:Int32	Status
	);

The Stop Method is called by a Client to stop execution of the entity which is represented by the state machine.

The possible Method result codes are formally defined in Table 40.

The Stop Method representation in the AddressSpace is formally defined in the table below.

7.11 SystemOperationType ObjectType

7.11.1 Overview

The SystemOperationType is an AddIn Type to extend instances of ControllerType described in 7.18. The SystemOperationType provides a state machine to monitor and/or command the controller behaviour at the system level and is formally defined in Table 42.

Robot systems may have conditions that must be acknowledged before some operational commands can be executed.

The system has two possibilities to enable the Client to acknowledge conditions.

By exposing at least one instance of AcknowledgeableConditionType inside the Server’s AddressSpace located within the Conditions folder as defined in the ConformanceUnit RobAckCondInstance.

By handling such conditions using the OPC UA Eventing mechanisms as defined in the ConformanceUnit RobAckCondEventing.

7.11.2 SystemOperationType definition

The SystemOperationType is formally defined in Table 42.

The Object SystemOperationStateMachine provides a state machine to monitor or command the controller at the system level. The SystemOperationStateMachineType is inherited from the OperationStateMachineType.

The folder Conditions (part of the ConformanceUnit RobAckCondInstance) provides instances of AcknowledgeableConditionType for the acknowledgement of single conditions or instances of MultiAcknowledgeableConditionType (see 8.1) for the acknowledgement of multiple conditions.

The Property 0:DefaultInstanceBrowseName of the SystemOperationType has an additional Attribute defined in

Table 44.

7.12 SystemOperationStateMachineType

The SystemOperationStateMachineType represents the behaviour of a controller at the system level and can be used for monitoring and for external or direct operation. In robot systems, a distinction is typically made between external and direct operation, depending on the OperationalMode (see 7.7.2).

If the system takes a significant amount of time to transition from the Idle State to the Ready State, the Idle State can be extended by the sub state machine IdleSubstateMachine. Alternatively, a vendor/application specific Substate machine may also be used.

For certain stop modes, the transition from the Executing State to the Ready State can take a significant amount of time. In such cases, the Executing State can be extended by the sub state machine ExecutingSubstateMachine. Alternatively, an application or vendor specific Substate machine may also be used.

The Substate machines enable the client to get more information during the transition.

The SystemMonitor Server Facet supports monitoring of the activities performed by the operator or system internally. (e.g. monitor condition changes and base causes) The SystemOperation Server Facet extends on the SystemMonitor Server Facet and adds support to operate the system.

The overview of the SystemOperationStateMachine with the IdleSubstateMachine as Substate machine of Idle State and the ExecutingSubstateMachine as Substate machine of Executing State with all transitions is shown in Figure 8.

The transitions in this state machine can occur due to internal processes of the system or they may be triggered by a method call. In case the transition is triggered by a method call, the transition might not occur immediately (e.g. it will be delayed until internal conditions are met).

The SystemOperationStateMachineType is formally defined in Table 45.

The Idle State of SystemOperationStatemachineType has additional subcomponents which are defined in Table 46

To acknowledge the state changes in a system the Conditions within the Conditions folder of SystemOperationType must be taken under consideration. A client might need to acknowledge them so that the robot system can be activated. (e.g. operational mode change requires acknowledgement to start the system)

The components of the SystemOperationStateMachineType have additional references which are defined in the table below.

The component Variables of the SystemOperationStateMachineType have additional Attributes defined in the table below.

7.12.1 Start Method

The signature of this Method is specified below.

Signature

	Start (
	[out]	0:Int32	Status
	);

The Start Method is called by a Client to start execution of the system that is represented by the state machine. If the method is successfully called, the method should return with a Good or Uncertain result code.

The Start Method allows an authorized Client to command the system to the Executing State.

The possible Method result codes are formally defined in Table 52

The Start Method representation in the AddressSpace is formally defined in Table 53.

7.12.2 Stop Method

The signature of this Method is specified below.

Signature

	Stop (
	[in]	0:Int64 	StopMode
	[out]	0:Int32	Status
	);

The Stop Method allows an authorized Client to command the system to stop executing and leave the Executing state.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Executing state (e.g. the ExecutingSubstateMachine in 7.14)

The input argument StopMode must be either 0 or one of those listed in the PossibleStopModes Variable (see Table 31). If not, then a Bad_InvalidArgument Result Code is returned.

The possible Method result codes are formally defined in Table 55

The Stop Method representation in the AddressSpace is formally defined in Table 56

7.12.3 GetReady Method

The signature of this Method is specified below.

Signature

	GetReady (
	[out]	0:Int32	Status
	);

The GetReady Method allows an authorized Client to request the system to transition from the Idle state to the Ready state. Internally the system prepares to get started in the next step (e.g. switching on the intermediate circuit). If the internal preparations for this transition are successful, the system will transition from Idle to Ready. If the internal preparations are unsuccessful then the IdleToIdle transition occurs.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Idle state (e.g. the IdleSubstateMachine in 7.13)

The possible Method result codes are formally defined in Table 58

The Start Method representation in the AddressSpace is formally defined in Table 59.

7.12.4 StandDown Method

The signature of this Method is specified below.

Signature

	StandDown (
	[out]	0:Int32	Status
	);

The StandDown method allows an authorized Client to request the system to:

transition from the Ready state to the Idle state or

cancel an ongoing preparation of the system and causes the IdleToIdle transition.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Idle state (e.g. the IdleSubstateMachine in 7.13)

The possible Method result codes are formally defined in Table 61.

The StandDown Method representation in the AddressSpace is formally defined in Table 62.

7.13 IdleSubstateMachineType

The IdleSubstateMachineType, a Substate machine of the Idle State of the SystemOperationStateMachine, represents a mechanism to prepare a system in a way that it will reach Ready State of the SystemOperationStateMachine after preparation.

The overview of the IdleSubstateMachine with all transitions is shown in Figure 24.

Figure 24 – IdleSubstateMachine

7.13.1 Overview

Figure 25 – IdleSubstateMachineType Overview

The IdleSubstateMachineType is formally defined in Table 63.

The Variable LastTransitionReason provides the reason for the LastTransition. The EnumValue and ValueAsText of this 0:MultiStateValueDiscreteType are described in the table below.

Table 64 – IdleSubstateMachineType Attribute values for child nodes

The states of the IdleSubstateMachineType are described in Table 65.

Table 65 – IdleSubstateMachineType State Descriptions

The transitions are described in .

Table 66 – IdleSubstateMachineType Transition Descriptions

The components of the IdleSubstateMachineType have additional references which are defined in Table 67.

The component Variables of the IdleSubstateMachineType have additional Attributes defined in Table 68.

7.14 ExecutingSubstateMachineType

The ExecutingSubstateMachineType, a Substate machine of Executing State of the SystemOperationStateMachine, represents a mechanism for describing the stopping behaviour of the system. This can be used to display the stopping behaviour in more detail depending on the StopMode commanded.

The overview of the ExecutingSubstateMachine with all transitions is shown in Figure 8.

Figure 26 – ExecutingSubstateMachine

7.14.1 Overview

Figure 27 – ExecutingSubstateMachineType Overview

The ExecutingSubstateMachineType is formally defined in the table below.

The Variable LastTransitionReason provides the reason for the LastTransition. The EnumValues of this 0:MultiStateValueDiscreteType are described in Table 70.

Table 70 – ExecutingSubstateMachineType Attribute values for child nodes

The states of the ExecutingSubstateMachineType are described in Table 71.

Table 71 – ExecutingSubstateMachineType State Descriptions

The transitions are described in .

Table 72 – ExecutingSubstateMachineType Transition Descriptions

The components of the ExecutingSubstateMachineType have additional references which are defined in the table below.

The component Variables of the IdleSubstateMachineType have additional Attributes defined in the table below.

7.15 TaskControlOperationType ObjectType

The TaskControlOperationType is an AddIn to extend instances of TaskControlType described in 7.21. It provides the possibility to handle programs with designated task controls. The task controls may be started manually or in a system context by use of SystemOperation.

The TaskControlOperationType provides a state machine to monitor or control a task control and information about which motion devices are controlled by this task control and is formally defined in Table 63.

7.15.1 Overview

The optional Variable MotionDevicesUnderControl provides an array of NodeIds pointing to instances of MotionDeviceType described in 7.2, which are under control of this task control, in combination with the loaded program.

The Object TaskControlStateMachine provides a state machine to monitor or to control the task controls which instantiated the TaskControlOperationType.

The Property 0:DefaultInstanceBrowseName of the TaskControlOperationType has an additional Attribute defined in Table 64.

7.16 TaskControlStateMachineType

The TaskControlStateMachineType represents the behaviour of a task control and can be used for monitoring or for remote control.

To provide information about the condition of a program loaded inside a task control and the possibility to reset the loaded program the Ready State can be extended by the ReadySubstateMachineType.

The Task Control Monitor ConformanceUnit supports monitoring of the activities done by the operator or system internally. The Task Control Operation ConformanceUnit supports additional operations by Methods.

The overview of the state machine with all transitions is shown in

When the state machine changes from Executing State to Ready State caused by internal behaviour of the task control (e.g. because program is ended) it is expected that the task control can be started immediately again e.g. by the Start() method. So, the application may set the loaded program to its entry point (like the ResetToProgramStart() Method) while transition ExecutingToReady or when the Start() Method is called, that no additional reset of the program is needed.

Figure 29 – TaskControl State Machine with ReadySubstateMachine in Ready State

7.16.1 Overview