Hallo Gemeinde, ich habe hier im Forum schon gesucht und das Gewünschte nicht gefunden. Es geht um eine CAN-Bus_2.0A-Anwendung mit ca. 20 Teilnehmern. Diese müssen unterscheidbar sein und idealerweise am Strang in aufsteigender Reihen folge (1-20) erscheinen. Die Crux ist jetzt, dass die CAN-Nodes in rauher Umgebung betrieben werden und physisch eigentlich nur ein vergossenen Klötzchen sind. Es gibt keine Drehschalter und keine Mäuseklaviere um eine Teilnehmeradresse zu vergeben. Im Auslieferungszustand könnte per Definition die Teilnehmeradresse "0" sein. Meines Wissens gibt es eine "Daisy Chain"-Lösung, bei der alle Teilnehmer mit einer ankommenden und einer abgehenden Digitalleitung nacheinander aktiviert werden. Wenn sie eine gültige Teilnehmeradresse haben oder eine von einem Master erhalten haben schalten sie die abgehenden Digitalleitung ein, und der nächste Teilnehmer mit Teilnehmeradresse "n+1" kommt an den Bus. Weiterhin könnte man eine Art Analogschalter für den weiterführenden CAN-Strang in Betracht ziehen. Der weiterführende CAN-Strang wird dann eingeschaltet, wenn der aktuelle Teilnehmer eine gültige ID hat (oder ausgehandelt hat). Was aber, wenn der Fall auftritt, dass zwei Teilnehmer exakt die gleiche CAN-ID haben? Also z.B. "Teilnehmer n" ID = 4 = OK; "Teilnehmer n+1" ID = 4 = falsch Ist dann noch der Fall unterscheidbar und können die Nodes eine "richtige" Teilnehmeradresse beziehen? Ein Tipp wäre hilfreich. Grüße Runout
Alle Geräte haben eine Input- und eine Output-Leitung für Daisy-Chain (im folgenden DC genannt). Alle Geräte sind am CAN verbunden und senden ohne gültige ID-Vergabe erstmal nichts sondern hören nur zu. 1. Beim Eintreffen einer Nachricht zur ID-Neuvergabe auf z.B. 0x7F0 (auf die alle Geräte IMMER hören) vergessen alle Geräte ihre ID und schalten ihren eigenen DC-Ausgang logisch "1". Das erste Geräte hat den DC-Eingang offen und sieht logisch "0". 2. Jetzt wird auf 0x7F0 dazu aufgefordert, die erste ID zu vergeben. Das Gerät, dass noch nicht konfiguriert ist UND dessen Eingang auf "0" ist, akzeptiert die Nachricht (im ersten Moment das erste Gerät). Konfiguriert seine eigene ID UND deaktiviert seinen Ausgang. 3. Der Erfolg kann auf z.B. 0x7F1 gemeldet werden oder der Master macht einfach mit einer gewissen Wartezeit weiter. 4. Das Spiel wiederholt sich, bis keine Antwort mehr kommt (oder wenn keine Antwort vom Knoten vorgesehen ist, einfach nach Nmax Messages). 5. Der Master meldet oder gleicht ab, wie viele Knoten gefunden wurden. Ggf. gibt es noch einen Funktionstest Anmerkungen: - Mit jeder neuen ID-Vergabe kann eine spezifische ID vergeben werden oder man gestaltet es so, dass einfach durchnummeriert wird. - Ich würde davon absehen, dieses Spiel jedesmal beim Start zu durchlaufen. Besser die Geräte merken sich ihre Konfiguration. Man macht einen gesonderten Ablauf bei der Inbetriebnahme, damit der ganze Ablauf unter Beobachtung abläuft.
CAN hat keine Teilnehmeradressen. Du hast Message-IDs und die müssen eindeutig sein. Die Message-IDs sind aber nicht bestimmten Nodes zugeordnet. Jeder Node kann beliebige Message-IDs senden und auf beliebige Message-IDs reagieren. Du kannst natürlich entscheiden bestimmte Message-IDs bestimmten Nodes zuzuordnen, sowohl was den Empfang als auch Versand angeht. Mein Vorschlag: verpass jedem Node bei der Herstellung eine unveränderbare GUID, also global eindeutige ID. Viele Microcontroller haben sowas schon fertig eingebaut, kann man aber z.B. auch als EEPROMs fertig vorprogrammiert kaufen. Jetzt lässt Du immer jeden Node alle paar Sekunden seine GUID mit einer bestimmten Message-ID seine GUID senden. Den genauen Abstand zwischen den Nachrichten absichtlich mit etwas Zufall versehen. Wenn man jetzt eine Weile auf dem Bus lauscht bekommt man die GUIDs aller angeschlossenen Geräte. Und dann vergibst Du eine Message-ID mit der ein Gerät per GUID gezielt angesprochen werden kann. Damit kannst Du dann z.B. eine LED an dem Gerät aufleuchten lassen um es von den anderen zu unterscheiden. Und genauso ihm eine individuelle Message-ID zuordnen über die es dann in Zukunft angesprochen werden kann. Alternativ kann man natürlich auch die GUIDs jedes Nodes auf einen Barcode drucken und auf jeden Node aufkleben, auflasern etc.
Können die Nodes zur Konfiguration vom Bus genommen werden? Es gibt im CANopen z.B. das LSS-Protokoll, das ist für genau so eine Konfiguration gemacht. MfG
Beim J1939 gibt es den "Address Claimed"-Mechanismus, der dafür sorgt, dass anfänglich identische Knoten unterschiedliche Knotennummern bekommen. Aufsteigend nach mechanischer Anordnung wird das allerdings nicht.
CAN ist dafür einfach ungeeignet und erfordert eine parallele Daisy-Chain, eine eindeutige ID (z.B. eine Seriennummer oder eine MAC-Adresse) oder eine manuelle gewählte Adresse. Ein Vorteil von CAN ist, dass z.B. mit einer MAC-Adresse eine Adressierung direkt über das Protokoll problemlos möglich ist. Auf eine Anfrage "wer ist da und noch nicht adressiert" können alle gleichzeitig antworten und nur ein Telegramm gewinnt. Der Master sendet nun ein "Adressierungstelegramm" mit der 1 und dieser MAC-Adresse. Das Device ist nun adressiert. Und dann geht es genauso weiter, bis alle adressiert sind. (Das ist ähnlich Gerts GUID, nur braucht es keine "Variationen")
Verstehe die Frage nicht ganz. Vielleicht passt meine Antwort daher überhaupt nicht zu dem, was du wissen wolltest: Wenn man mitbekommt, dass 2 Teilnehmer die gleiche Adresse haben, dann muss die ganze Adressierung eben neu gemacht werden. Mitbekommen kann man das, indem man eine Nachricht von einem Teilnehmer empfängt, die man eigentlich nur selbst senden sollte. Daraufhin muss man eben eine Bus neu Adressierung auslösen. Einfaches Beispiel: alle Teilnehmer senden regelmäßig eine Nachricht mit ihrer Adresse als ID. Wenn einer nun so eine Nachricht empfängt ohne sie selbst gesendet zu haben, ist wohl was verkehrt. Dann sendet er ein Signal zum neu Adressieren. Alle vergessen ihre Adresse und mithilfe der Daisy Chain gibt's neue Adressen für alle Wenn beide Teilnehmer mit der gleichen Adresse gerade zufällig zur selben Zeit senden, würde man das erstmal nicht mitbekommen. Je nach Anwendung kann man dann sagen egal, beim nächsten Mal wird's wohl nicht wieder gleichzeitig sein oder man muss eben noch irgendeine Form von unique identifier anhängen.
Gerd E. schrieb: > Mein Vorschlag: verpass jedem Node bei der Herstellung eine > unveränderbare GUID, also global eindeutige ID. Viele Microcontroller > haben sowas schon fertig eingebaut, kann man aber z.B. auch als EEPROMs > fertig vorprogrammiert kaufen. Allerdings sind die weltweit eindeutig und haben deshalb (zu) viele Bits. Wie kann man daraus kürzere Adressen machen, die trotzdem garantiert eindeutig sind? Geht das irgendwie?
Ja. Indem der Master jeder GUID eine aufsteigende Zahl zuordnet. Der ersten, die er hört, die 1. Auf can-msg 4711 sendet jeder neue Teilnehmer seine GUID. Ruhig gleichzeitig, das ist ja die Stärke von can, dass einer gewinnt und keiner zerstört Auf can msg 4712 ordnet der Master einer GUID eine Adresse zu. Wer seine hat, sendet nicht mehr auf 4711. Einen Master braucht es nicht unbedingt, aber ohne ist bei der config des TO kaum sinnvoll
:
Bearbeitet durch User
Bauform B. schrieb: > Allerdings sind die weltweit eindeutig und haben deshalb (zu) viele > Bits. Wie kann man daraus kürzere Adressen machen, die trotzdem > garantiert eindeutig sind? Geht das irgendwie? Ja, so in etwa wie Bruno geschrieben hat. Du hast die langen GUIDs, die werden nur für die initiale Erkennung und Zuweisung einer individuellen Message-ID verwendet. Die eigentliche Kommunikation läuft dann über die kurzen, individuellen Message-IDs. Was ich anders machen würde als Bruno schrieb ist, dass ich die GUIDs immer senden würde, auch wenn einmal individuelle Message-IDs bereits zugeordnet wurden. Und zwar kann es sein dass durch einen Fehler, Umbau, Tausch einzelner Nodes etc. es nötig wird die Zuweisung neu zu machen. Das ist einfacher wenn die GUIDs ständig gesendet werden. Muss ja nur alle paar Sekunden sein, auf dem Bus ist in den meisten Fällen genug Zeit für sowas frei. Und man kann dafür ja auch eine Message-ID mit niedrigster Priorität verwenden, dann stören die nicht.
Bruno V. schrieb: > Ruhig gleichzeitig, das ist ja die Stärke von can, dass einer gewinnt > und keiner zerstört Setzen 6 Die Arbitrierung erfolgt nur auf die Nachrichten ID. Werden zwei Nachrichten mit gleicher ID und unterschiedlichem Inhalt zeitgleich ausgegeben erkennen beide TN dass die CRC ihrer Daten nicht stimmt und senden ein Error auf dem Bus und alle verwerfen die Nachricht.
Clemens S. schrieb: > Bruno V. schrieb: >> Ruhig gleichzeitig, das ist ja die Stärke von can, dass einer gewinnt >> und keiner zerstört > > Setzen 6 Stimmt. Sorry und Danke.
Hallo Gemeinde, vielen Dank für die guten Anregungen. von Stephan S. (plonk) 21.04.2026 18:18 Können die Nodes zur Konfiguration vom Bus genommen werden? Nein, das System wird fertig montiert und danach wird die Zuweisung der Nodes durchgeführt. Das CANopen/LSS-Protokoll schau ich mir an. Ebenso die Eindeutigkeit der Nodes über eine GUID. Grüße Runout
Thomas T. schrieb: > Meines Wissens gibt es eine "Daisy Chain"-Lösung, bei der alle > Teilnehmer mit einer > ankommenden und einer abgehenden Digitalleitung nacheinander aktiviert > werden. CAN hat - wie der Name schon sagt - eine Bus-Struktur die keine ankommenden und abgehenden Leitungen kennt.
Dieter W. schrieb: > die keine > ankommenden und abgehenden Leitungen kennt. CAN nicht, aber die vom TO erwähnte und von Harald erläuterte Version mit zusätzlicher Leitung ist nicht unüblich. Das kann ein Digitaler Eingang + Ausgang sein oder der vorherige schaltet jeweils die Spannungsverorgung des nächsten ein. Manche haben das früher auch mit Relais gemacht. Ich bin kein Freund davon, da ich die Vorteile der Dasy-Chain zu schätzen weiß, was Durchsatz und Fehlersuche angeht. Aber wer es gebrauchen kann, gerne. Harald A. schrieb: > Alle Geräte haben eine Input- und eine Output-Leitung für Daisy-Chain > (im folgenden DC genannt). Alle Geräte sind am CAN verbunden und senden > ohne gültige ID-Vergabe erstmal nichts sondern hören nur zu. > > ...
:
Bearbeitet durch User
Bruno V. schrieb: > CAN nicht, aber die vom TO erwähnte und von Harald erläuterte Version > mit zusätzlicher Leitung ist nicht unüblich. Das kann ein Digitaler > Eingang + Ausgang sein Da musst Du aber ziemlich aufpassen was Common-Mode-Probleme angeht. Wenn Du z.B. einfach direkt auf einen Pin vom Prozessor gehst, kann das Dir schnell den Controller braten. Man könnte jeweils 2 Drähte nehmen und damit einen Optokoppler im nächsten Node treiben. Dann ist das eine Stromschnittstelle und keine Common-Mode-Probleme mehr zu erwarten. Aber in rauhen Umgebungen sind zusätzliche Drähte und größere Stecker oft recht teuer umzusetzen, weil das da alles mechanisch robust, wasserdicht etc. ausgeführt werden muss. Von daher muss man sich gut überlegen ob die dadurch mögliche vollautomatische Adressierung wirklich so wichtig ist im Vergleich zu einem einmaligen Einlernvorgang.
Bei mir ist das ein open-collector Ausgang und ein analoger Eingang mit starkem Pull-Up speziell für diesen Zweck. D.h. die haben Schutzbeschaltung gegen allerlei Fehler (Kurzschluss, Überspannung, negative Spannung, etc.) und die Schaltschwelle ist großzügig ausgelegt, z.B. unterhalb 1/3 UB ist logisch "1" und oberhalb 2/3 UB logisch "0", dazwischen Hysterese. Klar, das System hat bzgl. Common-Mode trotzdem Grenzen. Dieses System vs. vorherige feste ID-Vergabe: Für das Ersatzteilgeschäft ist das mit dem Daisy-Chain eine feine Sache, denn der Monteur braucht das neue Gerät nur einbauen und den Einlernprozess starten (wie auch immer der dann benannt wird). Für eine feste ID muss der Monteur einen CAN-Programmieradapter nebst funktionierender SW haben oder das Ding muss spezifisch im Werk bestellt werden. Im letzteren Fall ist dann noch die spannende Frage, wie der Prozess zwischen Lager und Versand aussieht. Kann das jemand in der Logistik bewerkstelligen? Wie ist das Teil überhaupt gekennzeichnet, dass es vor Auslieferung einer Einstellung bedarf? Oder ruft die Logistik jedesmal in der Entwicklung und fragt nochmal nach, was damit geschehen muss? Wissen alle Bescheid? Und klappt das auch im Notdienst/Wochenende?
:
Bearbeitet durch User
Harald A. schrieb: > Dieses System vs. vorherige feste ID-Vergabe: Für das Ersatzteilgeschäft > ist das mit dem Daisy-Chain eine feine Sache, denn der Monteur braucht > das neue Gerät nur einbauen und den Einlernprozess starten (wie auch > immer der dann benannt wird). klar, das ist der Vorteil. > Für eine feste ID muss der Monteur einen > CAN-Programmieradapter nebst funktionierender SW haben oder das Ding > muss spezifisch im Werk bestellt werden. Na das wäre dann aber echt schlecht gemacht. Du wirst in diesem Konzept ja irgendeinen Master-Controller oder sowas haben in dem man über irgendeine Bedienschnittstelle den Einlernprozess startet. Und der kann dabei natürlich auch das Lauschen auf die GUIDs und Vergabe der individuellen Message-IDs implementieren. Sagen wir mal Du implementierst die von mir oben zuerst vorgeschlagene Variante mit der LED an jedem CAN-Node. Beim Einlernen aktiviert der Master jetzt per gezielter Nachricht an eine GUID irgendeine der LEDs. Du drückst jetzt eine "Nächster"-Taste am Master bis die LED vom ersten CAN-Node leuchtet. Dann drückst Du "Ok". Jetzt leuchtet wieder die LED an irgendeinem Node außer dem ersten. Du drückst die "Nächster"-Taste bis Du die vom 2. Node hast und so weiter. Diese Erkennung kann man natürlich auch anders als mit LEDs machen. Man kann z.B. Phototransistoren einbauen und die mit ner Taschenlampe anblinken, so wie es die Stromzähler machen. Oder nen kleinen Hallsensor in den Dingern verbauen und mit einem Magnet mehrfach drangehen oder ähnliches. Da müsste man die genauen Gegebenheiten der Nodes kennen um die beste Variante zu finden. Natürlich musst Du den Anlernvorgang irgendwo dokumentieren.
:
Bearbeitet durch User
Gerd E. schrieb: > Na das wäre dann aber echt schlecht gemacht. > > Du wirst in diesem Konzept ja irgendeinen Master-Controller oder sowas > haben in dem man über irgendeine Bedienschnittstelle den Einlernprozess > startet. Und der kann dabei natürlich auch das Lauschen auf die GUIDs > und Vergabe der individuellen Message-IDs implementieren. Naja, er hat keine Angaben zu seinen Anforderungen gemacht und hat schon eine gute Lösung. Es gibt genügend Anwendungen ohne GUID oder wo die Reihenfolge die Funktion bestimmt. Auch bei anderen "Bussen" (Interbus, Ethercat). Gleichartige Sensoren (z.B. 0-10V) werden hintereinander gesteckt und der erste misst (in dieser Anwendung) den Druck, der zweite die Temperator oben, der dritte unten, ... Der Vorteil: Der Servicetechniker muss quasi nur den "Verdrahtungsplan" kennen und kann beliebige Kreuztests machen.
Bruno V. schrieb: > CAN nicht, aber die vom TO erwähnte und von Harald erläuterte Version > mit zusätzlicher Leitung ist nicht unüblich. Ja. Der Nachteil ist halt, das ein bis zwei Adern mehr benötigt werden, was die Kosten für die Verkabelung und Kontaktierung in die Höhe treibt. Die einzige Alternative ist, eben keinen Bus (im engeren Sinne) zu benutzen, sondern jeden Teilnehmer als bidirektionalen Repeater zu betreiben. Das hat dann natürlich wieder andere Nachteile, insbesondere den Sachverhalt, das ein ausgefallenes Gerät alle "dahinter" liegenden auch von der Kommunikation abschneidet. Das kann man aber mit Watchdog und Relais-Bypass gut bekämpfen. Zumindest, wenn die Gesamtlösung mit kurzzeitigen Kommunikationsausfällen im Bereich einiger ms noch leben kann. Denn so lange dauert es leider, bis so ein Bypass-Relais umschaltet.
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.