Re: CANOpen PDO assignment.

Bertil Bäck <[email protected]>
Newsgroups gmane.comp.hardware.bus.can
Message-ID <[email protected]>
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.

"&#137; Per default, each node has access to 8 PDOs,

messages with process data in them

• 4 Transmit PDOs (TPDO)

• 4 Receive PDOs (RPDO)

&#137;

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.