CAN FD über Optokoppler...

[Martin Τrautmann]

On Tue, 30 Nov 2021 21:21:22 +0100, Sieghard Schicktanz wrote:

Hallo Martin Τrautmann,

Du schriebst am Tue, 30 Nov 2021 07:47:22 +0100:

Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn
...
Carrier-Sense Multiple Access with Collision Detection - das ist das
prinzipielle Übertragungsverfahren auf dem Bus-System.

Zumindest so ähnlich; einen \"Carrier\" gibt\'s da ja nicht.
Deswegen wird da ja mit Signalen unterschiedlicher \"Stärke\" gearbeitet:

Der \"Kupferdraht\" ist der Carrier. Es wird nicht auf in anderes Signal
aufmoduliert.

Die Frage ist, ob und wie sie diese Kollisionserkennung weitergeben.

Denen wird wohl nichts anderes übrigbleiben, als das weiterzugeben,
wenn das Gerät system- und standardkonform arbeiten soll. Die gängigen
Controller machen sowas allerdings schon selbständig innerhalb der
jeweiligen Funktionsmodule; muß man aber die Signale \"außerhalb\" noch
modifizieren, sind diese Bedingungen zu beachten.

Mit hinreichender Geschwindigkeit der Koppler ist das machbar - oder mit
Runterdrehen der Übertragungsgeschwindigkeit.

 

[Tilmann Reh]

Am 30.11.2021 um 21:16 schrieb Sieghard Schicktanz:

Für CAN werden die Signale der beiden Richtungen separat übertragen,

Wäre mir neu - ein Bus ist doch dadurch gekennzeichnet, daß er _mehr_
als 2 Stationen miteinander verbindet. Zur Ankopplung _an_ den Bus
könnte an so auskommen, wenn der Controller die Koppel-Elektronik
steuern kann. Als Repeater zur Potentialtrennung geht das nicht.

Niemand hier - außer Dir - denkt an oder spricht über Repeater.

Es geht die ganze Zeit nur um die galvanische Trennung zwischen
Controller und Transceiver - mit ganz gewöhnlichen Optokopplern oder
Isolatoren, getrennt für TXD und RXD.

Tilmann

 

[Hans-Peter Diettrich]

On 12/1/21 7:28 AM, Martin Τrautmann wrote:

On Tue, 30 Nov 2021 21:21:22 +0100, Sieghard Schicktanz wrote:

Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn
...
Carrier-Sense Multiple Access with Collision Detection - das ist das
prinzipielle Übertragungsverfahren auf dem Bus-System.

Zumindest so ähnlich; einen \"Carrier\" gibt\'s da ja nicht.
Deswegen wird da ja mit Signalen unterschiedlicher \"Stärke\" gearbeitet:

Der \"Kupferdraht\" ist der Carrier. Es wird nicht auf in anderes Signal
aufmoduliert.

Flasch. Ein Carrier ist ein Signalträger, was Du meinst ist \"current\".

>>> Die Frage ist, ob und wie sie diese Kollisionserkennung weitergeben.

Wer soll was weitergeben? Jeder Sender, der eine Kollission erkennt,
bricht seine Übertragung ab und versucht es später nochmal, wenn die
Leitung wieder frei ist.

DoDi

 

[Martin Τrautmann]

On Wed, 1 Dec 2021 13:54:32 +0100, Hans-Peter Diettrich wrote:

On 12/1/21 7:28 AM, Martin Τrautmann wrote:
On Tue, 30 Nov 2021 21:21:22 +0100, Sieghard Schicktanz wrote:

Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn
...
Carrier-Sense Multiple Access with Collision Detection - das ist das
prinzipielle Übertragungsverfahren auf dem Bus-System.

Zumindest so ähnlich; einen \"Carrier\" gibt\'s da ja nicht.
Deswegen wird da ja mit Signalen unterschiedlicher \"Stärke\" gearbeitet:

Der \"Kupferdraht\" ist der Carrier. Es wird nicht auf in anderes Signal
aufmoduliert.

Flasch. Ein Carrier ist ein Signalträger, was Du meinst ist \"current\".

Ich meine nicht Current. Es ist die Definition von
https://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Detection

Carrier ist das Übertragungsmedium - auf unterster OSI Layer also Kabel,
Spannungspegel, Ströme, Widerstände, alles was den BUS ausmacht.

Zur Definition der Physical Layer gehört noch einiges mehr - das ist
aber für die Kollisionserkennung nebensächlich.

Die Frage ist, ob und wie sie diese Kollisionserkennung weitergeben.

Wer soll was weitergeben? Jeder Sender, der eine Kollission erkennt,
bricht seine Übertragung ab und versucht es später nochmal, wenn die
Leitung wieder frei ist.

