Can bus. Wer hat jetzt Priorität.

[Heizer (Gast)]

Hallo Leute,


A 1 0 0 1 0 1 0 0
B 1 0 0 1 0 0 1 0
C 1 0 0 1 0 1 1 0

So. Hier gewinnt natürlich der Sender B. Als nächstes ist der Sender A 
und  dann C dran.
ABER:
Angenommen der Sender B (welches zuerst senden darf) sendet ein 
Botschaft an C mit Aufforderung der z.B. aktuellen Sensordaten?
Nun jetzt, Wer darf als nächses?
Gilt weiterhin die Reihenfolge B, A, C
oder hat sich die Reihenfolge jetzt geändert und B, C, A geworden?

Vielen Dank

[Rudolph (Gast)]

Beim CAN gibt es keine Priorisierung nach Sender oder Empfänger, die 
Botschaften sind durch die IDs priorisiert.

Wenn Dein Sender "C" mit der niedrigsten ID sendet dann darf er das 
zuerst.

[cantest (Gast)]

wenn die sensordaten wichtig sind, muss der header der nachricht von C 
eben höher priorisiert sein. ansonsten gilt die selbe reihenfolge, falls 
a und c wieder gleichzeitig senden, wird sich die nachricht von a 
durchsetzen.

sender C muss ja nicht zwingend immer seine nachrichten mit 1 0 0 1 0 1 
1 0 beginnen.

[Heizer (Gast)]

cantest schrieb:
> sender C muss ja nicht zwingend immer seine nachrichten mit 1 0 0 1 0 1
> 1 0 beginnen.

was heißt das konkret?
Also kann C als Antwort für B mit einer anderen Adressierung antworten 
als sonst?

[Karl H. (kbuchegg)]

Heizer schrieb:
> cantest schrieb:
>> sender C muss ja nicht zwingend immer seine nachrichten mit 1 0 0 1 0 1
>> 1 0 beginnen.
>
> was heißt das konkret?
> Also kann C als Antwort für B mit einer anderen Adressierung antworten
> als sonst?

In CAN hat nicht der Sender eine Adresse.
Genau genommen ist die Grundidee von CAN, dass es keinen dezidierten 
Sender bzw. Empfänger gibt.
Sondern wer etwas zu sagen hat, der brüllt einfach sein Weisheit auf den 
Bus raus und wen es auch immer interessiert, der hört zu und fischt sich 
aus den Nachrichten die raus, die für ihn brauchbar sind.

Das ist die Grundidee hinter CAN

Das man damit durch den Nachrichteninhalt wieder so was wie eine Sender 
Empfänger Abhängigkeit erzielen kann, ist eine andere Geschichte, die 
aber an CAN komplett vorbeigeht.

Es sind die Nachrichten (deren Id) die eine Priorisierung tragen und 
nicht die Geräte.
Und ja. Wenn ein Busteilnehmer die Temperatur, den Reifendruck und 
Regenmenge misst, dann erzeugt er eben 3 verschiedene Nachrichten auf 
dem Bus mit jeweils einer eigenen Id. Den ABS Sensor interessieren 
vielleicht die Regenwerte und er holt sich die vom CAN Bus. Das 
Armaturenbrett interessiert nur die Temperatur und daher holt es sich 
diese Nachrichten vom Bus. Das alles interessiert aber den Sensor nicht. 
Der teilt einfach nur zur gefälligen Kenntnisnahme regelmässig seine 
Werte der Allgemeinheit mit.

[cantest (Gast)]

beispiel für das was karl heinz schrieb:

du hast eine nachricht "sensordaten anfragen" beginnt mit 1 0 0 1 0 0 1 
0
dabei ist es egal ob diese nachricht von a, b, c oder xyz gesendet wird. 
deine sensoren oder ein sensor hört auf diese nachricht und sendet seine 
daten mit der nachricht "sensordaten" 1 0 0 1 0 0 0 0 mit einer höheren 
priorisierung. dann hört b die nachricht und freut sich "huhu 
sensordaten, die brauch ich doch" und verarbeitet diese (vllt hört aber 
auch a zu und freut sich ebenfalls ).

in einem can-netzwerk sollte man also nachrichttypen definieren und 
diese anhand der id priorisieren und die sender/empfänger so 
programmieren, das sie die entsprechende nachrichten senden bzw 
empfangen und verarbeiten.

[Rudolph (Gast)]

cantest schrieb:
> du hast eine nachricht "sensordaten anfragen"

Das ist schon normal nicht wirklich sinnvoll.
Die Knoten senden einfach zyklisch und wenn man Daten hat die seltener 
gebraucht werden dann packt man die eben nur alle 500 ms auf den Bus und 
vielleicht noch mit niedrigerer Priorität.
Und wenn dem Knoten der das empfängt gerade danach ist das zu 
verarbeiten, dann macht er das halt.

[Sven Green (Gast)]

Im Auto mag das weniger sinnvoll sein, aber bei CANopen durchaus 
vorgesehen. Dort gibt es die ProzessDatenObjekte mit denen z.B. ihren 
Hauptwert regulär, übertragen, entweder im festen Intervall, ausgelöst 
durch ein Sensor-Ereignis oder nach Empfang eines SYNC-Telegramms. 
Andererseits gibt es die ServiceDatenObjekte womit sich alles abfrägen 
lässt, was ein Sensor so an Info zu bieten hat (inkl. Konfiguration 
etc.). Und da kann ich mir schon viele Szenarien vorstellen, dass man 
etwas nur im Bedarfsfall abfragt anstatt den Bus permanent damit zu 
füllen.