CANopen PDO

Question

Hi,

I am trying to understand the CANopen protocol.
For now, I do not have any CAN hardware nor the CANopen stack to experiment with.
I would like to know how to write a Java program to simply interpret CANopen messages that are received at the RS232 port.

Questions

• Are there CAN interfaces that are installed as a serial port?
  
  
• Will I be able to write a program to process CANopen messages? I want only to be able to receive and interpret messages. Is it as simple as creating a buffer for the input stream and then break up the transmission into separate messages according to the SOF and EOF? How do I know what is the SOF/EOF since it is only 1-bit long?
  
  
• Why is there a limit on the number of PDOs of a CAN node?
  
  
• How do I process the PDO to identify the node from which it is sent and the data type and value? Is the PDO a standard CAN frame?
  
  

Thank you.

Answer 1

I don't know of any CAN interface that connects to the serial port. (it wouldn't be too hard to create one based on a microcontroller with CAN and serial ports) However, standard serial ports would be too slow to support the higher speeds available in CAN.

Generally, when using the API for a CAN interface, you will be able to read messages consisting of ID, Length and up to 8 bytes of data. You don't need to care about SOF/EOF. Even if interfacing directly on low level with a CAN controller (i.e. if you have a CAN interface for which you need to write the driver/API yourself) you still don't need to care about those details. And you don't want to try to access the CAN bus without using a CAN controller at all...

If you want to pretend that you have a CAN interface, you may create a stub function which returns those three items: an ID, a data length and a 64-bit data buffer. This is basically what all CAN interface APIs will give you. And when transmitting CAN messages, you will use the same parameters (ID, length data).

PDOs are defined by their use of the CAN ID field. In theory the number of PDOs for a device is not really that limited, but the predefined connection set have only allocated a small number (4) of PDOs for each node.

The PDOs are standard CAN frames. As mentioned, the CAN ID identifies the PDO. In the predefined connection set (which most devices follow), the CAN ID of all messages consists of a functional part and a module-ID part (the module ID may be hard coded for the device, or configurable by dip switches for example). Bits 10-7 of the CAN ID is the function code and bit 6-0 is the module number. For example TxPDO1 from a device with module ID 0x10 would have CAN ID 0x190. The upper four bits of the 11-bit CAN ID, ((CAN_ID & 0x780) >> 7), gives you the function code (TxPDO1 = 3) and the rest of the bits,(CAN_ID & 0x7f), gives the module id (which in in this example was 0x10). So if you read a message on the CAN bus with CAN ID 0x190, you would know that this was a PDO from the device with module ID 0x10.

(A simpler way to express this might be to say that TxPDO1 has CAN ID set to 0x180+<module ID>, TxPDO2 has CAN ID set to 0x280+<module ID> etc...)

How you should interpret the data in the PDO depends on your device.

I suggest that you find a good CANopen tutorial. Unfortunately most of them make everything sound much more complicated than it really is. So look around until you find one that appears understandable.

Answer 2

Let's just say that if the API is not available, how will I be able to interface directly on low level with a CAN controller? How do I process the messages?

What is the predefined connection set?

I do not understand this example given above:

"For example TxPDO1 from a module with ID 0x10 would have CAN ID 0x190. ((CAN_ID & 0x780) >> 7) gives the function (TxPDO1 = 3) and (CAN_ID & 0x7f) gives the module id (in this example 0x10)."

Can someone help to clarify further?