Ich hab folgendes Problem für die Erstellung eines eignen Protokolls. Ich habe ein Human Machine Interface Steuergerät das ein Display und eine Tastatur enthält sowie meherer Applikations Steuergeräte. Wenn jetzt zwei Applikations Steuergeräte gleichzeitig CAN Botschaften an das Human Machine Interface Steuergerät senden, dann geht die CAN Botschaft verloren die eine niedrigere Priorität hat. Wie kann ich dies in einem Human Machine Interface Protokoll lösen, das auch die niedrigere priore CAN Botschaft noch verarbeitet werden kann? Appl-SG_1 CAN-ID: 50hex Appl-SG_2 CAN-ID: 51hex <-- diese CAN Botascht hat eine niedrige Prorität
Weisst du wie man so ein Protokoll aufziehen bzw. grafisch (Skizze) darstellen kann?
Blödsinn. Nix geht verloren. Die Message mit der niedrigen Prio wird später gesendet. Das macht der CAN-Controller föllig selbstständig. Volker
> Ich habe ein Human Machine Interface Steuergerät das ein Display und > eine Tastatur enthält sowie meherer Applikations Steuergeräte. Wenn > jetzt zwei Applikations Steuergeräte gleichzeitig CAN Botschaften an das > Human Machine Interface Steuergerät senden, dann geht die CAN Botschaft > verloren die eine niedrigere Priorität hat. Wie kann ich dies in einem > Human Machine Interface Protokoll lösen, das auch die niedrigere priore > CAN Botschaft noch verarbeitet werden kann? Hallo Ingo, ein proprietaeres CAN - Protokoll aufzusetzen ist schon eine Aufgabe! Genau deshalb sind die CAN Layer eben definiert wie sie definiert sind. WAS and Deiner Kommunikation ist den neigentlich "CAN"? Normalerweise ist diese Arbitrierung genau in der CAN Spezification definiert. Wenn Du aber selber was bastelst, musst Du einfach Deinen Sender mirhoeren lassen und den Pegel auf dem Physical Layer mit dem Sendesignal vergleichen. Der erste, der eine Abweichung feststellt, wartet bis die naechste Botschaft vorbei ist und probierts dann eben nochmal. Und wie VOlker sagt: Das muesste Dein System selber machen...ausser Du baust ein CAN Netzwerk mit PIC16F88 auf ;-) Gruss Michael
Ich möchte quasi ein eigenes Protokoll entwerfen das auf Layer 3 sitzt. CAN deckt ja Layer 2 und 1 ab.
Hallo Volker, was du geschrieben hast stimmt aber so nicht. >>Blödsinn. Nix geht verloren. Die Message mit der niedrigen Prio wird >>später gesendet. Das macht der CAN-Controller föllig selbstständig. Wie soll der Controller automatisch nochmal die CAN Botschaft senden. Das muss schon ein übergeordnetes Protokoll (Layer 3) tun.
Hallo, ich bin davon ausgegegangen das der TE die höheren Schichten "designen" will. Als ala CANopen, DeviceNez, J1939 etc. Sich alo nicht die Schichten 0 und 1 vornehmen wollte. Aber vielleicht könnte Ingo ja genau erklären was er erstellt(ISO 7-Schichtenmodell,Hard- und/oder Sofware)? Volker
Human Machine Interface Protokoll auf der Basis von CAN entwerfen. -quasi gleichzeitige Kommunikation der Appl-SG mit dem Human Machine Interface-SG -Die Zuordnung der CAN-Botschaften zum jeweiligen Appl-SG sicherstellen -Der Zugriff auf das Human Machine Interface-Sg soll geregelt werden
Dann würde ich mal sagen, dass das ganze erst mal gar nichts mit einem HID zu tun hat. Wenn die Messages verloren gehen können, musst du daran arbeiten das zu unterbinden. Und erst da drauf wird dann die HID-Schicht gesetzt. D.h. die Schicht die du im Begriff bist zu entwerfen, kann sich schon auf einen Unterbau stützen, bei dem Messages auch wirklich ankommen und nichts verloren geht.
Hallo Ingo, priorisieren heißt nicht wegschmeissen. Die zertifiezirten CAN-Controller änthalten auch Funktionen höherer Schichten. (Ich glaube auch Funcktionen aus Schicht 5 waren dabei, finde jetzt aber keine Quelle). Selbst fehlerhafte Messages werden erkannt und müssen vom Controller eine bestimmte Anahl(je nach Fehler) wiederholt werden. Siehe Seite 5. http://www.can-cia.org/fileadmin/cia/specifications/CAN20A.pdf ciao Volker
ingo schrieb: >>>Blödsinn. Nix geht verloren. Die Message mit der niedrigen Prio wird >>>später gesendet. Das macht der CAN-Controller föllig selbstständig. > > Wie soll der Controller automatisch nochmal die CAN Botschaft senden. > Das muss schon ein übergeordnetes Protokoll (Layer 3) tun. Wenn ein CAN-Controller während des Sendens den Bus verliert, hört er auf zu senden und beginnt dann wieder, wenn der Bus wieder frei ist. Vollkommen selbstständig. Es sei denn, der CAN-Controller hat sowas wie einen "One Shot Mode" (der MCP2515 hat sowas). Dann werden die Nachrichten grundsätzlich nur ein mal gesendet. Auch wenn sie unterbrochen werden.
Hallo Ingo, tut er aber nicht. Er enthält auch die Sicherungsschicht. Es sei den Du verwendest einen selbst gebauten CAN-Controller. @Sven dieses Feuture haben neuerdings viele CAN-Controller. Den "One Shot Mode" sollte mann aber nur für Testzwecke oder besondere Fälle (selbst konfigurierende Busse) verwenden, da er ein erheblichen Einschnitt in die Sicherheit des CAN-Busses darstellt. Alle hoeheren Protokolle verlassen sich auf die Sicherungsschicht des CAN-Controllers. ciao Volker
Danke für eure Unterstützung. Mich verwirrt das ganze. >Wenn ein CAN-Controller während des Sendens den Bus verliert, hört er >auf zu senden und beginnt dann wieder, wenn der Bus wieder frei ist. >Vollkommen selbstständig. Wird dann gleich wieder automatisch die gleiche Nachricht wieder auf den BUS gesendet? Auf welcher Schicht ist dies angesidelt?
Hallo Ingo, Das CAN-Protokoll ist keine saubere 1:1-Implementierung des 7-Schichtenmodels. Es wurden Schichten weggelassen (3. Network Layer), bei anderen wurden nur Teile der Schicht implementiert (5. Session Layer). Als ich würde das der Schicht 4. (Transport Layer) zu ordnen. Viel spass in der Realität. Volker
Bin noch irgendwie ratlos. Soll ich das Protokoll auf Basis von CanOpen entwerfen oder soll ich mir was eigenes überlegen?
Wer veranlasst eigentlich, das die niederpriore CAN-Botschaft nochmals verwendet wird? Ist das die WIRED - AND - Buslogik?
Hallo Ingo, CANopen bietet sicherlich alles was Du brauchst. Und das was in einem Jahr noch dazu kommt, auch. Es giebt für (fast) alles ein Profil. Es giebt genug Anbieter des CANopen-Stack. CANopen ist aber auch sehr mächtig. Das heisst das du ein paar Wochen brauchen wirst, um einen Überblick zu bekommen. Den Stack selber zu schreiben ist praktisch nicht möglich. Da ich weder deine übrigen Randbedingungen kenne, noch mich in den anderen höheren CAN-Protokollen auskenne, kann ich dir leider nichts empfehlen. Das was ich empfehlen kann ist eine systematisches Vorgehen: Festlegen der Anforderungen, Lesen der Spezifikationen, tabelarische Auswertung. ciao Volker
ingo schrieb: > Wer veranlasst eigentlich, das die niederpriore CAN-Botschaft nochmals > verwendet wird? Ist das die WIRED - AND - Buslogik? NEIN, das ist in Hardware gegossene Logik des CAN-Controllers. Hat nichts mit der Bus-Logik oder dem Transceiver zutun. Noch ein Rat: Bevor du dir ein höheres Protokoll auswählst, solltest du CAN-bus, die verschiedenen Transceiver und die Kontroller kennen. Mit deinem jetzigen Wissenstand würde ich kein höheres Protokoll selbst entwerfen. Es giebt auch Schulungen zu diesem Themengebiet, wenn das Selbststudium Probleme aufwirft. ciao Volker
Randbedingungen: -Am CAN-Bus hängen mehrere Appl-Steuergeräte und ein Human-Machine-Interface-Steuergerät -Appl-Steuergerät: dort läuft eine Appl (benötigt die Interaktion mit dem Fahrer) -Human-Machine-Interface-Steuergerät: Interaktion mit dem Fahrer -keine Zeitl. Festlegungen für die Nutzung des Human-Machine-Interface-Steuergerät
Mit "Randbedingung" meinte ich eher soetwas wie Budged, Zeit, Anzahl der Entwickler, anschluß von Fremdgeräten etc. Aber auch für die NUR technische Auswahl des richtigen Protokolss, reichen deine allgemeine Beschreibung nicht aus. Hier sind Funktion und Zahlen gefragt. Aber nicht von mir! Jetzt Verstanden? Wer will weiter machen?
Nur noch eine Sache. Wer veranlasst eigentlich, das die niederpriore CAN-Botschaft nochmals gesendet wird? Wo ist dies im CAN Protokoll definiert bzw. umgesetzt? Das verwirrt mich nämlich. Dies bedeutet ja eigentlich, dass man sich darum gar nicht mehr kümmern muss, das die niederpriore CAN-Botschaft versendet wird oder?
wenn: a) noch buskapazität frei ist b) one-shoot o.ä. deaktiviert ist (ist die regel) kannst du davon ausgehen, dass alle nachrichten von allen teilnehmern empfangen werden, (solange keiner in einem fehlerzustand schmollt) Was nicht garantiert ist: es können nachrichten doppelt ankommen, ohne dass es dem empfänger mitgeteilt wird (durch einen bitfehler im akn-bit beim sender).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.