mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN Adressierungproblematik


Autor: Fabian B. (fabs)
Datum:

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

Autor: peterguy (Gast)
Datum:

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

Autor: Fabian B. (fabs)
Datum:

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

Autor: schobbe (Gast)
Datum:

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

Autor: Fabian B. (fabs)
Datum:

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

Autor: peterguy (Gast)
Datum:

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

Autor: schobbe (Gast)
Datum:

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

Autor: peterguy (Gast)
Datum:

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

Autor: schobbe (Gast)
Datum:

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

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

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

Autor: TommyS (Gast)
Datum:

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

Autor: Gast333 (Gast)
Datum:

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

Autor: Fabian B. (fabs)
Datum:

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

Autor: Fabian B. (fabs)
Datum:

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

Autor: Holger T. (holgert)
Datum:

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

Autor: Fabian B. (fabs)
Datum:

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

Autor: Holger T. (holgert)
Datum:

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

Autor: Gast333 (Gast)
Datum:

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

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.