Here’s a list of commonly used CANopen objects, along with their standard object indexes, names, data types, and access permissions according to CiA standards (mainly CiA 301 and CiA 402 profiles). These objects are part of the *CANopen Object Dictionary* and are widely adopted in CANopen networks for device configuration and communication. ### Common CANopen Objects | Index | Object Name | Data Type | Access | Description | |---------|---------------------------------|-----------|------------|---------------------------------------------| | `0x1000`| **Device Type** | `uint32` | Read Only | Specifies the type of the CANopen device. | | `0x1001`| **Error Register** | `uint8` | Read Only | General error flags (e.g., hardware error). | | `0x1002`| **Manufacturer Status Register**| `uint32` | Read Only | Device-specific status information. | | `0x1003`| **Pre-defined Error Field** | Array | Read/Write | Stores historical error codes. | | `0x1005`| **COB-ID Sync Message** | `uint32` | Read/Write | CAN ID for the SYNC message. | | `0x1006`| **Communication Cycle Period** | `uint32` | Read/Write | Time period for SYNC messages. | | `0x1007`| **Synchronous Window Length** | `uint32` | Read/Write | Time window for SYNC-dependent data. | | `0x1010`| **Store Parameters** | Array | Read/Write | Commands to store parameters to non-volatile memory. | | `0x1011`| **Restore Default Parameters** | Array | Read/Write | Commands to reset parameters to defaults. | | `0x1014`| **COB-ID Emergency** | `uint32` | Read/Write | CAN ID for the emergency message. | | `0x1017`| **Producer Heartbeat Time** | `uint16` | Read/Write | Heartbeat interval produced by the device. | | `0x1018`| **Identity Object** | Record | Read Only | Information about device vendor, product code, revision, serial number. | | `0x1029`| **Error Behavior** | Array | Read/Write | Specifies behavior when errors occur. | | `0x1200`| **Server SDO Parameter** | Record | Read/Write | Parameters for the first SDO channel. | | `0x1400`| **Receive PDO Communication Parameter** | Record | Read/Write | Parameters for the first RPDO communication.| | `0x1600`| **Receive PDO Mapping Parameter** | Record | Read/Write | Mapping for the first RPDO. | | `0x1800`| **Transmit PDO Communication Parameter** | Record | Read/Write | Parameters for the first TPDO communication.| | `0x1A00`| **Transmit PDO Mapping Parameter** | Record | Read/Write | Mapping for the first TPDO. | | `0x2000`–`0x5FFF` | **Manufacturer-Specific Objects** | Varies | Varies | Reserved for device-specific functions. | | `0x6000`–`0x9FFF` | **Standardized Device Profile Area** | Varies | Varies | Reserved for standardized profiles, e.g., CiA 402. | ### Notable CANopen Device Profile (CiA 402) Objects | Index | Object Name | Data Type | Access | Description | |---------|---------------------------------|-----------|------------|---------------------------------------------| | `0x6060`| **Modes of Operation** | `int8` | Read/Write | Selects operating mode of the drive. | | `0x6061`| **Modes of Operation Display** | `int8` | Read Only | Current operating mode of the drive. | | `0x6064`| **Position Actual Value** | `int32` | Read Only | Current position in encoder counts or other units. | | `0x607A`| **Target Position** | `int32` | Read/Write | Sets the desired position for the drive. | | `0x607D`| **Software Position Limit** | Record | Read/Write | Sets the limits for the drive position. | | `0x6081`| **Profile Velocity** | `uint32` | Read/Write | Sets the maximum velocity in profile mode. | | `0x6083`| **Profile Acceleration** | `uint32` | Read/Write | Sets the acceleration in profile mode. | | `0x6084`| **Profile Deceleration** | `uint32` | Read/Write | Sets the deceleration in profile mode. | | `0x60FF`| **Target Velocity** | `int32` | Read/Write | Sets the velocity for velocity mode. | | `0x6040`| **Controlword** | `uint16` | Read/Write | Control commands for drive operation. | | `0x6041`| **Statusword** | `uint16` | Read Only | Status feedback from the drive. | ### Notes: - **Access Rights**: `Read/Write`, `Read Only`, or `Write Only` determine the permissions for each entry. - **Data Types**: `uint32`, `uint16`, `int8`, `int32`, etc., indicate the expected data type. - **Object Types**: - **Variable**: A single value (e.g., `0x6060` Modes of Operation). - **Array**: A list of values (e.g., `0x1003` Pre-defined Error Field). - **Record**: A structured data group (e.g., `0x1018` Identity Object). This list provides an overview of typical entries you can use to structure your `MechObjectDictionary` to follow CANopen standards. These objects serve various functions, including device information, error handling, SYNC and PDO communications, and control commands in motion profiles (particularly with CiA 402 devices). The **Device Type** object at index `0x1000` in a CANopen object dictionary is a standardized, read-only entry that describes the type and capabilities of a CANopen device. This information is essential for configuring and identifying devices within a CANopen network, as it allows other devices or network managers to recognize what type of device is connected and what functionality it may offer. ### Details of 0x1000 Device Type | Field | Value/Description | |-------------------|--------------------------------------------| | **Index** | `0x1000` | | **Object Name** | Device Type | | **Data Type** | `uint32` | | **Access** | Read Only | | **Description** | Provides information about the device’s type and profile.| ### Structure of 0x1000 (Device Type) The `Device Type` object uses a 32-bit unsigned integer (`uint32`) to encode the primary information about the device. This value is structured as follows, with specific bits or ranges indicating different categories: 1. **Bits 31–16**: **Device Profile Number** - This field typically identifies the type of device and the application profile to which it conforms. The profile number is standardized by the CiA (CAN in Automation) association. Here are some common values: - `0x401` (CiA 401) - Generic I/O devices - `0x402` (CiA 402) - Drives and motion control devices - `0x406` (CiA 406) - Encoders - `0x40A` (CiA 410) - Measuring devices - `0x40C` (CiA 404) - Position sensors 2. **Bits 15–8**: **Device Subclass** - This field may be used to identify subcategories or specific types within the broader profile type. Subclasses are profile-dependent, and their meaning can vary. For example, in CiA 401, this field could specify if the device is a digital I/O, analog I/O, etc. 3. **Bits 7–0**: **Device Specific Field** - The specific usage of these bits can be manufacturer-specific, providing more detailed information about device characteristics. For instance, a drive device may use these bits to indicate the supported control modes or feedback mechanisms (e.g., torque mode, speed mode, or position mode for CiA 402 devices). ### Example Values for `0x1000` Below are some examples of what the `0x1000` Device Type value might look like for different types of devices: | Device Type | Profile Number (Bits 31-16) | Example Value (`0x1000`) | |-----------------------------|-----------------------------|---------------------------| | **Generic I/O Device** | `0x401` (CiA 401) | `0x00040100` | | **Drive (Position Control)**| `0x402` (CiA 402) | `0x00040201` | | **Encoder** | `0x406` (CiA 406) | `0x00040600` | | **Measuring Device** | `0x40A` (CiA 410) | `0x00040A00` | For example, a value of `0x00040200` in `0x1000` would indicate: - **Device Profile Number**: `0x402` (Drive and Motion Control) - **Device Subclass**: `0x00` - **Device-Specific Field**: `0x00` (no additional characteristics indicated) ### Why the Device Type (0x1000) is Important 1. **Device Identification**: The Device Type helps distinguish devices on the network, ensuring compatibility and interoperability. 2. **Standardization**: By conforming to CANopen profiles (such as CiA 401 or CiA 402), devices provide consistent behavior, which simplifies integration in diverse applications. 3. **Device Configuration**: Knowing the type and capabilities allows for automatic configuration and validation of devices on the CANopen network, such as configuring PDOs (Process Data Objects) and SDOs (Service Data Objects) according to the device’s profile. The `0x1000` Device Type is one of the core entries in a CANopen object dictionary, enabling devices to advertise their type and capabilities while maintaining the flexibility for specific manufacturer requirements. For devices that are software-only or non-standard/custom objects, CANopen allows flexibility through **manufacturer-specific identifiers** and **reserved ranges** that enable custom device classifications outside of strict CiA profile definitions. ### Device Type for Software Objects Software objects don’t directly correspond to physical hardware profiles, so their `Device Type (0x1000)` would typically not adhere to the hardware-centric profiles (like CiA 402 for motion control). Instead, they can be assigned to **manufacturer-specific object ranges** or **reserved categories**. 1. **Use of Manufacturer-Specific Range (`0x2000–0x5FFF`)**: - For a software-only device, manufacturers often assign a `Device Type` using values in the **manufacturer-specific range** of `0x2000–0x5FFF` within the CANopen object dictionary. - This range is designed specifically for device-specific functions or software-only objects that don’t require a standard profile like CiA 401 or CiA 402. 2. **Device Type Value**: - For example, setting `Device Type` to a value in this range, such as `0x2001`, could identify a custom software object without physical hardware characteristics. - Manufacturers typically document these custom device types to ensure consistency across deployments. ### Device Type for Custom or Non-Standard Devices For devices that don’t fit into any standard CiA profile but are still hardware-based, or for devices with unique functionality, a similar approach applies. 1. **Reserved Range (`0x6000–0x9FFF`)**: - The **reserved range** `0x6000–0x9FFF` is available for custom device profiles or future standard profiles not yet defined by CiA. - This range can serve as an interim classification for non-standard devices until they’re standardized or further profiled. 2. **Manufacturer-Specific Device Types**: - Within this reserved range, values can be assigned to devices that don’t align with existing profiles but have specialized functions. For example: - **0x6000** might be assigned to a non-standard robotic arm that doesn’t fully follow CiA 402. - **0x6001** could be for a specialized sensor with additional capabilities outside CiA 406. - These custom classifications are typically internal or proprietary, so they’re best documented for use within specific systems or custom CANopen networks. ### Example Device Type Values for Software or Custom Devices | Device Type | Device Type Value (`0x1000`) | Description | |----------------------|------------------------------|--------------------------------------------------| | **Custom Software** | `0x2001` | Software object, no physical hardware component. | | **Non-Standard Device** | `0x6000` | Custom hardware device, e.g., unique sensor. | | **Extended Function Device** | `0x6001` | Hardware device with custom, non-standard behavior. | ### Summary For **software-only devices**, values in the manufacturer-specific range (`0x2000–0x5FFF`) are commonly used. For **custom or non-standard hardware devices**, values in the reserved range (`0x6000–0x9FFF`) are available. These ranges enable custom classifications outside of CiA profiles, allowing flexibility for devices with unique or specialized capabilities.