Cookie
Electronic Team, Inc. uses cookies to personalize your experience on our website. By continuing to use this site, you agree to our cookie policy. Click here to learn more.

Auf ein Modbus-RTU-Gerät über ein Netzwerk zugreifen — ohne ein Hardware-Gateway

Editorial Team Editorial Team
Aktualisiert: Jul 16, 2026

Ihre SPS, Ihr Energiezähler oder Ihr Durchflussregler kommuniziert über Modbus RTU über ein serielles Kabel. Ihr SCADA-, HMI- oder Datenlogger-System läuft auf einem Rechner auf der anderen Seite des Gebäudes — oder des Landes. Diese Anleitung zeigt, wie Sie diese Lücke mit einem virtuellen COM-Port überbrücken, damit Ihre vorhandene Software den Unterschied nie bemerkt.

Auf ein Modbus-RTU-Gerät über ein Netzwerk zugreifen

Das Problem: Seriell auf der einen Seite, Netzwerk auf der anderen

Modbus RTU ist nach wie vor das vorherrschende Protokoll in Fabrikhallen, Umspannwerken und abgelegenen Einsatzorten. Es ist schnell, deterministisch und wird von praktisch jedem Industriegerät unterstützt, das in den letzten 40 Jahren hergestellt wurde. Das Problem ist, dass es für ein kurzes Kabel ausgelegt wurde, nicht für ein Netzwerk.

Das typische Szenario sieht so aus: Ein Modbus-Master — eine SCADA-Plattform wie Kepware, Ignition oder eine benutzerdefinierte Anwendung — muss Register auf einem entfernten Gerät abfragen. Das Gerät verfügt über einen RS-232- oder RS-485-Port. Die Master-Software erwartet einen lokalen COM-Port. Dazwischen befindet sich ein Unternehmens-LAN — oder ein WAN.
Wichtige Erkenntnis

Wenn Sie am entfernten Standort bereits einen PC oder ein eingebettetes Linux-Gerät haben — einen Server, ein Edge-Gateway, einen Raspberry Pi — benötigen Sie keinen Hardware-Geräteserver. Ein softwarebasierter virtueller COM-Port kann dieselbe Aufgabe übernehmen, unter Verwendung von Hardware, die Sie bereits besitzen.
Die herkömmliche Antwort ist ein Hardware-Seriellgeräte-Server — ein Moxa NPort, ein Lantronix UDS oder ein Digi PortServer. Das sind dedizierte Geräte, die neben dem Feldgerät stehen, sich mit Ihrem Netzwerk verbinden und den seriellen Port als TCP-Socket bereitstellen. Sie funktionieren gut, aber sie kosten $150–$500 pro Port, erfordern eine physische Installation und fügen an jedem entfernten Standort zusätzliche Hardware hinzu, die gewartet werden muss.

Modbus RTU vs. Modbus TCP — und warum der Unterschied wichtig ist

Bevor wir fortfahren, ist es hilfreich zu verstehen, was diese beiden Varianten tatsächlich sind — denn sie sind nicht austauschbar, und die Unterscheidung bestimmt die Wahl des Ansatzes.
Immobilie
Modbus RTU
Modbus TCP
Transport
Serielles Kabel (RS-232, RS-485, RS-422)
Ethernet-/TCP/IP-Netzwerk
Rahmenformat
Binär, CRC-16-Prüfsumme
Binär mit MBAP-Header, keine CRC
Standardport
Physischer COM-Port (z. B. COM3)
TCP-Port 502
Unterstützung für mehrere Master
Nein — ein Master pro Bus
Ja — mehrere Master können sich verbinden
Geräteanforderung
Jedes Gerät mit RS-232/485-Anschluss
Das Gerät muss Ethernet unterstützen
Protokollkonvertierung
—
Ja, wenn das Gerät nur RTU ist
Ein Modbus-TCP-Gateway übersetzt zwischen diesen beiden Varianten auf Protokollebene — es spricht RTU mit dem seriellen Gerät und TCP mit dem Netzwerk-Client. Es versteht Modbus-Frames, entfernt oder fügt den MBAP-Header hinzu und konvertiert die CRC.

