mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN Identifizierung mehrerer Teilnehmer / Taufverfahren


Autor: Florian J. (fjay24)
Datum:

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

Autor: Tr (Gast)
Datum:

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

Autor: Bernd (Gast)
Datum:

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

Autor: nasefuss (Gast)
Datum:

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

Autor: Postmann (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Thomas O. (kosmos)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Martin (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Thomas O. (kosmos)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Thomas O. (kosmos)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
>  Alle senden drauf los, irgendwann kommt jeder an die Reihe.

 Das kann man auch viel kürzer schreiben - Chaos...

Autor: Alex Wka (de1m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Computernetzwerken ist sowas schon längst realisiert, nennt sich DHCP 
Server(https://de.wikipedia.org/wiki/Dynamic_Host_Configu...).

Du brauchst natürlich das nicht so kompliziert, aber Grundprinzip 
könntest du in deinem Fall benutzen.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex W. schrieb:
> In Computernetzwerken ist sowas schon längst realisiert, nennt sich DHCP
> Server(https://de.wikipedia.org/wiki/Dynamic_Host_Configu...).

Oder Auto-IP, was im Prinzip das gleiche Ziel hat, nur eben ohne Server.
https://de.wikipedia.org/wiki/Zeroconf#Automatisch...

Autor: Wolfgang (Gast)
Datum:

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

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

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

Matthias

Autor: Rudolph (Gast)
Datum:

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

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Chris (Gast)
Datum:

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

Autor: rcc (Gast)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Rudolph (Gast)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

Autor: Florian J. (fjay24)
Datum:

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

Autor: guest (Gast)
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: Thomas O. (kosmos)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: guest (Gast)
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

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.