CanOpen Telegramm Aufbau

Ups ich meinte auch in meiner Telegramm Tabelle stehen diese nicht mit
drin.

Ich entnehme aus meinem CANopen Buch für die ID:
Bit 31(MSB)   Value 0 = PDO Valid; 1 = PDO Invalid
Bit 30        Value 0 = RTR allowed on this PDO; 1 = not allowed
Bit 29        Value 0 = 11Bit ID; 1 = 29Bit ID
Bit 28-11     Value if Bit 29=0; if Bit 29=1: Bits 28-11 of COB ID
Bit 10-0(LSB) Value x; Bits 10-0 of COB ID

Weiss nicht so wirklich, ob dir das was hilft =/
Habe schon seit längerem nichtmehr mit CANopen gearbeitet.

Freundlichen Gruss
Michael S.

Ich denke es handelt sich um das SDO Download expedited protocol.

2f = Schreibt das 1 Byte in den Serverknoten Objekt Verzeichnis.

 | 600 + nodeID | 0 | 2f | Objekt-Index | Subindex | Nutzdaten |

Nutzdaten: nur 1 Byte enthält Daten, der Rest ist nicht Definiert also
           auf 0 setzen.


MfG
Cnud Grevenitz

Vielleicht ist das eine Lösung:

http://www.microcanopen.com/

Implementiert einen CANopen-Stack, der zwar nicht 100% Standardkonform
ist, aber mit den meisten Profilen zurechtkommt. Insbesondere DS401.

mfg, Stefan.

Hallöchen erstmal Danke für die Antworten nur  leider bin ich immer noch
nicht weiter gekommen.
Hab hier mal einen Log von Telegrammen

Es ist mir immer noch ein Rätzel was die ersten 2Byte zu bedeuten haben
auch aus der Beschreibung der Hardware geht es nicht hervor.

          |  nodeID | ?? | Objekt-Index | Subindex |  Nutzdaten  |
Gesendet  |  640    | 40 |  00   62     |    01    | FF 00 00 00 |
Empfangen |  5C0    | 4f |  00   62     |    01    | 00 00 00 00 |

Gesendet  |  640    | 40 |  00   65     |    01    | 2d 00 00 00 |
Empfangen |  5C0    | 4b |  00   65     |    01    | 00 00 00 00 |

Gesendet  |  640    | 40 |  00   62     |    01    | 00 00 00 00 |
Empfangen |  5C0    | 4b |  01   64     |    01    | e0 21 00 00 |

^
                       |
Ups ich meinte nur das 1 Byte nicht die ersten 2Byte

Das erste Byte ist der sog. "Command Specifier" der den Typ des
SDO-Pakets angibt...

Wie Jörn schon richtig schreibt, ist das bei den SDO-Sequenzen die
Antwort-Kennung, die je nach Datentyp (im Payload) verschieden ist:

        | Lesebefehle
-----------------------------------------------
Befehl  | 40h | HaInd | SubIn |
Antwort | 4Fh | HaInd | SubIn | D0
-----------------------------------------------
Befehl  | 40h | HaInd | SubIn |
Antwort | 4Bh | HaInd | SubIn | D0 D1
-----------------------------------------------
Befehl  | 40h | HaInd | SubIn |
Antwort | 43h | HaInd | SubIn | D0 D1 D2 D3
-----------------------------------------------

In der ersten Doppel-Reihe steht das 4Fh als Kennung für 8 Bit, in der
zweiten Doppel-Reihe steht das 4Bh als Kennung für 16 Bit und in der
letzten Doppelreihe steht das 43h als Kennung für 32 Bit
(zurückgegebenen Datentyp = Payload).

MFG,

Stephan

P.S. Die entsprechende Kennung bei Schreibbefehlen ist 2Fh (Befehl, mit
8 Bit Datentyp), 2Bh (Befehl, mit 16 Bit Datentyp) und 23h (Befehl, mit
32 Bit Datentyp).

Hallo ich verwende einen neuen Mikrocontroller von Infineon Typ 
Bezeichnung XC888. Das Senden und Empfangen von CAN Nachrichten 
funktioniert soweit.
Möchte nun ein CanOpen Protokoll in C für diesen Mikrocontrollertyp 
umsetzen.
Hat von euch einer einen C Code wie sowas realiisert werden könnte?