....weshalb die Kollision [sic] quasi analog, quasi in Echtzeit erfolgen
muss. Da darfst du nicht groß verzögern oder sogar mehrere Bits
zwischenpuffern. Die Zeitfenster der Reaktionszeit sind recht genau
definiert und müssen halt mit der galvanischen Trennung dazwischen auch
noch funktionieren. Die ersten CAN-Knoten hatten die Signalstärken im
Knoten selbst definiert, mit Anstiegszeiten usw. Der \"Optokoppler\" muss
all das entsprechend übersetzen. Eher braucht man einen CAN-Knoten ohne
entsprechende Ausgangstreiber, ohne kombiniertem TR, mit maximal
schnellem T(ransmit).

 

[Newdo]

Am 01.12.2021 um 13:54 schrieb Hans-Peter Diettrich:
> On 12/1/21 7:28 AM, Martin Τrautmann wrote:

(...)

Der \"Kupferdraht\" ist der Carrier. Es wird nicht auf in anderes Signal
aufmoduliert.

Flasch. Ein Carrier ist ein Signalträger, was Du meinst ist \"current\".

CSMA ist schon die richtige Bezeichnung, auch wenn es hier eine
spezielle Form ist (s.u.).

Die Frage ist, ob und wie sie diese Kollisionserkennung weitergeben.

Wer soll was weitergeben? Jeder Sender, der eine Kollission erkennt,
bricht seine Übertragung ab und versucht es später nochmal, wenn die
Leitung wieder frei ist.

Man nennt es CSMA/CR beim CAN-Bus (CR=collision resolution)

Grüße - Udo

 

[Martin Τrautmann]

On Wed, 1 Dec 2021 17:47:30 +0100, Newdo wrote:

Wer soll was weitergeben? Jeder Sender, der eine Kollission erkennt,
bricht seine Übertragung ab und versucht es später nochmal, wenn die
Leitung wieder frei ist.

Man nennt es CSMA/CR beim CAN-Bus (CR=collision resolution)

Ist das neu? In der ursprünglichen Spec stand noch CSMA/CD.

Wär natürlich doof, es nur zu erkennen und nicht darauf zu reagieren.

Tatsächlich ist es aber genauso CSMA/CA, weil für den stärkeren
überhaupt kein Konflikt auftritt und für den schwächeren der sich
zurückzieht, noch bevor der Konflikt eskaliert.

 

[Hans-Peter Diettrich]

On 12/1/21 2:31 PM, Martin Τrautmann wrote:

...weshalb die Kollision [sic] quasi analog, quasi in Echtzeit erfolgen
muss. Da darfst du nicht groß verzögern oder sogar mehrere Bits
zwischenpuffern.

Schau Dir einfach mal an, wie die Transceiver funktionieren. Ganz
einfaches Beispiel: RS-485 chips. Wenn der Feedback nicht stimmt wird
der Sender sofort abgeschaltet. Da gibt es keine Puffer und keine
Verzögerung, die liegen in der vorgeschalteten Elektronik.

DoDi

 

[Martin Τrautmann]

On Wed, 1 Dec 2021 23:34:28 +0100, Hans-Peter Diettrich wrote:

On 12/1/21 2:31 PM, Martin Τrautmann wrote:

...weshalb die Kollision [sic] quasi analog, quasi in Echtzeit erfolgen
muss. Da darfst du nicht groß verzögern oder sogar mehrere Bits
zwischenpuffern.

Schau Dir einfach mal an, wie die Transceiver funktionieren. Ganz
einfaches Beispiel: RS-485 chips. Wenn der Feedback nicht stimmt wird
der Sender sofort abgeschaltet. Da gibt es keine Puffer und keine
Verzögerung, die liegen in der vorgeschalteten Elektronik.

CAN konzentriert sich primär auf die Definition der Data Link Layer. Was
man drunter auf der Physical Layer macht, da hat man halbwegs freie
Bahn. Ob man das über Kupfer macht, als echten Zweidrahtbus mit Signal
auf eine Versorgungsspannung aufmoduliert, als sog. Eindrahtbus (was für
mich immer eine Mogelpackung ist, weil Kirchhoff nicht wegdefinierbar
ist und Stromkreis noch immer geschlossen werden müssen) oder als
optisch, da hat man recht freie Hand.

Rezessiv/Dominant ist optisch trivial machbar: Licht aus ist rezessiv,
Licht an ist dominant. Spannungsversorgung ist über Optik nicht
vernünftig machbar. Also muss auch die Spannungsversorgung selbst
nochmals galvanisch getrennt werden, was dann eher im Ausnahmefall
sinnvoll ist - weniger innerhalb eines Kfz mit nur einer Bordbatterie,
eher bei großen Strecken und womöglich sogar einzelnen CAN-Knoten mit
eigener Batterieversorgung.

