Embedded Networking with CANopen

By Olaf Pfeiffer

[ Select a Protocol  | HLP | Overview | Device Profiles | EDS | PDO | NMT | Implementing ]

Device Profiles

Although the object dictionary concept allows for structuring the data that needs to be communicated, there is still something missing: Which entry in the dictionary is used for what? The dictionary is far too big that we could allow the master to take "wild guesses" and simply try to access certain areas of the dictionary to see if they are supported.

The solution is simple: First of all, there are a few mandatory entries that all CANopen nodes must support. These include the identity object with which a node can identify itself and an error object to report a potential error state. Additional entries are specified by device profiles. Device profiles describe all the communication parameters and object dictionary entries that are supported by a certain type of CANopen modules. Such profiles are available for generic I/O modules, encoders and other devices.

A master or configuration tool can read-access the identity object of any slave node using a SDO. As a reply, it receives a SDO with the information about which device profile a module conforms to. Assuming the master knows which object entries are defined for a particular device profile, it now knows which object dictionary entries are supported and can access them directly.

CANopen is open! If an application requires the implementation of non-standardized, manufacturer specific object dictionary entries, then that is not a problem. Adding entries that disable/enable a certain functionality that is not covered by one of the existing device profiles can be implemented to any device, as long as they conform to the structural layout of the object dictionary.

[ Select a Protocol  | HLP | Overview | Device Profiles | EDS | PDO | NMT | Implementing ]

Copyright © 2001 Circuit Cellar. All rights reserved.

ESAcademy, 2000

www.esacademy.com
info@esacademy.com