RE: CANOpen Object Dictionary Help

Hi John,

That’s a great question!
Here are some point form answers.
1. CAN is a robust communications protocol connecting 2 or more devices along a bus using a “one to many” broadcast model. That means a message is sent and one or more nodes provide an ACK that the messages was correctly formed on the bus.  Not that a specific node received the message.  This is key.

2. To work with CAN some sort of Higher Level Protocol (HLP) is needed and CANOpen is one of those.  There’s also J1939, DeviceNet, MilCAN and others.  And some people write their own depending on the project complexity.

3. The biggest mistakes people make with CAN is wiring and termination at the hardware level and improper use of the CAN message Identifier bits at the HLP level.  That’s why it’s often a good idea to use Commercial Off The Shelf (COTS) products and especially if you are developing your own hardware to have at least one COTS USB to CAN dongle for diagnostics and bus monitoring.

4. Because the low level protocol is “one to many” it’s easy to create a global shared memory that resides over all the nodes.  That in essence is what CANOpen does with the Object Dictionary (OD).  Each Node’s OD is indexed by the specific node ID.  So think of it as a multi-dimensional array across the entire system where an entry is described by 

CANOpen_OD[NodeID,  Index, SubIndex, Value()]; 

In this example Value() is used to describe anything from a single bit for TRUE/FALSE to a string of characters representing text.

5. To access a Node OD entry you send a Service Data Object Message requesting the Index:SubIndex value (ID=0x600+NodeID of target).  The Node returns an SDO answer as ID= 0x580 + NodeID of itself plus the OD data.  Since it’s against the rules for identical IDs on the bus from different nodes only one node is allowed to send SDO messages to another node.  So the System master can access the OD of the Motor Controller with an SDO message but the display can’t do the same to the Motor Controller or there might be two identical SDO messages showing up at the same time.  And it’s a full hand shaking method requiring two messages for every transaction since there is always  a reply.

6. At first glance than makes it look like you cannot have a peer to peer network because the OD is not really accessible between other nodes and that’s true. Sort of.  CANOpen also describes another type of message called a Process Data Object (PDO).  There are both receive and transmit versions although that can be confusing to beginners.  

The easier way to see it is that each PDO is predefined to contain a number of OD values.  So you might have a PDO that has the XY and Z positions of a motor controller.  You might have another that shows the voltages of a number of power supplies.  The PDOs are generally broadcast on a periodic basis and can also be sent when an event occurs like a change in value.

7. The system designer now puts together the system in such a way so that no Node ever duplicates a message ID with the easiest way being that a node always includes its own ID as part of the PDOs.  The IDs are 0x180+NodeID, 0x200+NodeID all the way up to 0x500+NodeID in 0x80 increments.

The Motor Controller needs 3 values X,Y and Z  located in the OD at  0x7000:1, 0x7000:2, and 0x7000:3 so the system controller sends out a PDO with say 0x180+SystemNodeID and the X,Y,Z values in the one message.  The Motor Controller looks for that PDO and uses the values to move the motors storing the values in  0x7000:1, 0x7000:2, and 0x7000:3 in its local copy of the OD. 

While it’s moving the motors the Motor Controller sends out a PDO using ID 0x200+MotorNodeID with the current X,Y,Z values that it keeps at  0x7100:1, 0x7100:2, and 0x7100:3.  Meanwhile the 3 line display controller has been instructed to watch for both sets of messages. 

The Display fills in its own OD entries at location 0x7000:1, 0x7000:2, and 0x7000:3 with the target XYZ values and 0x7100:1, 0x7100:2, and 0x7100:3 with the current XYZ values.  Since the display is graphical its firmware displays the target and current XYZvalues on separate locations on the screen.  It doesn’t care who sent information to fill the OD entries.  It just knows that it displays the values in those OD entry locations on a specific spot on the screen.  

8. The CANOpen firmware in the Display uses other OD entries as mapping values to translate and separate out the PDO values into the unique OD entries.

Change to a different manufacture for a screen display or hang on a PC with a dongle and CANOpen software and the PC can also display the information or even log the messages.  And there’s the cool thing about CANOpen.  As long as you know how the OD is configured you can listen in on the bus and add features or diagnose issues without changing any software on any of the nodes.

It’s a lot of work to set up the OD.  And there’s more going on under the hood with ALIVE messages and NMT state messages etc.  But CANOpen does allow you to replace one device with a totally different manufacturer’s device with minimal effort.  If it’s done right.

Do you need to use CANOpen?  No.  Do you need to do something similar to CANOpen? Yes. 

Best Regards,
John Dammeyer


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>