Welcome to the CAN-bus Wiki project

Which Standards are available?

CanOpenStandards – since 2005 they are all available for free, simply download at CiA] Web site.

Current version of the CiA 301 document is 4.2

What is the Electronic Data Sheet EDS

Electronic Data Sheets are used to describe CANopen or DeviceNet devices. The name EDS is used by others as well. Different formats for these files are in use. Nowadays XML is used as generic format. another question is what is inside. CANopen and others are using ISO-Standard 15745 which allows to describe more of the device functionality than older formats. The CiA standard for the old EDS format is CiA306, for the XML based CiA311. In XML the file extension is xdd for XML Device Description file. An short example.

How does a NMT master know the node state?

Edison asked: The NMT master issues NMT control messages to the slaves. But the slave does not respond. Then how does the NMT master know whether the slave has entered the state the master wanted it to enter?

By watching heart beat, node state is coded there; mailto:oe@port.de

you are right, NMT is an unconfirmed service. For checking the actual state of the devices Heartbeat or Guarding can be used. With Heartbeat each configured device periodically transmits its status. With the (old) Guarding the NMT Master transmits a Remote Frame to which the slave answers with its status. mailto:juergen.klueser@web.de

You can check the network state either with Nodeguarding or with Heartbeat. Both NMT error control services work with the same identifier (700h + Node ID).

  • Nodeguarding
    • On transmission of the NMT error control message by the master with the RTR bit set, you get a response from the slave (DLC is 1). The first byte of the response message denotes the slave's state:
4 = Stopped
5 = Operational
127 = Pre-Operational

Please note that the most-significant bit in the response message toggles for each request.

  • Heartbeat
    • This is the recommended method, since it does not use the RTR mechanism. The CANopen slave transmits a message cyclically with the Identifier 700h + node ID, DLC = 1 and the state information as described above. The Heartbeat producer time can be set via index 1017h.


Where is the object dictionary stored, in the device or in the EDS?

Of course, the object dictionary IS stored in the device. The EDS file is a description of the objects stored in the device. And typical it is a electronic file, stored on some electronic readable media. If an configuration master, or application master wants to know data types, it has to read and evaluate the file. Or it knows implicitly what and how to access. Besides this, a specification exists, that a CANopen device can store the EDS internally in the device. Other devices (don't use “master” always, remember we really have a multi-master system) can download the EDS using SDO domain transfer. mailto:oe@port.de

HeartBeat or NodeGuarding

Since version 4.0 of the DS301, it is recommended to use Heart Beat. For a new development you should prefer it. From the technical view Heart Beat provides a better usage of the CAN network bandwith. From the commercial point of view: choose a library which provides both, than your device can be configured to take part in either of both methods. See also CanOpenAndRtr.

Is CanOpen Multi Master ?

Yes it is! CanOpen is based on CAN - an CAN is. For short, Multi Master means, every node can aquire the bus without asking a dedicated network bus muster. It is very visible with CanOpen PDO communication objects. In typical cases the change of an process value or the change of the status of a variable is used to send out this information as soon as this happens. This is considered as event driven communication in CANopen. A node using this communication can immediately send out it's PDO containing the new value without being asked to do so by a master or without waiting for a time slice when it is allowed to send.

How is the Object Dictionary accessed by the device? How does it know where the OD is stored?

Using Default-SDO with a master in the network

Daniel: we have a network with different kinds of CANopen-nodes. One of these nodes is superior. This node is a control which function as master. So far the general situation. Now every node has its Default SDO-Server, which is defined under 0x1200 in the object dictionary. To configure the nodes, the master uses at the start-up of the network the default SDO-Server. Now there is diagnostic system in the network to monitor the nodes of the network. The question: Has the diagnostic system to use an other SDO Server at the nodes to to monitor them? Someone told me, that only the master should use the Default-SDO and this should be a part of the standard, but I can't find it there. Is this right, or are there other requirements of that kind?

Jürgen: this is right, normally a second SDO client should use another SDO. It is not documented in the CANopen specifications, since this is already a requirement of the underlying CAN: Every ID in the network must be send only by one device (exist some exceptions…).

But in practical systems the used devices have only one SDO server available. For solving this problem, CiA has defined in CIA302 the so-called SDO Manager, which is responsible to manage the assignment of the SDOs. There are only a few applications with an SDO Manager in the market. In most systems there is not really a problem: Typically a “Master” uses SDOs only in the start-up phase. So the SDOs can be used later on. But in fact this is responsibility of the system integrator.

The CANopen standards do specify protocols, services etc., but it does not intend to specify how to be used. Like with CAN: It specifies messages IDs, but not, what do to with.

How can a duplicate node Id be detected?

In systems having nodes where the node-id is set using switches, it can happen that two nodes are using the same switch settings, resulting in the same node-id. How can this situation be detected?

  • by the node itself
  • by a network tool
  • by the network master

QR Code
QR Code can_higher_layer_protocols:canopen_faq (generated for current page)