Ein virtueller COM-Port-Redirector wie Serial to Ethernet Connector macht etwas anderes: Er tunnelt den rohen seriellen Bytestrom transparent über TCP. Die Master-Software sendet weiterhin Modbus-RTU-Frames an einen COM-Port — es ist nur so, dass der COM-Port virtuell ist und die Bytes über das Netzwerk übertragen werden, bevor sie das physische serielle Gerät erreichen. Es findet keine Protokollkonvertierung statt. Das Gerät sieht identische RTU-Frames; die Software sieht einen identischen COM-Port.
Hinweis

Wenn Ihre Master-Software bereits Modbus RTU spricht und auf einen COM-Port abzielt, erfordert der Ansatz mit virtuellem COM-Port keinerlei Änderungen an der Software. Wenn Ihre Software nur Modbus TCP (port 502) unterstützt, benötigen Sie ein Gateway — oder die Software selbst muss die Konvertierung übernehmen. Die meisten modernen SCADA-Plattformen (Kepware, Ignition, Inductive Automation) unterstützen beides und lassen Sie dies pro Kanal auswählen.

Wie der Virtual COM Port Tunnel funktioniert

Serial to Ethernet Connector wird auf zwei Rechnern gleichzeitig als Hintergrunddienst ausgeführt: auf der Serverseite (wo sich der physische serielle Port befindet) und auf der Clientseite (wo die Modbus-Master-Software läuft). Zusammen bilden sie ein passendes Paar virtueller Ports, die über eine dauerhafte TCP-Sitzung verbunden sind.

[Modbus Master (Kepware / Ignition)] → [Virtual COM5 — SEC client] ⟷ TCP / LAN / WAN ⟷ [SEC server] → [Physical COM1 RS-485] → [PLC / Meter / RTU]

Aus Sicht der Anwendung verhält sich COM5 genau wie ein echter serieller Port. Die Baudrate, Parität, Stoppbits und RTS/CTS-Signale werden alle weitergeleitet. Die Anwendung setzt 9600 8N1 auf COM5 und erhält genau dieses Verhalten auf dem entfernten COM1 — obwohl dazwischen eine TCP-Verbindung besteht.

Das bedeutet, dass keine Änderungen an bestehenden Softwarekonfigurationen erforderlich sind. Wenn Ihr SCADA-Projekt bereits mit einer lokalen SPS über COM3 kommuniziert hat, richten Sie es einfach auf den neuen virtuellen Port um, und es funktioniert. Der Modbus-Treiber weiß nicht — und es ist ihm auch egal —, dass der Port virtuell ist.
Modbus RTU über ein Netzwerk
14 Tage kostenlose Testversion
Kostenlos testen

Eins-zu-Viele und Viele-zu-Viele: Mehrere Geräte gleichzeitig verbinden

Ein einfacher Punkt-zu-Punkt-Tunnel ist nützlich, aber Serial to Ethernet Connector geht noch weiter: Es unterstützt Eins-zu-viele- und Viele-zu-viele-Verbindungstopologien, was direkt der Art und Weise entspricht, wie echte Modbus-Netzwerke aufgebaut sind.
Ein Master, viele Slave-Geräte

Ein Master, viele Slave-Geräte

Im häufigsten industriellen Szenario muss ein einzelner Modbus-Master (Ihre Remote-SCADA, HMI oder Datenerfassungsanwendung) viele Feldgeräte — Zähler, SPSen, RTUs, Antriebe — abfragen, die über ein Gelände oder über mehrere entfernte Standorte verteilt sind. Mit Serial to Ethernet Connector konfigurieren Sie eine Server-Verbindung pro entferntem seriellen Port und einen entsprechenden virtuellen Client-COM-Port pro Gerät auf dem Master-PC. Die Master-Anwendung sieht eine Reihe unabhängiger virtueller COM-Ports, einen pro Gerät, und fragt jeden so ab, als wäre es eine lokale serielle Verbindung.

