Hi Leute, Vorstellung: ich habe an einem CAN Bus mehrere Geräte. Jetzt will ich mit einem Tastendruck an einem beliebigen Gerät alle anderen Geräte aufwecken. Dazu würde ich z.B. MSG-ID 1 nehmen und damit allgemein ON signalisieren. Jetzt dürfen ja eigentlich keine zwei Sender die gleiche ID benutzen können, weil dann Kollisionen auftreten. Fällt jemandem eine intelligente Lösung dazu ein, ohne dass ich z.b. sage alle Nachrichten IDs von z.B. 1-15 sind ON-Messages und jedes Gerät nimmt seine "eigene ON-ID"? Diese Problematik tritt ja immer auf, wenn ich eine "Anweisung" von mehreren Stellen versenden kann und nicht nur "selbst produzierten inhalt" kund tun will. CANopen scheint ja eine Lösung zu haben, aber die Beschreibung auf der Webseite http://www.can-cia.org find ich nicht gerade verständlich. Ich bin gerade am evaluieren von Bus Systemen. Eckdaten: Kabellänge >20m möglich, >100kbit/s, Multimaster-Fähig Vielleicht hat ja jemand noch andere Anregungen. Gruß Fabian
Wenn du für den Wakeup unterschiedliche IDs verwendest, hätte das den Vorteil, daß du über diese Nachrichten die Teilnehmer auch schlafen schicken könntest. So funktioniert das z.B. im automotive Bereich, das Stichwort heißt hier NetzwerkManagement. Rein zum Aufwecken ist die ID doch egal, da die CAN Transceiver den Wakeup generell bei CAN Bus Aktivität auslösen. Du könntest den Aufweckenden Knoten auch einfach seine normalen Botschaften senden lassen und alle würden aufwachen.
Das Wakeup war hauptsächlich als Beispiel gedacht...is schwer zu erklären. Ich hab halt das Problem, dass mehrere Geräte prinzipiell die gleiche ID senden können müssten und ich suche nach einem Ausweg, da die Geräte per-se erstmal nicht wissen wen es sonst noch im Netz gibt. Anderes Beispiel: Ich will einen Motor einschalten der an einem CAN-Bus-Teilnehmer hängt. Der Einschalt-Befehl kann von beliebigen unabhängigen anderen Teilnehmern kommen, die nichts von einander wissen müssen. Wie kann ich hier effizient dafür sorgen, dass ich keine gleichen IDs von unterschiedlichen Teilnehmern aufm Bus habe? Gruß Fabian
Hallo, CAN ist doch Nachrichten ID basiert. Siehe Wikipedia: Der Objektidentifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht. Zudem dient der Objektidentifier auch der Priorisierung der Nachrichten. Du musst die Filter der Geräte am Bus entsprechend konfigurieren so, dass sie auf die Nachrichten reagieren. Im Grunde ist also JEDE Nachricht eine Broadcast Nachricht. D.h. du kannst eine Nachricht "WECKE ALLE" definieren und bei den Geräten bekannt machen so dass alle darauf reagieren. Nächtle :-)
Das ist schon klar, kenne den Artikel ;-) Aber in diesen Beschreibungen geht es immer nur um das Broadcasten "selbst produzierter" Daten. CAN muss doch aber auch als Steuerbus nutzbar sein, also, dass ein Gerät sagt "mach-das". Und wenn jetzt dieses "mach-das" von mehreren, einander unbekannten, Geräten kommen könnte, habe ich u.U. Arbitierungsprobleme. Wie löse ich das? Wie machen das die Leute bei HomeAutomation... da gibts doch auch viele Lichtschalter, die eine Lampe einschalten wollen. Da müsste dann ja jeder Schalter eine eigene ID zum versenden haben, damit nix kollidiert. Gruß Fabian
Gute Frage, wie man das löst. Ich glaube auch, daß es zu Arbitrierungsproblemen kommen kann, wenn die Knoten die selbe ID senden. In meinen Augen gibt es mehrereMöglichkeiten: 1. Du verwendest unterschiedliche IDs 2. Du verwendest nur eine ID und trägst den Arbitrierungsproblemen Rechnung, indem z.B. der Dateninhalt weggelassen wird (DLC = 0). In dem Fall wäre es ja theoretisch egal, ob es Kollisionen gibt. 3. Du baust ein eigenes Protokoll auf, das auf CAN zurückgreift. So könntest du z.B. eine Ringbotschaft definieren, die immer die selbe ID hat, aber im ersten Datenbyte den Empfänger enthält. Wenn der Empfänger die Botschaft empfangen hat, so sendet er ebenfalls auf der ID, aber mit einer anderen Empfänger Adresse. Das ganze funktioniert natürlich nur, wenn keiner der Empfänger fehlt. Bei der HomeAutomation gehen die Lichtschalter doch sicherlich erst an einen Zentralen Rechner, der dann die Verknüpfung zu den Aktuatoren ( z.B. Licht) herstellt. Da wird es doch schon so sein, daß jeder Teilnehmer seine eigene ID hat, oder?
Warum sollte es zu Arbitrierungsproblemen kommen?
Nehmen wir an Gerät A und Gerät B legen die selbe Botschaft auf den Bus.
Beide Nachrichten sind doch identisch.. also genau die gleiche Bitfolge,
genau die gleichen dominanten und rezessiven Pegel. Da wird ja nix
destruktiv zerstört.. die Nachricht gelangt auf den Bus!
CAN ist doch CSMA/CA... und nicht CSMA/CD wie bei Ethernet! Dort
entsteht Müll auf der Leitung ("JAM").. und nach ein zufälligen Zeit
wird die Aussendung wiederholt.
CAN ist "Collision Avoidance" Kollisions Vermeidung. Da gibts sowas net.
ALso können meiner Meinung nach beide GEräte die gleiche Nachricht ohne
Probleme senden.
> Nehmen wir an Gerät A und Gerät B legen die selbe Botschaft auf den Bus. > > Beide Nachrichten sind doch identisch.. also genau die gleiche Bitfolge, > genau die gleichen dominanten und rezessiven Pegel. Da wird ja nix > destruktiv zerstört.. die Nachricht gelangt auf den Bus! Jup, die Probleme treten erst auf, wenn die Nutzdaten unterschiedlcih sind. Deswegen schrieb ich ja, der Dateninhalt sollte gleich ganz weggelassen werden.
Ah, ok. Gerät A und Gerät B könnten ja intelligente Sensoren sein, die einen Aktor GErät C ansprechen, welcher die Temperatur regelt. Mhm, wenn beide Geräte nun berechtigt sind Gerät C mit der gleichen ID zu steuern hat man meiner nach ein grundsätzliches Problem. Z.B. Gerät A sendet: Temperatur auf 25 °C regeln Gerät B sendet: Temperatur auf 40 °C regeln Gerät C würde dann versuchen einmal auf 25 °C zu regeln und dann wieder auf 40 °C. Das ist so als wollten 2 Leute "gleichzeitig" einen Lichtschalter benutzen, der eine möchte das Licht einschalten, der andere aber aus. Aber grundsätzlich ist es möglich. Es kommt meiner Meinung nach zu Konflikten, aber nicht zu Kollisionen. Ansonsten entscheiden die Bits der Parameter über die Priorität.. ;-)
Ich hatte mal ein sehr ähnliches Problem. Jeder Teilnehmer hat eine eigene ID. Für eine Sonderfunktion wurde eine bestimmte ID + Length = 0 gesendet, wie oben schon mal erwähnt. Das hat jeder Teilnehmer verstanden und Arbitrierungsprobleme gibts dann auch nicht. Hat wunderbar funktioniert.
Es gibt ja auch immer noch die Möglichkeit der Maskierung/Filterung. Können beispielsweise die Microchip CAN-Controller (wobei ich wetten könnte, daß alle anderen marktüblichen das auch können). Dann nimmst Du im Identifier die ersten x Bit als gleiche "Wake-Up-Adresse" und die restlichen Bits zur eindeutigen Identifizierung der Message. Musst dazu halt die richtigen Masken/Filter setzen. Grüße, TommyS
Verwende extended CAN-IDs mit 29Bit und definiere davon (z.B.) die oberen Bits als Zieladresse und die unteren Bits als Absendeadresse. Beispiele: Teilnehmer1 schickt an Teilnehmer2 die ID 0x00020001 (anschliessend Nutzdaten). Teilnehmer 57 schickt an Teilnehmer 99: 0x00990057... Der Empfänger maskiert die unteren Bits einfach aus, um zu prüfen, ob die Nachricht für ihr bestimmt ist. Damit hast du dann keine Probleme mit 2 gleichen IDs auf dem Bus.
Danke schomal für die vielen Antworten. Jedem Teilnehmer eine eigene ID verpassen, wollte ich eigentlich vermeiden, da das ja dem Sinn der Message-ID-Basierten Kommunikation entgegenläuft, Da muss ich dann u.U. ja meine Maske auf FFF (alles egal) setzen. Aber ein Teil, z.b. 6 Bits könnte man als eindeutige Adresse nehmen und die vorderen 5 Bit geben noch den Nachrichteninhalt an...so könnte man etwas vorfiltern. Aber eine Methode die hinteren 6 Bits "automatisch" zu ermitteln hat scheinbar noch keiner, oder? Ich will vermeiden, dass ich in jedem Gerät 6 Dip-Switches haben muss und bei falscher Bedienung doch wieder Mist passiert. DeviceNET hat laut Beschreibung ja irgendeine intelligente Methode um automatisch eindeutige Adressen zu wählen, aber ich finde das nirgends genauer beschrieben. Aber nochmal zur HA zurück. Ich habe z.B. 20 Lichtschalter in der Wohnung. Muss ich die dann alle per Software, oder Schalter auf eine eindeutige ID setzen und jede Lampe lauscht dann auf allen diesen IDs (via Maske), oder geht das dort anders? Gruß Fabian
CANopen scheint es auch so zu machen, dass die CAN-ID zum Teil aus einer eindeutigen Node-ID besteht...ne andere Möglichkeit sehe ich jetzt erstmal auch nicht. Trotzdem wäre interessant wie das die leute aus der Home Automation lösen, weil man mit dieser Methodik entweder immer sehr viele Nachrichten verarbeiten muss (weiter Filter) oder auf wenige Nodes beschränkt ist. Kennt sich da keiner aus? Gruß Fabian
> Trotzdem wäre interessant wie das die leute aus der Home Automation > lösen, weil man mit dieser Methodik entweder immer sehr viele > Nachrichten verarbeiten muss (weiter Filter) oder auf wenige Nodes > beschränkt ist. > Kennt sich da keiner aus? > Naja, die 29bit einer extended MsgID sind ja eine ganze Menge, da kann man einiges mit machen. Ich habe neben Ziel- und Senderadresse (je 8 bit, so ähnlich wie Gast333 es beschreibt) auch 5 bit für eine Gruppenadresse reserviert, sowie weitere 5-bit, die die Art der Nachricht (z.B. Temperatur, Uhrzeit o.ä) beschreiben. Als Controller verwende ich Atmel AT89C51CCxx. Der hat 15 Message Objekte zur freien Verwendung. Eines ist für TX reseviert, bleiben 14 mögliche zum Empfang von Nachrichten. Da kann ich also 14 verschiedene Filter setzen z.B: MO1: empfange alle Nachrichten, die an Gruppe 0b00001 gerichtet sind MO2: empfange alle Nachrichten, die an "meine" Node-ID gerichtet sind MO3: empfange alle Nachrichten, die von Node-ID soundso kommen MO4: empfange alle Nachrichten deren Inhalt Temperaturwerte sind oder etwas komplexer zu MO4 MO4(a): empfange alle Nachrichten deren Inhalt Temperaturwerte sind und an Gruppe 0b01000 gerichtet sind ...usw vielleicht hilft das weiter. Gruß -Holger P.S. Mit welchen Parametern die Message-Objekt-Filter zu initialisieren sind, steht natürlich im E(E)PROM, dann braucht man keine DIP-Switches.
Die Nachricht von Gast333 hab ich vorhin gar nicht gesehn, die hat sich wohl mit meiner Zeitlich grad überschnitten. Aber die Anregungen sind erstmal gut, danke! Jetzt muss ich mir "nur noch" eine Methode zum automatischen vergeben/erkennen der "eigenen" ID überlegen...also wie lernen die Geräte welche ID noch frei ist. Gruß Fabian
> Jetzt muss ich mir "nur noch" eine Methode zum automatischen > vergeben/erkennen der "eigenen" ID überlegen...also wie lernen die > Geräte welche ID noch frei ist. Das dürfte schwierig machbar sein *). Gib' jedem Knoten vorab eine eindeutige Adresse! Die kann (wie schon erwähnt) im EEPROM liegen zusammen mit allen weiteren Filterparametern. -Holger *) und ich sehe auch keinen Sinn darin. Wie willst Du dann einen bestimmten Knoten erreichen, wenn dessen ID dynamisch zugewiesen wurde, woher weißt Du dessen ID?
Noch was: Überschätze die Hardwarefiltermöglichkeiten nicht. Es ist in aller Regel kein Problem eine Softwarefilterung im CAN-RX-Interrupt zu machen. Ein solcher Interrupt kann sehr kurz gehalten werden, wenn die Botschaft nicht für den Knoten bestimmt ist (Laufzeit nur wenige µs; ich sag mal max.5..10µs; dürfte für die meisten µC mit integriertem CAN-Interface hinkommen). Bei einer Baudrate von 100kBit/s bekommst du ~1 Botschaft pro ms, d.h. du hast durch deine Softwarefilterung eine Auslastung deines Prozessors von max. 0.5..1% (bei 100% Buslast!), die du durch Hardwarefilterung sparen könntest - also vernachlässigbar wenig.
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.