Setting the Baud Rate and Node IDs in a CANopen System Version Application Note AN-AON

Size: px

Start display at page:

Download "Setting the Baud Rate and Node IDs in a CANopen System Version Application Note AN-AON"

Darleen Pitts
6 years ago
Views:

1 Version Restrictions Abstract Public Document This application notes introduces several methods for setting the baud rate and node IDs in a CANopen System. Table of Contents 1.0 Overview Assigning Node IDs DIP Switch Connector Encoding Hard Wired Layer Setting Services Unique Device Types Address Claiming Protocol Geographical Issue Baud Rate DIP Switch Layer Setting Services Autobauding Questions & Answers Additional Resources Contacts...6 Copyright Vector CANtech, Inc. Contact Information: or

2 1.0 Overview CANopen requires each device to have a unique node ID and a common baud rate within a system. This document presents common and popular methods used to meet this requirement. The need for a common baud rate is obvious, since this is a fundamental requirement of the standard CAN protocol (independent of a higherlayer protocol like CANopen). The node ID is required to uniquely address a device in the CANopen network. If two devices have identical node IDs, then there will be identical CAN identifiers, which will crash the network. 2.0 Assigning Node IDs The following section describes several ways to assign a node ID to a CANopen device. 2.1 DIP Switch A DIP switch or jumper is the method most frequently used to set the node ID. The internal software will read the hardware setting via ports at boot-up time and store the value in an internal variable. The biggest advantage to this method is the ease of use. A disadvantage is the additional cost associated with the hardware. This method may not be possible in harsh environments. 2.2 Connector Encoding The node ID can also be read in via ports from the connector. Yes, the connector requires additional effort on the hardware end, but no configuration effort will be needed on the installation end. Another advantage becomes evident when two identical devices with different functionality are used. The connector encoding can be clearly differentiated, since fixed node IDs can be assigned for the particular task (see Section 4). 2.3 Hard Wired A chain can be built with additional wire. For example, if each device has a signal as input on the "left" and output on the "right", the first node will know that is the leftmost device since its left pin is open. This is now the only node allowed to talk on the network. After initialization and self-assignment of the node ID, this device will set the right port. Then the next node will know that it is now ready for initialization and gets the next node ID. This method requires additional effort on the hardware end, and can only be used with a pure line topology. Setting the node ID is fast and does not require flash memory or serial numbers. This will work with standard CANopen devices from other companies, but the address setting needs to be handled carefully. 2.4 Layer Setting Services CANopen specifies a standard protocol for the dynamic assignment of node IDs and baud rates. This is called Layer Setting Services (LSS) and it is defined in CiA DSP CANopen Layer Setting Services and Protocols (LSS). LSS requires that each device have a unique serial number within the manufacturer and product code. The following is an illustration of how the LSS Master performs a search for Slaves that exist in a range of serial numbers according to CiA DSP 305. The LSS protocol requires a dedicated Master. The LSS Master performs a binary search to find all devices that are available. Once all Slaves are uniquely identified, the LSS Master assigns node IDs to each device using a series of commands. The selection of the appropriate node ID is made with either the product code or a database. In most situations, LSS requires a certain level of configuration. 2

3 Figure 1 LSS Identify Remote Slave Protocol If a Slave device within the serial number range exists, the Slave responds with the following protocol. Figure 2 LSS Identify Slave Protocol 3

4 2.5 Unique Device Types With some applications, a specific device type may only exist in a single instance. In this situation the device can be manufactured with a fixed node ID. This method is the least expensive, but it also has the least flexibility. 2.6 Address Claiming Protocol The Address Claiming Protocol was developed by Vector. It originated from project work within the Electronic Door Equipment Industry. This protocol is defined in the following CiA documents: CiA DSP CANopen application profile for building door control (General definitions and basic principles) CiA DSP CANopen application profile for building door control (Virtual device definitions) CiA DSP CANopen application profile for building door control (Pre-defined communication objects) Every module is uniquely identified, normally with the Vendor ID and serial number. This protocol has a synchronization phase and a cycle driven negotiation that results in a set of unique node IDs. The assignment of node IDs can be influenced by application-dependent information, like device types, geographical position, or configuration. This protocol is purely a software mechanism, and does not require a dedicated Master. It also avoids collisions, just like the SAE J1939 Address Claiming procedure. 2.7 Geographical Issue Another requirement to understand is the identification of devices according to their position within a machine (or other system), for example, when two identical I/O modules have different tasks in a machine. In this case some type of geographical location identification is necessary. This can be handled by defining rules for assigning node IDs to particular positions within the machine. Note that this may not always be possible. For example, let s say that identical light switches are mounted in several rooms. Since each building is different, a fixed node ID assignment does not work. A possible solution here is "Connector Encoding", but whichever way, the responsibility lies with the application. 3.0 Baud Rate Since CANopen does not dictate the use of one particular baud rate, the best rate for the application can be selected. The following baud rates are permissible in CANopen (Kb/s): 1000, 800, 500, 250, 125, 50, 20, DIP Switch The DIP switch method for setting the baud rate is similar to the DIP switch method of setting the node ID. The internal software will read the hardware setting via ports at boot-up time and store the value in an internal variable. The biggest advantage to this method is ease of use. A disadvantage is the additional cost associated with the hardware. This method may not be possible in harsh environments. 3.2 Layer Setting Services LSS contains services for setting a node's baud rate, so this can theoretically be used in an existing network. However, if a problem arises the device in question must be removed from the network. Therefore, it is recommended that the device's baud rate be set in a separate configuration node. This is especially helpful when the device's baud rate is not known (and does not match the system baud rate), since it could quite possibly crash the network and cause severe damage. 4

