RE: CANOpen PDO assignment.

Heinz,

So my assumption about the Device's point of view is correct.  Alright.
That makes sense from a Master/Slave perspective.

And if a number of Devices also use information from other devices?  Then
the model falls apart right?

For example.  Three devices all send 3 PDOs with their digital inputs and
analogue inputs as per 401.  One of the inputs on each node is a START
button spread along a long fabrication machine.  They each use TPDOs:
180+node-ID

280+node-ID

380+node-ID



Now the nodes have to use TPDO COBIDs with the respective NodeIDs to
capture this START button event.



My question and point was I guess, that as long as you maintain a
Master/Slave architecture the TPDO, RPDO concept works.  As soon as you
start having inter-device (slave to slave) communications the TPDO, RPDO
concept breaks down.



What started me thinking about this was when I was at the International
CAN Conference someone mentioned how a CANOpen system could be designed to
be completely masterless with the PDOs serving as the communication
backbone for a system where say an A/D value from one device (TPDO) caused
a motor to run at a certain speed (RPDO) while a third device displayed
both status values from both devices (RPDOs).



OTOH, with a small master in place it receives the TPDOs from the A/D
device and creates RPDOs for the Motor and Display devices.



And this brings up a new question.  What are CANOpen implementers actually
doing with RPDOs and TPDOs.  Are 99.9% of the CANOpen systems really just
Master/Slave?



Thanks



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-Jurgen Oertel
Sent: Wednesday, October 31, 2012 9:51 AM
To: 'Canlist'
Subject: Re: [CANLIST] CANOpen PDO assignment.



Am Montag 29 Oktober 2012, 22:19:57 schrieb John Dammeyer:

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



John,

others have explained it already correctly.

See the device PDOs always from the devices point of view.

Each device has 8 pre-defined PDOs it can use without any configuration.

4 Transmit PDOs, where it can send out process data

and 4 Receive PDOs.

The content is defined in the device profile standard.

401 devices for example use there TPDOs for sending its digital inputs and
analog inputs.

Received PDOs are mapped to there digital outputs and analog outputs.

The pre-defined get there CAN ID assignment from a simple rule

For TPDOs

180+node-ID

280+node-ID

380+node-ID

480+node-ID

and for Receive PDOs

200+node-ID

300+node-ID

400+node-ID

500+node-ID



The predefined connection set should ensure

that no one of it collides with another one.



Hope this helps too.



Heinz