CAN vs. Ethernet

Billigere HW/SW.

CAN hat Hardware gesicherte Nachrichtenprioritäts Kontrolle
bei Ethernet wird sowas in den höheren Schichten mit QoS nur simuliert

Klaus schrieb:
> Billigere HW/SW.

Ist das nur ein Gefühl von Dir oder kennst Du echte Gegenüberstellungen 
bei vergleichbaren Anforderungen?

benwilliam schrieb:
> CAN hat Hardware gesicherte Nachrichtenprioritäts Kontrolle
> bei Ethernet wird sowas in den höheren Schichten mit QoS nur simuliert

Wie relevant ist das?
Selbst PROFIsafe funktioniert und arbeitet mit Ethernet.

Peter Dannegger schrieb:
> Man kann CAN auch nicht durch zu hohen Traffic aus dem Tritt bringen,
> Ethernet dagegen schon.

Liegt der Traffic, bei dem bei Ethernet die Probleme beginnen, nicht 
schon deutlich über dem, was mit CAN überhaupt möglich ist?

Wen möchtest du überzeugen josch. CAN und Ethernet(TCP/IP, UDP) sind für 
grundlegende andere Einsatzgebiete konzipiert worden. Ethernet erkauft 
sich höhere Datenraten mit hörerer Störanfälligkeit. Es gibt z.b. 
Gründe, warum in einem Röntgengerät der CAN-Bus zur steuerung genutzt 
wird und kein Ethernet.
Und dein Beispiel von PROFIsafe bezieht sich nur auf PROFInet. Dieses 
nutzt zwar ein Ethernetkabel, aber die Protokolle sehen anders aus, als 
bei TCP/IP.

Und vom Hard/Software-Aufwand liegt Ethernet deutlich über CAN. Allein 
weil Ethernet ein PHY und einen Übertragerbrauch, die zusammen gern mal 
15-20 Euro pro Knoten kosten, wenn der Mikrocontroller eine MAC besitzt.

josch schrieb:
> Wie relevant ist das?
> Selbst PROFIsafe funktioniert und arbeitet mit Ethernet.

PROFISafe auf Ethernet (PROFINET) ist größtenteils eine Software lösung 
(mit unterstützung von den richtigen switches), somit ist der 
implementierungs Aufwand wesentlich höher um eine Ähnliche Sicherheit 
wie CAN bzw. ProfiBus zu erreichen, aber man gewinnt eben von dir 
genannten Vorteile.
Wenn du lediglich ein paar "dumme" sensoren/aktoren hast ist eine 
Ethernet anbindung meines Erachtens ein Overkill.
CAN ist eben von vornehinein dafür ausgelegt gewesen, Ethernet wurde 
nachträglich so lange "verbogen" bis es ausrichend gepasst hat.
LEtztendlich außer kosten/nutzen spricht nichts gegen Ethernet
ich mag Ethernet auch :)

Syliosha schrieb:
> Und vom Hard/Software-Aufwand liegt Ethernet deutlich über CAN. Allein
> weil Ethernet ein PHY und einen Übertragerbrauch, die zusammen gern mal
> 15-20 Euro pro Knoten kosten, wenn der Mikrocontroller eine MAC besitzt.

Sobald man aber für eine Datenverbindung alle Komponenten betrachtet 
(Stecker, Kabel, etc.) relativiert sich das.

Hallo,

wenn du eine konkrete Anwendung in den Augen hast, dann vergleiche mal 
den Energieverbrauch der Komponenten. Zumindest mit dem enc28j60 war der 
Energieverbrauch "sehr" hoch (im Verhältnis zum Mikrocontroller, der CAN 
konnte). Wenn etwas dauerhaft eingeschaltet ist, könnte es bei vielen 
Kommunikationsknoten ein Aspekt sein.

benwilliam schrieb:
> CAN ist eben von vornehinein dafür ausgelegt gewesen, Ethernet wurde
> nachträglich so lange "verbogen" bis es ausrichend gepasst hat.

Ich stimme zu, dass an Ethernet (es war ursprünglich ja eher für 
Bürotechnik konzipiert) ganz schön herumgebogen wurde.
Ähnliches ist aber wohl auch mit CAN geschehen (es kommt aus dem 
Automotive-Bereich mit Kabellängen von typisch 2-5m und stabiler Masse), 
schließlich gibt es gut ein dutzend verschiedener CAN-Spezifikationen, 
die zudem jeweils noch massiv an die konkreten Übertragungsanforderungen 
angepasst werden müssen.

Im Gegensatz zu CAN ist Ethernet nicht Echtzeit-tauglich, da es keine 
garantierte Übertragungszeit bietet.

