ich brauche Informationen, wie auf unterster Ebene eine Ethernet-Verbindung aufgebaut wird. Hab schon länger gesucht, aber finde immer nur Grundlagenwissen, das mir größtenteils (spätestens jetzt) schon bekannt ist.
Nun die lange Version. Ein Mikrocontroller übernimmt die Rolle eines Modbus-Servers und soll über Ethernet mit einem Modbus-Client kommunizieren. Das ist die Aufgabe.
Hab eine Bibliothek (nanoMODBUS-master) gefunden, die mir TCP-Pakete generiert, heißt ich muss "nur" noch alles bis OSI Layer 3 selbst machen.
Der Mikrocontroller (TMS320F28388D) hat eine MII-Schnittstelle. Ein Board ist mit PHY und RJ45-Buchse ist schon fertig. Über MDIO kann ich Register des PHY auslesen und schreiben. Mit einem Beispiel-Programm ist es mit gelungen, Daten über Ethernet zu senden und zu empfangen, heißt die Hardware funktioniert so weit, sprich OSI Layer 1 wäre abgehakt. Fehlen noch Layer 2 und 3. Meine IP-Adresse und die des Clients vorher zu konfigurieren (also kein DHCP) wäre in Ordnung.
Im nächsten Schritt habe ich mir den Aufbau eines Ethernet-Pakets angeschaut und mit dem, was der Mikrocontroller macht, verglichen. Der generiert die Präambel und den SFD. Den restlichen Inhalt muss ich selbst generieren, damit auch die MAC-Adressen. Meine eigene kann ich mir ausdenken, so weit so gut. Aber die MAC-Adresse des Ziels kenne ich nicht. Ich nehme an, für den Anfang benutze ich deshalb die Broadcast-Adresse, spreche den Modbus-Client mit seiner IP-Adresse an und erfahre von ihm dann seine MAC-Adresse. Ab hier kann ich mir das Ethernet- und IP-Frame mit bekannten Daten zusammenstricken und muss nur noch die TCP-Daten einfügen.
Liege ich mit meiner Annahme richtig, oder läuft das anders ab?
Wenn das so abläuft, wie genau geht das? Das ist eine Standardaufgabe, sollte also unabhängig von Modbus oder Mikrocontroller/PC sein. Ich finde nur, wie ich auf Anwendungsebene die MAC-Adresse herausbekommen, nichts zum IP-Paket selbst.
Hat jemand eine Adresse, wo das Protokoll grundlegend erklärt wird und nicht nur der Aufbau der Frames? Wenn ich ganz auf dem Holzweg bin, dann bitte zurück ins Licht führen, danke!
MAC-Adresse des Ziels kenne ich nicht. Ich nehme an, für den Anfang
benutze ich deshalb die Broadcast-Adresse, spreche den Modbus-Client mit
seiner IP-Adresse an
Schlagworte "ARP" und "RFC826".
Ganz kurz: Du sendest ein ARP-Frame als Broadcast mit dem Inhalt "wer kennt IP Adresse 47.11.08.15" und bekommst (hoffentlich) als Antwort "47.11.08.15 findest du unter MAC Adresse "1:2:3:4:5:6". Und schon kann Info ausgetauscht werden (naja, fast).
Das TCP/IP lässt Du auf dem Connectivity Manager (dem Cortex M4 Core) laufen. TI hatte zumindest früher ein TI-RTOS für die ARM- und die C2000-Seite, und beim ARM-Paket ist auch der Netzwerk-Stack dabei. Den hab ich früher für TI TIVA-C verwendet.Normalerweise brauchst Du also das Rad nicht mehr neu zu erfinden.
unterster Ebene eine Ethernet-Verbindung aufgebaut wird
Ethernet ist eigentlich der IEEE 802.3 beschrieben. Die "Verbindung" ist hier eher physikalischer Natur in Form eines Übertragungsmediums, da wird mit handfester Hardware "aufgebaut".
Vermutlich meinst du garnicht direkt Ethernet, sondern eher eines der üblichen Protokolle die da oberhalb "draufsitzen"?
Vielleicht erstmal darüber klar werden, aus welchen Ebenen üblicherweise eine Kommunikation verfügen muss. Die ggf. alles selbst zu implementieren macht alles andere als Spaß!
Wenn man denn mal weis was man genau implementieren will, sind die entsprechenden RFC die erste Anlaufstelle (und es dort durchaus "normal" das man sich durch dutzende davon durchackern muss bis man alles zusammen hat):
TCP/IP ist kein Protokoll, das dem OSI-Schichtenmodell folgt, auch wenn es gewisse Ähnlichkeiten gibt.
Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP betrieben werden soll? In den meisten Fällen wird stattdessen nämlich UDP genutzt.
Bei UDP gäbe es durchaus noch eine Restchance, das ganze in erträglicher Zeit selbst zu implementieren, aber TCP mit all den Sonderlocken ist schon eine ganz andere Hausnummer. Alleine über eine Pufferverwaltung, die auch das effiziente Zusammensetzen vertauschter, fragmentierter Pakete ermöglicht, könnte man schon eine Doktorarbeit schreiben.
Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP
betrieben werden soll? In den meisten Fällen wird stattdessen nämlich
UDP genutzt.
Das habe ich bislang noch nirgenwo gesehen. Hast Du mal ein Standarddokument dazu, das die Spezifikation beschreibt? Oder ist das nur irgendwo ein Hack, wo jeder das so macht, wie er das gerade für richtig hält (mal mit 7 Byte Header, mal ohne, mal mit CRC am Ende, mal ohne,...)
(Unklar, ob UDP nur im generischen Modus oder auch für Modbus)
Oder ist das
nur irgendwo ein Hack, wo jeder das so macht, wie er das gerade für
richtig hält (mal mit 7 Byte Header, mal ohne, mal mit CRC am Ende, mal
ohne,...)
Es sind auf dem Markt haufenweise schrottige Geräte erhältlich, bei denen der Hersteller einfach einen beliebigen Konverter von Ethernet mit TCP/IP auf UART an die vorhandene Modbus-RTU-Schnittstelle rangebastelt hat. Das ergibt dann natürlich kein Modbus-TCP, sondern eben Modbus-RTU per Netzwerk. Das ist besonders heikel, wenn dann z.B. T35 nicht durch den Buskonverter erzeugt wird, sondern irgendwie durch den Host sichergestellt werden muss. Für die beliebten Lantronix XPort-Module gibt verschiedene Firmwareversionen für generische Portwandler und speziell Modbus. Diese unterstützen offenbar kein Modbus-TCP über UDP.
Und das will der TE eben mal auf die Schnelle nebenher erledigen.
Ich erinnere mich noch mit Grausen daran, wie viel Zeit wir damals(tm) für das Debugging der Speicherverwaltung des TCP/IP-Stacks von Nucleus PLUS investieren mussten. Da krachte es vorne und hinten beim Zusammensetzen der ganzen Fragmente. Und dabei hatten wir noch nicht einmal solche Sachen wie URG-Signalisierung getestet; ähem, nutzt die heutzutage überhaupt irgendjemand?
Hast du Einfluss auf den Empfänger? Dann könnte man das Brett auch an der dünnsten Stelle bohren:
UDP-Message an IP 255.255.255.255 und MAC ff:ff:ff:ff:ff:ff, kommt immer an, sofern kein Router dazwischen ist.
UDP ist wesentlich simpler als TCP, evtl. Paketverluste kompensiert man einfach durch Mehrfach-Senden, die Fragmente werden durch eine ID unterscheidbar gemacht ... mache ich bei Sensornetzen "im Felde" so, klappt hervorragend, quasi idiotensicher.
Das mag es zwar sein, aber damit ist Modbus-TCP halt einfach nicht möglich.
Einen freien IP-Stack für Microcontroller gibt es in Form von lwip, den haben schon Leute auf den üblichen ARMen mit integriertem NIC zum Laufen bekommen.
Das Rad neuzuerfinden und sich "mal eben" einen IP-Stack selbst zu
basteln ist kein sinnvoller Zeitvertreib.
Richtig. Einen LwIP zu portieren macht man ebenfalls nicht im vorbeigehen.
Deshalb würde ich schauen, dass ich die benötigten Daten auf anderem Weg zum Ziel bringe.
Das ist natürlich die perfekte Lösung, statt ein standardisiertes, wohlbekanntes Protokoll zu verwenden, für das es zig Analyse- und Testwerkzeuge gibt, frickelt man sich eine komplett zu allem inkompatible Sonderlocke.
Wenn es einen überfordert, einen Netzwerkstack zu nutzen, sollte man im Falle von Modbus den naheliegenderen Weg gehen und Modbus/RTU verwenden -- immer vorausgesetzt, daß das Modbus-Device das unterstützt.
Das ist natürlich die perfekte Lösung, statt ein standardisiertes,
wohlbekanntes Protokoll zu verwenden, für das es zig Analyse- und
Testwerkzeuge gibt, frickelt man sich eine komplett zu allem
inkompatible Sonderlocke.
Aha. Und was ist an UDP gefrickelter Nicht-Standard?
Vermutlich meinst du garnicht direkt Ethernet, sondern eher eines der
üblichen Protokolle die da oberhalb "draufsitzen"?
Ich meine das als Sammelbegriff für die physikalische Schnittstelle Ethernet mit den ganzen Protokollen, die darüber sitzen. Alles, was üblicherweise in Kombination mit einer RJ45-Buchse einhergeht, wohlwissend, dass Ethernet auch ohne IP-Protokoll existieren kann und erst recht ohne TCP oder UDP, genau so wie TCP/IP ohne Twisted-Pair-Leitungen über eine RJ45-Buchse funktioniert.
Mir ist dafür kein anderer Sammelbegriff bekannt und ich ging davon aus, die Leute hier werden aus dem Kontext verstehen, was damit gemeint ist.
Eine Sackgasse ist es nicht, denn es steht dem Erreichen des Ziels in keinster Weise im Weg. Das Ziel ist nur weiter weg als gedacht. Für TCP wird es sicherlich auch fertige Bibliotheken geben. (wie sich weiter unten bestätigt)
Dann nehme doch die Ethernet etc. Bibliotheken der IDE. Wenn damit ein
Ping geht kannst du mit dem Modbus weitermachen.
Die Bibliotheken zum Controller enthalten nur Material für die MII-Schnittstelle und das Ethernet-Paket. Hab aber nun gesehen, dass es abseits von den Controller-Bibliotheken bei den third-party-Bibliotheken die Bibliothek "lwIP" gibt, die einen TCP/IP-Stack realisiert. Das hatte ich bisher einfach übersehen. Ich denke, damit ist eigentlich alles vorhanden und das Problem gelöst.
Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP
betrieben werden soll? In den meisten Fällen wird stattdessen nämlich
UDP genutzt.
Ja, siehe zum Beispiel: https://de.wikipedia.org/wiki/Modbus
Oder auch die offizielle Spezifikation: https://modbus.org/specs.php
Es ist immer nur von RTU oder TCP die Rede. Beckhoff beschreibt zwar auch Modbus/UDP, aber das scheint nicht offiziell vorgesehen zu sein.
Und das will der TE eben mal auf die Schnelle nebenher erledigen.
Das hat der TE nie behauptet. Das entspringt deiner Phantasie. Ich möchte nur, dass der Mikrocontroller über Modbus/TCP mit anderen Geräten kommuniziert. Es war nie die Rede davon, dass ich jede Zeile Code selbst schreiben möchte, was schon daran zu erkennen ist, dass ich plane nanoMODBUS zu verwenden.
Hab aber nun gesehen, dass es
abseits von den Controller-Bibliotheken bei den third-party-Bibliotheken
die Bibliothek "lwIP" gibt, die einen TCP/IP-Stack realisiert
Gut, dass der nicht schon von drei Leuten genannt wurde :-)
Vielleicht erst mal mit einem Linux anfangen?
Dann sind die unteren Layer schon alle fertig, betriebsbereit
und man weiß, dass sie funktionieren.
z.B. ein Raspberry Pi
Dort ist UDP in der Tat nicht als Übertragungsprotokoll aufgeführt. Aber nichtsdestotrotz gibt es ja nachweislich entsprechende Geräte. Ich vermute, dass die Übertragung per UDP zu einer Zeit eingeführt wurde, in der kleine ethernetfähige Microcontroller noch nicht genug RAM für einen vollen TPC/IP-Stack hatten, aber für UDP ausreichten.
(Unklar, ob UDP nur im generischen Modus oder auch für Modbus)
Du darfst nicht von einem Ethernet-Deviceserver, der RS485 spricht,
davon ausgegen, daß das irgendwas mit Modbus-TCP zu tun hätte.
Das sind zwei sehr unterschiedliche Paar Schuhe.
Hast Du Dir überhaupt mal die Waveshare-Produkte angeschaut? Offenbar nicht, denn dann wüsstest Du, dass diese auch explizit einen Modbus-Modus besitzen.
Ich habe wahrscheinlich schon mehr Geräte und Anlagen mit Modbus-RTU und -TCP sowohl entwickelt als auch in Betrieb genommen als Du jemals in Deinem Leben gesehen hast. Hierbei habe ich zwar UDP noch nicht verwendet, aber es ist mir eben (siehe obige Aufzählung) schon mehrmals begegnet.
Nenne doch einen ganz konkreten Grund, aus dem Wago und ADFweb/Wachendorff ein angeblich nicht existentes Protokoll in ihre Serienprodukte aufgenommen haben.
Dort ist UDP in der Tat nicht als Übertragungsprotokoll aufgeführt. Aber
nichtsdestotrotz gibt es ja nachweislich entsprechende Geräte.
Nicht wirklich.
Ich
vermute, dass die Übertragung per UDP zu einer Zeit eingeführt wurde, in
der kleine ethernetfähige Microcontroller noch nicht genug RAM für einen
vollen TPC/IP-Stack hatten, aber für UDP ausreichten.
Ja.
Nenne doch einen ganz konkreten Grund, aus dem Wago und
ADFweb/Wachendorff ein angeblich nicht existentes Protokoll in ihre
Serienprodukte aufgenommen haben.
Das, was da wirklich passiert, ist MODBUS-MTU, NICHT MODBUS-TCP. Der einzige Trick dabei ist: transport layer wird aber nicht direkt über RS485-Endpunkte abgewickelt, sondern es wird statt dessen ein "UDP-Tunnel" darunter gebaut.
Solche Umleitungen einfacher serieller Verbindungen gibt es nicht nur bei MODBUS, sondern auch bei vielen anderen Protokollen.
Der Punkt ist: Das ist eben NICHT MODBUS-TCP. Das ist deutlich anders gestrickt. Es verläßt sich nämlich auf TCP als Sicherungsschicht und wirft dafür fast die gesamte Sicherungsschicht von MODBUS-MTU raus aus dem Protokoll.
MODBUS-TCP over UDP wäre machbar, hätte aber praktisch fast keine Sicherungsschicht mehr und wäre damit im (echten) praktischen Einsatz weitestgehend unbrauchbar.
Ich habe wahrscheinlich schon mehr Geräte und Anlagen mit Modbus-RTU und
-TCP sowohl entwickelt als auch in Betrieb genommen als Du jemals in
Deinem Leben gesehen hast.
Wollen wir uns über Fenster und das Hinauslehnen unterhalten?
Vielleicht erst mal mit einem Linux anfangen?
Dann sind die unteren Layer schon alle fertig, betriebsbereit
und man weiß, dass sie funktionieren.
z.B. ein Raspberry Pi
Ein ganzes OS kommt dafür nicht in Betracht und ein Raspberry Pi auch nicht.
Auch wenn sich der Thread auf Modbus bezieht, und Modbus sich bei Ethernet offenbar auf TCP festlegt, möchte ich vorsorglich darauf hinweisen, dass es Aufgaben gibt, die besser auf UDP abbildbar sind. Manche denken automatisch an TCP als Universallösung, ohne die Situation erst zu analysieren.
