|
Anzeige
|
CanOpen Telegramm Aufbau
Gast
#391123
Habe ein kleines Problem mit der zusammensetzung eines CanOpen Telegramms. 640 | 2F | 01 64 | 01 | 11 22 33 44 Node_ID| ?? | Objekt-Index|Subindex| Nutzdaten Was ist ^^ das ? Also 2F wieß nicht woraus ich mir die bilden kann auch in meiner Telegramm stehen diese nicht mit drin. Kann mir jemand von euch dabei Helfen?
Gast
#391124
Ups ich meinte auch in meiner Telegramm Tabelle stehen diese nicht mit drin.
Gast
#391125
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.
Gast
#391126
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
Gast
#391127
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.
Gast
#391128
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 |
Gast
#391129
^
|
Ups ich meinte nur das 1 Byte nicht die ersten 2Byte
Gast
#391130
Das erste Byte ist der sog. "Command Specifier" der den Typ des SDO-Pakets angibt...
Gast
#391131
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).
Gast
#597990
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?
Gast
#598753
Gast
#598866
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.
Gast
#598874
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.
Gast
#598952
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?
Gast
#600544
Hallo...... Hab zwar noch 0-Ahnung von CAN, aber ich wüde es so machen. Master holt Daten von Slave1 und sendet die Daten an Slave2. Slave2 lässt LED leuchten.?? Nicht so schwer, oder?? Meine Frage: 1. Ich hab einen CAN-Bus quer durchs Haus. Kann ich mit einem zweiten Master über die gleichen Leitungen Senden/Empfangen? (Kollision?) 2. Kann man mit einem yP(mit CAN Treiber) den Bus mitprotokollen (sniffen), damit man das laufende Protokoll entschlüsseln kann? Die Nodeaddressen hab ich! Sind Raumthermostate.
Gast
#601362
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.
Gast
#601577
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
Gast
#601597
Hallo Martin Schneider wie meinst du das genau? Ich deinen Beitrag nicht verstehen.
Gast
#601609
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
Gast
#601646
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?
Gast
#601721
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
Gast
#601799
Hi CANnie, recht herzlichen Dank für die Dokumente. Hab soeben mal reingeschaut, ist nicht schlecht.
Gast
#601834
Wer suchet, der findet. Noch besser, wenn man weiß, wo man suchen muss... Antwort schreiben |
Anzeige
|
