mikrocontroller.net

Forum: Haus & Smart Home CanOpen Telegramm Aufbau


Autor: David Hartung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: David Hartung (Gast)
Datum:

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

Autor: Michael S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cnud Grevenitz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: smay4finger. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: David Hartung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 |

Autor: David Hartung (Gast)
Datum:

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

Autor: Jörn Ihlenburg (Gast)
Datum:

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

Autor: Stephan Tratter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gast123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo......

Autor: T. A. (wambly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

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

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: CANnie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Patrick (Gast)
Datum:

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

Autor: CANnie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer suchet, der findet.
Noch besser, wenn man weiß, wo man suchen muss...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.