Automatische Identifier Vergabe CAN-Bus

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?

Gruß Arne

Reply to
Arne
Loading thread data ...

Arneschrieb: "

hier jemand ein

CAN-Bus verbunden sind.

Geräten eindeutige

wieder entfernt

Steckplätze für diese Geräte.

Benutzer-erkennbare

mit statischen IDs

Seriennummer auf eine

sie mit einem

Seriennummer und neuer CAN-ID

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

Reply to
Dirk Ruth

Prof. Kaiser hat um 2000 Papers zu dem Thema veroeffentlicht. Es ging eigentlich um etwas anderes, aber es war ein Teilproblem.

formatting link

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).

Genau dieses Problem wurde damals geloest.

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.

Ab hier wird es wieder richtig.

Siehe oben. Ist aber sehr (zu) knapp gefasst und wenn man nicht in der Materie drinnen ist sehr schwer zu verstehen.

Reply to
Peter Schaeffer

hier jemand ein

CAN-Bus verbunden sind.

den Geräten eindeutige

wieder entfernt

Steckplätze für diese Geräte.

Benutzer-erkennbare

mit statischen IDs

Seriennummer auf eine

steigen sie mit einem

Seriennummer und neuer CAN-ID

auskommt?

Es zerstoert ein Paket und blockiert den Bus.

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.

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.

Reply to
Peter Schaeffer

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=C3=B6ht der den Fehlerz=C3=A4hler nicht= =20 st=C3=A4rker als die anderen, die auf den Error Frame nur aufspringen?

Wenn der dann fr=C3=BCher in Error Passive geht, muss er etwas l=C3=A4nge= r warten vor dem n=C3=A4chsten Sendeversuch, IIRC.

Das ganze h=C3=A4ngt damit aber auch etwas von der "Bushistorie" ab,=20 sprich dem aktuellen Stand der Fehlerz=C3=A4hler.

Aber ist in denn in diesem Fall die Kollisionswahrscheinlichkeit=20 nicht so gering, dass man einen kurzen Bus-off einzelner Teil- nehmer in Kauf nehmen kann?

Gru=C3=9F, Enrik

Reply to
Enrik Berkhan

Am 20.05.2010 02:16, schrieb Peter Schaeffer:

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?

Reply to
Heiko Lechner

Stimmt, es sehen zwar alle das Errorframe, aber nur er wird seinen Fehlerzaehler hochzaehlen und Error-Passiv werden.

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.

Die sollten i.A. 0 sein, ansonsten hat man noch ganz andere Probleme.

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.

Reply to
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.

Reply to
Peter Schaeffer

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.

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

Reply to
Arne

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.

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).

Reply to
Peter Schaeffer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.