PDOs bei CANopen

[Ingo]

Hallo,
ich komme mit PDOs nicht so ganz klar, und die ganze Literatur hilft
mir auch nicht viel weiter. Im Zeltwanger steht (auf Seite 49) etwas
vom PDO-Linking. Weder konnte ich irgendwo anders etwas zu dem Thema
finden (z.B. im CiA Draft Standard 301), noch erschließt sich mir der
Sinn. Wofür wird überhaupt unterschieden zwischen TPDOs und RPDOs.
Dass festgelegt sein muss, wer PDOs verschickt, ist ja klar, aber
warum, wer sie empfängt?
Also entweder habe ich ein Brett vor dem Kopf, oder die ganze
CANopen-Literatur, die ich bisher gesehen habe, ist wirklich so
schlecht wie ich glaube...

Gruß,
loki

 

[Oliver Betz]

l.o.k.i@web.de (Ingo) schrieb:

mir auch nicht viel weiter. Im Zeltwanger steht (auf Seite 49) etwas
vom PDO-Linking. Weder konnte ich irgendwo anders etwas zu dem Thema
finden (z.B. im CiA Draft Standard 301), noch erschließt sich mir der
Sinn. Wofür wird überhaupt unterschieden zwischen TPDOs und RPDOs.

Es geht um die Definition, was das Gerät mit den Prozeßdaten macht.
Ein RPDO wird empfangen, z.B. um einen Ausgang zu setzen. Ein TPDO
wird gesendet, z.B. wenn ein Eingang sich verändert hat.

In ein PDO kannst Du verschiedene Daten reinpacken, auch gemischt.
Z.B. 7 Bits Digitaleingang, 1 Bit Status, 16 Bit Analogwert.

Die Zuordnung zwischen PDO-Daten und Gerätefunktion muß also irgendwo
stattfinden.

[...]

Also entweder habe ich ein Brett vor dem Kopf, oder die ganze
CANopen-Literatur, die ich bisher gesehen habe, ist wirklich so
schlecht wie ich glaube...

Ist sie. Zumindest bis man sie verstanden hat <g>. Danach geht's so.

BTW: eine größere Konzentration an CAN(open) Experten findest Du in
der canlist.org Mailingliste, die IIRC Vector betreibt.

Servus

Oliver
--
Oliver Betz, Muenchen

 

[Ingo]

Oliver Betz <OBetz@despammed.com> wrote in message news:<4027e6cd.43662039@z1.oliverbetz.de>...

Es geht um die Definition, was das Gerät mit den Prozeßdaten macht.
Ein RPDO wird empfangen, z.B. um einen Ausgang zu setzen. Ein TPDO
wird gesendet, z.B. wenn ein Eingang sich verändert hat.

So gesehen macht das Sinn, aber eigentlich gibt es doch keine
technische Notwendigkeit für diese Unterscheidung. Wenn Gerät A ein
PDO-Telegramm sendet, und Gerät B kennt das Mapping, kann es doch mit
dem Telegramm machen was es will. Wer interessiert sich dafür, was B
damit macht?
Irgendwo habe ich einen Knoten in meiner Logik, dem ich gerne auf die
Spur kommen möchte. Z.B.: im Zeltwanger steht, dass für die ersten
vier PDOs Default-Identifier vergeben werden. Ist für diese PDOs auch
ein Default-Mapping vorgesehen? In dem CiA Draft Standard 301 steht zu
den Default-Identifiern bei den Receive POD Communication Parameter:
1400h: 200h+Node-ID,
1401h: 300h+Node-ID,
1402h: 400h+Node-ID,
1403h: 500h+Node-ID,
1404h-15FFh: disabled
Warum hat ein Gerät bei den Receive-PDOs seine eigene Node-ID? Es gibt
doch kein Gerät, welches diese COB-IDs für seine TPDOs vergeben hat,
oder?
Noch eine Frage zu den COB-IDs: defaultmäßig sind ja immer die oberen
4 Bits der Functioncode und die unteren 7 die Node-ID. Wenn man für
PDOs neue COB-IDs vergibt, müssen die doch dieser Systematik nicht
folgen, oder?