5 3.3 Autobauding If a device supports automatic baud rate detection (autobauding), no other mechanisms are required. One prerequisite is that at least one device must actively specify the baud rate by transmitting messages at that particular baud rate. There are several different mechanisms for detecting the baud rate at which that particular device is transmitting. This entirely depends on the hardware, and can be achieved at the bit or message level. For example, there are CAN Controllers with a "Listen Only" mode. With this type of CAN Controller, it is possible to switch between any of the CANopen baud rates by listening for and receiving valid messages. Other alternatives use additional hardware. Due to the large variety of possible solutions, it is not feasible to list them here. Furthermore, commercial interests and patents protect several of these mechanisms. 4.0 Questions & Answers Why doesn't the CiA specify one exact method for setting a Node ID? If the CiA were to fix this mechanism, the result would be conflicting requirements for different applications. CiA has defined a communication protocol called CANopen, and that protocol says there must be a node ID. How to use this protocol is up to the application. Why isn't there an Object Dictionary entry for the Node ID? Safety and practicality are two reasons. Setting the node ID in the Object Dictionary requires the use of a Service Data Object (SDO) to accomplish the modification. This is not possible, since the SDO requires the device to already have a node ID for communication. In the event there are two or more devices with the same node ID, there is no chance to identify the next device in line to be re-configured. There is also a risk that the node ID might accidentally be changed. Password protection or something of that nature could be used, but then it would be so complex that one might as well use Layer Setting Services (LSS). 5.0 Additional Resources Additional information can be found in the following: VECTOR APPLICATION NOTES AN-ION Introduction to the CANopen Protocol AN-AON Introduction to the CANopen Documentation Family AN-ION Getting Started with CANopen AN-ION Master and Slave in the CANopen World AN-AND Business Introduction to the CAN Protocol AN-AND Technical Introduction to the CAN Protocol AN-AND Beginner's Guide to CAN Development AN-AND Basic CAN Bit Timing AN-AND Glossary of CAN Protocol Terminology AN-AND Advanced CAN Bit Timing AN-ANI Common High Speed Physical Layer Problems AN-ANI High Speed CAN Physical Layer Specification Template 5

6 6.0 Contacts Vector Informatik GmbH Ingersheimer Straße Stuttgart Germany Tel.: Fax: Vector France SAS 168 Boulevard Camélinat Malakoff France Tel: +33 (0) Fax: +33 (0) Vector CANtech, Inc Orchard Hill Pl., Ste 550 Novi, MI USA Tel: Fax: Vector Japan Co. Ltd. Seafort Square Center Bld. 18F , Higashi-shinagawa, Shinagawa-ku J Tokyo Tel.: Fax: info@vector-japan.co.jp VecScan AB Lindholmspiren Göteborg Sweden Tel: +46 (0) Fax: +46 (0) info@vecscan.com Vector Korea IT Inc. Daerung Post Tower III, 508 Guro-gu, Guro-dong, Seoul, Republic of Korea Tel.: Fax: info@vector-korea.com 6

Reasons for System Simulation with CANoe J1939 Version /06/04 Application Note AN-ION

Reasons for System Simulation with CANoe J1939 Version /06/04 Application Note AN-ION Version 1.1 04/06/04 Application Note AN-ION-1-3400 Author(s) Restrictions Abstract Jürgen Klüser None This Application Note discusses advantages of Communication System Modelling and Simulation by using