Hallo Leute, ich hoffe ihr könnt mir helfen oder nützliche Infos geben. Ich muss für ein Projekt CAN-Daten über einen LWL-Sender zu einem LWL-Empfänger bringen und dann wieder auf eine normale CAN-Struktur bringen. Nur leider hab ich keine Ahnung wie ich das anstellen soll. Mir geht es in erster Linie um die Treiberschaltungen für den Sender und den Empfänger. Eben der Teil der das CAN-Signal auf den LWL bringt und den Teil der des wieder vom Empfänger runter bringt. Ich bin für jede Hilfe dankbar. Gruß Simon
Gar nicht so einfach, weil der Knoten ja seine eigene Sendung wieder empfangen können muß.......
CAN over Ethernet und dann an nen Switch mit LWL Uplink? Muss das wirklich selbst gebastelt werden?
Wenn Daten nur in eine Richtung durchgeleitet werden sollen, und es im CAN-Netz auf Empfänger-Seite keine Sender gibt, geht es einfach so: Sendernetz -> CAN Transceiver -> RX Signal -> LWL Sender -> LWL Empfänger -> CAN Transceiver (TX Signal) -> Empfängernetz wenn sich aber auf beiden CAN Netzen Sender befinden, wird es kompliziert. Entweder du schaffst es irgendwie das LWL bidirektional zu betreiben und dabei auch die strengen Timing-Anforderungen einzuhalten, oder du machst es mit zwei Mikrocontrollern: CAN Netz <-> CAN Transceiver <-> Mikrocontroller <-> zB UART <-> LWL <-> zB UART <-> Mikrocontroller <-> CAN Transceiver <-> CAN Netz Die Mikrocontroller musst du dann so programmieren, dass sie die Nachrichten vom CAN zum zB UART umsetzen und hin und her senden. Dabei kannst du z.B. auch die ID's filtern und nur bestimmte Nachrichten übertragen.
@Sascha ja, muss leider selber gebastelt werden @Dr. Sommer fällt dir noch ne Möglichkeit ein für Bidirektionalen Datenverkehr ohne Microcontroller? Könnte man nicht je Seite, einen LWL-Sender und LWL-Empfänger anbringen? Es gibt ja auch LWL Transceiver die beides vereinen, also Senden und Empfangen. Leider fallen die bei mir Flach, weil ich den Anschlusstyp vom LWL vorgegeben hab und der so alt ist, dass es dafür keine Transceiver gibt.
Das Problem dabei ist, daß bei unidirektionaler Lösung der jeweilige Sender kein ACK bekommt (und kein NACK), von daher wird er vermutlich früher oder später seinen Error-Counter überlaufen lassen und dan stellt er sich taub... Meines Wissens nach geht es nicht, einen CAN-Teilnehmer als reinen Sender laufen zu lassen...
Simon R. schrieb: > Könnte man nicht je Seite, einen LWL-Sender und LWL-Empfänger anbringen? Ja, wenn wie gesagt das LWL+Transceiver Konstrukt schnell genug ist. Ein Bit muss in unter einer Bit-Zeit vom einen Netz ins andere und wieder zurück kommen. Da gibts genaue Vorgaben, da musst du mal in den CAN-Spezifikationen etwas graben. npn schrieb: > Das Problem dabei ist, daß bei unidirektionaler Lösung der jeweilige > Sender kein ACK bekommt (und kein NACK) Das größere Problem ist, dass zwei Controller nicht gleichzeitig auf beiden Netzen senden dürfen, da es sonst zur Kollision kommt, daher müssen die Bits schnell genug hin und her gehen... Das nicht ankommende ACK-Bit kann man typischerweise auch ignorieren. npn schrieb: > Meines Wissens nach geht es nicht, einen CAN-Teilnehmer als reinen > Sender laufen zu lassen... Richtig, es sei denn es gibt keine weiteren Sender.
Ist doch zum Mäuse melken.... Dachte eigentlich das es kein großes Problem darstellt, die CAN-Leitung kurzzeitig durch einen LWL zu ersetzen. Sprich CAN<->LWL<->CAN Ach, vllt zur vereinfachung, des ganze wird/soll am Ende nur eine Point to Point strecke sein! Also keine anderen CAN Teilnehmer. Nur der PC mit Software dann auf CAN und dann direkt zum Steuergerät. Vllt hilft des zur Vereinfachung. Hintergrund sind EMV-Messungen in einer Isolierten Kammer, da sollten halt keine Kupferleitungen von draussen rein führen. Somit war gedacht, den PC ausserhalb aufzustellen, auf eine Selbstentworfene Platine drauf mit CAN, die es dann auf LWL umsetzt. Dann den LWL in die Kammer legen, und direkt am Stuergerät mit der zweiten Platine das LWL Signal wieder auf CAN umsetzen. Macht es die erklärung beser oder noch schlimmer? :)
Simon R. schrieb: > Ach, vllt zur vereinfachung, des ganze wird/soll am Ende nur eine Point > to Point strecke sein Immerhin... Kannst du uns sagen ob nur Nachrichten in eine Richtung (PC->Gerät oder andersrum) müssen? Das würde es vereinfachen.
Dr. Sommer schrieb: > Richtig, es sei denn es gibt keine weiteren Sender. Und was ist mit dem notwendigen ACK? Wenn das nicht kommt, läuft doch der Errorcounter über, oder?
npn schrieb: > Und was ist mit dem notwendigen ACK? Wenn das nicht kommt, läuft doch > der Errorcounter über, oder? Wenn man den Sender umprogrammieren kann, könnte man es einstellen dass das fehlende ACK-Bit ignoriert wird. Bei den CAN-Controllern der STM32 z.B. geht das, und bei den Vector CANcase's ebenfalls. Alternativ hängt man einfach einen "dummy" Can Controller dran, der nichts anderes macht als das ACK-Bit zu senden ;-)
Dr. Sommer schrieb: > Alternativ hängt > man einfach einen "dummy" Can Controller dran, der nichts anderes macht > als das ACK-Bit zu senden ;-) Auch 'ne Möglichkeit ;-)
@Dr. Sommer Leider in beide Richtungen, Das Endgerät ist eine Drehzahlsimulationsbox mit entsprechenden Hall-Sensoren. Diese wird für Drehzaländerungen angesprochen also PC->Gerät und die Sensoren wieder ausgelesen Gerät->PC. bleibt also bidirektional. @Stefan Ja, sollte selber gebaut werden. Weil die feritgen Lösungen im Internet je nach Qualität, zwischen 1000 und 3000 € kosten.
Simon R. schrieb: > Hallo Leute, > > ich hoffe ihr könnt mir helfen oder nützliche Infos geben. > Ich muss für ein Projekt CAN-Daten über einen LWL-Sender zu einem > LWL-Empfänger bringen und dann wieder auf eine normale CAN-Struktur > bringen. > > Nur leider hab ich keine Ahnung wie ich das anstellen soll. > > Mir geht es in erster Linie um die Treiberschaltungen für den Sender und > den Empfänger. > Eben der Teil der das CAN-Signal auf den LWL bringt und den Teil der des > wieder vom Empfänger runter bringt. > > Ich bin für jede Hilfe dankbar. > > Gruß Simon leg den CAN-Bus auf einen Transceiver, da fallen auf der anderen Seite Rx & Tx heraus. Die legst Du auf Deinen LWL-Teil (2 Adern) und am Ende gehst Du über RX/TX wieder auf den Transceiver und hast wieder einen CAN-Bus am werken. Wo ist das Problem?
CAN schrieb: > Wo ist das Problem? Wie schon 2x gesagt, die Geschwindigkeit muss stimmen. Wenn der Sender ein Bit sendet, muss das in einem Bruchteil der Bitzeit beim anderen Ende ankommen, damit die andere Seite nicht gleichzeitig eine andere Nachricht sendet.
Dr. Sommer schrieb: > CAN schrieb: >> Wo ist das Problem? > > Wie schon 2x gesagt, die Geschwindigkeit muss stimmen. Wenn der Sender > ein Bit sendet, muss das in einem Bruchteil der Bitzeit beim anderen > Ende ankommen, damit die andere Seite nicht gleichzeitig eine andere > Nachricht sendet. Ich weiß wovon ich rede. Da heute GBit-Teile LWL-Sender als auch Empfänger zur Verfügung stehen sehe ich - abgesehen von der Laufzeit durch mehrere km Kabel - kein Problem. BTDT. Mit dem Plastik-Audio-Zeugs gehts nicht, aber davon war auch nicht die Rede.
CAN schrieb: > Da heute GBit-Teile LWL-Sender als auch Empfänger zur Verfügung stehen > sehe ich - abgesehen von der Laufzeit durch mehrere km Kabel - kein > Problem. BTDT. Ich ahnte dass das jetzt kommt. GBit/s ist eine Bandbreiten-Angabe, keine Latenz-Angabe. Es muss sichergestellt sein, dass die Latenz eingehalten wird. Welche optischen Transceiver das können, weiß ich nicht.
>Sieh einmal diese Seite an:
"Diese Verbindung ist nicht sicher"
hmmm....
Na, soooo schwierig ist das auch wieder nicht. Hamwa schon vor 15 Jahren gemacht, als CAN gerade aufkam mit den Intel-Demoboards. Siehe http://www.can-cia.org/ oder auch http://www.peak-system.com/PCAN-LWL.214.0.html Servus, Helmut.
Simon R. schrieb: > Dachte eigentlich das es kein großes Problem darstellt, die CAN-Leitung > kurzzeitig durch einen LWL zu ersetzen. > Sprich CAN<->LWL<->CAN So trivial kann es nicht sein, sonst wären die Sontec OPTOCAN 2000 nicht so konkurrenzlos. Bisher hat jedes EMV-Labor versucht, sich seine eigene Lösung zu frickeln und ist für anspruchsvolle Aufgaben doch immer wieder beim OPTOCAN gelandet.
Dr. Sommer schrieb: > CAN schrieb: >> Da heute GBit-Teile LWL-Sender als auch Empfänger zur Verfügung stehen >> sehe ich - abgesehen von der Laufzeit durch mehrere km Kabel - kein >> Problem. BTDT. > Ich ahnte dass das jetzt kommt. GBit/s ist eine Bandbreiten-Angabe, > keine Latenz-Angabe. Es muss sichergestellt sein, dass die Latenz > eingehalten wird. Welche optischen Transceiver das können, weiß ich > nicht. Naja, was erwartest Du dir? TO fragt nach Optischer Trennung, werde ich also nicht Leuchttürme oder Rauchzeichen mittels Lagerfeuer als Transportmedium nennen. Wir haben mit ca. 100ns zusätzlicher Latenz durch die Optoteile bisher jedenfalls kein Problem bei 250kbit gehabt. Und da der CAN-Knoten selber von dem ganzen Medienkonverterpipapo nichts mitbekommt verstehe ich Deine Sorge nicht. Und da der TO nicht sagt wie hoch die Bitrate in seinem CAN ist... TO soll sich den ISO1050 anschauen (als Prinzip) und/oder andere CAN-Empfänger mit RS auf GND gelegt anschauen, da sind die Durchlaufzeiten auch ca. +/- 100ns, macht also in Summe max. 300ns durch die Chips und dann die Laufzeit durch den LWL. PS: Gbit über LWL funktioniert auch nicht wenn die Latenz zu hoch wird. So what.
Hallo, Ok, bei den Anforderungen ist LWL klar - aber muss es denn CAN sein? Eine einfache serielle Schnittstelle über ein POF-Zwillings-LWLkabel zu führen ist vergleichsweise trivial. Georg
Besagter Sontec OPTOLIN 2000 hat eine Durchlaufzeit von 140 ns. Dazu kommen noch 100 ns pro 20 m Lichtleiterkabel für die Lichtgeschwindigkeit.
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.