RE: CANOpen PDO assignment.

Klüser, Jürgen <[email protected]>
Newsgroups gmane.comp.hardware.bus.can
Message-ID <[email protected]>
Hi John;

Maybe it helps thinking not in Master-Slave-terms, but in a producer-consumer-model. The spec of a TPDO has to be seen from the producer that transmits the PDO. The RPDO is just an object dictionary entry in a consumer. In CANopen PDOs not necessarily are send between slaves and the master, but from producers to anyone that is configured to consume. This may be another "slave".
The specified default COB-IDs just help in simple (but typical) systems to avoid the configuration step.

In a simple system the "master" application configures its own object dictionary to control all slaves. So these entries do not really have their DS301-spec assigned default values. This sometimes leads to the theoretical confusion.

If you like to get an overview about a more distinguished view on the terms master, manager... it is recommended to read CiA document 302. But don't worry, this documents helps in more complex systems but does not need to be applied to simple systems.

Best regards
Juergen

-----------------------------------------------------
Jürgen Klüser
Director PON
Tools for Open Networking and Avionics
Vector Informatik GmbH
Ingersheimer Str. 24
70499 Stuttgart
Deutschland / Germany
Tel.: +49 711 80670-2132
Fax: +49 711 80670-249
mailto:[email protected]
Internet: www.vector.com
             www.avionics-networking.com
             www.canopen-solutions.de

Sitz der Gesellschaft / Head Office: Stuttgart
Handelsregister / Commercial Register:
Amtsgericht Stuttgart, HRB 17317
Geschaeftsfuehrer / Managing Directors:
Dr. Thomas Beck, Eberhard Hinderer,
Martin Litschel, Thomas Riegraf, Dr. Helmut Schelling
-----------------------------------------------------

From: [email protected] [mailto:[email protected]] On Behalf Of David Harris
Sent: Tuesday, October 30, 2012 7:33 AM
To: [email protected]
Subject: Re: [CANLIST] CANOpen PDO assignment.

I am not sure I follow.  However, one way out of your dilemma might be to
consider the master to be the node with the higher nodeID.
Does that help?
David
On Mon, Oct 29, 2012 at 11:31 PM, David Harris <[email protected]<mailto:[email protected]>> wrote:
I am not sure I follow.  However, one way out of your dilemma might be to consider the master to be the node with the higher nodeID.
Does that help?
David
On Mon, Oct 29, 2012 at 10:19 PM, John Dammeyer <[email protected]<mailto:[email protected]>> wrote:
I've been trying to write up a short description on the difference between the standard transmit and receive PDOs and I'm having trouble explaining the difference.  Here's why.

From a master/slave perspective a transmit PDO is one the slave sends to the master.  The receive PDO is the one that it programs in a filter so that the message makes it through to the slave.

For the Master, each Transmit PDO is really a receive PDO and each Receive PDO is really a Transmit PDO.

But I've always thought one of the up sides of CANOpen is that it functions well as a masterless system.  So two slave class devices can use PDOs to hold multple bits of information and other slave devices pick out what they need.  Who uses the standard Transmit PDO and who uses the Receive and for which direction?

As each message on the bus has to be unique the sender of the PDO will always put their Node ID in the bottom 7 bits of the COB ID.  You really can't have two nodes both sending a 0x182 Transmit PDO message so Node 3 will send 0x183 and node 5 will send 0x185.  IfNode 3 needs the information in the Transmit PDO from Node 5 it's going to set filters to receive the message with that COB ID.  Or should node 5 also be sending identical information in a Receive PDO 0x205?

In trying to explain this I end up thinking the concept of default Transmit and Receive PDOs are redundent and they should have been just named PDOs without the Transmit or Receive adjective.

Or am I missing something?

John Dammeyer




"ELS! The Solution"
Automation Artisans Inc.
http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950<tel:1%20250%20544%204950>
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.