RE: CANopen PDO assignment.

Gentlemen,

Because of the very early history of CANopen (I/O-expansion of PLCs), 
default connection set
provides by default direct communication between PLC and expansion 
devcies.

In modern, distributed systems mostly TPDOs of each node are essential 
because each message
is sent by only one node. I have been successfully using default TPDOs as 
long as it has been
possible (=met schedulability requirements). RPDOs need to be adapted to 
the producers' TPDOs
anyway.

Another comment regarding "autostart". Please do never use it in real 
systems! It is a safety risk
because even a simple NMT-master starts up only the defined nodes. If 
there are invalid nodes,
they are not started. If the devices are starting automatically, there is 
no control over the structure
of the system.

The main differnece between SDO and PDO is, that SDO is more or less 
"parameter transfer"
protocol - it has large overhead because of a generic addressing. It is 
itended to provide a generic
OD access for random reads/writes. But PDO is intended to be used for 
periodic signal value updates.
Please notice that in CANopen, both signals and parameters are OD objects 
- the only differences
may be found from AccesType and PDOmapping attributes of the objects. All 
objects can be accessed
by using SDO, but only defined objects can be mapped to/from PDOs.

Best regards,

-H





"John Dammeyer"




From:   "John Dammeyer" <[email protected]>
To:     <[email protected]>
Date:   01.11.2012 18:44
Subject:        RE: [CANLIST] CANopen PDO assignment.
Sent by:        [email protected]




Hello Heinz,

I realize what is written in the standard and the various books and pdf
documents.  I just disagree that it's relevant anymore.  From an
educational point of view I think it's redundant to refer to a node having
predefined RPDOs with the COBIDs

0x201..0x27f,
0x301..0x37f,
0x401..0x47f,
0x501..0x57f

when there aren't any nodes with predefined TPDOs that send those COBIDs.
Unless we talk master/slave.  In that case I agree.

I think from a teaching CANOpen perspective that my statement is valid.
Where SDOs are used to access a single data value in the object
dictionary, PDOS are used to place a number of the object dictionary data
values onto the CAN bus in one packet.   Generally each value in a PDO
should also be available as a single message using an SDO packet.

SDO's must be sent from a master to a slave since the Node ID part of the
CAN ID addresses the target for the Transmit SDO message.
Correspondingly, the Receive SDO should have the senders Node ID number in
the bottom 7 bits of the CAN ID;  not the master's ID #.  Otherwise you
end up with the possibility of two nodes responding with a Receive SDO
that has an identical CAN ID.

So clearly the PDOs are designed to pack multiple SDO values into one
message.  And again in a Master/Slave environment a slave node receives
RPDOs sent by the master and sends TPDOs to the master and in each case
the bottom 7 bits of the CAN ID contain the slaves Node ID #.

But as stated at the ICC and referred to in passing in some of the books
and documents is the concept of a masterless system with one node taking
on the NMT SYNC message duties.  Nodes can even automatically transition
to NMT_OPERATIONAL status without being told to by a master.  In this case
there is no such thing as a predefined set of PDOs since each node by the
definition has 4 TPDOs and 4 RPDOs and none of them match.  In other words
no one can receive the 4 predefined TPDOs because their 4 predefined RPDOs
have a different 4 high bits in the CAN ID  (COBID).

Again I'm talking about the pre-defined values for the TPDOs and RPDOs.
For the masterless system to work the RPDO COBID (CAN ID high order 4
bits) have to be redefined to have the same values as the TPDO high order
bits  which then makes them RTPDOs (ha ha).

Or just dispense with the definitions of RPDOs and TPDOs and call them all
PDOs.  I understand it.  I just see no point anymore to the separate
definitions as soon as the CANOpen system is defined to have slave to
slave communications.  That's really my point.

Perhaps point me to a real product for sale that cannot have the PDO COBID
changed.

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 Heinz-Jürgen Oertel
> Sent: Thursday, November 01, 2012 4:47 AM
> To: [email protected]
> Subject: Re: [CANLIST] CANopen PDO assignment.
>
>
>
> Hi John,
> up to  the second last section you gave a perfekt summary.
> But
> > Each node as 8 PDOs that it can use as TPDOs.
> Is not correct.
> As already explained, each node can have 4 TPDOs and 4 RPDOs
> as pre-defined PDOs.
> But can have more than 8 in sum or even more than 8 TPDOs.
> In this case the system designer has to ensure that all TPDOs
> are configured with parameters fitting to all other nodes
> especially to have no Id conflicts.
>
>  Regards
>      Heinz
>
> Am Donnerstag, 1. November 2012, 03:45:21 schrieb John Dammeyer:
> > 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
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[email protected]>
>

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




This e-mail is confidential and it is intended only for the addressees. Any review, dissemination, distribution, or copying of this message by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system. The sender does not accept liability for any errors or omissions in the contents of this message which may arise as a result of the e-mail transmission.