[Modbus Master SCADA] → COM5 ⟷ TCP ⟷ SEC server → COM1 → [Energy Meter, Site A]
→ COM6 ⟷ TCP ⟷ SEC server → COM1 → [PLC, Site B]
→ COM7 ⟷ TCP ⟷ SEC server → COM1 → [RTU, Site C]
Jeder virtuelle COM-Port ist ein dedizierter, isolierter Kanal. Die Master-Software fragt jeden unabhängig ab, mit seiner eigenen Baudrate, seinem eigenen Slave-ID-Bereich und seinem eigenen Abfrageintervall. Es gibt keine theoretische Begrenzung für die Anzahl der entfernten Geräte — Sie fügen für jedes ein Server/Client-Paar hinzu.
Viele Master, ein Gerät

Viele Master, ein Gerät

Serial to Ethernet Connector unterstützt auch den umgekehrten Fall: mehrere Modbus-Master-Anwendungen – oder mehrere Engineering-Workstations – greifen gleichzeitig auf dasselbe physische serielle Gerät zu. Dies ist nützlich, wenn beispielsweise ein SCADA-System und der Laptop eines Wartungstechnikers beide vom selben Energiezähler oder entfernten PLC lesen müssen, ohne Kabel abzuziehen. Jeder Master verbindet sich mit dem Server-Port und erhält seinen eigenen virtuellen COM-Port, während der Server den Zugriff auf den gemeinsam genutzten physischen Port verwaltet.
Viele Master, viele Geräte

Viele Master, viele Geräte

Die beiden Topologien können frei kombiniert werden. Eine große Installation kann Dutzende von entfernten seriellen Geräten umfassen, die jeweils von ihrer eigenen SEC-Server-Instanz bedient werden, wobei mehrere Engineering-Workstations oder SCADA-Knoten jeweils einen Satz virtueller Client-Ports besitzen. Das Ergebnis ist ein vollständiges virtuelles serielles Netzwerk — flexibel, softwaredefiniert und ohne zusätzliche Hardware über das bereits Vorhandene hinaus.
Praktischer Tipp

Wenn mehrere Master sich den Zugriff auf einen physischen seriellen Port teilen, ist es wichtig, dass Ihr Modbus-Polling serialisiert wird — jeweils nur ein Master sollte gleichzeitig eine Anfrage senden, da Modbus RTU keine Kollisionserkennung hat. Die meisten SCADA-Plattformen stellen Anfragen automatisch in eine Warteschlange. Wenn Ihre dies nicht tut, konfigurieren Sie die Master so, dass sie sich nicht überschneidende Polling-Fenster verwenden, oder nutzen Sie separate physische Ports pro Master.

Schritt-für-Schritt-Einrichtung