Wenn du ein komplettes System betrachtest, dann ist Ethernet um einiges 
teurer, wenn es um ein industrielles Umfeld geht. CAN ist der Stecker 
sehr egal. Ethernet nicht. Dazu ist das verlegen und der Aufbau eines 
Ethernetnetzwerkes mit zusätzliches Komponenten(Switches) verbunden.
Bei CAN kannst du alles an eine Leitung packen.

Ich habe nichts gegen Ethernet, aber man sollte schon den Bus nehmen, 
der für eine gegebene Anwendung am besten passt.
Ethernet ist kein Allheilmittel und schon gar nicht die 
Eierlegendewollmichsau.

Der Vorteil von Ethernet ist, man kann das doppelt auslegen, also ein 
Switch,
zwei Kabel. Dann kann man einfach einen Kabel ausstecken, und alles 
läuft
munter weiter, ohne daß man was merkt. Wenn man die Switches auch 
doppelt
auslegt, kann auch ein Switch sterben und es geht trotzdem.
Dies ist schwer zu übertreffen. Auch ist die Einfachheit von 
ModbusTCP/ProfibusTCP sowie die Remotefähigkeit top.
Im Industrieumfeld ist und war immer schon der Masseausgleich ein 
Problem.
Bei Ethernet ist alles schön isoliert, bei Can meistens nicht.
Auch ist Ethernet bei intelligenten Komponenten wie eine Cognex Kamera
von Vorteil, bzw setzt sich immer mehr durch. Hat man Ethernet, kann man
remote Support machen, hat man dies nicht, muss ein Techniker mit dem
Laptop her. Auch sind Datenbankanbindungen zusammen mit Barcode, Tracing
usw immer wichtiger geworden.

Seit wann ist CAN echtzeittauglich? Auch bei CAN ist kein Zeitfenster 
definiert. Mit Einführung des FlexRay steht ein deterministischer Bus 
zur Verfügung.

und wenn man den Aufwand noch weiter treiben möchte
kann man auch das gesammte Ethernet Netzwerk auf optischen 
Glasfaserleitungen aufbauen :)

<ironie>
jippie es lebe das Ethernet
</ironie>

josch schrieb:
> Sobald man aber für eine Datenverbindung alle Komponenten betrachtet
> (Stecker, Kabel, etc.) relativiert sich das.

Das mit dem Relativieren ist aber kein Argument. Nach dieser Logik wären 
auch Massivgold-Leitungen vertretbar wenn nur das Gesamtprojekt teuer 
genug ist...

Ich frage mich sowieso warum es hier immer so kontrovers zugeht bei 
Sachen die friedlich nebeneinander existieren können.

Wenn ich eine Menge Knoten habe die mit wenig Energie-und 
Hardwareaufwand auskommen müssen ist CAN die bessere Wahl. Schon weil 
die ganzen Switches entfallen. Über 2 Adernpaare kriegt man 
Stromversorgung und Daten. Bei genügend kleinen Datenraten ist auch bis 
zu gewissen Grenzen eine Sternanbindung möglich.

Selbst ein Mischbetrieb ist in meinen Augen absolut vertretbar. Die 
Auto-Industrie geht nach unten auch den nächsten Schritt mit LIN, da wo 
es passt.

Es ist wieder mal so wie mit dem Beton. Es kommt nur darauf an was man 
daraus macht...

In der Automatisierungstechnik verwendet man Ethercat, das dies auch 
deterministisch und echtzeitfähig ist. Ethernet selber mit Tcp wir nur 
auf höheren Ebenen verwendet wenn man es richtig macht. Ethercat ist 
jedoch wesentlich teurer als CAN, aber bietet wesentlich höhere 
Datenraten

Syliosha schrieb:
> CAN ist der Stecker
> sehr egal. Ethernet nicht. Dazu ist das verlegen und der Aufbau eines
> Ethernetnetzwerkes mit zusätzliches Komponenten(Switches) verbunden.
> Bei CAN kannst du alles an eine Leitung packen.

Wenn ich mir die dLAN-Komponenten von Devolo anschaue, dann kann ich bei 
Ethernet an Lösungen denken, die mit CAN nur deutlich aufwändiger zu 
realisieren wären.

Syliosha schrieb:
> Ethernet ist kein Allheilmittel und schon gar nicht die
> Eierlegendewollmichsau.

Dem stimme ich voll zu. Auch CAN hat, wie viele andere 
Übertragungsarten,  seine Berechtigung.

