The object dictionary is the heart of every CANopen device: a structured table that holds all of the device's settings, data and capabilities in one addressable place. Every entry is reached by a sixteen-bit index and an eight-bit subindex, so any parameter, from a communication setting to a live measurement, has a precise address. The dictionary is organised into areas for communication parameters, manufacturer-specific data and standardised device-profile objects. An accompanying EDS file documents what a particular device's dictionary contains, and understanding that layout is what tells you which objects a gateway can actually read up into a SCADA system.
CANopen object dictionary in one line: A CANopen object dictionary is the structured table inside every CANopen node that holds all of its communication, manufacturer-specific and device-profile parameters. Each entry is addressed by a sixteen-bit index and an eight-bit subindex, giving every value a unique location. The device's EDS file documents which entries exist, and reading the object dictionary is how a controller or gateway accesses a node's configuration and data.
The object dictionary is best pictured as a big, well-organised table. Every row has an address made of two parts: a sixteen-bit index that identifies the object, and an eight-bit subindex that selects a component within it. A simple value lives at a single index with subindex zero, while a more complex object, such as an array or a record with several fields, uses the same index with different subindices to reach each element. This two-level addressing is what lets a device expose everything from a single scalar to a structured block in a consistent way.
The dictionary is divided into ranges that group similar objects together. One range holds communication-related parameters, the settings that govern how the node talks on the bus. Another range is reserved for manufacturer-specific objects, where a vendor can expose whatever custom data and settings their device needs. Further ranges hold standardised device-profile objects, which define common meanings for particular device types so that similar devices from different makers expose comparable information in comparable places.
This organisation is deliberate and valuable. Because the address ranges are standardised, a controller or tool that knows CANopen can find the communication settings of any node in the expected place, regardless of who made it. At the same time, the manufacturer range gives room for device-specific richness. The result is a table that is both predictable in its common parts and flexible in its specialised parts, and every single element in it has a definite index-and-subindex address you can point to.
The communication area of the object dictionary contains the parameters that shape how the node participates on the network. This is where the objects that define messaging behaviour live, including the settings that control how process data is transmitted and how the node is identified and monitored. When you configure how a node communicates, you are almost always writing to entries in this part of the dictionary, so it is the region a commissioning engineer touches to get a node talking correctly.
The manufacturer-specific area is where a device's individuality shows up. A drive might expose detailed motor parameters here, a sensor might expose calibration data, and an I/O module might expose channel configuration that no generic profile could anticipate. Because this area is reserved for the vendor, its contents vary from device to device, and it is exactly where you look when a device offers useful data that is not part of any standard profile. The EDS file is essential for making sense of this area, since only the manufacturer knows what each entry means.
The device-profile area brings standardisation back for common device types. A profile defines, for a class of device such as a generic I/O module or a motion controller, which objects should exist and what they mean, so that a digital input value or an analog reading appears in a predictable place across compliant devices. This is what allows a tool to interact with, say, an I/O node from one manufacturer much as it would one from another. Between the standardised communication and device-profile areas and the flexible manufacturer area, the object dictionary manages to be both interoperable and expressive.
The object dictionary is only useful to an integrator if they know what is in it, and that is the job of the EDS file. The EDS, or electronic data sheet, is a document supplied with the device that lists its object-dictionary entries: which indices and subindices exist, what each one means, its data type, and whether it can be read, written or mapped into process data. Loading the EDS into a configuration tool turns the abstract dictionary into a browsable list of named parameters, which is the practical starting point for any integration work.
For someone pulling data up into a cloud SCADA system, the EDS is what reveals which objects are worth reading. Not every entry in a dictionary is a live value an operator cares about; many are configuration settings that are set once and left alone. The EDS lets an integrator pick out the meaningful measurements and status objects, note their exact index and subindex, and map them to cloud tags with the right data type and meaning. Without it, the integrator would be facing a numbered table with no explanation of what each address holds.
In practice this means a gateway bringing CANopen data into a platform like Merobix is really navigating the object dictionary, guided by the EDS. The integrator identifies the objects that represent the values they want to monitor, confirms their addresses and types from the electronic data sheet, and configures the gateway to read them and forward them upward as named tags. Understanding the object dictionary is therefore not academic: it is the concrete knowledge that determines which of a node's values can be surfaced in a dashboard and which are simply internal settings that stay on the device.
Each entry is addressed by a sixteen-bit index that identifies the object and an eight-bit subindex that selects a component within it. A simple value uses subindex zero, while arrays and records use the same index with different subindices for each element, giving every parameter a precise, unique location.
The communication area holds standardised settings for how the node talks on the bus, the device-profile area holds standardised objects defined for a class of device so similar products look alike, and the manufacturer area holds vendor-specific data and settings unique to that device. Together they make the dictionary both interoperable and flexible.
An EDS, or electronic data sheet, is a file supplied with a CANopen device that documents its object-dictionary entries, including their indices, meanings, data types and access rights. Loading it into a tool turns the numbered dictionary into a browsable list of named parameters, which is what lets an integrator find and map the values worth reading.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.