In ein PDO kannst Du verschiedene Daten reinpacken, auch gemischt.
Z.B. 7 Bits Digitaleingang, 1 Bit Status, 16 Bit Analogwert.
Die Zuordnung zwischen PDO-Daten und Gerätefunktion muß also irgendwo
stattfinden.

Aber das ist doch das Mapping, oder? Das habe ich ja halbwegs
verstanden.

Das komische ist, dass ich ständig das Gefühl habe, dass das alles
eigentlich ziemlich einfach ist

Auf jeden Fall Danke für Deine schnelle Antwort!

Gruß,
loki

 

[Oliver Betz]

l.o.k.i@web.de (Ingo) schrieb:

Es geht um die Definition, was das Gerät mit den Prozeßdaten macht.
Ein RPDO wird empfangen, z.B. um einen Ausgang zu setzen. Ein TPDO
wird gesendet, z.B. wenn ein Eingang sich verändert hat.

So gesehen macht das Sinn, aber eigentlich gibt es doch keine
technische Notwendigkeit für diese Unterscheidung. Wenn Gerät A ein
PDO-Telegramm sendet, und Gerät B kennt das Mapping, kann es doch mit
dem Telegramm machen was es will. Wer interessiert sich dafür, was B

klar kann es das - aber es soll einen standardisierten Weg geben, das
zuzuordnen.

damit macht?
Irgendwo habe ich einen Knoten in meiner Logik, dem ich gerne auf die

ja.

Spur kommen möchte. Z.B.: im Zeltwanger steht, dass für die ersten
vier PDOs Default-Identifier vergeben werden. Ist für diese PDOs auch
ein Default-Mapping vorgesehen? In dem CiA Draft Standard 301 steht zu

nein, wie auch? Vielleicht in einem Geräteprofil, da mußt Du selbst
nachsehen. Bei mir paßte leider keins.

den Default-Identifiern bei den Receive POD Communication Parameter:
1400h: 200h+Node-ID,
1401h: 300h+Node-ID,
1402h: 400h+Node-ID,
1403h: 500h+Node-ID,
1404h-15FFh: disabled
Warum hat ein Gerät bei den Receive-PDOs seine eigene Node-ID? Es gibt

Es hat nur eine Node-ID.

doch kein Gerät, welches diese COB-IDs für seine TPDOs vergeben hat,
oder?

_Diese_ IDs bestanden dann aber nicht per Default, sondern wurden
konfiguriert.

Noch eine Frage zu den COB-IDs: defaultmäßig sind ja immer die oberen
4 Bits der Functioncode und die unteren 7 die Node-ID. Wenn man für
PDOs neue COB-IDs vergibt, müssen die doch dieser Systematik nicht
folgen, oder?

IMHO kannst Du da sogar extended IDs nehmen.

In ein PDO kannst Du verschiedene Daten reinpacken, auch gemischt.
Z.B. 7 Bits Digitaleingang, 1 Bit Status, 16 Bit Analogwert.
Die Zuordnung zwischen PDO-Daten und Gerätefunktion muß also irgendwo
stattfinden.

Aber das ist doch das Mapping, oder? Das habe ich ja halbwegs
verstanden.

Das komische ist, dass ich ständig das Gefühl habe, dass das alles
eigentlich ziemlich einfach ist

Ist es, aber kompliziert erklärt. Und wer es verstanden hat, hat dann
keine Lust, eine einfache Beschreibung zu machen. Vielleicht stelle
ich aber einmal ein paar Links zusammen.

Ansonsten nochmal der Tip mit der Mailingliste. Da lesen einfach mehr
Spezialisten.

Servus

Oliver
--
Oliver Betz, Muenchen