Ethernet vs GPIB

    Hallo Allerseits,


    wenn man Ethernet und GPIB als Protokoll für industrielle Steuerung/Datenerfassung gegenüberstellt (nicht Vintage Computing, sondern aktuell), was würdet ihr da als Vor- und Nachteile sehen, v.a. wenn man Verfügbarkeit, Störsicherheit im Fokus hat?


    Grüße

    Stephan

    Telex 563140 goap d

    GPIB benutzt asymetrische Signalpegel, was weniger Störsicherheit bietet als die symmetrischen Pegel, die im Ethernet verwendet werden. Darüber hinaus bietet Ethernet auch eine galvanische Trennung zwischen Sender und Empfänger.


    Heutzutage gibt es keinen Grund, GPIB zu verwenden, wenn man nicht Geräte mit dieser Technik anschließen muss. Ethernet ist wesentlich flexibler, schneller, störsicherer, leichter zu verlegen, etc. pp.

    Wir benutzen in der Firma aus eher praktischen Gründen nur noch Ethernet. Vorteil ist, dass man per Ethernet dann meist auch per remote auf die Bedienoberfläche der Messgeräte kommt. Auch haben viele moderne Messgeräte gar keinen physischen GPIB Port mehr. Die letzten Geräte, die nur GPIB sprechen, werden bei uns über eine separate Box ans Netz gehängt. Allerdings sollte man ein eigenes Netz ohne Internetzugang nur für die Messgeräte haben, denn viele ältere Geräte laufen noch unter Windows 7 oder sogar XP. Da hatten wir auch schon Viren drauf.


    GPIB direkt scheitert meist daran, dass moderne PCs einen USB nach GPIB Adapter brauchen, der oftmals nicht zuverlässig funktioniert. Ist gefühlt einfach Murks.

    Eigentlich ist beides heute (schon lange) nicht mehr das Mittel der Wahl für aktuelle Entwicklungen - Du vergleichst also zwei Dinos miteinander (Heute würde man eher CAN nehmen, ganz einfach weil man das aus dem Laden kaufen kann ohne viel zu basteln).


    Das aus dem Weg, hat Ethernet die prinzipielle Eigenschaft, das jeder Teilnehmer jederzeit einen (auch einen gültigen) Rahmen verwerfen kann und darf, wenn's ihm danach ist. Das ist aus Sicht von Echtzeiteigenschaften und Übertragungssicherheit natürlich erstmal was, was man eigentlich nicht will. Natürlich kann man da drumrumarbeiten, aber das Prinzip wird man nicht los, weil eingebaut.


    Was die elektrische Sicherheit angeht, ist Ethernet wesentlich symphatischer as GPIB: Ethernet trennt die Teilnehmer galvanisch voneinander und arbeitet mit differenziellen Pärchen, während GPIB im Prinzip TTL-Logik (zwar mit wesentlich höheren Treiberleistungen, aber trotzdem) verwendet und deswegen prinzipiell elektrisch schon empfindlicher ist.


    Und alleine schon das GPIB-Kabel-und-Stecker-Gelumpe ist sauteuer, klobig, kaum mehr zu bekommen, und deswegen doof. Ethernet-Magnetics, Kabel und Stecker sind zwar auch aufwendg und brauchen Platinenplatz, aber weil millionenfach im Einsatz und gängig absolut kein Problem.


    Ein wichtiger Aspekt: Ethernet ist immer noch gebräuchlich, deswegen gibt es fertige Chipsätze, die den Phys-Level implementieren. Die gab's zu den Hochzeiten von GPIB dafür auch, nur heute leider nicht mehr. GPIB ist, obwohl alt, da, was die einzuhaltenden Zeiten angeht, garnicht mal so anspruchslos: Sieht ein Busteilnehmer ein "ATN" hat er 200ns (!) Zeit, seine Treiber vom Bus wegzunehmen (Ansonsten gibt's möglicherweise zerstörerische Buskollisionen). Das ist selbst mit einem modernen µC wie einem ATMEGA oder sowas illusorisch. Früher gab's Chips, die das in Hardware gemacht haben, aber die gibt's nicht mehr. Soll das also ein Controller tun, braucht man schon ein Pfund, das so schnell reagieren kann, oder man realisiert das tatsächlich in nachgebauter HW, was dann entsprechend aufwendig wird.


    GPIB würde man heute wohl nur noch nehmen, wenn man aus irgenwelchen Gründen dazu gezwungen ist. Die Verfügbarkeit der "alten" Chipsätze, die mit den Zeitanforderungen klarkommen, ist gegen Null und nachbauen ist aufwendig. Ethernet kann man nehmen, wenn man mit dem o.a. Prinzip leben kann, und CAN "kann" man nehmen, weil das einfach heute gängig ist und das Eth-Problem nicht hat.

    Bei IEEE-488 hatte ich immer den Vorteil gesehen (und das Feature auch gebraucht), dass man mehrere Messgeräte exakt gleichzeitig/synchron triggern kann. Bei Ethernet war da immer eine unkalkulierbare Verzögerung.

    Wie macht man das heute (mit Ethernet oder CAN Bus) wenn man synchrone, Echzeit-Messungen macht?

    Zitat von Martin Hepperle

    Bei IEEE-488 hatte ich immer den Vorteil gesehen (und das Feature auch gebraucht), dass man mehrere Messgeräte exakt gleichzeitig/synchron triggern kann. Bei Ethernet war da immer eine unkalkulierbare Verzögerung.

    Wie macht man das heute (mit Ethernet oder CAN Bus) wenn man synchrone, Echzeit-Messungen macht?

    Das hätte man (auch damals) eigentlich auch mit einem Broadcast zur Not auch mit Ethernet hingekriegt. Und heute macht man das auch nicht anders.

    Wer zeitkritische Anwendungen hat, sollte vielleicht Industrial Ethernet anschauen und nutzen. Wobei "zeitkritisch" auch näher zu definieren ist. Ich erinnere mich an einen von mir gebauten Meßplatz, bei dem es um Explosionsmessungen ging (also in einem Reaktor etwas zur Zündung bringen und dann alles mögliche messen). Da war zeitkritisch im 10^-7s Bereich. HP hat damals die Geräte geliefert, die mittels GPIB vernetzt waren. Kann mich aber nicht wirklich erinnern, ob das Standard war oder die da auch was besonderes machen mussten.

    Zitat von Toshi

    Was ist denn das in abgrenzung zu "normalem Ethernet"?

    Da gibt es verschiedenste Sachen zu.


    Mit PROFINET habe ich vor 15-20 Jahren selber mal gearbeitet. Erlaubt auch isochrone Ansteuerung.

    Dann gibt es Ethernet/IP, EtherCAT, Ethernet Powerlinkund noch einen ganzen Haufen weitere, mit denen ich aber nur marginal Berührung hatte.


    Ich glaube, ein guter Einstieg zur eigenen Recherchie bietet die Norm IEC 61158, in der die gebräuchlichen Feldbusse standardisiert sind - eben auch, aber nicht nur die Ethernet-basierten.


    Jedes dieses industrial Ethernet hat verschiedene Anforderungen und ist entsprechend für unterschiedliche Anwendungen geeignet.


    Ich selber habe vor allem mit PROFIBUS, PROFINET und (Wireless) HART gearbeitet.