RE: CANOpen PDO assignment.

Hi Bertil,

If anything the slides support the idea that the default PDO descriptors
are not really relevant.  They may well have been a mechanism to simplify
the design of slave devices that didn't have the more modern features of
larger EEROM and in circuit rewriteable FLASH.  ie. EPROMs erased with UV
light and programmed outside the end product.

From a typical master/slave perspective, where slave PDOs aren't
dynamically configurable and only talk to masters, it all makes sense.
But today  we live in a world where we often choose a 32 bit processor
with features in a 80 pin TQFP package that make it more power than the
masters that were around when CANOpen was designed.  PLCs now have full
TCP/IP stacks with email and FTP support and CAN is only one small part of
it.  Firmware is upgraded in place from Micro-SD cards or TCP and
sometimes even CAN.

And a RPDO data structure has to be configurable in order to know which
COB ID to 'receive'.  That value might be programmed into a filter or mask
to receive a group of COB IDs.

So to generalize, PDOs occupy the COB ID space from 181 to 5FF.  When the
node is configured to receive and act on some of the of a specific COB ID
data then inside the node it's referred to as an RPDO.  A PDO designed to
be sent by a node on a periodic basis, by event or synchronized by a SYNC
message is termed a TPDO by the node.  All PDOs have the originating 7 bit
NODE ID # as part of the TPDO and TPDOs are the only PDOs actually sent on
the bus.

In other words an RPDO is never transmitted.  It's just the name for a PDO
that is received and inside the node defines how the data part is used.
Pretty well every CANOpen network needs some level of configuration
including devices that need the 7 bit ID part of an RPDO COB ID programmed
so they know which message to accept.  Each node as 8 PDOs that it can use
as TPDOs.  It can receive and act on COB IDs from 181 to 5FF excluding
those with their own NODE ID.

John Dammeyer

"ELS! The Solution"
Automation Artisans Inc.
http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Bertil
Bäck
Sent: Thursday, November 01, 2012 1:05 AM
Cc: John Dammeyer; [email protected]
Subject: Re: [CANLIST] CANOpen PDO assignment.


Hi John,
seems like you referenced the "Embedded Networking with CAN and CANopen"
book here earlier.
So I presume that you have the book.

I think the chapter 2.5.4 describes it quite well.

Then I found the following presentation.
http://mbed.org/media/uploads/sam_grove/canopenhot.pdf
look at slide 35 to 41.

"‰ Per default, each node has access to 8 PDOs,
messages with process data in them
• 4 Transmit PDOs (TPDO)
• 4  Receive  PDOs  (RPDO)
‰
Per default, all transmit PDOs are received and
handled ONLY by the master

Per default, ONLY the master is allowed to use the
CAN message IDs used for transmit PDOs (think this sould say receive)
• So it’s only the master who can send data to the
nodes"

But to make things better it seems like we have a typo in the text to make
it easier :)

Then what is a master in a multimaster network like CAN. In my mind the
master is the node that acts as NMT master ie. the node that starts the
network (setting all the nodes in operational).

Hope this helps

Br,

Bertil BÄCK R&D Manager Hardware

T +358 6 357 6305, M +358 50 588 6895, F +358 6 357 6320

[email protected], www.tke.fi - www.canopen.fi
On 31.10.2012 21:17, John Dammeyer wrote:


Heinz,

Indirectly you've answered my question.  Although 301 and 401 talk about
default TPDO and RPDO COBIDs in reality there is no such thing.  They are
all just PDO COBIDs from 0x181 through to 0x57F and how you use them
within a node determines if they are a TPDO or a RPDO.  The only hard and
fast rule is the lower 7 bits 'should' be the CANOpen Node ID of the
sender to avoid any possibility of collisions.

Even Christian, Andrew and Olaf's "CAN and CANOpen" book really don't
address this aspect other than mentioning that some nodes 'Receive' a TPDO
and 'Send' a RPDO and how to map the Object Dictionary in a way to make
the data show up at the right spot.

Microchips CANOpen stack, in order to be small and fast, has so many
levels of indirection and macro processing definitions that it's extremely
hard to follow what they are doing.  And it had some bugs.

And yet, the basics of CANOpen with SDOs and PDOs, can make it a simple
system to describe.  As long as the dynamic configuration etc. is left for
later chapters.

It's easy to get lost in the overall universality of CANOpen.  Like the
expression.

When you are up to your ass in alligators it's hard to remember that you
were there to drain the swamp.  And to drain the swamp all you need to do
is pull the drain plug.

Thanks for the feedback.

John Dammeyer



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