|
Anzeige
|
Can bus. Wer hat jetzt Priorität.
Gast
#3824293
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
Gast
#3824300
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.
Gast
#3824301
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.
Gast
#3824368
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? 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.
Gast
#3824401
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.
Gast
#3824952
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.
Gast
#3973156
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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
