Hallo Wenn ich von einem CAN Netz die Daten in ein anderes CAN Netz senden will und ich als Vermittler ein anderen Bus benutzte (z.B. Ethernet), wie gehe ich dann vor? Meine Idee war so: 1) Lese eingehende CAN Nachricht 2) Blockiere CAN Eingang für weitere Nachrichten 3) Sende empfangene Nachricht an Ziel Netz 4) Warte auf Bestätigung, dass am Ziel Netz die Nachricht auf den Bus gelegt wurde (bei entsprechender Buslast kann dies etwas dauern) 5) Wenn erfolgreich arbitrierte wurde, wieder Eingang am Quell CAN aktivieren So ist sichergestellt das sich keine Nachrichten anhäufen. Wird das so gemacht?
Hmm...ich hab das jetzt nicht im Detail durchdacht, aber warum willst du den CAN sperren? Eine Nachricht muss auf dem physical Layer so und so im ACK Bit "sofort" innerhalb des jeweiligen Subnetzwerkes bestätigt werden. Der Sender weiss also nur, dass innerhalb des Subnetzes die Nachricht definitiv richtig und fehlerfrei versendet wurde (oder auch nicht). Ob das Senden durch das Gateway ins andere Netz auch erfolgreich war kann nicht sichergestellt werden (oder nur durch entsprechende Programmierung in der darüber liegenden Anwendung). Der einfachste Fall wäre wirklich, ein Gateway mit Ein- und Ausgangspuffer zu bauen, und dann alle empfangenen Daten sofort ins andere Netzwerk zu senden (oder zumindest auf den Ausgangspuffer zu legen). Wenn dabei unterschiedliche Busgeschwindigkeiten zu Schwierigkeiten führen können, muss man sich weitere Gedanken machen. Beispielsweise nur die Nachrichten "routen" die wirklich in beiden Subnetzen notwendig sind. Auch die darüber liegende Anwendung sollte mit fehlenden/verzögerten Nachrichten zurecht kommen können und tollerant auf solche Fehler reagieren. Achja, Echtzeit, so es sie denn bei CAN wirklich gibt, muss in solch einem Fall natürlich nochmal untersucht werden. Torsten.
Du meinst es gibt ein Problem, wenn die Nachricht im Ziel Netz nicht gesendet werden kann (warum auch immer), und trotzdem schon am Quell Netz ein ACK gegeben wurde?
Meine Überlegung wäre sinnvoll z.B. bei folgendem Szenario: Quell-Netz: Anwender sendet "Motor an" und irgendwann wieder "Motor aus". Also 2 verschiedene CAN Nachrichten. "Motor aus" kann jedoch nur abgeschickt werden wenn "Motor an" am Ziel bestätigt wurde, sonst gibt es kein ACK und der Benutzer versucht solange bis es endlich klappt. Mit Puffern kann es passieren dass "Motor an" und danach sofort "Motor aus" hinternander folgen. Ich frage mich nur inwieweit der Benutzer mitkriegt dass es für eine Nachricht kein ACK gab. Wahrscheinlich garnicht. Angenommen der Sendeknoten sendet unaufhörlich (bis ein ACK kommt) und der Benutzer entscheidet ein anderes Siganl zu senden. Reiht dich das "andere Signal" hinten dran (FIFO) oder wird das vorherige Signal einfach storniert und mit dem neuen überschrieben?
Wenn wir von "ACK" reden, reden wir dann von dem CAN-Bus-ACK-Bit oder von einem aus der Anwendung???
"Mit Puffern kann es passieren dass "Motor an" und danach sofort "Motor aus" hinternander folgen." Wie schnell kann denn "Motor aus" auf "Motor an" folgen? Selbst wenn man einen Puffer hat, sollte sich das gesamte Senden im Millisekundenbereich abspielen, wenn nicht, dann sollte man das ganze Design noch mal überdenken. Torsten.
Wenn ich die Puffer am Ausgang verwende, solltes dann ein FIFO sein? Die CAN Nachrichten schicke ich dann in der Reihenfolge wie sie vorher empfangen wurden.
OK. Also das ACK Bit muss während das Datenpaket gesendet wird gesendet werden. Man kann damit nicht warten bis es über Ethernet gesendet wurde und dann auf dem Ziel-Bus empfangen wurde. Das ACK ist wirklich nur dazu da, um die Übertragung der Nachricht innerhalb des Subnetzes abzusichern. Alles andere musst du über deine Applikation und weitere Nachrichten machen (z.B. Bestätigungsnachricht, wenn der Motor an oder aus ist). Eine Andere Möglichkeit ist es, ständig (alle 100ms) den aktuellen Zustand (ein/aus) zurück zu senden und anzuzeigen, damit weiss der Nutzer immer über den aktuellen Status bescheid (Status-LED oder Display...). Ja ich würde ein FIFO verwenden, damit kann zumindest die Reihenfolge der Nachrichten eingehalten werden (nochmal: Zeitbedingungen können massiv durcheinander gewürfelt werden!!), aber zum Ein/Ausschalten des Motors sollte es reichen. Endlich WE :-) Torsten.
Mit dem ACK-Bit im CAN-Frame kann man nicht wirklich viel anfangen, denn innerhalb der CAN-Bus-Topologie senden alle CAN-Knoten, die noch am Bus sind, ein ACK auf eine Message. Für den Sender kann das nur noch soweit ausgewertet werden, als daß er noch am Bus teilnimmt und irgend einer ihn empfangen hat. Denn, der CAN-Bus ist broadcastfähig. Gruß Dietmar
@Armin:
Wie echtzeitfähig ist denn so ein Ethernet?
Ich muß gestehen, daß ich von Ethernet überhaupt keine Ahnung habe,
Echtzeitfähigkeit, vom CAN-Bus hingegen schon. Auch wenn meine
CAN-Bus-Applikation nicht alle Möglichkeiten ausreizt, die eine
CAN-Applikation haben kann.
Zu 1:) bis 7:) Blockieren auf gar keinen Fall. Ich habe in allen
CAN-Knoten ein RX- und TX-FIFO implementiert.
>So ist sichergestellt das sich keine Nachrichten anhäufen.
Da werden die Messages so schnell sie können abgearbeitet. FIFO
deswegen, um keine Message zu verlieren, anstatt Blockieren. Auch für
ein CAN-Gateway macht das Sinn.
Wie sind denn die maximalen Reaktionszeiten, d.h., von der
CAN-Steuer-Message bis zur Antwort an den CAN-Knoten, der die Auslösung
verursacht?
Das wird sicher in CAN-Messages mit spezifizierten Identifiern verpackt
werden müssen.
Also:
Sende CAN-Message an einen CAN-Controller mit Ethernet-Bridge
Warte auf eine CAN-Acknowledge-Message vom CAN-Controller mit
Ethernet-Bridge
Dabei ist die Acknowledge Message eine Antwort vom Ziel-CAN-Controller
mit spezifiziertem CAN-Identifier hinter der Ethernet-Bridge an den
Quell-CAN-Controller mit spezifiziertem CAN-Identifier vor der
Ethernet-Bridge.
Gruß
Dietmar
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.