|
Anzeige
|
Funktionsweise CAN <-> LWL <-> CANHi, es gibt von Peak System ein Gerät PCAN-LWL (Ankopplung für optische Übertragung von CAN- und CAN-FD-Daten). Mit dem kann man eine CAN-Verbindung über LWL betreiben: https://www.peak-system.com/PCAN-LWL.214.0.html . Man schaltet 2 dieser Teile in eine bestehende CAN-Verbindung mit LWL dazwischen. Wie funktioniert so eine Umsetzung technisch? Die Kommunikation geht ja in beide Richtungen, das ist dadurch nicht trivial. Ist das mit einem Mikrocontroller gelöst oder geht das auch ohne? Beim analogen Telefon nennt man das Gabelschaltung. Für digitale Signale kann man das auch nachbauen ohne Prozessor. Ist halt etwas Logik dahinter, aber geht schon. Das ist ähnlich einem CAN-Repeater oder einem optischen Isolator mit Optokopplern. Genaue Beschreibungen finden sich bei diversen Herstellern und im Wikipedia.
Könntest Du mir einen Tipp geben, mit welchen Begriffen ich genau suchen muss? Bisher bin ich selbst nicht weiter gekommen. Bzw. einen konkreten Link zu entsprechenden Infos nennen? Ein Schaltplan einer solchen Schaltung wäre super.
Naja, ganz so einfach ist das nicht. Der schwierige Teil ist das enge Timing. Denn bei CAN musst Du die CRC prüfen und hast dann nur wenige Takte Zeit zu entscheiden ob Du ACK sendest oder nicht. Und ein gesendetes ACK muss dann im richtigen Moment auf dem Rest des gesamten Busses ankommen. Weil das bei höheren Datenraten auch schon mit normalem, direkt verbundenem, CAN-FD schwer wird, haben die dieses ACK-Konzept beim Nachfolger CAN-XL rausgeworfen. CAN funktioniert mit einen dominanten ('0) und einen rezessiven('1') Signal und der Erkennung der Kanalbelegung wenn bei der Arbitrierung ein dominates Signal erkannt wird obwohl man selbst nur rezessiv "sendet". Das geht auch mit Licht, 'Licht an' ist dominant, Licht aus rezessive. Man darf aber nur mit solchen Baudraten senden, das die Erkennung noch innerhalb des Taktes erfolgen kann. Wenn man in das PCAN-LWL Benutzerhandbuch schaut bekommt man einige Hinweise zur Funktion, z.B. gibt es jeweils zwei CAN Transceiver (Low-/High-Speed, maximal 500 kBit/s bei High-Speed) von denen man einen auswählen muss und die Verbindung zwischen den beiden Modulen erfolgt durch zwei Lichtwellenleiter.
Man muss nur die Bedienungsanleitung lesen: https://www.peak-system.com/produktcd/Pdf/Deutsch/PCAN-LWL_UserMan_deu.pdf Auf Seite 7 steht dann:
Also zwei Leitungen, eine für jede Richtung.
Schon klar, dass man 2 Leitungen benötigt. Aber wenn ich am Gerät 1 eine "0" sende, geht der CAN-Bus an Gerät 1 auf dominanten Pegel. Zeitverzögert auch auf CAN-Bus an Gerät 2. Das Ganze wird über den LWL Rückkanal zu CAN-Bus an Gerät 1 zeitverzögert zurückgegeben. Und dann hat man dauerhaft dominanten Pegel auf den CAN-Bussen (Selbsthaltung). Das Gerät 1 kann die "0" wegnehmen, aber der Pegel bleibt durch die "0" den Rückkanal erhalten. Zumindest so lange, bis der CAN-Transceiver seinen Timeout hat und den dominanten Pegel vom Bus trennt. Kann somit nicht funktionieren. :
Bearbeitet durch User
Für die Bus Arbitrierung findet man einige Beispiele, z.B. das hier ("TI Designs: TIDA-01487 - Isolated CAN FD Repeater Reference Design" unter "2.4.3 CAN Bus Arbitration Logic"): Hier in diesem Artikel wurde das aufgebaut, leider ohne nähere Beschreibung der Hardware. https://www.spiedigitallibrary.org/conference-proceedings-of-spie/13699/136995G/CAN-bus-communication-over-optical-wireless/10.1117/12.3075349.full Dort wird auch beschrieben, dass das ACK durch die Kette eine Herausforderung bleibt. Und dann gibt es noch das Problem mit dem dominanten Pegel, so wie in anderen Repeater-Konzepten auch. Man könnte all diesen Probleme aus dem Weg gehen, in dem man auf beiden Seiten einen ganz normalen CAN-Knoten aufbaut und die Information via RX/TX (z.B. LAWICEL) seriell austauscht. Ja, ich weiß, ist in vielen Aspekten nicht das identische Verhalten (Remoteframes werden schwierig - wenn man es denn unbedingt braucht), wird aber für viele Anwendungen trotzdem reichen.
Mit "CAN repeater" hatte ich schon ein Stichwort gegeben. Hier ist mal ein konkreter Link: https://www.ems-wuensche.com/can-technology/can-repeater-inhibit-time/ Diese Inhibit time ist wichtig, damit man keinen dominanten Loop bekommt. Soo schwierig ist das nicht. Ich habe selber in den 90er Jahren, als wir mit der CAN-Steuerung unserer Geräte anfingen, so ein Ding designed. War ein kleines EPLD mit zwei Optokopplern und zwei CAN-Transceivern. Für LWL-Anschluss braucht man halt die optischen Interfaces und die Logik dazwischen. Viele Specs über CAN findest du bei der CiA (https://www.can-cia.org/news). Wir waren damals Gründungsmitglied und hatten viel mit Holger Zeltwanger zu tun.
Und Holger Zeltwanger verweist hier auf das oben bereits verlinkte Design von TI.
Früher hatten wir gelernt, sich die Infos selber zu suchen. Dieses Vorgehen ist anscheinend heutzutage verloren gegangen, wenn man bei Eingabe von "CAN" und "Repeater" nichts passendes findet. CiA war halt damals ausser Steinbeis in Ravensburg der Nabel der (deutschen) CAN-Welt.
So klar ist das überhaupt nicht. Du kannst eine Faser genauso im Duplexbetrieb nutzen, z.B. verschiedene Wellenlängen für die beiden Richtungen. Es ist eine wirtschaftliche Abwägung, ob eine zweite Faser oder der zusätzliche Aufwand für bedirektionalen Betrieb günstiger ist.
Vielen Dank für den Link! Das ist genau das, was ich gesucht habe.
Ich habe schon gesucht, aber nicht die Kombination CAN + Repeater, sondern z.B. CAN + LWL bzw. CAN + Fiber. Und da bekommt man keine vernünftigen Treffer. Die Kunst ist, die passenden Suchbegriffe zu kennen. Auf die Idee "Repeater" zu verwenden, wäre ich nie gekommen.
Auf jeden Fall hast Du nicht einmal das Bild auf der von Dir verlinkten Seite angesehen, das zeigt ganz deutlich zwei optische Stecker an jeder Einheit (1xrot 1xschwarz) Hi, ich habe nun eine Platine gemacht, die die Arbitrierungslogik beinhaltet. Wenn jeweils nur eine LWL-Leitung gesteckt ist, ist die Datenübertragung in beide Richtungen OK. Wenn man beide LWL-Leitungen gemeinsam gesteckt hat und noch nichts sendet, ist noch alles OK. Aber wenn ein Signal von einem CAN-Teilnehmer kommt, schwingt das System dauerhaft, auch wenn man den CAN-Teilnehmer trennt (es ist aktuell nur auf einer Seite einer dran). Oszibild des Schwingkreises anbei. Da gibt es irgendwo einen Kopplungszweig, der das Schwingen verursacht. Der CAN-Bus ist jeweils mit 120R abgeschlossen. Die Übertragungsstrecke ist wie folgt: CAN Transceiver 1 - Arbitrierungslogik - LWL Transceiver - 20 m LWL (separat für TxD und RxD) - LWL Transceiver - CAN Transceiver 2 TI hat in seinem Dokument separate ICs für die Arbitrierungslogik verwendet, ich habe die selben Gattertypen zu einem IC zusammengefasst. Könnte dadurch die unerwünschte Kopplung entstanden sein? Oder ist die Leitungsführung im Layout ungünstig, so dass die Rückkopplung entsteht?
Angehängte Dateien:
Mir ist gerade was aufgefallen: TI hat in der Delay-Line im "realen" Schaltplan noch weitere Komponenten eingefügt, um die Verzögerungszeit zu erreichen. Dumm gelaufen, dass ich mir die Delaytime des 74HC04 nicht im Datenblatt angeschaut habe. Aber ob das zu der Schwingung führt?
Angehängte Dateien:
:
Bearbeitet durch User
Das ist gewöhnlich so, ohne Kopplung würdest du nie eine Schwingung bekommen. Damit eine Kopplung zu einer Schwingung führt, muss immer auch die Phasenlage/Zeitpunkt stimmen. Querverbindungen zwischen den Zweigen gibt es ja. Anhand eines Oszibildes des resultierenden Signals siehst du zwar die Schwingung, erkennst aber nicht, wo du eine Zeitbedingung verletzt. Dafür musst du tiefer rein gucken und mit den Worst-Case Daten für Flankentiming aus den Datenblättern vergleichen. Sonst kann es dir passieren, dass das System bei Temperaturerhöhung um 5°C wieder schwingt. :
Bearbeitet durch User
Das wäre nicht nötig, man kann natürlich LWL auch bidirektional nutzen, indem man auf unterschiedlichen Wellenlängen sendet. So machts auch der Glasfaseranschluss, über den manche ihr Internet bekommen.
Ja, prinzipiell schon, aber die Hardware ist nun für 2 LWL ausgelegt und wird diesbezüglich nicht geändert.
So ganz ist das aus deinem Post nicht ersichtlich, sind die RC-Glieder in deiner aktuellen Schaltung nicht drin?
Nein die sind nicht drin! Anbei nochmal die 2 Schaltpläne von TI. Ich habe die zweite Version leider erst heute entdeckt.
Angehängte Dateien:
Die Zeitglieder sind entscheidend wichtig, aber das ist Dir ja auch selber klar geworden. Nachrüsten in der Form schwierig. :
Bearbeitet durch User
Wird man schon irgendwie reinflicken können. Gibt halt ein etwas Bastelarbeit. Ob die fehlende Verzögerung die Ursache für das Schwingen ist? Die Logik setzt ja nur den Pegel auf High, wenn von beiden Seiten gesendet wird. Laut meiner Erfahrung mit > 10 Jahren CAN und Repeatern ist die Delayline ZWINGEND nötig! Und auch sollte man Tests machen, wie das Temperaturverhalten der Bauteile ist. Wir hatten das früher mit einem FPGA gelöst, bei dem man die Delayzeit programmieren konnte. So musste die Leiterplatte nicht geändert werden.
Dass man die Delayzeit benötigt ist mir klar. Aber kann es durch die zu kleine Zeit (weil ohne RC-Glied) zu dem Schwingen kommen? Ich vermute es gibt im System noch ein zweites Problem, dass das Schwingen verursacht.
Das ändert nur etwas auf unterstem Level des physical Layers im ISO Modell. Für die Signale bleiben das dabei weiterhin zwei unabhängige Strecken (WL-Multiplex).
Natürlich. Wenn Zeitspezifikationen der Reihenfolge der Signale verletzt werden, hängt es nur von der Schaltung ab, wie sich das nach außen bemerkbar macht. Ich weiß, per FPGA oder diskreter Logik ist das alles viel toller aber man könnte mal schauen, ob man das nicht mit einem ATTINY1616 hinbekommt. Der hat min. 2 Blöcke „programmable custom logic“, dazu viele Timer und sonstigen Kram. Programmierung über einen Pin, Spannung 2..5V, keine Außenbeschaltung. Also nicht als CAN-Komponente sondern auf reiner Bitebene das nachbilden, was diese Schaltung macht. Nur eben etwas abgesicherter. Bei 20MHz Takt dürfte das schnell genug sein für CAN. Hauptvorteile wären der sehr geringe Bauteileaufwand, Platz und die leichte Anpassbarkeit.
Früher (TM) hat man die Flankenlage über Gatterlaufzeit oder einen kleinen Kondensator passend hingeschoben und sich vorher Gedanken gemacht, welche Zeit genau verletzt wird. Auch bei „programmable custom logic“ wird man nicht umhin kommen, sich genauer mit dem Timing zu beschäftigen. Mache gerne wie früher, ich habe nichts dagegen. Früher(TM) habe ich auch gemacht wie früher. Alles kann, nichts muss. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
