Automatische Identifier Vergabe CAN-Bus
Arne
ich mï¿œchte Teilnehmen an einem CAN-Bus eine eindeutige CAN-ID zuweisen, kennt hier jemand ein
erprobtes zuverlï¿œssiges verfahren?
Nehmen wir einmal an ich habe bis zu 12 verschiedene Teilnehmer die ï¿œber den CAN-Bus verbunden sind.
Ein logischer Master fragt von den Teilnehmern Daten ab, der Master vergibt den Gerï¿œten eindeutige
CAN-IDs.
Die unterschiedlichen Teilnehmer kï¿œnnen beliebig an diesen Bus angesteckt und wieder entfernt
werden, auch gleichzeitig. Insgesamt gibt es sehr viel mehr als die 12 Steckplï¿œtze fï¿œr diese Gerï¿œte.
Aller Gerï¿œte verfï¿œgen ï¿œber eine eindeutige 32Bit Seriennummer.
Es ist wichtig, das ich gezielt einzelne Teilnehmer ansprechen kann, eine Benutzer-erkennbare
Zuordnung zum Physikalischen Gerï¿œt ist nicht notwendig.
In dem Bus-System sind neben den 12 Steckplï¿œtzen noch weitere Teilnehmer, die mit statischen IDs
arbeiten.
Bisherige Idee:
Master sendet ein Broadcast worauf alle Teilnehmer ohne ID mit Ihrer Seriennummer auf eine
definierten Sammel-ID antworten. Antworten zwei Teinehmer gleichzeitig steigen sie mit einem
Errorframe aus und wiederholen die Antwort nach einer Zufallszeit.
Kennt der Master die Seriennummern, kann er mit einen Broadcast mit Seriennummer und neuer CAN-ID
als Dateninhalt einzelne Teilnehmer konfigurieren.
Kennt jemand ein besseres Verfahren, in dem man evtl. ohne Errorframe auskommt?
Gruￜ
Arne
Dirk Ruth
"
>Hallo NG,
>
>ich m�chte Teilnehmen an einem CAN-Bus eine eindeutige CAN-ID zuweisen, kennt hier jemand ein
>erprobtes zuverl�ssiges verfahren?
>
>Nehmen wir einmal an ich habe bis zu 12 verschiedene Teilnehmer die �ber den CAN-Bus verbunden sind.
>Ein logischer Master fragt von den Teilnehmern Daten ab, der Master vergibt den Ger�ten eindeutige
>CAN-IDs.
>
>Die unterschiedlichen Teilnehmer k�nnen beliebig an diesen Bus angesteckt und wieder entfernt
>werden, auch gleichzeitig. Insgesamt gibt es sehr viel mehr als die 12 Steckpl�tze f�r diese Ger�te.
>Aller Ger�te verf�gen �ber eine eindeutige 32Bit Seriennummer.
>
>Es ist wichtig, das ich gezielt einzelne Teilnehmer ansprechen kann, eine Benutzer-erkennbare
>
>In dem Bus-System sind neben den 12 Steckpl�tzen noch weitere Teilnehmer, die mit statischen IDs
>
>Bisherige Idee:
>Master sendet ein Broadcast worauf alle Teilnehmer ohne ID mit Ihrer Seriennummer auf eine
>definierten Sammel-ID antworten. Antworten zwei Teinehmer gleichzeitig steigen sie mit einem
>Errorframe aus und wiederholen die Antwort nach einer Zufallszeit.
>
>Kennt der Master die Seriennummern, kann er mit einen Broadcast mit Seriennummer und neuer CAN-ID
>als Dateninhalt einzelne Teilnehmer konfigurieren.
>
>Kennt jemand ein besseres Verfahren, in dem man evtl. ohne Errorframe auskommt?
>
Was genau st�rt dich denn am Errorframe? Den sieht doch nur der
jeweilige Slave und ist doch erw�nschtes Verhalten auf dem CAN-Bus.
Ich w�rde auch die Zufallszahl weglassen, dann sieht der Master alle
Slaves sofort in der Reihenfolge ihrer Seriennummern. Besser kann man
es doch nicht haben. Ich kenne jetzt deine Slaves(Controller) nicht,
aber die besseren sollten das wiederholende Senden nach einem Error
automatisch ausf�hren, bis erfolgreich gesendet wurde. Springt halt
mal kurz der Errorcounter im Slave hoch, aber im Idealfall merkst du
davon nichts. M.W. wechselt der Error-State im Slave erst bei 128
Errors oder man konnte es konfigurieren o.s.�.
Dirk
Peter Schaeffer
> Hallo NG,
>
> ich mï¿œchte Teilnehmen an einem CAN-Bus eine eindeutige CAN-ID zuweisen,
> kennt hier jemand ein erprobtes zuverlï¿œssiges verfahren?
Prof. Kaiser hat um 2000 Papers zu dem Thema veroeffentlicht. Es ging
eigentlich um etwas anderes, aber es war ein Teilproblem.
http://www-ivs.cs.uni-magdeburg.de/eos/forschung/publications/index.shtml.de
Ich finde dort auf die schnelle allerdings nicht das Paper,
welches ich suche. Such mal folgendes in Google:
"The WAN-of-CAN structure is the central"
Kapitel 2.2.1.1 und Anhang A.2.
Es enthaelt allerdings einen kleinen Fehler, es
funktioniert nur mit Handshake, der SSI Befehl ist also
falsch beschrieben (Nebensatz ersatzlos streichen).
> Nehmen wir einmal an ich habe bis zu 12 verschiedene Teilnehmer die ï¿œber
> den CAN-Bus verbunden sind.
> Ein logischer Master fragt von den Teilnehmern Daten ab, der Master
> vergibt den Gerï¿œten eindeutige CAN-IDs.
>
> Die unterschiedlichen Teilnehmer kï¿œnnen beliebig an diesen Bus
> angesteckt und wieder entfernt werden, auch gleichzeitig. Insgesamt gibt
> es sehr viel mehr als die 12 Steckplï¿œtze fï¿œr diese Gerï¿œte. Aller Gerï¿œte
> verfï¿œgen ï¿œber eine eindeutige 32Bit Seriennummer.
>
> Es ist wichtig, das ich gezielt einzelne Teilnehmer ansprechen kann,
> eine Benutzer-erkennbare Zuordnung zum Physikalischen Gerï¿œt ist nicht
> notwendig.
>
> In dem Bus-System sind neben den 12 Steckplï¿œtzen noch weitere
> Teilnehmer, die mit statischen IDs arbeiten.
Genau dieses Problem wurde damals geloest.
> Bisherige Idee:
> Master sendet ein Broadcast worauf alle Teilnehmer ohne ID mit Ihrer
> Seriennummer auf eine definierten Sammel-ID antworten. Antworten zwei
> Teinehmer gleichzeitig steigen sie mit einem Errorframe aus und
> wiederholen die Antwort nach einer Zufallszeit.
Schlechte Idee. Wenn du nichts machst, werden sie die Nachricht
gleichzeitig wiederholen und und wieder ein Errorframe produzieren.
Auf diese Art werden alle niederprioren CAN-Paket blockiert.
> Kennt der Master die Seriennummern, kann er mit einen Broadcast mit
> Seriennummer und neuer CAN-ID als Dateninhalt einzelne Teilnehmer
> konfigurieren.
Ab hier wird es wieder richtig.
> Kennt jemand ein besseres Verfahren, in dem man evtl. ohne Errorframe
> auskommt?
Siehe oben. Ist aber sehr (zu) knapp gefasst und wenn man
nicht in der Materie drinnen ist sehr schwer zu verstehen.
Peter Schaeffer
> Arneschrieb:
> "
>> Hallo NG,
>>
>> ich m�chte Teilnehmen an einem CAN-Bus eine eindeutige CAN-ID zuweisen, kennt hier jemand ein
>> erprobtes zuverl�ssiges verfahren?
>>
>> Nehmen wir einmal an ich habe bis zu 12 verschiedene Teilnehmer die �ber den CAN-Bus verbunden sind.
>> Ein logischer Master fragt von den Teilnehmern Daten ab, der Master vergibt den Ger�ten eindeutige
>> CAN-IDs.
>>
>> Die unterschiedlichen Teilnehmer k�nnen beliebig an diesen Bus angesteckt und wieder entfernt
>> werden, auch gleichzeitig. Insgesamt gibt es sehr viel mehr als die 12 Steckpl�tze f�r diese Ger�te.
>> Aller Ger�te verf�gen �ber eine eindeutige 32Bit Seriennummer.
>>
>> Es ist wichtig, das ich gezielt einzelne Teilnehmer ansprechen kann, eine Benutzer-erkennbare
>> Zuordnung zum Physikalischen Ger�t ist nicht notwendig.
>>
>> In dem Bus-System sind neben den 12 Steckpl�tzen noch weitere Teilnehmer, die mit statischen IDs
>> arbeiten.
>>
>> Bisherige Idee:
>> Master sendet ein Broadcast worauf alle Teilnehmer ohne ID mit Ihrer Seriennummer auf eine
>> definierten Sammel-ID antworten. Antworten zwei Teinehmer gleichzeitig steigen sie mit einem
>> Errorframe aus und wiederholen die Antwort nach einer Zufallszeit.
>>
>> Kennt der Master die Seriennummern, kann er mit einen Broadcast mit Seriennummer und neuer CAN-ID
>> als Dateninhalt einzelne Teilnehmer konfigurieren.
>>
>> Kennt jemand ein besseres Verfahren, in dem man evtl. ohne Errorframe auskommt?
>>
>
>
> Was genau st�rt dich denn am Errorframe? Den sieht doch nur der
> jeweilige Slave und ist doch erw�nschtes Verhalten auf dem CAN-Bus.
Es zerstoert ein Paket und blockiert den Bus.
> Ich w�rde auch die Zufallszahl weglassen, dann sieht der Master alle
> Slaves sofort in der Reihenfolge ihrer Seriennummern. Besser kann man
> es doch nicht haben.
Nein, er kann keine 32-Bit ID in einen 29-Bit Arbiter stecken,
also muss es ins Datenfeld. Die Pakete kommen also gleichzeitig,
da gleicher Arbiter => Errorframe => automatische Wiederholung
(auch gleichzeitig) ... ==> Bus Contention.
Zufallszahl loesst das Problem nicht, man kann es nur nicht mehr
reproduzieren.
Zufallzeit bringt bei niedriger Prioritaet und hoher Busauslastung
auch nichts, und ist nicht trivial zu implementieren, da man dazu ein
CAN-Paket aus dem CAN-Controller entfernen muss, je nach Controller
haesslich bis unmoeglich.
> Ich kenne jetzt deine Slaves(Controller) nicht,
> aber die besseren sollten das wiederholende Senden nach einem Error
> automatisch ausf�hren, bis erfolgreich gesendet wurde. Springt halt
> mal kurz der Errorcounter im Slave hoch, aber im Idealfall merkst du
> davon nichts. M.W. wechselt der Error-State im Slave erst bei 128
> Errors oder man konnte es konfigurieren o.s.�.
Wenn einer in den Bus-off geht, koennte es die Contention aufloesen,
aber da sich die Teilnehmer i.A. deterministisch und gleich verhalten,
werden die auch alle gleichzeitig off gehen und wieder gleichzeitig
aufspringen, das Spiel geht von vorne los.
Enrik Berkhan
> Wenn einer in den Bus-off geht, koennte es die Contention aufloesen,
> aber da sich die Teilnehmer i.A. deterministisch und gleich verhalten,
> werden die auch alle gleichzeitig off gehen und wieder gleichzeitig
> aufspringen, das Spiel geht von vorne los.
Verhalten sich die Teilnehmer denn wirklich gleich? Einer wird doch
den Fehler als erster erkennen (der mit dem ersten rezessiven bit)
und den Error Frame beginnen. Erhöht der den Fehlerzähler nicht
stärker als die anderen, die auf den Error Frame nur aufspringen?
Wenn der dann früher in Error Passive geht, muss er etwas länger
warten vor dem nächsten Sendeversuch, IIRC.
Das ganze hängt damit aber auch etwas von der "Bushistorie" ab,
sprich dem aktuellen Stand der Fehlerzähler.
Aber ist in denn in diesem Fall die Kollisionswahrscheinlichkeit
nicht so gering, dass man einen kurzen Bus-off einzelner Teil-
nehmer in Kauf nehmen kann?
Gruß,
Enrik
Heiko Lechner
> Zufallszahl loesst das Problem nicht, man kann es nur nicht mehr
> reproduzieren.
>
> Zufallzeit bringt bei niedriger Prioritaet und hoher Busauslastung
> auch nichts, und ist nicht trivial zu implementieren, da man dazu ein
> CAN-Paket aus dem CAN-Controller entfernen muss, je nach Controller
> haesslich bis unmoeglich.
Ich habe jetzt nicht l�nger dar�ber nachgedacht, aber was w�re mit einer
Zufallswartezeit _vor_ der Broadcast- Antwort, also bevor es zum
Errorframe kommt?
Peter Schaeffer
> Peter Schaeffer <sp...@peter-schaeffer.de> wrote:
>> Wenn einer in den Bus-off geht, koennte es die Contention aufloesen,
>> aber da sich die Teilnehmer i.A. deterministisch und gleich verhalten,
>> werden die auch alle gleichzeitig off gehen und wieder gleichzeitig
>> aufspringen, das Spiel geht von vorne los.
>
> Verhalten sich die Teilnehmer denn wirklich gleich? Einer wird doch
> den Fehler als erster erkennen (der mit dem ersten rezessiven bit)
> und den Error Frame beginnen. Erhöht der den Fehlerzähler nicht
> stärker als die anderen, die auf den Error Frame nur aufspringen?
Stimmt, es sehen zwar alle das Errorframe, aber nur er wird
seinen Fehlerzaehler hochzaehlen und Error-Passiv werden.
> Wenn der dann früher in Error Passive geht, muss er etwas länger
> warten vor dem nächsten Sendeversuch, IIRC.
Sobald er Error-Passiv ist, wird der andere durchkommen, und
wenn er wieder aktiv wird, wird er auch durchkommen.
Nur, wenn noch mehr da sind, werden sich die Anderen bis
zum Error-Passiv durchschlagen, und bis die so weit sind,
ist der erste wieder da und das Spiel geht von vorne los.
Es ist keine schoene Loesung. Ich wuerde das nicht in einem Produkt
einsetzen wollen, weil irgendwann geht es beim Kunden schief, und man
kann den Fehler bei sich nicht nachvollziehen, weil man eine andere
Seriennummernkonstellation hat.
> Das ganze hängt damit aber auch etwas von der "Bushistorie" ab,
> sprich dem aktuellen Stand der Fehlerzähler.
Die sollten i.A. 0 sein, ansonsten hat man noch ganz andere Probleme.
> Aber ist in denn in diesem Fall die Kollisionswahrscheinlichkeit
> nicht so gering, dass man einen kurzen Bus-off einzelner Teil-
> nehmer in Kauf nehmen kann?
Der CAN-Bus ist im Normalzustand deterministisch, sonst wuerde die
Arbitrierung nicht funktionieren und der Teilnehmer mit der
hoechsten Prioritaet wuerde nicht gewinnen. Und einen Busoff als
normalen Betriebszustand bei der Anmeldung zu missbrauchen finde
ich gewagt.
Peter Schaeffer
Bringt nichts. Normalerweise will man die Anmeldung mit niedriger
Prioritaet fahren, d.h. wenn gerade ein Burst hochpriorer Nachrichten
auf dem Bus ist, werden sich die Anmeldungen hinten anstellen und
alle gleichzeitig loslegen, es sei denn man macht die Zufallszeit absurd
lange. Und durch diesen Effekt ist selbst dann die
Kollisionswahrscheinlichkeit relativ hoch. Selbst wenn man die
Anmeldung hochprior laufen laesst, muss das Ende des aktuellen Paketes
abgewartet werden.
Und sobald die erste Kollision da war, verhaelt sich der Bus
deterministisch, d.h. die Muellen sich mit Errorframes zu, bis einer
Error-Passiv wird.
Arne
> eigentlich um etwas anderes, aber es war ein Teilproblem.
>
> http://www-ivs.cs.uni-magdeburg.de/eos/forschung/publications/index.shtml.de
Danke fï¿œr den Input, das verfahren, wenn ich es richtig verstanden habe, sendet einfach die
Seriennummer zerstï¿œckelt im Identifier ï¿œber mehrere Nachrichten. Hï¿œrt isch gar-nicht so blï¿œd an.
> Schlechte Idee. Wenn du nichts machst, werden sie die Nachricht
> gleichzeitig wiederholen und und wieder ein Errorframe produzieren.
> Auf diese Art werden alle niederprioren CAN-Paket blockiert.
Hm, die eingesetzten Controller haben eine Option die nennt sich STT (Single Transmission Try),
damit wird ledglich einmal versucht die Nachricht ï¿œbermitteln, d.h. habe volle Softwarekontrolle,
kann kï¿œnnte damit eine Zufallszeit einbauen.
Gruￜ
Arne
Peter Schaeffer
>> Prof. Kaiser hat um 2000 Papers zu dem Thema veroeffentlicht. Es ging
>> eigentlich um etwas anderes, aber es war ein Teilproblem.
>>
>> http://www-ivs.cs.uni-magdeburg.de/eos/forschung/publications/index.shtml.de
>
>
> Danke fï¿œr den Input, das verfahren, wenn ich es richtig verstanden habe,
> sendet einfach die Seriennummer zerstï¿œckelt im Identifier ï¿œber mehrere
> Nachrichten. Hï¿œrt isch gar-nicht so blï¿œd an.
Ja, die Idee war, das ein leeres Datenpaket nie ein
Errorframe erzeugt, da alles ueber die Arbitrierung laeuft
(hier fuehrt ein Fehler zum Verlust der Arbitrierung und nicht zu einem
Busfehler). Danach muss man sich nur noch Gedanken machen,
wie der Master die einzelnen Fragmente zusammenstueckelt, auch
wenn mehrere Slaves sich gleichzeitig anmelden.
>> Schlechte Idee. Wenn du nichts machst, werden sie die Nachricht
>> gleichzeitig wiederholen und und wieder ein Errorframe produzieren.
>> Auf diese Art werden alle niederprioren CAN-Paket blockiert.
> Hm, die eingesetzten Controller haben eine Option die nennt sich STT
> (Single Transmission Try),
> damit wird ledglich einmal versucht die Nachricht ï¿œbermitteln, d.h. habe
> volle Softwarekontrolle, kann kï¿œnnte damit eine Zufallszeit einbauen.
Soetwas kannte ich nicht. Alle Controller die ich kenne wiederholen
endlos (evtl. gehen sie vorher vom Bus, aber das Paket bleibt da.
Lustig, wenn keine Gegenstelle da ist, und man sich wundert, warum die
Puffer nicht frei werden).