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?
"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