Im Folgenden wird davon ausgegangen, dass Sie zwei Windows-Rechner im selben Netzwerk haben (oder über VPN verbunden sind). Dasselbe Prinzip gilt für Linux bei Verwendung der Kommandozeilenversion.
1
Installieren Sie Serial to Ethernet Connector auf beiden Rechnern — Führen Sie das Installationsprogramm auf dem Server-Rechner aus (dem mit dem physischen RS-232/485-Anschluss, der mit Ihrem Modbus-Gerät verbunden ist) und auf dem Client-Rechner (dem, auf dem Ihre SCADA- oder Modbus-Master-Software läuft). Dasselbe Installationsprogramm deckt beide Rollen ab.
Installieren Sie Serial to Ethernet Connector auf beiden Rechnern
2
Erstellen Sie eine Serververbindung auf dem Rechner mit dem physischen Port — Öffnen Sie die App, klicken Sie auf Verbindung hinzufügen → Serial over Ethernet → Server. Wählen Sie den physischen COM-Port (z. B. COM1), stellen Sie die Baudrate und das Frame-Format so ein, dass sie zu Ihrem Gerät passen (z. B. 9600 8N1 für die meisten Modbus-RTU-Geräte), und wählen Sie einen TCP-Port, auf dem gelauscht werden soll (Standard 5000). Klicken Sie auf Verbinden — der Dienst lauscht jetzt.
Erstellen Sie eine Serververbindung auf dem Rechner mit dem physischen Port
3
Erstellen Sie eine Client-Verbindung auf dem Modbus-Master-Rechner — Klicken Sie auf dem zweiten Rechner auf Verbindung hinzufügen → Seriell über Ethernet → Client. Geben Sie die IP-Adresse des Server-Rechners und denselben TCP-Port (5000) ein. Die Software erstellt einen neuen virtuellen COM-Port (z. B. COM5) und verbindet sich. In beiden Instanzen wird der Status „Verbunden“ angezeigt.
Erstellen Sie eine Client-Verbindung auf dem Modbus-Master-Rechner
4
Richten Sie Ihre Modbus-Master-Software auf den neuen virtuellen Port — In Kepware, Ignition, ModRSsim oder welchem Tool auch immer Sie verwenden, ändern Sie den COM-Port des Kanals auf den neuen virtuellen Port (COM5). Behalten Sie alle anderen Einstellungen — Baudrate, Parität, Slave-ID, Abfragerate — unverändert bei. Die Kommunikation sollte sofort beginnen.
5
Mit einer Modbus-Abfrage verifizieren — Verwenden Sie Modbus Poll oder QModMaster, um eine manuelle Leseanforderung (Funktionscode 03) an die Slave-ID Ihres Geräts zu senden. Wenn Register Werte zurückgeben, funktioniert der Tunnel Ende-zu-Ende. Wenn Sie eine Zeitüberschreitung erhalten, prüfen Sie, ob die Baudrate am virtuellen Port mit der des physischen Ports übereinstimmt und keine Firewall den TCP-Port 5000 blockiert.
RS-485-Tipp

RS-485-Multidrop-Busse (viele Geräte, ein Kabel) werden vollständig unterstützt. Konfigurieren Sie den physischen COM-Port auf der Serverseite mit aktivierter RTS-Steuerung, wenn Ihr USB-zu-RS485-Adapter dies für die Halbduplex-Richtungsumschaltung erfordert. Der virtuelle Port auf der Clientseite spiegelt dasselbe RTS-Verhalten automatisch wider.

Häufige Setups und Gerätetypen

Der Tunnel funktioniert mit jedem Gerät, das Modbus RTU spricht. Häufigste Konfigurationen:


  • SPSen (Siemens S7, Allen-Bradley, Schneider Modicon) — Fernprogrammierung und Live-Datenabfrage über das Anlagen-LAN.
  • Energie- & Gaszähler (Eastron, Carlo Gavazzi, Socomec) — Zählerauslesung in Umspannwerken oder Schaltanlagen von einem zentralen Energiemanagementsystem aus.
  • Frequenzumrichter (Danfoss, ABB ACS, Siemens SINAMICS) — Auslesen von Drehzahl-/Drehmomentregistern und Fernschreiben von Sollwerten.
  • RTUs & Schutzrelais (Schweitzer SEL, GE Multilin) — Auslesen von Ereignisprotokollen und Statusregistern aus entfernten Umspannwerken über WAN/VPN.
  • Industriewaagen & Fahrzeugwaagen (Mettler-Toledo IND, Rice Lake) — Auslesen von Gewichtswerten von einer zentralen Leitstelle oder einem ERP-System aus.
  • Solar-Wechselrichter (SMA, Fronius, Growatt) — Überwachung von Ertrag, String-Daten und Fehlercodes über eine zentrale Monitoring-Plattform.
  • Durchfluss- & Druckmessgeräte (Yokogawa, Endress+Hauser) — Erfassung von Prozessdaten ohne Austausch der bestehenden RS-485-Feldverkabelung.
  • HMIs & Bedienpanels (Weintek, Kinco) — Gemeinsame Nutzung des COM-Ports eines einzelnen Panels durch mehrere Engineering-Workstations.

Software- vs. Hardware-Seriell-Geräteserver: Ehrlicher Vergleich

