Ethernet/IP

Ich beschaeftige mich nun schon laenger mit Ethernet/IP (IP = Industrial Protocol), einem Protokoll zum Messen von Daten/Steuern von Anlagen ueber das Ethernet (was eigene Steuer-/Messhardware und neue Infrastruktur [z.b. dedizierte LWL] überfluessig macht). In Anbetracht des Mediums (CSMA/CD laesst gruessen) und wenn man sich betrachtet, dass ueber das Ethernet ja schliesslich noch der ganz normale Netzwerkverkehr uebertragen wird, ist der Jitter relativ gering (irgendwo im ms-Bereich). An und fuer sich also echt cool - nur wenn man sich das ganze von der Spezifikation und aus der praktischen Umsetzung betrachtet, ist es nur noch eine schlecht zusammen geschusterte technische Neuerung. Ethernet/IP ist im Grunde ein Protokoll dass ca 10 Befehle integriert, wobei bei zweien ein anderes Protokoll (CIP) gekapselt wird. Im Großen und Ganzen sehe ich folgende Probleme: - ListIdentity liefert die selben Informationen wie der CIP-Service Get_Attributes_All des Objektes Identity Instance 1 - es ist also mehr als nur Schwachsinn innerhalb des übergeordneten die selbe Funktionalität noch einmal zu spezifizieren - Das Length-Feld des Ethernet/IP-Headers wird bei einigen Befehlen nicht genutzt, statt dessen wird im Datenblock eine Anzahl der Elemente angegeben. Das wiederum ist inkonsequent; wuerde das Length-Feld immer genutzt koennte man hier pauschal eine Fehlerbehandlung (empfangene Daten kleiner Length + Groesse Header ohne Datenblock) integrieren - CIP ist teilweise zu komplex. Wenn man sich die Interaktionen zwischen Objekten betrachtet die manchmal notwendig sind, wird das - in einem Diagramm - recht unuebersichtlich - Aenderungen in CIP hat Auswirkungen auf Ethernet/IP - besser waere es, wenn die Protokolle komplett getrennt waeren. Beim Service Forward_Open muss vom Connection Manager die Konnektivitaet in Form von Sockets an die Gegenseite uebermittelt werden. Die Sockets selber werden aber von der Ethernet/IP-Ebene verwaltet... - Spezifikation halboffen: An entscheidenden Stellen ist die Dokumentation nur halboffen - so beispielsweise ist nicht dokumentiert, wie man von der Gegenseite eine Liste aller vorhandenen Variablen mit Datentyp abfragen kann, obwohl dies definitiv geht (siehe mehrere bestendene Anwendungen) Und mein aktuelles Problem heute: Die Integration von CIP-Identity ist heute gescheitert - moechte ich in RSLogix die Module Info meines Generic Ethernet/IP Modules haben, so bekomme ich auch zwei Anfragen (einmal mit Instance 1 und einmal mit 0) - und beantworte diese auch nach Spezifikation korrekt (ich habe dies mittels ethereal geprüft - die Datenpakete sind korrekt und vollstaendig), dann quittiert mir RSLogix alles nur mit einem E_INVALID_ARG (ohne dass ich erfahre, welche von beiden Antworten denn angeblich so falsch war...). Dabei ist mir weiterer Schwachsinn aufgefallen: Im Identity-Object gibt Attribute für die Major und Minor Revision; fuer diese beiden Attribute ist der Wert 0 ungueltig. Wenn man allerdings die Spezifikation weiterliest, so sieht man das man beim Service Get_Attributes_All auf Klassenebene als Standard bei der Minor-Revision 0 senden soll (Hallo? Ungueltiger Wert als Standard?) Naja .... mal sehen was Ethernet/IP morgen bringt...