Man braucht eben die dafür geeigneten Transceiver, die auf der einen
Seite mit CAN-auf-was-auch-immer reingehen und auf der anderen Seite R
und T getrennt anbieten. Entsprechend muss das Bittiming eingehalten
werden. Möglicherweise braucht man auch noch Leitungen vom Transceiver
zur Fehlermeldung.

Die meisten Kunden wollen eine Einchip-Lösung mit integriertem
Transceiver. Wer was anderes will sucht eben in der Krabbelkiste der
üblichen Verdächtigen. Allerdings geht man dann von den Schnittstellen
des CAN-Knotens aus und legt erst mal fest, welche Datenraten man
braucht.

 

[Gerald Oppen]

Am 01.12.21 um 11:51 schrieb Tilmann Reh:

Am 30.11.2021 um 21:16 schrieb Sieghard Schicktanz:

Für CAN werden die Signale der beiden Richtungen separat übertragen,

Wäre mir neu - ein Bus ist doch dadurch gekennzeichnet, daß er _mehr_
als 2 Stationen miteinander verbindet. Zur Ankopplung _an_ den Bus
könnte an so auskommen, wenn der Controller die Koppel-Elektronik
steuern kann. Als Repeater zur Potentialtrennung geht das nicht.

Niemand hier - außer Dir - denkt an oder spricht über Repeater.

Es geht die ganze Zeit nur um die galvanische Trennung zwischen
Controller und Transceiver - mit ganz gewöhnlichen Optokopplern oder
Isolatoren, getrennt für TXD und RXD.

Das hört sich in der OP-Frage anders an:

--
ich suche eine taugliche Schaltung zur galvanischen Trennung von CAN FD
über Optokoppler.
Insbesondere betreffens der Auswahl der richtigen OKs bezüglich
Laufzeiten und Isolation (5-8kV peak, 500..600V Vrms dauerhaft).
--
Nach meiner Auffassung eben der galvanischen / optischen Trennung von
CAN-FD Busleitungen. Die Rx/Tx Leitungen vor einem CAN-Transceiver
galvanisch zu trennen hat elektrisch nichts mit CAN zu tun insofern man
der Baudrate entsprechend auf ausreichend Flankensteilheit /
Durchlaufzeiten achtet.

GErald

 

[Gerald Oppen]

Am 30.11.21 um 09:46 schrieb Newdo:

Am 29.11.2021 um 22:17 schrieb Sieghard Schicktanz:
Hallo Newdo,

Du schriebst am Mon, 29 Nov 2021 13:22:46 +0100:

ebenfalls. Nennt sich auch \"Rückkopplung\".

Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn er

Rückkopplung ist ein Prinzip des CAN-Bus? Wäre mir neu.

Den Begriff hast _Du_ letztlich eingeführt.
Das Prinzip ist, dass der Zustand des Busses direkt zurückgelesen wird.
Wer einen dominanten Zustand erzeugt hat, kann nicht entschieden werden.
Wenn man in der Lage ist, das Prinzip auch über andere Medien
abzubilden, gibt es da kein Lock- oder Rückkopplungs- oder wie auch
immer genanntes Problem. Alle Macht geht vom CAN-Controller aus.

Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
Entgegen der naheliegenden Interpretationsmöglichkeit der Ausgangsfrage
geht es wohl nicht um eine galvanische Trennung der CAN-Bus-Leitung
sondern einer Trennung zwischen Controller und Transceiver.
Beides ist möglich!
Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf eine
Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten
Baudrate, dafür muss man die Node-Hardware anpassen.

Das ist schon richtig, und das ist bei einem _Controller_ auch
unkritisch, weil der ja \"weiß\", was er gesendet hat und nicht einfach
das Empfangssignal wieder auf den Senderausgang schreibt.
Aber _genau_ _letzteres_ tut ein passiver Koppler, der z.B. aus zwei
Optokopplern mit ein bisserl Beschaltung besteht, und hält sich damit
selber in einem (im dominanten) Zustand fest, so daß der
_vorgeschaltete_ Sender nicht mehr mit einem anderen (rezessiven) Pegel
durchkommt.
Ist das so verständlich?

Warum die Phantasie dich in genau diese Schaltungstopologie mit den ihr
innewohnenden Problemen leitet, kann ich ich ehrlich gesagt nicht
verstehen.

Das ist ein Fall1 Problem, tritt bei Fall2 natürlich nicht auf.

BTW, genau dafür, diesem Problem abzuhelfen, gibt es die speziellen
Buskoppler für diesen und andere Busse, die zudem meistens von
vornherein auf die benötigten Geschwindigkeiten ausgelegt sind.

Vielleicht weisst Du auch einen lieferbaren Typen, der die beschrieben
Anforderungen erfüllt? Das wäre eine Hilfe.

Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang
angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die
Datenrate, um so schärfer die Anforderungen.

Gerald

 

[Newdo]

