Details about CANopen

Question

I’m creating industrial automation projects based on Delta IA products. So far I am using serial connections or ethernet for my projects. For more than a year I am trying to understand the CANopen protocol. Delta has a lot of products that support CANopen. The problem I’m facing is the CANopen understanding. Its more easy to understand something by comparing to something we already know. In my case I’m well known of instructions, operands, addresses and other terms. So what are SDO, PDO, NMT? Are they instructions, operands or something else?! Where is this EDS file located? Do we download it from somewhere? If yes do we download it to the PLC or keep it on the notebook? Where is object dictionary located? Do we create it?

A lot of people think (quite rightly so) that the CANopen explanations are very unclear and do not use the right approach to the users who want to understand the matter.

Thank you!

I tried to learn all that stuff from datasheets regarding CANopen and thats exactly the problem…

Answer 1

There is a series of short videos on YouTube especially to help newcomers to CANopen like you. You can find it here.

For a general overview of all important communication objects in CANopen including EMCY, as well as some other core concepts, see this poster in PDF format here.

Once you understand more, you should request a copy of the CiA 301 standard where all the basics are specified here. Yes, it's very technical but an indispensable reference if you are unclear about certain details.

Answer 2

So what are SDO, PDO, NMT? Are they instructions, operands or something else?!

They are data communication protocols sent over the bus, so your analogies from programming aren't really applicable.

Where is this EDS file located?

It is delivered together with the product or on request. It's a text file describing default mapping and CANopen feature support of the product.

If yes do we download it to the PLC

In case of PLC programming, that probably helps indeed. The main use of EDS files is actually for the benefit of PLC programming. Micro-controller programmers or the one designing the CANopen network don't have much use of the raw file.

Where is object dictionary located? Do we create it?

The object dictionary is an abstract address map existing on every CANopen node. It may or may not correspond to physical memory locations. The idea with the object dictionary is that each node provides more or less full access to all of its CANopen internals, so that it may be configured by user.

Overall CANopen can be a bit overwhelming, because it is super-flexible and super-generic, but in practice we only need to use like <5% of what's covered by the CANopen standards, at least if you are only a user and not implementing/adapting a protocol stack yourself.

I have very little experience from PLC programming but I often get to deal with customers using them, whom are confused over how to use CANopen. Because the PLC can handle a lot of the stuff for free between the lines, but in some PLC-specific way. So you have to learn that too, in addition to CANopen, so in practice most users will need help from the PLC manufacturer's support in setting everything up, at least for the first time.

---

Example of implementation of a simple GPIO link:

• Lets say you are programming a PLC which controls some relay module.

• You configure node id (maybe by means of a physical dip switch) to 1 for the PLC and 2 for the relay module.

• You can check in the EDS file for the relay module which RPDO(s) it supports. You then need to pair it with a corresponding TPDO in your PLC.

• In the simplest form with no PDO mapping etc, you can just create a 1-to-1 relation between the TPDO in the PLC and the RPDO in the relay module, pairing them together.

• Assuming that everyone involved follows the standard default settings, then the first available TPDO in the PLC will be TPDO1 with default CAN frame identifier (COBID) 0x180 + node id = 0x181. And the first available RPDO in the relay module will be RPDO1 with COBID 0x200 + node id = 0x202.

• Ok so we have a TPDO with COBID 0x181 and we want the CAN data from it to go into a receiver frame with COBID 0x202. But they must use the same COBID or communication will not be possible. It is smart to configure everything on the PLC side, so that in case you need to change the relay module you just need to change the node id and then it will be ready to go.

• Changing COBID for TPDO, as well as a lot of other stuff is found in the communication parameters of the PLC's object dictionary, at address 0x1800 + node id. The various sub indices of the communication parameters contain lots of stuff that can be configured, but 0x1801:01 we find the COBID. This needs to be changed to 0x202 to match the relay module's RPDO.

  Note: CANopen uses little endian for most of the payload data, but CAN uses big endian for the actual CAN identifier, which is what we are dealing with here. You may have to enter this in little endian format in the object dictionary, but it will come out as big endian on the actual bus.

• Assuming everything is configured correctly now, then TPDO1 of the PLC will have COBID 0x202 and will control the relay module outputs.

• If we wished to instead change the COBID of the relay module's RPDO, we could do so as well by accessing the relay module's object dictionary. This is done by sending SDO protocols, usually at start-up. This means that during power-on and with every module booted, the PLC will send out a lot of SDOs to configure all slaves, before it later puts the bus in operational. (a PLC is very often the "NMT master" and therefore in charge of sending out NMT messages like "go operational", "revert to safe mode" etc).