Beide Ansätze funktionieren. Die richtige Wahl hängt davon ab, ob Sie am entfernten Standort bereits einen PC haben und wie wichtig Ihnen einfache Bereitstellung im Vergleich zu Geräteunabhängigkeit ist.
Kriterium
Serial to Ethernet Connector
Hardware-Geräteserver (Moxa / Lantronix / Digi)
Vorauszahlung pro Port
✓ Softwarelizenz, einmalig
150–500 $ Hardware pro Port
Physische Installation erforderlich
✓ Nein — wird auf einem vorhandenen PC installiert
Ja — Rack-Montage oder DIN-Schiene vor Ort
Funktioniert ohne PC am entfernten Ende
Benötigt einen PC/Server/SBC
✓ Ja — eigenständiges Gerät
Protokollkonvertierung (RTU → TCP)
Nein — nur transparenter Tunnel
Viele Modelle enthalten dies optionalerweise
RS-485-Mehrpunktunterstützung
✓ Ja
✓ Ja
Eins-zu-viele / viele-zu-viele
✓ Ja — unbegrenzte virtuelle Portpaare
Begrenzt durch die Anzahl der physischen Ports pro Einheit
Remote-Konfiguration
✓ Über die Software-Benutzeroberfläche oder die Befehlszeile
Web-Benutzeroberfläche oder Telnet
Funktioniert über VPN / WAN
✓ Ja — es ist eine TCP-Verbindung
✓ Ja
Funktioniert unter Linux / eingebetteten Systemen
✓ Ja — CLI-Edition für RPi, x86
Hardware ist das Linux-Gerät
Keine Änderungen an der Modbus-Master-App
✓ COM-Port einfach neu zuweisen
✓ Gleiches Modell für virtuelle Port-Treiber
Ideal, wenn
Ein PC oder SBC befindet sich bereits vor Ort
Überhaupt kein PC am entfernten Ende

Häufige Probleme und wie man sie behebt

Modbus-Zeitüberschreitungen bei jeder Abfrage

Die häufigste Ursache ist eine Nichtübereinstimmung der Baudrate. Bestätigen Sie, dass der physische Port auf der Serverseite und der virtuelle Port auf der Clientseite auf dieselbe Baudrate und dasselbe Frame-Format wie das Feldgerät eingestellt sind. Modbus-RTU-Geräte verwenden standardmäßig 9600 8N1, einige werden jedoch mit 19200 oder 38400 ausgeliefert. Prüfen Sie das Gerätehandbuch oder verwenden Sie zunächst einen seriellen Monitor am physischen Port.

Die Verbindung wird nach einigen Sekunden unterbrochen

Prüfen Sie, ob eine Unternehmens-Firewall oder die Windows Defender-Firewall inaktive TCP-Verbindungen schließt. Fügen Sie auf dem Servercomputer eine eingehende Regel für den TCP-Port 5000 hinzu. Wenn Sie über ein WAN arbeiten, vergewissern Sie sich, dass der VPN- oder NAT-Router die Verbindung nicht wegen Zeitüberschreitung trennt; aktivieren Sie TCP-Keepalive in den Einstellungen des Serial to Ethernet Connector, um dies zu verhindern.

RS-485-Halbduplex-Kollisionen

Wenn Sie einen RS-485-Adapter verwenden, der eine softwareseitige RTS-Steuerung für die Richtungsumschaltung erfordert, aktivieren Sie den RTS-Umschaltmodus am physischen Port in der serverseitigen Konfiguration. Dadurch wird sichergestellt, dass der Sendeaktivierungs-Pin des Adapters vor jedem Modbus-Anforderungsrahmen korrekt angesteuert wird. Andernfalls können verstümmelte Antworten auftreten oder es erfolgt überhaupt keine Antwort.

Mehrere Slaves auf einem RS-485-Bus reagieren nicht

RS-485-Multidrop funktioniert normalerweise — ein virtueller COM-Port auf der Client-Seite kann alle Slave-IDs auf dem Bus abfragen. Stellen Sie sicher, dass Ihre Modbus-Master-Software Unicast-Anfragen mit spezifischen Slave-IDs (1–247) sendet und keine Broadcast-Anfragen (Slave-ID 0), die keine Antworten erzeugen. Fügen Sie Verzögerungen zwischen den Abfragen hinzu, wenn der Bus stark ausgelastet ist.