http://atlas.web.cern.ch/Atlas/GROUPS/DAQTRIG/DCS/LMB/PROFILE/cano-sdo.htm

Vielen Dank für den Link. Gibt es dazu bereits einen C-Code?
Das ganze ist nicht so trivial. Ich würde mal gerne sehen, wie so ein 
Beispiel aussehen könnte.

Eine CAN Nachricht ist dann z.B. so aufgebaut:

CAN Header|Command oder Replay|Object Index|Sub-Index|Reserved oder Data

Dies bedeutet laut CANOpen habe ich pro CAN Nachricht keine 8 Byte als 
Nutzdaten sondern nur 4 Byte.

Ich habe immer gedacht CAN Header (ID) und dann die 8 Byte Nutzdaten.

Der Master soll z.B. am Busteilnehmer 1 eine Anforderung senden. Dieser 
sendet dann die Nutzdaten auf den Bus. Jetzt soll aber ein anderer 
Busteilnehmer z.B. Nr. 3 die Nutzdaten empfangen und dementsprechend auf 
den LED's anzeigen.
Woher weiss der Busteilnehmer 3 dass er gemeint ist?

Hallo......

Hi T.A.,

das habe ich mir gestern Abend auch schon überlegt. Das der Master 
vorgibt, was zu tun ist. Anders kann ich es mir nicht vorstellen wie das 
noch gehen könnte.

CAN arbeitet normalerweise nachrichten-/objekt-orientiert. Das heißt 
hier, der Knoten x lauscht auf das Objekt A, egal, wer es sendet. Es muß 
also nicht vom Master abgeholt und wieder irgendwohin geschickt werden. 
Es reicht völlig, wenn der produzierende Knoten (z.B. der 
Tasten-Einleser) den Tastendruck als Objekt A auf dem Bus mitteilt. Alle 
(vorher so konfigurierten) Knoten, die Objekt A sehen wollen, reagieren 
dann darauf.
Ich weiß nicht genau, ob und wie CANOpen das unterstützt, es sollte aber 
schon gehen, schließlich ist das einer der wesentlich Vorteile von CAN.

Ahoi, Martin

Hallo Martin Schneider wie meinst du das genau?
Ich deinen Beitrag nicht verstehen.

Ganz simpel: Wenn Slave1 einen Tastendruck erkennt, schickt er diese 
Information als CAN-Nachricht auf den CANBus. In CANOpen müßte das als 
PDO konfiguriert sein.
Slave2 ist so konfiguriert, daß er auf diese PDOs hört und reagiert, 
d.h. er schaltet dann seine LED an.
Einen Master braucht es dann also nicht mehr.
Lediglich zum Hochfahren/Konfigurieren könnte ein Master erforderlich 
sein, falls die Konfigurieration nicht fest im Programm steckt.

Besser verständlich?

Ahoi, Martin

Das bedeutet die CAN-ID besteht dann nur aus der Nummer des Message 
Objektes?
Wie ist dann die Busteilnehmernummer z.B. vom SLAVE1 enthalten?

Das Prinzip das du mir soeben erläutert hast, ist sozusagen der Remote 
Betrieb. Sende Remote Bit (Anforderung) vom SLAVE2. Auf SLAVE1 wird 
gewrtet bis Remote Bit emfpangen wurde, dieser sendet dann die Nutzdaten 
auf dem gleichen CAN-ID. Ist dies so korrekt?

Hilfe!
guckst du hier:
http://src.lenze.com/downloadbereich/C1%20-%20Automation/C11%20-%20Industrielle%20Kommunikation/C112%20-a%20CAN/KHB_CAN_v2-0_DE.pdf
http://src.lenze.com/downloadbereich/Y1%20-%20Kleinantriebe/Y11%20-%20Servo-Umrichter%20931/KHB_931M_W_CAN_v2-0_DE.pdf

So. ich hoffe die Links helfen weiter

Hi CANnie, recht herzlichen Dank für die Dokumente.
Hab soeben mal reingeschaut, ist nicht schlecht.

Wer suchet, der findet.
Noch besser, wenn man weiß, wo man suchen muss...