"CAN - CAN Bridge" Prinzip

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.

Mit "ACK" meine ich das CAN-Bus-ACK-Bit

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