Natürlich findet man bei vielen Steuerungen den CAN-Bus. Trotzdem scheint es, dass Ethernet zurzeit ganz gewaltig an Boden gewinnt. Einerseits gibt es ein riesiges Angebot an preiswerten Netzwerkkomponenten, andererseits schein es stabiler zu laufen (es hat z.B. kein zeitkritisches ACK). Gibt es im Automatisierungsbereich (nicht Automotive) Applikationen, bei denen CAN Vorteile gegenüber Ethernet besitzt?
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.
josch schrieb: > andererseits schein es stabiler zu laufen (es hat > z.B. kein zeitkritisches ACK). Ich habe genau den entgegengesetzten Eindruck, CAN läuft super stabil. Wenn das Kabel zu schlecht ist, um die gewünschte Baudrate zu übertragen, rast der Errorcounter hoch. Das läßt sich also einfach feststellen. Man kann CAN auch nicht durch zu hohen Traffic aus dem Tritt bringen, Ethernet dagegen schon. Wenn ich mal vergleiche, wie lange der Explorer öfters mal braucht, ehe ich ein Netzlaufwerk sehe, da möchte ich keine kritischen Sachen drüber steuern.
:
Bearbeitet durch User
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.
josch schrieb: > Liegt der Traffic, bei dem bei Ethernet die Probleme beginnen, nicht > schon deutlich über dem, was mit CAN überhaupt möglich ist? 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.
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.
Test schrieb: > In der Automatisierungstechnik verwendet man Ethercat, das dies auch > deterministisch und echtzeitfähig ist. Da verwendet man deshalb sogar noch das archaische ARCNET.
:
Bearbeitet durch User
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.
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.