Version 1.2 2008-05-29 Restrictions Abstract Public Document This application note explains the meanings of the terms Master and Slave as they relate to the CANopen protocol. It also describes the range of Master functionality in different stages of development. Table of Contents 1.0 Overview...2 2.0 Master and Slave...2 2.1 The Master in CAN-based Systems...2 2.2 Master and Slave in CANopen...2 2.3 Master and Slave in the Application...2 3.0 Network Management (NMT)...3 3.1 NMT Master Features...3 3.1.1 Switching NMT Master ON and OFF...3 3.1.2 Start Message Transmission...4 3.1.3 Heartbeat or Guarding Event Handling...4 3.1.4 NMT Slave Assignement List...4 3.1.5 Triggering the NMT Message...4 3.1.6 Activating and Deactivating Guarding...4 3.2 NMT Slave Features...4 3.3 Starting the System...5 3.3.1 Overall Procedure...5 3.3.2 NMT Master Tasks...6 4.0 Layer Setting Services (LSS)...7 5.0 SDO and PDO...7 5.1 SDO Client and Server...7 5.2 PDO Communication...7 6.0 Conclusions...7 7.0 Additional Resources...10 8.0 Contacts...10 Copyright 2008 - Vector CANtech, Inc. Contact Information: www.vector-cantech.com or 1-248-449-9290 1
1.0 Overview CANopen uses the terms Master and Slave in a variety of ways. This document discusses the meanings and importance of these terms in a CANopen system. Properties of a completely developed CANopen Master will be presented along with how an application can benefit from this functionality. 2.0 Master and Slave In engineering development, a Master-Slave relationship defines an entity called a Master that is related to at least one other entity called a Slave. Within this relationship, the Master initiates a task and the Slave executes it immediately (or after a time delay). In CAN-based systems, the term Master and how it relates to the term Slave appears in several different relationships and contexts. In order to maintain a proper perspective, it is ABSOLUTELY ESSENTIAL to pay careful attention to the context in each case. 2.1 The Master in CAN-based Systems The term Multi-Master System is frequently used throughout CAN communication literature. This term simply describes the bus access method that CAN Controllers use. In CAN-based communications, each member of the network gains access to the bus with no pre-determined arrangement. Whichever device has data to send is allowed access to the bus. CAN avoids conflicts through a bit-wise arbitration defined in ISO 11898: Road Vehicles Interchange of Digital Information Controller Area Network (CAN) for High-Speed Communication. 2.2 Master and Slave in CANopen When the terms Master and Slave are used in CANopen, they appear in the following two contexts: Network Management (NMT) Layer Setting Services (LSS) Here, Master and Slave refer to a type of communication relationship. This Master-Slave NMT relationship will be explained later on in great detail. The following CANopen functionality can only be implemented within an NMT Master device: SDO Manager - The SDO Manager handles the dynamic development of SDO relationships in a CANopen network. Configuration Manager (CMT) - The CMT allows the networked nodes to be configured during boot-up. The SDO Manager and Configuration Manager are defined in CiA DSP 302 - CANopen Framework for CANopen Managers and Programmable CANopen Devices. The CANopen Manager is a combination of an NMT Master and SDO Manager (or CMT). Note that the term CANopen Master is not defined here. 2.3 Master and Slave in the Application Many distributed applications in the Industrial Automation area are implemented with a simple Master-Slave hierarchical scheme. The Master application deals with control and one (or more) Slave applications are implemented as sensors and actuators. This Master-Slave application level relationship is an entirely different topic and will not be discussed any further in this document. 2
3.0 Network Management (NMT) CANopen has Network Management to monitor and control all devices that are connected on the network. Each CANopen device implements a state machine, which can be controlled by an NMT Master via the bus. This state machine is the core of NMT Slave functionality. The NMT Master is the only device that is able to influence other state machines in the network, and only one NMT Master is allowed in a network. Note that an NMT Master is available network functionality and can exist with an NMT Slave on the same physical device. Figure 1 NMT Master and NMT Slave 3.1 NMT Master Features The NMT Master is responsible for the following two network tasks: Triggering the NMT Message Guarding If CiA DS 301 v3.0-compliant devices are to be used, then Guarding should be supported, since these devices typically do not have Heartbeat functionality implemented. If this compatibility is not required, the NMT Master functionality can be reduced to sending the NMT message. NMT Master functionality is configured with entries in the Object Dictionary (OD). This configuration ability includes the following features according to CiA DSP 302 v3.0 - CANopen Framework for CANopen Managers and Programmable CANopen Devices: 3.1.1 Switching NMT Master ON and OFF (OD entry 0x1F80 NMT StartUp) Remember, only one device can be the acting NMT Master when several networked devices contain NMT Master functionality. 3
3.1.2 Start Message Transmission (OD entry 0x1F80 NMT StartUp) The Start message switches a device state machine to its OPERATIONAL state. This can be done with selected devices or all devices in the network. 3.1.3 Heartbeat or Guarding Event Handling (OD entry 0x1F80 NMT StartUp) Depending on the particular application, different strategies can be implemented to handle this event. Either all nodes or a single node associated with this event can be handled accordingly. 3.1.4 NMT Slave Assignement List (OD entry 0x1F81 SlaveAssignment) All devices that are to be managed by the NMT Master are entered into this list. It is possible to indicate whether a device is a MANDATORY or OPTIONAL participant in the network. In addition to simply pre-configuring the NMT Master functionality, it is possible to trigger it as needed. This means there are Object Dictionary entries for triggering the NMT message and activating/deactivating Guarding. The device having NMT Master functionality must not be in the STOPPED state, since SDO communication is not allowed in this state. 3.1.5 Triggering the NMT Message (OD entry 0x1F82 RequestNMT) The NMT Master can be triggered to send an NMT message with this Object Dictionary entry. Certain CANopen tools can generate the NMT message as well. In this situation, the NMT Master detects the state change in the connected device. This is why the NMT Slave Assignment list is maintained. 3.1.6 Activating and Deactivating Guarding (OD entry 0x1F82 RequestGuarding) Guarding can be activated for selected individual nodes or all nodes by entries in the Object Dictionary. These values are used as parameters, which have already been entered in the NMT Slave Assignment list. 3.2 NMT Slave Features An NMT Slave only makes a valid CANopen state machine available and responds to the corresponding NMT messages. The Boot-Up message is naturally part of a complete CANopen state machine. The Boot-Up message is sent after the state transition from INITIALIZATION to PRE-OPERATIONAL is made. 4
Figure 2 NMT State Machine An NMT Slave must support either Guarding or Heartbeat. Heartbeat is the first choice for new implementations. With the Heartbeat mechanism, the Heartbeat consumer generates a specific Heartbeat message. When Guarding is used, the NMT Slave must generate a response to the corresponding Guarding request. 3.3 Starting the System 3.3.1 Overall Procedure There are four main steps to starting a CANopen network. Step 1 Device Parameter Configuration This configuration is performed with SDO write accesses to the Object Dictionaries of the connected devices. If the configuration is stored in non-volatile memory, then this configuration process should run internally within that device. If this is the case, no SDO traffic on the network is needed. Note that this entire configuration step is not even required with extremely simple systems. Step 2 Synchronous Communication Initiation The SYNC Producer is activated by setting the SYNC ID (OD entry 0x1005) and Cycle Time (OD entry 0x1006). Step 3 Heartbeat or Guarding Initiation In general, Heartbeat and Guarding can exist in parallel in the same network. Note that the NMT Slave cannot implement Guarding while being a Heartbeat Producer at the same time. Step 4 Make NMT Slaves OPERATIONAL Devices must be in their OPERATIONAL states in order to exchange process data. The NMT Master handles this state transition. 5
This procedure allows a great deal of flexibility when starting a network. As a result, problems do occur in practice and are either inadequately handled or not even dealt with at all. To avoid this, the CANopen Manager boot-up process is defined in CiA DSP 302 v3.0 CANopen Framework for CANopen Managers and Programmable CANopen Devices. 3.3.2 NMT Master Tasks The NMT Master is responsible for starting and configuring all devices in the network. This requires the NMT Master to undergo additional testing. The list of assigned Slave devices is the basis for the start-up procedure. If a device s Node ID is in the list, then that device will be started. The following are actions (in proper sequence) an NMT Master performs during the start-up of a network. 1. Layer Setting Services (LSS) This process sets the Node ID, baud rate, and Identity Object when a device is required to be reconfigured. LSS is defined in CiA DSP 305 CANopen Layer Setting Services and Protocols (LSS). Naturally, there must be an initial configuration (first-time assignment of layer parameters) using LSS. 2. Flying Master Process This process selects the NMT Master when multiple nodes can potentially function as the NMT Master in the network. These devices make a decision among themselves using a special protocol. This is especially practical in systems where the NMT Master functionality is redundant. 3. Reset Nodes Using The NMT Message All nodes state machines are reset, except for the NMT Master. 4. Boot Slave Process This process starts each individual node in the network. Several devices can be started in parallel. 5. NMT Master Transition To OPERATIONAL The State machine starts the device which has the NMT Master functionality. 6. Start All Devices After the NMT Master has been started, all other NMT Slaves are transitioned to their OPERATIONAL states. The Boot Slave Process consists of the following action sequence: 1. Verify that assigned device exists Accessing Object Dictionary entry 0x1000 of the device that is to be started does this check. This Object Dictionary (OD) read access is repeated for devices that have longer initialization periods. The device is deemed not available if there is no response (or a time out). Note that a default time can be specified for each individual mandatory device. If a mandatory device does not respond in time, the network start-up is aborted. The network start-up continues when optional devices do not respond in time. 2. Verify device type and identity match defaults Every Slave contains Object Dictionary entries for Device Type (OD entry 0x1000) and Identification (OD entry 0x1018 Identity Object). The Master can contain these same values for each networked device and compare them at boot-up. 3. Verify and restore device configuration The configuration date is checked for each device that is to be started. If necessary, the configuration is re-generated by the Configuration Manager (DCF Concise Data Format). 4. Start Heartbeat or Guarding The NMT Master will enable the corresponding service, depending on which network management mechanism has been configured. 5. Start the device with the NMT Message Networked devices can be started together with all nodes or individually. This means a device is switched to the OPERATIONAL state while other devices are being configured. In most cases, the transition to OPERATIONAL will not take place until all required nodes are present. 6
The NMT Master must also be configured for special case behavior. An example is the configuration of Heartbeat/Guarding for optional devices that are added to the network at a later time. 4.0 Layer Setting Services (LSS) LSS is required when devices need to have the following parameters configured over the network: Baud rate Node ID Identity Object LSS is defined in CiA DSP 305 CANopen Layer Setting Services and Protocols (LSS). 5.0 SDO and PDO 5.1 SDO Client and Server Every CANopen device s Object Dictionary is made available over the network. Object Dictionary entries can have read and/or write access attributes. Every node on a CANopen network needs to support the Service Data Object (SDO) in order for one device to read or write an Object Dictionary entry of another device. A device that pushes these read/write operations into the Object Dictionary must exist as well. Since this is usually the same node that controls the application in the network, the NMT Master and SDO Client are usually found on the same physical device. 5.2 PDO Communication A Process Data Object (PDO) is exclusively exchanged using a Producer-Consumer relationship. Master functionality is not required in the corresponding physical devices that are involved in this data transfer. It is critical to properly configure the PDOs in both the Producer and Consumer. 6.0 Conclusions The terms Master and Slave in CANopen really only relate to Network Management (NMT) and Layer Setting Services (LSS). In practice however, the terms are often used without any clear differentiation between the two. A CANopen Slave device is normally implemented with the following functionality: State machine according to CiA DS 301 CANopen Application Layer and Communication Profile Object Dictionary and SDO Server Error Control Mechanism (Heartbeat Producer or Guarding from the NMT Slave point of view) Relevant process data to be communicated with PDOs On the other hand, there is not a standard feature list for the CANopen Master. The following features are used quite often in practice: NMT Master (NMT Message for controlling state machines and Guarding) SDO Client for accessing an Object Dictionary in another device 7
The controlling application is located on this same physical CANopen Master device that directly uses the basic CANopen Master services listed above. In this situation, the CANopen Master does not usually have its own Object Dictionary. This type of CANopen Master instance is frequently found with simple interface connections or as a standard function in PLC (Programmable Logic Controller) run-time environments. Figure 3 Simple CANopen Master In more advanced Master implementations, the CANopen Master has its own Object Dictionary in order to configure itself. Figure 4 CANopen Master with Object Dictionary The CANopen Master functionality is always configurable when using a CANopen Manager (NMT Master with either Configuration Manager (CMT) or SDO Manager). This type of Master implementation is very flexible to use and separates the Application Engineer from many internal CANopen protocol details. 8
Figure 5 CANopen Master with Object Dictionary and SDO Manager 9
7.0 Additional Resources Additional information can be found in the following: VECTOR APPLICATION NOTES AN-ION-1-1100 Introduction to the CANopen Protocol AN-AON-1-1101 Introduction to the CANopen Documentation Family AN-ION-1-1102 Getting Started with CANopen 8.0 Contacts Vector Informatik GmbH Ingersheimer Straße 24 70499 Stuttgart Germany Tel.: +49 711-80670-0 Fax: +49 711-80670-111 Email: info@vector-informatik.de Vector France SAS 168 Boulevard Camélinat 92240 Malakoff France Tel: +33 (0)1 42 31 40 00 Fax: +33 (0)1 42 31 40 09 Email: information@vector-france.fr Vector CANtech, Inc. 39500 Orchard Hill Pl., Ste 550 Novi, MI 48375 USA Tel: +1-248-449-9290 Fax: +1-248-449-9704 Email: info@vector-cantech.com Vector Japan Co. Ltd. Seafort Square Center Bld. 18F 2-3-12, Higashi-shinagawa, Shinagawa-ku J-140-0002 Tokyo Tel.: +81 3 5769 6970 Fax: +81 3 5769 6975 Email: info@vector-japan.co.jp VecScan AB Lindholmspiren 5 402 78 Göteborg Sweden Tel: +46 (0)31 764 76 00 Fax: +46 (0)31 764 76 19 Email: info@vecscan.com Vector Korea IT Inc. Daerung Post Tower III, 508 Guro-gu, Guro-dong, 182-4 Seoul, 152-790 Republic of Korea Tel.: +82-2-2028-0600 Fax: +82-2-2028-0604 Email: info@vector-korea.com 10