PDOs bei CANopen

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

Reply to
Ingo
Loading thread data ...

snipped-for-privacy@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.

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.

[...]

Ist sie. Zumindest bis man sie verstanden hat . 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
Reply to
Oliver Betz

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?

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

Reply to
Ingo

snipped-for-privacy@web.de (Ingo) schrieb:

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

ja.

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

Es hat nur eine Node-ID.

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

IMHO kannst Du da sogar extended IDs nehmen.

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
Reply to
Oliver Betz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.