RE: CANopen PDO assignment.

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]>