CAN Busknoten mit demselben Identifier

[Holger B. (rst-el)]

Hallo,
ich habe ein CAN Netzwerk mit mehreren Knoten laufen. Es gibt eine 
Zentralsteuereinheit (Master) und ca. 32 Peripherieknoten (Slaves).

Die Identifier der Slaves werden per DIP-Schalter festgelegt. 
Theoretisch könnte der Benutzer versehentlich an mehreren Knoten die 
DIP-Schalter gleich einstellen, wodurch diese mit denselben Identifieren 
arbeiten.

Ich würde gerne eine Erkennung einbauen, die dies zuverlässig erkennt.

Bei Tests habe ich festgestellt, daß bei gleichzeitigem Senden der 
Slaves mit derselben DIP-Schaltereinstellung der Transmit Error Counter 
inkrementiert wird.

Gibt es eine Möglichkeit, solche Zustände anders zu diagnostizieren als 
über die Auswertung der Fehlerzähler ?


Gruß H.

[jochen (Gast)]

Hallo,

Im Allgemeinen gibt es im CAN keinen Identifier für einen Knoten, 
sondern die zu versendene Nachricht besitzt einen Identifier, dessen 
Wert bestimmt gleichzeitig die Priorität der Nachricht auf dem BUS.


Jochen

[bernd (Gast)]

Da muss ich Jochen Recht geben. Und es ist ja auch eine gewollte 
Eigenschaft des CAN-Bus das manche "Knoten" eben auf denselben 
Identifier reagieren. Zum Beispiel auf Alarmnachrichten.

[Wolfgang B. (logox2)]

Hallo,

da muß ich Bernd und Jochen recht geben:

Beim CAN-Bus haben Nachrichten bestimmte Identifier, Knoten können auch 
Nachrichten mit verschiedenen Identifiern mitlesen.
Der Bus ist eben auch extra so ausgelegt, das eine Nachricht von 
mehreren Empfänger gelesen werden kann.

Somit sehe ich leider keine Möglichkeit die Einstellung zu 
diagnostizieren.

Grüße
Wolfgang

[peterguy (Gast)]

> Im Allgemeinen gibt es im CAN keinen Identifier für einen Knoten,
> sondern die zu versendene Nachricht besitzt einen Identifier, dessen
> Wert bestimmt gleichzeitig die Priorität der Nachricht auf dem BUS.

Generell hast du da recht, aber bei Holgers Anwendung ist es schon so 
daß die IDs der Nachrichten knotenspezifisch sind, da sie am Knoten 
eingestellt werden.

Zum Problem an sich:
Vielleicht kann in zufälligen Abständen jeder Slave für kurze Zeit auf 
seine eigene ID lauschen (ohne selbst zu senden). Wenn er was empfängt 
ist das dann ein Fehler.

[Peter D. (peda)]

Holger B. schrieb:
> Bei Tests habe ich festgestellt, daß bei gleichzeitigem Senden der
> Slaves mit derselben DIP-Schaltereinstellung der Transmit Error Counter
> inkrementiert wird.

Es dürfen zwar mehrere Teilnehmer den selben ID empfangen, aber nicht 
senden.
Denn die Arbitrierung ist nach dem Identifier beendet und dann erzeugen 
unterschiedliche Daten unweigerlich einen Error, d.h. auch das 
Datenpaket des dominanten Masters wird ungültig.


Im Unterschied zu I2C, da ist das erlaubt. Ein Master kann bis zum 
letzten Datenbit die Arbitrierung verlieren. Die Daten des dominanten 
Masters bleiben gültig.


Peter

[(prx) A. K. (prx)]

Ein Verfahren dafür liesse sich schon implementieren. Indem eine Node, 
die frisch ins Netz geht, erst ein paarmal ihre ID(s) als NOP-Message 
rausbläst und auf die Reaktion horcht. Wenn es dabei nicht scheppert und 
sich niemand beschwert, dann sieht es gut aus.

Sinnvollerweise wird man nach erheblichem Anstieg der Fehlerzustände 
diese Prozedur wiederholen.

[Sven T. (svent)]

Hallo,
zunächst einmal für mich zum Verständnis :
Das System hat einen Master-Knoten M und viele Slaves S1 bis S32.
An S1 bis S32 können IDs vergeben werden die eigenltich eindeutig sein 
sollten.


Ich vermute nun, dass das System so sein soll, dass M eine Botschaft mit 
verchickt, die einen der Slaves dazu veranlassen soll zu antworten.
Sehe ich das so richtig ?

Eigentlich ist der Ansatz von CAN ein anderer....es gibt eigentlich 
keine Master und Slaves sondern ein Knoten legt dann eine Botschaft auf 
den Bus wenn er was zu sagen hat....aber okay.

Mir scheint hier eine Art "ich fordere Daten von einem Knoten an" 
realisiert zu werden.

Dazu sind im CAN Protokoll eigentlich die Remote Frames gedacht.
Hierbei setzt der initiierende Knoten das RTR (das erste Bit nach der 
ID).
Das veranlasst den empfangenden Knoten dass er sendet.

Ich vermute aber eher dass dies hier nicht verwendet wird.

Aber seis drum.

Was durchaus üblich ist ist folgende Vorgehensweise :
Ein Slave sendet eine Botschaft auf die eigentlich nur er selbst 
antworten müsste.
Kommt eine Antwort ist noch ein anderer mit der selben ID konfiguriert.


S.