Hallo zusammen,
ich arbeite gerade an einem Taufverfahren für mehrere CAN-Bus
teilnehmer.
Kuckts euch doch mal an, wenn ihr Tipps zur verbesserung / vereinfachung
habt nur her damit :-)!
Das Hauptziel sollte sein, das die Geräte untereinander verhandeln und
so wenig Intelligenz wie möglich beim Master liegen sollte, da der
Master nicht in meiner Hand liegt und es schwer wäre irgendwelche
komplizierten Algorithmen an andere Hersteller zu kommunizieren.
Hier mal die Grobübersicht des zu erstellenden systems.
______
| |
| Master |
|________|
|
____________________|_________CAN___________________
| | | |
Slave 1 Slave 2 Slave 3 Slave n
Also man nehme an das jeder der Slaves das gleiche Gerät ist mit
gleicher Software und Hardware, nur unterschiedlicher Seriennummer.
Werden jetzt mehrere an das CAN-Netzwerk angeschlossen können diese
natürlich nicht mit der gleichen ID senden, sonst weiß der Master ja
nicht von wem es kommt.
Mein Plan jetzt:
1. Gerät 1 wird angeschlossen und frägt ob es Nr 1 schon gibt.
-> wartet 10 sek -> keine Meldung also legt Gerät 1 Base ID auf z.B.
0x110
2. Gerät 2 wird angeschlossen und frägt ob es Nr 1 schon gibt.
-> wartet 10 sek -> Gerät 1 sagt ja ich bin hier.
-> Gerät 2 frägt ob es Nr 2 schon gibt.
-> wartet 10 sek -> keine Meldung also legt Gerät 2 Base ID auf z.B.
0x120
3. Gerät 3 wird angeschlossen und frägt ob es Nr 2 schon gibt.
-> wartet 10 sek -> Gerät 1 sagt ja ich bin hier.
-> Gerät 3 frägt ob es Nr 2 schon gibt.
-> wartet 10 sek -> Gerät 2 sagt ja ich bin hier.
-> Gerät 3 frägt ob es Nr 3 schon gibt.
-> wartet 10sek -> keine Meldung also legt Gerät 3 Base ID auf z.B.
0x130
So mal das angedachte prozedere, jetzt muss dem Master nur irgendwie
mitgeteilt werden welche seriennummer zu welcher Base-ID gehört. Dazu
senden die Geräte ab und zu eine Message mit der Seriennummer in der
Base-ID um die Daten richtig zuordnen zu können.
Wie findet ihr dieses Verfahren? Es ist noch nicht komplett definiert
aber mal im Ansatz halt.
Über feedback würde ich mich freuen!
VG
Florian
Finde ich zu umständlich, besonders wenn der Master dann eine Zuordnung SNr - Bus ID vorhalten muss. Lass doch die Slaves ihre Bus ID aus der Seriennummer erzeugen.
Es kommt drauf an, was dir als Zuordnung wichtig ist. Bei deinem Ansatz sorgst du für eindeutige IDs, aber eine richtige Zuordnung fehlt dir ja immer noch. Woher weiß ich dann was an dem entsprechenden Gerät angeschlossen ist? Selbst wenn ich die Seriennummer kenne, hilft mir das wenig. Der Ansatz bringt nur etwas, wenn die Geräte in einer bestimmten Reihenfolge angesteckt werden. Z.B. neues Gerät ist immer eine bestimmte Position weiter und du baust das selbstlernende Netzwerk (auf die ID bezogen) immer Position für Position von der selben Seite zur anderen auf.
Florian J. schrieb: > Also man nehme an das jeder der Slaves das gleiche Gerät ist mit > gleicher Software und Hardware, nur unterschiedlicher Seriennummer. OK. > Werden jetzt mehrere an das CAN-Netzwerk angeschlossen können diese > natürlich nicht mit der gleichen ID senden, sonst weiß der Master ja > nicht von wem es kommt. Wieso nicht? Soweit ich weiß greift die Arbitrierung auch im Datenfeld, von daher könntest Du einfach ein paar Byte für deine Seriennummer reservieren. Probleme gibt es nur, wenn ein Teilnehmer mit hoher Prio nicht mehr aufhört zu senden ("babbling idiot"), aber dem kann man ja vorbeugen. > Mein Plan jetzt: > ... Sowas wie eine Base-ID gibt es eigentlich nicht. Bevor die Teilnehmer "getauft sind", werden die in deinem Procedere erstmal mit der selben ID und anscheinend auch identische Daten senden (den Request). Das kann eigentlich nur Probleme geben. Nutze das Datenfeld um Teilnehmer gleicher ID zu identifizieren.
Irgendwie kling das für mich wie das OSEK Netzmanagement. Dort wird auch durch die Ringbildung gelernt, welche Busknoten vorhanden sind. Was soll den in deinem Verfahren passieren, wenn wärend der laufenden Buskommunikation ein Knoten ausfällt?
Florian J. schrieb: > -> wartet 10 sek Warum muss das Gerät 10 Sekunden auf etwas warten, was in wenigen Millisekunden klar sein dürfte. Solche ewig langen Timeouts deuten im Ansatz auf einen Designfehler... Was passiert z.B. wenn das gesamte Netz mit 10 Teilnehmern gleichzeitig eingeschaltet wird? PowerUp -> 10 Teilnehmer fragen an, ob es Nr 1 schon gibt --> keine Meldung --> alle 10 Teilnehmer verwenden fürderhin die ID 0x110 Und wenn das nicht bei 0x110 passiert, dann nach Murphy garantiert spätestens bei 0x150
waren es nicht 11 bzw. 29 Bit (2.048/536.870.912)für den Identifier? Ich verstehe den Grund nicht warum du die Teilnehmer identifizieren musst. Als Beispiel beim Hausbus wenn ich 100 Schalter habe und einer sendet "Licht im Schlafzimmer 1 aus", spielt es doch keine Rolle welcher Teilnehmer das absendet, es sei den man möchte ein Bewegungsprofil erstellen. Ansonsten würde ich "einen" Befehl absetzen, meldet euch alle mal mit eure ID, so melden sich dann alle und sie kommen mit ihrer höchsten Prio durch wenn man die ID an den Anfang des Identifier setzt. So sparst du dir mehrere Abfragen.
Florian J. schrieb: > Das Hauptziel sollte sein, das die Geräte untereinander verhandeln und > so wenig Intelligenz wie möglich beim Master liegen sollte, da der Das ist schon mal eine schlechte Idee, Master ist dazu da, um für Ordnung auf dem Bus zu sorgen. Lothar M. schrieb: > Was passiert z.B. wenn das gesamte Netz mit 10 Teilnehmern > gleichzeitig eingeschaltet wird? Ja, genau. Ich habe mal etwas ähnliches gemacht, allerdings hat der Master alle 2 Sekunden gefragt, ob es Teilnehmer mit Adresse 255 gibt. Adresse wird im Eeprom aufbewahrt, beim Flashen auf 255 gesetzt. Beim Einschalten wartet der neue Teilnehmer auf Command 0xFF (als Beispiel) wenn diese empfangen wird, sendet er seine SerNr und ein zusätzliches Word mit seinen Eigenschaften und Fähigkeiten. Wenn seine Antwort durchkommt (Priorität), kriegt er von Master sein ID und neue Adresse zurückgeschickt und gut ist es.
Marc V. schrieb: > Das ist schon mal eine schlechte Idee, Master ist dazu da, um für > Ordnung auf dem Bus zu sorgen. Stimme zu 100% zu. Sehe Dir mal das CANopen Protokoll an, speziell das LSS und SDO. (Spezifikation CiA301) Genau damit lässt sich die von Dir gewünschte Eindeutigkeit der Knotennummern und COB-IDs / Nachrichtenzuordnung herstellen.
nasefuss schrieb: > Soweit ich weiß greift die Arbitrierung auch im Datenfeld, Nö. Kollisionen im Datenfeld bewirken einen Errorframe mit anschließendem Retry, bis der Errorcounter den Sender abschaltet. Um z.B. den 48Bit-ID eines Maxim 1-wire-ICs aufzulösen, könnte man 2 CAN-Pakete mit 29Bit-ID abwechselnd senden.
oder man belässt den ID als Prioritätsmerkmal und überträgt eben mehrere Bytes an Daten sind ja bis zu 8 Bytes möglich, so das man eben auch diese 48 bits unterbekommt. Aber selbst bei dem Beispiel das beim Einschalten der Stromversorgung plötzlich 10 Geräte das senden anfangen gibt es wegen der Priorität der Nachrichten keine Probleme, wer verliert probiert es ja kurze Zeit später nochmal
Thomas O. schrieb: > Aber selbst bei dem Beispiel das beim Einschalten der Stromversorgung > plötzlich 10 Geräte das senden anfangen gibt es wegen der Priorität der > Nachrichten keine Probleme, wer verliert probiert es ja kurze Zeit > später nochmal Das ist von Anfang an falsch gedacht. Erstens: So ein System braucht gar keinen Master und ist deswegen auch zum Scheitern verurteilt. Zweitens: Beim Einschalten mit 10 Geräten dauert es mindestens 100 Sekunden bis alle Geräte (sich selbst) eine Nummer zugewiesen haben. Und in der Zwischenzeit hört der Master brav mit und macht praktisch dasselbe wie jeder Teilnehmer einzeln, oder wie ? Master verwaltet normalerweise eine Tabelle mit SerNr, Eigenschaften und Fähigkeiten (Fest, vorgegeben durch jeden Teilnehmer einzeln) und zugewiesenen IDs (veränderlich, durch Master zugewiesen). Wenn ein Teilnehmer Temperatur messen kann und ein anderer Temperatur messen und regeln kann, kriegt der entweder zwei verschiedene IDs oder gleich eine höhere Priorität. Und darüber entscheidet der Master und nicht jeder Teilnehmer einzeln, da der letzte Teilnehmer überhaupt nicht weiss, wer von den schon angemeldeten Teilnehmern auf dem Bus was kann, bzw. tun soll. Woher soll ein Teilnehmer wissen ob er z.B. bei Dunkelheit Licht selbstständig einschalten soll oder erst auf Befehl von Master ? Ist vielleicht ein schlechtes Beispiel, aber einzelne Teilnehmer sollen selbständig nur melden, wer danach was machen soll, entscheidet einzig und alleine der Master.
Das ist doch genau das was ich sagen will. Man braucht weder einen Master noch muss man sich mit 10 Sek begnügen. Alle senden drauf los, irgendwann kommt jeder an die Reihe. Nach der End of Frame Sequenz+3 Bits wird wieder drauf los gesendet wird und jeder Empfänger entscheidet doch für sich ob er die Infos verwendet oder nicht. Florian möchte aber anscheinend eine Anwesenheitsliste bzw eine fortlaufende Liste wer alles dabei ist.
Thomas O. schrieb: > Alle senden drauf los, irgendwann kommt jeder an die Reihe. Das kann man auch viel kürzer schreiben - Chaos...
In Computernetzwerken ist sowas schon längst realisiert, nennt sich DHCP Server(https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol). Du brauchst natürlich das nicht so kompliziert, aber Grundprinzip könntest du in deinem Fall benutzen.
Alex W. schrieb: > In Computernetzwerken ist sowas schon längst realisiert, nennt sich DHCP > Server(https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol). Oder Auto-IP, was im Prinzip das gleiche Ziel hat, nur eben ohne Server. https://de.wikipedia.org/wiki/Zeroconf#Automatische_IP-Zuweisung
Marc V. schrieb: > Thomas O. schrieb: >> Alle senden drauf los, irgendwann kommt jeder an die Reihe. > > Das kann man auch viel kürzer schreiben - Chaos... Dafür wurde CAN entwickelt. Jeder darf es versuchen und der Schwächste (rezessivere ID) kommt zuletzt dran. Die mit dominaterer ID müssen nur irgendwann mal die Schnauze halten.
Wolfgang schrieb: > Marc V. schrieb: >> Thomas O. schrieb: >>> Alle senden drauf los, irgendwann kommt jeder an die Reihe. >> >> Das kann man auch viel kürzer schreiben - Chaos... > > Dafür wurde CAN entwickelt. Jeder darf es versuchen und der Schwächste > (rezessivere ID) kommt zuletzt dran. Die mit dominaterer ID müssen nur > irgendwann mal die Schnauze halten. Das ist aber eben nicht so einfach möglich da die ID ja erst vergeben werden muss. In einem komplett synchronen System ist das Problem nur zu lösen wenn im Fall einer Kollision eine zufällige Zeit gewartet wird. Dazu darf dann die automatische Sendewiederholung im CAN-Controller auch nicht aktiviert sein. In der Praxis sollte es allein durch Toleranzen im System dazu kommen das einer gewinnt und seine Nachricht als erster auf den Bus bekommt. Wie man sowas recht robust hinbekommt zeigt z.B. J1939 (address claim) https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/ Matthias
Und wofür braucht man das ganze? CAN kennt eigentlich keinen Bus-Master, da per Protokoll einen drauf setzen zu wollen bringt jetzt was für einen Vorteil? CAN wird normalerweise auch nicht wild zusammen gesteckt, das kann man nicht nur planen, das sollte man auch planen. Mehrere Knoten die praktisch identisch sind und vom Inhalt her identische Botschaften senden/empfangen sollen, aber auf unterschiedlichen IDs? Die sollen dabei aber die gleiche Software verwenden? Ist da eine Serien-Nummer eincompiliert ist es sowieso nicht die gleiche Software, dann kann man auch beim compilieren anhand der Nummer den ID-Bereich festlegen. Eine Unit-ID kann man auch am Gerät per Dip-Schalter oder Koder-Widerstände festlegen, die jeweilige Geräte-Klasse bekommt im Plan einen Basis-ID Bereich zugewiesen, Gerät 0 (oder 1) sendet/empfängt dann zum Beispiel bei 0x400..0x40f, die nächste Einheit bei 0x410..0x41f und so weiter. Unterschiedliche Geräte-Klassen kann man über die IDs als wichtiger oder unwichtiger einstufen.
Rudolph schrieb: > Und wofür braucht man das ganze? > > CAN wird normalerweise auch nicht wild zusammen gesteckt, das kann man > nicht nur planen, das sollte man auch planen. Wird CAN halt doch. Das auf CAN aufbauende Protokoll J1939 wird (erweitert) in der Landwirtschaft (ISOBUS) eingesetzt. Und dort stöpselt der Landwirt je nach Bedarf eben verschiedene Anbaugeräte (auch mehrere gleiche) an den Trecker. Und dann muss man die Dinger adressieren können. Natürlich war CAN nie dafür gedacht. Funktioniert aber und wird in großem Umfang professionell eingesetzt. Matthias
Rudolph schrieb: > CAN kennt eigentlich keinen Bus-Master, da per Protokoll einen drauf > setzen zu wollen bringt jetzt was für einen Vorteil? Ordnung auf dem Bus. 1) IDs werden vom Master verteilt, je nach Eigenschaften und Fähigkeiten. Ein Teilnehmer kann auch mehrere IDs erhalten, je nach dem wozu der fähig ist. 2) Master fragt (zumindest bei mir) alle 2 Sekunden nach neuen Teilnehmern, fehlt diese Abfrage zwei Mal hintereinander, wissen die anderen das der Master ausgefallen ist, ein anderer übernimmt diese Aufgabe oder es wird ein Fehler am Bus gemeldet. 3) Sollte sich ein Teilnehmer eine gewisse Zeit nicht melden, fragt der Master diesen gezielt ab. Falls keine Antwort erfolgt, wird der Teilnehmer vorübergehend stillgelegt, eine Warnmeldung mit entsprechenden Daten wird rausgeschickt oder ähnlich. P.S. Du glaubst doch nicht wirklich, dass die Airbags von jedem Sensor einzeln ausgelöst werden ? Oder dass defekte OxySensors selbstständig die Warnlampe aufleuchten lassen ?
Marc V. schrieb: > Du glaubst doch nicht wirklich, dass die Airbags von jedem Sensor > einzeln ausgelöst werden ? Oder dass defekte OxySensors selbstständig > die Warnlampe aufleuchten lassen ? Glaubst du denn, dass es im Auto einen "Master" gibt, der das alles macht?
Rolf M. schrieb: > Glaubst du denn, dass es im Auto einen "Master" gibt, der das alles > macht? Natürlich nicht, es ist ein multi-master System. Auf jeden Fall muss es aber auf dem Bus mindestens einen Master geben. Und die verschiedenen Busse werden durch Gateways miteinander verbunden, falls nötig. Alles andere würde in totaler Anarchie enden. ;)
Ich habe in meiner Studienarbeit auch mit dem CAN-Bus gearbeitet. Hauptziel war dezentrale Messtechnik zu bauen, die über CAN die Messdaten an einen "Master" schickt, welcher an einen PC angebunden ist. Da habe ich die IDs mit einem DIP-Schalter auf der Platine festgelegt. Die IDs wurden dann im ersten Byte der Nachricht verschickt.
Daisy Chain ist da das Mittel der Wahl. Jeder kennt die ganzen Identifier und deren Zuordnung Slave 1...n die für die Slaves vorgesehen sind. Master legt Daisy auf high und sendet eine 1 bis er auf dem CAN Antworten auf der ID von Slave 1 bekommt, danach sendet er eine 2. Slave 1 zieht daraufhin seinen Ausgang auf high und mit Slave 2 geht das Spiel wieder los. Geht mit etwas mehr Aufwand auch ohne eigene Daisy Chain Leitung.
Marc V. schrieb: > Rolf M. schrieb: >> Glaubst du denn, dass es im Auto einen "Master" gibt, der das alles >> macht? > > Natürlich nicht, es ist ein multi-master System. > Auf jeden Fall muss es aber auf dem Bus mindestens einen Master > geben. Nö. Gibt es im Auto auch eher nicht. > Alles andere würde in totaler Anarchie enden. ;) Warum sollte es? In meinem Heimnetzwerk gibt's auch keinen Master, und trotzdem funktioniert das.
Rolf M. schrieb: >> Natürlich nicht, es ist ein multi-master System. >> Auf jeden Fall muss es aber auf dem Bus mindestens einen Master >> geben. > > Nö. Gibt es im Auto auch eher nicht. Doch, gerade im Auto. Rolf M. schrieb: > Warum sollte es? In meinem Heimnetzwerk gibt's auch keinen Master, und > trotzdem funktioniert das. Das ist etwas anderes. Weder ist das CAN, noch sind die Teilnehmer Mikrocontroller die selbständige Aufgaben ausführen. Es kommt natürlich darauf an, wozu die Teilnehmer in einem Netzwerk fähig sind und was dessen Aufgaben sind. Für stupides schalten von Glühbirnen bei Dunkelheit braucht man bestimmt keinen Master aber auch kein Netzwerk. Und nur weil etwas funktioniert, heisst es noch lange nicht, dass es auch gut und richtig ist.
Marc V. schrieb: >>> Natürlich nicht, es ist ein multi-master System. >>> Auf jeden Fall muss es aber auf dem Bus mindestens einen Master >>> geben. >> >> Nö. Gibt es im Auto auch eher nicht. > > Doch, gerade im Auto. Nö, nicht so richtig. Jedenfalls nicht so, dass zum Beispiel die Türsteuergeräte erst beim BCM nach IDs fragen müssen, bevor die funktionieren dürfen. Die haben einfach fest zugewiesene IDs und fertig, das sind dann auch vier verschiedene Geräte, obwohl die zumindest eine Schnittmenge an Funktionalität haben. Wenn man die Sitz-Steuergeräte ansprechen will geht das zwar nicht "mal eben so", die IDs werden in dem Prozedere aber nicht ausgehandelt, die sind fest. Das Protokoll da drauf dient der Sicherheit, im wesentlichen um ausgefallene Knoten erkennen zu können. Die Funktionalität wird frei gegegeben. Es gibt im Auto auch nur sehr wenige Stellen wo durch den Nutzer CAN-Knoten dazugeklemmt werden, noch dazu identische. Sitze im Bus vielleicht die ausgebaut werden können, aber auch die müssten nicht dynamisch adressiert werden in dem Sinne. Das Netz ist doch zur Auslieferung des Fahrzeugs komplett durchgeplant. Das Beispiel mit den Anbauteilen für den Trecker fand ich schon plausibel. Da dient die Nummer aber auch nur dem Komfort des Nutzers, oder vielleicht traut man dem das da auch einfach nicht zu, dass der einmalig seine gleichen Teile auf unterschiedliche Unit-IDs einstellt.
Rudolph schrieb: > Jedenfalls nicht so, dass zum Beispiel die Türsteuergeräte erst beim BCM > nach IDs fragen müssen, bevor die funktionieren dürfen. > Die haben einfach fest zugewiesene IDs und fertig, das sind dann auch > vier verschiedene Geräte, obwohl die zumindest eine Schnittmenge an > Funktionalität haben. > Das Netz ist doch zur Auslieferung des Fahrzeugs komplett durchgeplant. Genau, wo ist dann die Ähnlichkeit mit diesem Thread ? Der TO redet hier von einem Netz ohne feste Adressen, bzw. IDs.
Marc V. schrieb: > Rolf M. schrieb: >>> Natürlich nicht, es ist ein multi-master System. >>> Auf jeden Fall muss es aber auf dem Bus mindestens einen Master >>> geben. >> >> Nö. Gibt es im Auto auch eher nicht. > > Doch, gerade im Auto. Ich arbeite seit vielen Jahren genau in diesem Bereich. Das wäre mir aufgefallen, wenn das dort so wäre. Es gibt für das eine oder andere Teilsystem ggf. mal auf Applikationsebene sowas wie einen Master (also z.B. das Steuergerät, das beim Blinken vorgibt, wann genau alle Blinklichter anzugehen haben, damit sie auch alle synchron angehen), aber das war's dann auch. Wozu man da bei der CAN-Kommunikation einen Master brauchen könnte, wüßte ich nicht. > Rolf M. schrieb: >> Warum sollte es? In meinem Heimnetzwerk gibt's auch keinen Master, und >> trotzdem funktioniert das. > > Das ist etwas anderes. > Weder ist das CAN, noch sind die Teilnehmer Mikrocontroller die > selbständige Aufgaben ausführen. Selbstständige Aufgaben führen meine PCs auch aus. Und ob's Mikrocontroller oder PCs sind, spielt auch keine Rolle für die Frage, ob man nun einen Master braucht oder nicht. > Es kommt natürlich darauf an, wozu die Teilnehmer in einem Netzwerk > fähig sind und was dessen Aufgaben sind. Für stupides schalten von > Glühbirnen bei Dunkelheit braucht man bestimmt keinen Master aber > auch kein Netzwerk. Hast du denn mal ein Beispiel, wo man im Auto einen Master braucht, um vernünftige Buskommunikation zu gewährleisten? > Und nur weil etwas funktioniert, heisst es noch lange nicht, dass es > auch gut und richtig ist. Du meinst, mein Heimnetzwerk wäre besser, wenn es einen Master hätte?
Hallo zusammen, da schaut man mal zwei tage nicht rein und wird bombardiert :D. Freut mich das ich soviel Anregungen erhalten habe! 1. Master muss dumm sein weil: - Master liegt nicht in unserer hand und ich kann von den Kunden nicht erwarten das Sie ein kompliziertes protokoll implementieren. 2. Master muss Geräte identifizieren weil: - Jedes angeschlossene Gerät schickt 15 Frames voll mit Daten die auf das Gerät bezogen sind, deshalb ist es wichtig zu identifizieren. ... Ich versuchs jetzt folgendermaßen: Verwendung CAN2.0B standard CAN-ID = Seriennummer (=keine Kollision jedes Gerät individuell) Daten Frames: Das erste Datenbyte wird ein Messagecode, welcher angibt was in den nachfolgenden 7-Bytes enthalten ist. Somit kann der Master schon anhand des Identifiers die SN des Gerätes ableiten und die Daten gemäß Protokoll einfach decodieren. Viele Grüße Flo
Rolf M. schrieb: > Hast du denn mal ein Beispiel, wo man im Auto einen Master braucht, um > vernünftige Buskommunikation zu gewährleisten? Ob man den Master wirklich braucht kann ich nicht sagen, aber CAN-Busse im Master-Slave Betrieb gibt es definitiv auch im Auto, z.B. CiA447.
guest schrieb: > aber CAN-Busse > im Master-Slave Betrieb gibt es definitiv auch im Auto, z.B. CiA447. Naja, da geht es um ein standardisiertes Gateway für Sonder-Fahrzeuge um zusätzliche Komponenten an einem komplett getrennten und eigenem Netz betreiben zu könnnen anstatt am Fahrzeug-eigenen CAN. Und das Gateway stellt Informationen aus dem Fahrzeug zur Verfügung. Den "Master" habe ich da nicht gefunden. Ist das bei CANopen grundsätzlich so? Marc V. schrieb: > Genau, wo ist dann die Ähnlichkeit mit diesem Thread ? Moment, Du behauptest doch, das wäre im Auto so und müsste so sein.
Meiner Meinung nach bedeutet Multi-Master bei CAN eher, dass jeder Teilnehmer Master sein kann aber nicht muss. Es ist doch gerade der Vorteil das man keinen Master braucht, und die Identifier eben auch die Priorität darstellen. Also als erstes eine Liste machen mit der Priorität der einzelnen Nachrichten. Wenn ein bestimmter Teilnehmer eine Anwesendheit anderer Teilnehmer wissen möchte, kann er Sie doch 1. in bestimmten Zeitabständen einzeln ansprechen um die Buslast gering zu halten 2. er fragt in die Runde wer ist alles da, danach folgt aber eine Zeit sehr hoher Buslast bis sich alle je nach Prio gemeldet haben. 3. oder jeder Teilnehmer meldet sich beim anklemmen an den Bus selbstständig, was evtl. zu Beginn eine hohe Buislast verursachen würde. Aber diese Anwesendheitsnachrichten müssen ja nicht so hoch Priorisiert sein das Sie andere wichtige Dinge verzögern. Ich kenne es im KFZ Bereich auch so das die IDs fest vergeben bzw. reserviert sind, damit es eben nicht zu einem anlernen kommen muss, es gibt aber auch Hersteller da muss es passend codiert werden damit dann bestimmte Nachrichten auch ausgegeben werden.
Thomas O. schrieb: > Meiner Meinung nach bedeutet Multi-Master bei CAN eher, dass jeder > Teilnehmer Master sein kann aber nicht muss. Bei CAN selbst gibt es keinen Master. Alle Teilnehmer sind gleichberechtigt. Irgendwelche Master/Slave-Konzepte sind daher immer Teil irgendeines zusätzlichen Protokolls, dass da noch drüber gestülpt wird. > Es ist doch gerade der Vorteil das man keinen Master braucht, und die > Identifier eben auch die Priorität darstellen. Dabei geht es um die Arbitrierung. Das ist wieder ein anderes Thema. > Also als erstes eine Liste machen mit der Priorität der einzelnen > Nachrichten. Die ist aber nur dann wichtig, wenn bestimmte Botschaften sehr schnell rausgesendet werden müssen. Die Priorität sagt ja nur, welche Botschaft schneller rausgeht, wenn mehrere Teilnehmer gerade gleichzeitig senden wollen.
Rolf M. schrieb: > Ich arbeite seit vielen Jahren genau in diesem Bereich. Das wäre mir > aufgefallen, wenn das dort so wäre. Es gibt für das eine oder andere > Teilsystem ggf. mal auf Applikationsebene sowas wie einen Master (also Rudolph R. schrieb: > Naja, da geht es um ein standardisiertes Gateway für Sonder-Fahrzeuge um > zusätzliche Komponenten an einem komplett getrennten und eigenem Netz > betreiben zu könnnen anstatt am Fahrzeug-eigenen CAN. Was wollt ihr beiden Korinthenkacker überhaupt beweisen ? CAN kennt keinen Master, schreibt auch keinen vor, aber in fast jedem Netz gibt es einen Master und das ist auch gut so. Vor allem im Auto. Das hat nichts mit Messages zu tun, jeder Teilnehmer kann Messages senden wenn er es für nötig hält, es geht um die Koordination und wer was in diesem Netz machen darf und soll. Falls Scheibenwischer und Sitze auf dem selben Bus hängen, heisst es noch lange nicht, dass die auch das geringste gemeinsam haben. Rudolph R. schrieb: > Marc V. schrieb: >> Genau, wo ist dann die Ähnlichkeit mit diesem Thread ? > > Moment, Du behauptest doch, das wäre im Auto so und müsste so sein. Nein, ich sagte, dass es im Auto in jedem Netz einen oder mehrere Master gibt, aber die IDs bzw. die Adressen fest vergeben sind. Und noch einmal für euch beiden, da ihr offenbar Schwierigkeiten mit begreifen habt (auch nach vielen Jahren in genau diesem Bereich): Messages kann jeder Teilnehmer senden, falls er das für nötig erachtet, aber nur Master entscheidet, ob eine entsprechende Aktion nötig ist und auch ausgeführt wird. Endlich kapiert ?
Rudolph R. schrieb: > Naja, da geht es um ein standardisiertes Gateway für Sonder-Fahrzeuge um > zusätzliche Komponenten an einem komplett getrennten und eigenem Netz > betreiben zu könnnen anstatt am Fahrzeug-eigenen CAN. > Und das Gateway stellt Informationen aus dem Fahrzeug zur Verfügung. Eigentlich gehts da weniger um das Gateway, eher um das Protokoll bzw. die Standardisierung der Information (soweit möglich). Im Auto kocht ja sonst jeder Hersteller sein eigenes Süppchen. Ein Gateway braucht es meitens trotztem, irgenwo müssen die Infos ja herkommen und u.U braucht man auch Zugriff auf auf bestimmte Fahrzeugfunktionen. Das Gateway muß aber nicht notwendigerweise auch der Master sein. > Den "Master" habe ich da nicht gefunden. > Ist das bei CANopen grundsätzlich so? Jup, siehe: http://www.can-cia.org/can-knowledge/canopen/network-management Der Master macht u.A. nach dem Aufwachen des Busses die Enumerierung der Busteilnehmer und ist für die Verwaltung und Zuweisung der Node-IDs zuständig.
Marc V. schrieb: > Messages kann jeder Teilnehmer senden, falls er das für nötig > erachtet, aber nur Master entscheidet, ob eine entsprechende > Aktion nötig ist und auch ausgeführt wird. > > Endlich kapiert ? Hmm, lies noch mal alles durch, was Du selber weiter oben geschrieben hast. Mit Dir zu diskutieren erscheint sinnlos zu sein, weil Du zum einen unsachlich wirst und Dir zum anderen versuchst Dir irgendwie den Verlauf so hinzubiegen das Du Recht behälst.
Rudolph R. schrieb: > Hmm, lies noch mal alles durch, was Du selber weiter oben geschrieben > hast. > Mit Dir zu diskutieren erscheint sinnlos zu sein, weil Du zum einen > unsachlich wirst und Dir zum anderen versuchst Dir irgendwie den Verlauf > so hinzubiegen das Du Recht behälst. Ich bin weder unsachlich noch biege ich etwas hin. Ihr beide verwechelt ständig Messages und Buskommunikation mit Busarbitration und Master. Master in einem Netz kriegt kleinstmöglichen ID und kommt somit immer durch. Die anderen können melden was die wollen aber etwas wird nur dann ausgeführt wenn der Master dazu den Befehl gibt. Natürlich gilt das nicht für die Innenbeleuchtung und sonstigen Kram. Aber so wie ihr beide euch das vorstellt, würde es genügen, ein einziges Bus im Fahrzeug zu haben und da würden dann auch noch alle munter drauflos senden. Die Autohersteller wollen doch jeden cent sparen, warum machen die das nicht so, sondern führen immer neue Busse ein (CAN, LIN, MOST, FlexRay, Ethernet) ? Und verbinden diese mit Gateways ? Natürlich wisst ihr beide da viel besser Bescheid als die ungebildeten Morons in der Autoindustrie...
Marc V. schrieb: > Ich bin weder unsachlich noch biege ich etwas hin. Aha, sowas wie "Korithenkacker" ist für Dich also sachlich? > Ihr beide verwechelt ständig Messages und Buskommunikation mit > Busarbitration und Master. Nein. > Master in einem Netz kriegt kleinstmöglichen > ID und kommt somit immer durch. Die anderen können melden was die > wollen aber etwas wird nur dann ausgeführt wenn der Master dazu den > Befehl gibt. > Natürlich gilt das nicht für die Innenbeleuchtung und sonstigen Kram. Ach, die Knoten dürfen doch wild durcheinander senden? Und jetzt auf einmal auch auf nicht ausgehandelten IDs? Das meine ich mit zurecht biegen. Von der Funktions-Ebene war auch nie die Rede, die Frage ob ein Knoten selbständig eine Lampe anmachen darf oder nicht wurde nicht gestellt. Und die kleinsten IDs bekommen eher die Knoten mit den wichtigsten Informationen. > Aber so wie ihr beide euch das vorstellt, würde es genügen, ein > einziges Bus im Fahrzeug zu haben und da würden dann auch noch alle > munter drauflos senden. Wie kommst Du auf so eine Behauptung? Von Buslast war nie die Rede. Und auf dem jeweiligen Bus senden die Knoten drauf los. > Die Autohersteller wollen doch jeden cent sparen, > warum machen die das nicht so, sondern führen immer neue > Busse ein (CAN, LIN, MOST, FlexRay, Ethernet) ? Unterschiedliche Anforderungen, die sich in >30 Jahren CAN auch mal geändert haben. CAN - die Mutter aller Busse im Auto, quasi, zumindest als Standard LIN - der kleine Bruder vom CAN für kleine langsame Unter-Netze, Master-Slave MOST - hohe Datenrate für Bild und Ton, proprietär, teuer FlexRay - sollte ein aufgebohrter Super-CAN sein, kam nie richtig in Fahrt Ethernet - 100BaseT1, schnell, offen, als Punkt-zu-Punkt Verbindung ungeeignet CAN zu ersetzen Willst Du zu irgendwas davon mehr wissen? Aktuell sehe ich sowohl bei CAN-FD und 100BaseT1 mehr Aktivität als bei Flexray jemals, MOST ist als "Infotainment-Insel" sowieso aussen vor und ich rechne damit, dass das viel früher stirbt als CAN. > Und verbinden diese mit Gateways ? Sicherheit, Buslast, unterschiedliche Anwendungen? > Natürlich wisst ihr beide da viel besser Bescheid als die ungebildeten > Morons in der Autoindustrie... Ich bin in der Automobilindustrie unterwegs. Als Entwickler. Nur nicht im Umfang BCM oder Gateway.
Marc V. schrieb: > Was wollt ihr beiden Korinthenkacker überhaupt beweisen ? Wir wollen lediglich deine Behauptungen nicht einfach im Raum stehen lassen, sonst glaubt das nachher noch jemand. Übrigens werden die durch Garnierung mit Beleidigungen nicht besser. > Das hat nichts mit Messages zu tun, jeder Teilnehmer kann Messages > senden wenn er es für nötig hält, es geht um die Koordination und > wer was in diesem Netz machen darf und soll. > Falls Scheibenwischer und Sitze auf dem selben Bus hängen, heisst es noch > lange nicht, dass die auch das geringste gemeinsam haben. Man braucht einen Master, weil der Scheibenwischer nix mit dem Sitz zu tun hat? Merkwürdige Argumentation. > Messages kann jeder Teilnehmer senden, falls er das für nötig > erachtet, aber nur Master entscheidet, ob eine entsprechende > Aktion nötig ist und auch ausgeführt wird. Das ist aber eher das funktionale Thema und keines der Kommunikation. In irgendeinem Steuergerät ist natürlich die Funktion implementiert - wie ich oben beim Beispiel des Blinkers ja schon geschrieben habe. Das hat aber nichts mit einem Bus-Master zu tun. Marc V. schrieb: > Ihr beide verwechelt ständig Messages und Buskommunikation mit > Busarbitration und Master. Master in einem Netz kriegt kleinstmöglichen > ID und kommt somit immer durch. Alle kommen immer durch. Wenn nicht, ist die Buslast viel zu hoch. Nur wenn zwei gleichzeitig senden wollen, kommt der eine zuerst dran und der andere danach. Und man entscheidet sowas auch nicht basierend auf irgendeinem "Master", sondern darauf, wie dringend die entsprechende Botschaft ist und wie wichtig ihr Timing ist. Hier widersprichst du dir auch selber. Die Priorisierung über die ID ist ein Teil der Arbitrierung. > Aber so wie ihr beide euch das vorstellt, würde es genügen, ein > einziges Bus im Fahrzeug zu haben und da würden dann auch noch alle > munter drauflos senden. Du hast offenbar noch nie die Buskommunikation eines Autos gesehen und verstanden, sonst wüßtest du, dass die tatsächlich alle "munter drauflos senden". Dass es mehrere Busse im Auto gibt, hat verschiedene Gründe. Ein CAN wäre mit der gesamten Kommunikation schon lange überlastet. Außerdem trennt man die Busse funktional von einander, damit nicht gleich die gesamte Kommunikation im Auto tot ist, wenn ein Bus ausfällt. Und teilweise gibt's dann noch räumliche Trennung und den Wunsch, dass bestimmte Funktionen andere nicht beeinflussen können sollen (z.B. Motor-CAN). > Die Autohersteller wollen doch jeden cent > sparen, warum machen die das nicht so, sondern führen immer neue > Busse ein (CAN, LIN, MOST, FlexRay, Ethernet) ? Jedes dieser Bussysteme hat seine Vor- und Nachteile. CAN ist der Klassiker. LIN ist der billig-Bus, MOST ist für Multimedia, FlexRay war als Nachfolger für CAN gedacht, ist deterministischer als CAN und schneller, aber auch teurer. Ethernet ist für Aufgaben, wo auch FlexRay nicht mehr reicht. Gerade die Kosten sind der Grund, warum es so viele verschiedene Bussysteme gibt. > Natürlich wisst ihr beide da viel besser Bescheid als die ungebildeten > Morons in der Autoindustrie... Nein, wir wissen nur besser bescheid als du.
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.