Schneller Konnektivitätstest (Linux / Windows WSL):

nc -zv 192.168.1.50 5000
# Expected: Connection to 192.168.1.50 5000 port [tcp/*] succeeded!
# If this fails, the firewall is blocking the TCP port

Häufig gestellte Fragen

Nein. Der Ansatz mit dem virtuellen COM-Port bedeutet, dass Ihre Software weiterhin den Modbus-RTU-Treiber verwendet und einen COM-Port anspricht — genau wie bisher. Die einzige Änderung ist, welche COM-Port-Nummer Sie auswählen. Kein TCP-Port, keine IP-Adresse, keine Protokolländerung innerhalb der Anwendung.
Ja. An den einzelnen physischen RS-485-Port können viele Slaves angeschlossen werden (bis zu 32 an einem Standard-Bus, 256 mit Repeatern). Der virtuelle COM-Port auf der Master-Seite repräsentiert diesen gesamten Bus. Ihr Modbus-Master sendet Frames, die an einzelne Slave-IDs (1–247) adressiert sind, und jedes Gerät antwortet auf seine eigene Adresse, genau wie bei einer lokalen seriellen Verbindung.
Es gibt keine feste Begrenzung, die von der Software selbst festgelegt wird. Jedes entfernte serielle Gerät erhält sein eigenes Server-/Client-Port-Paar. In der Praxis sind Ihre Netzwerkbandbreite und die Abfragekapazität Ihrer Modbus-Master-Anwendung die Grenze. Installationen mit Dutzenden von entfernten COM-Ports sind üblich, insbesondere in Energiezähler- und SCADA-Umgebungen.
In einem lokalen LAN beträgt die zusätzliche Latenz typischerweise 1–5 ms — vernachlässigbar für Polling-Anwendungen. Über ein WAN oder VPN hängt sie von der Verbindungsqualität ab, aber die meisten SCADA- und Datenerfassungsanwendungen verwenden Polling-Intervalle, die in Sekunden gemessen werden, sodass selbst 50–100 ms zusätzliche Latenz irrelevant sind. Stellen Sie Ihren Modbus-Timeout sicherheitshalber auf mindestens das 3× der erwarteten Round-Trip-Zeit ein.
Serial to Ethernet Connector unterstützt einen Modus mit gemeinsamem Zugriff, bei dem mehrere virtuelle Client-Ports mit demselben Server-Port verbunden werden. Ob dies für Modbus funktioniert, hängt von Ihrer Master-Software ab — Modbus RTU ist ein Anfrage-/Antwort-Protokoll, und gleichzeitige Anfragen von mehreren Mastern führen zu Kollisionen auf dem Bus. Die meisten SCADA-Plattformen handhaben dies durch ihre eigene Anfragen-Warteschlange; wenn Ihre dies nicht tut, verwenden Sie separate physische Ports pro Master oder serialisieren Sie den Zugriff auf Anwendungsebene.
Ja, solange der Router des entfernten Standorts eine erreichbare IP hat (statisch oder DDNS) und der TCP-Port weitergeleitet wird. In der Praxis unterstützen die meisten industriellen Mobilfunkrouter Portweiterleitung oder VPN-Tunnel, was die sicherere Option ist. Aktivieren Sie die Keepalive-Einstellung in Serial to Ethernet Connector, um kurze Mobilfunkausfälle problemlos zu überbrücken.
Der standardmäßige TCP-Tunnel ist unverschlüsselt, was in isolierten Anlagennetzwerken gängige Praxis ist. Für über WAN verbundene Standorte besteht der empfohlene Ansatz darin, den Tunnel innerhalb eines VPNs auszuführen — IPsec oder WireGuard —, das die gesamte Sitzung verschlüsselt. Ein SSH-Tunnel ist ebenfalls unkompliziert für Linux-zu-Linux-Setups.
Serial to Ethernet Connector
Remote-Serienport über IP-Netzwerk für Windows zugreifen
Kostenlos testen
14-tägige kostenlose Testversion verfügbar
Der Lizenzpreis beginnt bei $259.95
Verfügbar für