PDOs bei CANopen

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
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

Re: PDOs bei CANopen
snipped-for-privacy@web.de (Ingo) schrieb:

Quoted text here. Click to load it

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.

[...]

Quoted text here. Click to load it

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

Re: PDOs bei CANopen

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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

Re: PDOs bei CANopen
snipped-for-privacy@web.de (Ingo) schrieb:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

ja.


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

Quoted text here. Click to load it

Es hat nur eine Node-ID.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

IMHO kannst Du da sogar extended IDs nehmen.

Quoted text here. Click to load it

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

Site Timeline