Am 02.12.2021 um 17:46 schrieb Gerald Oppen:

Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
Entgegen der naheliegenden Interpretationsmöglichkeit der Ausgangsfrage
geht es wohl nicht um eine galvanische Trennung der CAN-Bus-Leitung
sondern einer Trennung zwischen Controller und Transceiver.
Beides ist möglich!

Die CAN-Datenleitungen des CAN-Controllers (RxD, TxD) sind auf HiPot und
sollen _verstärkt isoliert_ an einem bestehenden (drahtgebundenen) CAN
FD-Bus wirken. Und das mit 5-8Mbps Datenrate.

Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf eine
Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten
Baudrate, dafür muss man die Node-Hardware anpassen.

Die Lösung muss mit variabler Baudrate arbeiten, bis zur angegebenen
Obergrenze. Warum ist deiner Ansicht nach nur eine fixe Baudrate möglich?

Vielleicht weisst Du auch einen lieferbaren Typen, der die beschrieben
Anforderungen erfüllt? Das wäre eine Hilfe.

Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang
angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die
Datenrate, um so schärfer die Anforderungen.

Das ist einer der Gründe, hier mal nachzufragen.
Wenn es physikalische Gründe für eine geringere Obergrenze gibt, dann
muss ich mich damit abfinden.

Danke für\'s Mitdenken.

Gruß Udo

 

[Gerald Oppen]

Am 02.12.21 um 18:28 schrieb Newdo:

Am 02.12.2021 um 17:46 schrieb Gerald Oppen:

Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
Entgegen der naheliegenden Interpretationsmöglichkeit der
Ausgangsfrage geht es wohl nicht um eine galvanische Trennung der
CAN-Bus-Leitung sondern einer Trennung zwischen Controller und
Transceiver.
Beides ist möglich!

Die CAN-Datenleitungen des CAN-Controllers (RxD, TxD) sind auf HiPot und
sollen _verstärkt isoliert_ an einem bestehenden (drahtgebundenen) CAN
FD-Bus wirken. Und das mit 5-8Mbps Datenrate.

Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf
eine Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten
Baudrate, dafür muss man die Node-Hardware anpassen.

Die Lösung muss mit variabler Baudrate arbeiten, bis zur angegebenen
Obergrenze. Warum ist deiner Ansicht nach nur eine fixe Baudrate möglich?

In Bezug auf Fall1:
Man muss erkennen auf welcher Seite der aktuelle Sender sendet und für
ca. eine Bitzeit (\"ca.\" weil u.a. Flankensteilheiten + Toleranzen
berücksichtigt werden müssen) die Datenübertragungsrichtung freischalten
um damit die Rückkopplung/Selbsthaltung zu vermeiden (Beide Seiten
würden statisch in den dominaten Zustand gehen). Die Bitzeit hängt ja
direkt an der Baudrate -> darum meine Aussage zu fixen Bitrate. Eine
automatische Baudratenerkennung mit entsprechender Anpassung der obigen
\"Bitzeit\" ist eventuell denkbar, aber zumindest nicht so trivial
realisierbar wenn man gleichzeitig die Forderung erfüllen will dass kein
Bit/Frame im Normalfall verloren gehen darf.
Anmerkung: Es geht hierbei um einen \"passiven\" Buskoppler - mit \"passiv\"
in der Bedeutung von \"es wird jedes Bit einzeln direkt übertragen\". Der
Buskoppler interessiert sich nicht für Bitkombinationen.
(D.h. passiv bedeutet hier nicht dass nur passive elektrische Bauteile
verwendet werden.)
Im Gegensatz dazu könnte man das ganze auch aktiv als Gateway ausführen.
Da wäre man dann frei in den Baudraten. Allerdings müssten man dann
ganze CAN-Frames zwischenpuffern und wohl den vollständigen CAN-Stack
implementieren. Dazu der Nachteil der Durchlaufverzögerungen.

Vielleicht weisst Du auch einen lieferbaren Typen, der die
beschrieben Anforderungen erfüllt? Das wäre eine Hilfe.

Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang
angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die
Datenrate, um so schärfer die Anforderungen.

Das ist einer der Gründe, hier mal nachzufragen.
Wenn es physikalische Gründe für eine geringere Obergrenze gibt, dann
muss ich mich damit abfinden.

Steht und fällt vermutlich mit der Verfügbarkeit entsprechend schneller
Optokoppler.

> Danke für\'s Mitdenken.

Gerne - musste mich mal mit der Problematik bzgl. Zusammenführung von
HS- und LS-Can beschäftigen. Ob das bei Fall1 so auch für einen
FD-CAN-Buskoppler funktionieren/gelten würde kann ich mangels Erfahrung
nicht sagen. Vielleicht gibt es hier ja noch Anmerkungen oder bessere
Lösungen dazu die ich nicht auf dem Schirm habe.

Gruß
Gerald