Vielleicht sollte man klären, in welchem Umfeld die Produkte eingesetzt 
werden sollen. Denn mit den Devoloprodukten baut man sicher kein 
Netzwerk auf, dass nur in irgendeinerweise als Feldbus eingesetzt werden 
könnte.

Syliosha schrieb:
> Denn mit den Devoloprodukten baut man sicher kein
> Netzwerk auf, dass nur in irgendeinerweise als Feldbus eingesetzt werden
> könnte.

Damit kann ich aber bestehende Leitungen, die vorher vielleicht einem 
ganz anderen Zweck dienten, für mein Netzwerk verwenden und muss nicht 
alle Leitungen neu legen.

Für CAN spricht, dass jede Menge

josch schrieb:
> Ähnliches ist aber wohl auch mit CAN geschehen (es kommt aus dem
> Automotive-Bereich mit Kabellängen von typisch 2-5m und stabiler Masse)

Zeig mir mal ein Auto, LKW oder was auch immer mit einem CAN von max. 5 
m Länge und einer sauberen Versorgungsspannung. Das wirst du nicht 
finden.



josch schrieb:
> schließlich gibt es gut ein dutzend verschiedener CAN-Spezifikationen,
> die zudem jeweils noch massiv an die konkreten Übertragungsanforderungen
> angepasst werden müssen.

Stimmt so auch nicht. Die "Übertragungsanforderung" ist immer identisch, 
da alle höheren Protokollschichten ( bsp. CANopen, J1939 ) als Grundlage 
den CAN haben. Daher kann man auf dem CAN-Bus gleichzeitig mehrere 
Protkolle laufen lassen.

Gerade im Automotivebereich wird es den CAN-Bus noch sehr lange geben. 
Ethernet gibt es ja schon teilweise in PKWs aber dann doch eher im 
Bereich Infotainment oder bei der Diagnose oder zum Flashen.

In der Automatisierungstechnik haben System wie EtherCAT oder ProfiNET 
deutlich mehr an Bedeutung, da man dort höhere Anforderungen hat. 
Versuch mal eine Echtzeitregelung von 100 Servos in einer 
Produktionslinie aufzubauen. Da bist du froh wenn was wie EtherCAT hast.

Gruß Max

Also ich arbeite recht viel mit beiden Bussen und würde solange es das 
Projekt hergibt immer den CAN Bus bevorzugen.
Dieser ist deutlich unkomplizierter im Handling und bei der Fehlersuche 
um ein vielfaches einfacher zu debuggen.

Allerdings gibt es oft Anwendungsfälle, bei denen es Sinn macht auf 
Ethernet zu setzen.
Z.B. wenn hohe Datenraten gefordert sind oder ein anderer Teilnehmer nur 
Ethernet unterstützt.
Vielen PLCs oder Displays kann man mit CAN beispielsweise nicht kommen, 
dafür unterstützen diese sehr oft MODBUS on TCP/IP oder ein anderes 
Ethernetbasiertes Protokoll.

Aber meist ist das Thema CAN vs. Ethernet ja eh keine entweder-oder 
Frage, sondern von anderen Parametern im Projekt schon entschieden 
worden.

Syliosha schrieb:
> Und vom Hard/Software-Aufwand liegt Ethernet deutlich über CAN. Allein
> weil Ethernet ein PHY und einen Übertragerbrauch, die zusammen gern mal
> 15-20 Euro pro Knoten kosten, wenn der Mikrocontroller eine MAC besitzt.

Wo findet man die denn so teuer? Eine komplette Netzwerkkarte kann man 
im Laden für weniger kaufen.

Stefan schrieb:
> Im Gegensatz zu CAN ist Ethernet nicht Echtzeit-tauglich, da es keine
> garantierte Übertragungszeit bietet.

Das tut CAN auch nicht. Auf dem CAN kann jeder senden, wann er Lust hat. 
Wenn zwei gleichzeitig senden wollen, muß aber einer warten, bis der 
andere fertig ist, und seine Botschaft verzögert sich entsprechend. Wenn 
viele senden wollen, kann diese Verzögerung länger werden.

Peter Dannegger schrieb:
> Es geht nicht um die Datenrate, sondern daß man so hohen Traffic
> erzeugen kann, daß damit andere Teilnehmer gestört werden.
> Beim CAN ist dagegen ein Traffic von 100% zulässig.

Nein. Durch die Prioritätensteuerung von CAN-IDs würden dann Botschaften 
mit höheren IDs nie auf den Bus kommen. Beim CAN ist es nur so, daß im 
Gegensatz zu Ethernet die effektive Nutzdatenrate bei hoher Last nicht 
sinkt.