Hallo Forumgemeinde, ich habe eine Frage zur CAN Kommunikation. Ich habe mich in das Thema CAN eingearbeitet aber jetzt stehe ich vor dem Problem dass ich den Nutzen des Remote- Frame nicht ganz verstehe. Mein Aufbau: Ich habe drei Experimentierboards mit jeweils einem MCP2515. Ein Board soll ein Master sein und die andern zwei sind die Slaves. Die Slaves sollen nach "Power On" in einen "Wartezustand" gehen. Der Master sendet ein Broadcast das die Slaves Ihre Adresse senden sollen. Jetzt kommt meine Frage. Der Master sendet ein "Extended- Data Frame Broadcast Telegramm" den die beide Slaves empfangen. Wie sollen die Slaves mit Ihrer Adresse auf dieses Telegramm antworten? Soll ein Slave auf ein Extended Data Frame mit einem extended remote Frame antworten? Ein Remote Frame darf ja eigentlich keine Daten enthalten. Würde es also reichen das der Slave einfach seine ID als Adresse sendet und so hat der Master die Adresse? Aber wie bekommt der Master bestimmte Daten von einem Slave? Ich habe es so verstanden, dass ein remote Frame zum empfangen von Daten benutzt wird. Aber wie? Ich würde mich freuen wenn mir jemand eine Info dazu geben könnte. Vielleicht gibt es auch ein Link zu einer Seite auf der beschrieben ist wie so eine Master- Slave Kommunikation ablaufen sollte. Viele Grüße, Marcel
Hallo Otto, ja diesen Link kenne ich natürlich. Das erklärt aber nicht meine Frage wie die Slaves auf ein Broadcast- Telegramm antworten sollen. Soll die Antwort wieder ein "extended Data Frame" sein oder sollte es ein "extended remote Frame" sein. Grüße...
Hi klingt alles sehr nach einem Protokoll das auf dem CAN gefahren wird. CAN ist OSI Layer 2 (und mehr deckt CAN im OSI-Modell nicht ab) und kennt keine Master/Slave Beziehungen. Matthias
Hi, mich würde halt interessieren ob jemand schon soetwas ähnliches gemacht hat. Sollte als Antwort auf eine Anfrage ein Remote- Frame oder ein Daten-Frame folgen. Grüße...
1. CAN ist ein multimaster bus - es gibt keine slaves.. 2. ein von dir bezeichneter "remote frame" ist ein "remote REQUEST frame" ... dh ein teilnehmer kann damit ein bestimmtes telegram (data frame) anfordern, wenn es gerade gebraucht wird - dadurch kann man bei sporadisch benötigten daten sehr viel bandbreite sparen, da die daten nicht ständig auf den bus gesendet werden müssen. was du mit "adressen" machen willst ist mir nich ganz klar - möchtest du 1nen knoten als "master" definieren und die anderen als "slaves" und diese "slaves" sollen dynamisch bestimmte adressen bekommen ? 1...n ?
Hallo Andi D., ja genau. Es werden mithilfe der Slaves RGBW- LED's gesteuert. Die Slaves haben z.B. die Adresse 3 und 5. Bevor der Master, der den Farbverlauf steuert, seine Arbeit beginnt, muss er wissen wie viele LED- Treiber am CAN angeschlossen sind. Die Slaves können über DIP- Schalter adressiert werden. Daher wollte ich wissen wie die Slaves am besten auf einen Broadcast antworten sollen. Ist die Slaveadresse ein Data-Request oder nur ein Bestätigungstelegramm welches einfach als extended Data Frame gesendet werden kann. Ich bin mir sicher, das der eine oder andere das hier in ähnlicher weise schon mal gemacht hat. Grüße, Marcel
Lass die Finger von Remoteframes. Das ist bei jedem uC anderst implementiert. Ich habe damit schon die übelsten Effekte im Zusammenhang mit CANOpen erlebt. Auch die CiA sagt mittlerweilse dass Remoteframes nicht mehr unterstützt werden sollten.....
Marcel K. schrieb: > ja genau. Es werden mithilfe der Slaves RGBW- LED's gesteuert. Die > Slaves haben z.B. die Adresse 3 und 5. Bevor der Master, der den > Farbverlauf steuert, seine Arbeit beginnt, muss er wissen wie viele LED- > Treiber am CAN angeschlossen sind. Die Slaves können über DIP- Schalter > adressiert werden. Daher wollte ich wissen wie die Slaves am besten auf > einen Broadcast antworten sollen. Ist die Slaveadresse ein Data-Request > oder nur ein Bestätigungstelegramm welches einfach als extended Data > Frame gesendet werden kann. > Ich bin mir sicher, das der eine oder andere das hier in ähnlicher weise > schon mal gemacht hat. Guck dir doch mal an wie CANOpen das macht. Lehne dich doch einfach an was bestendes an. Gruß Eddi
Marcel K. schrieb: > ja genau. Es werden mithilfe der Slaves RGBW- LED's gesteuert. Die > Slaves haben z.B. die Adresse 3 und 5. Adressen gibt es beim CAN nicht, genau wie Slaves. Wie schon Matthias meinte, muß man da noch ein weieres Protokoll drüberstülpen, wenn man das will. Bevor der Master, der den > Farbverlauf steuert, seine Arbeit beginnt, muss er wissen wie viele LED- > Treiber am CAN angeschlossen sind. Die Slaves können über DIP- Schalter > adressiert werden. Daher wollte ich wissen wie die Slaves am besten auf > einen Broadcast antworten sollen. Es gibt beim CAN nichts anders als Broadcasts. > Ist die Slaveadresse ein Data-Request oder nur ein Bestätigungstelegramm > welches einfach als extended Data Frame gesendet werden kann. Extended Data Frame heißt erstmal nur, daß die CAN-ID der Botschaft 29 Bit breit ist. Beim Standard CAN wären es 11.
Hallo,
ich habe mir in den letzten Minuten nochmal genau übrlegt wie das sein
sollte. Ich denke ich habe den falschen Ansatz. Ich sollte weg von
Master/Slave- Gedanke.
Der "Farb- Master" sendet ein Broadcast mit seiner Adresse. Dann
Antworten die "Farb- Slaves" mit Ihrer Adresse an die Broadcast-
Adresse. Jeder hat die gleichen Rechte! Der "Farb- Master" empfängt die
Adressen der angeschlossenen "Farb- Slaves" und kennt so alle Adressen.
Alles über die "extended Data Frames"
>Ich denke das ist der bessere Weg!!!
Marcel K. schrieb: > Hallo, > ich habe mir in den letzten Minuten nochmal genau übrlegt wie das sein > sollte. Ich denke ich habe den falschen Ansatz. Ich sollte weg von > Master/Slave- Gedanke. > Der "Farb- Master" sendet ein Broadcast mit seiner Adresse. Dann > Antworten die "Farb- Slaves" mit Ihrer Adresse an die Broadcast- > Adresse. Dein Gedankengang mit Adresse ist irgendwie falsch. Am CAN Bus wird nichts in der klassischen Form adressiert. Jeder Teilnehmer legt einfach seine Daten auf den Bus und wen es auch immer interessiert, der holt sich diese Daten vom Bus. Die Idee hinter CAN ist es, eben keine Adressen zu verwenden. Da gibt es einen Knoten der legt ein CAN-Paket auf den Bus und dieses Paket ist so markiert, dass es die aktuelle Geschwindigkeit enthält. D.h. der Radsensor schreibt nicht ins Paket rein: An den Tacho, sondern der 'ruft ins Haus hinein': Wen es auch immer interessiert, wir fahren momentan 60km/h. Und wer auch immer mit dieser Information etwas anfangen kann, der wertet sie aus und reagiert entsprechend. Ob das der Tacho ist, der die Anzeige entsprechend einstellt oder der Autoradio, der daraufhin etwas lauter wird oder die Zentralverriegelung, die die Türen absperrt, all das interessiert den Radsensor nicht. CAN-Knoten stellen einfach nur ihre Informationen zur Verfügung. Es sind die Daten selbst die identifiziert werden. Die Idee hinter dem Request ist es, dass einer am Bus einfach mal in die Runde ruft: Ich bräuchte mal die Motordrehzahl! Wieder interessiert er sich nicht dafür, welcher Sensor dafür zuständig ist, er will einfach nur einen Wert haben, wer auch immer dafür zuständig ist, ihn zu liefern. Und der zuständige legt dann eben ein Paket auf den Bus, in dem die aktuelle Drehzahl drinnen steht. Und wieder kann sich das jeder holen, der es haben will. unter anderem derjenige, der die Information angefordert hat. Das ist die Idee hinter CAN. Natrülich kannst du jetzt anstelle der Zuordnung, dass die ID 54 die aktuelle Geschwindigkeit kennzeichnet auch so tun, als ob das die Adresse eines CAN Knotens wäre. Das kann dir keiner verbieten, aber die eigentliche Idee hinter CAN ist eine andere. D.h. löse dich von dem Gedanken, dass ein CAN-Knoten eine Adresse hat. Der ist für eine RGB-LED zuständig und die hat eine ID. Dein 'Master' ruft also ins Blaue hinein: RDB-LED im Wohnzimmer auf 58 setzen. Und wer dann auch immer für diese LED zuständig ist, der führt das aus. Das ein Knoten für diese LED zuständig ist, das kann der Knoten zb über ein Mäuseklavier erfahren. Im Endeffekt ist der Unterschied zur Adressierung gar nicht mal so groß. Aber die Denkweise ist eine andere.
Hi Bedenke das CAN keine Absenderadressen kennt. Es kennt eigentlich gar keine Adressen im eigentlichen Sinn. Ich würde deine Slaves mit einer über die DIP-Schalter einstellbaren ID (2, 4, 6, ...) senden lassen (zyklisch) Der "Master" empfängt einfach alle IDs und sendet dann die Einstellungen an diese ID + 1 auf die wiederrum die Slaves hören. Primitiv aber funktioniert. BTW Was sind das für LED-Module mit CAN? Matthias
Hallo Karl Heinz Buchegger, Danke für Deine ausfürliche Erklärung. Das weiß ich echt zu schätzen!!!!! Ich kenne die Idee von CAN natürlich weil ich schon einiges darüber gelesen habe. Aber Du hast Recht. Ich bin da vom Thema abgekommen da ich gerne Adressieren wollte! Ich finde es gut, dass Du mich nochmal auf den Grundgedanken von CAN gebracht hast! Ich werde mein Vorhaben nochmal überdenken. Vielen Dank für Deinen hilfreichen Beitrag!
Hallo Matthias, das sind natürlich Module im Eigenbau!! ;o) Ich habe die ganze Zeit mit RS485 gearbeitet aber ich fand CAN sehr intersannt da ich mich um keine Kollision mehr kümmeren muss.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.