Protokoll-Labor

Erstelle eine Modbus-Anfrage und prüfe jedes Byte.

Wähle Funktion, Protokolladresse und Menge. Der Server kontrolliert Funktionsgrenzen und erzeugt die PDU als reproduzierbaren Nachweis.

Anfrage prüfen

Modbus Simulator Online für TCP, RTU und Register

Wähle Funktion, Protokolladresse und Menge. Der Server kontrolliert Funktionsgrenzen und erzeugt die PDU als reproduzierbaren Nachweis.

Drei Prüfungen vor der Geräteverbindung

01

Protokolladresse verwenden

Die Referenz 40001 wird häufig als Adresse 0 übertragen. Die Gerätekonvention ist im Handbuch zu prüfen.

02

Funktionsgrenzen beachten

Bit- und Registerfunktionen besitzen unterschiedliche Grenzen für Lesen und Schreiben.

03

Protokoll und Prozess trennen

Eine normale Antwort beweist nicht, dass Motor, Ventil oder Prozess physisch reagiert haben.

Deutscher SPS-Simulator

Praxisleitfaden für Modbus im Browser

Modbus-Simulator: Datenvertrag, Diagnose und belastbare Nachweise

Direkte Antwort

Ein Modbus-Simulator ist nützlich, wenn er Rollen, Transport, Geräteidentität, Funktionscode, Adresse, Datentyp, Byte- und Wortreihenfolge, Skalierung und Aktualität als einen prüfbaren Datenvertrag behandelt. Eine erfolgreiche Verbindung genügt nicht; der gelesene oder geschriebene Wert muss die beabsichtigte technische Bedeutung besitzen.

Dieser Leitfaden richtet sich an deutschsprachige SPS-Lernende, Inbetriebnehmer und Instandhalter, die Modbus RTU oder TCP verstehen, Datenpunkte zuordnen und Kommunikationsfehler schrittweise eingrenzen möchten. Das beabsichtigte Ergebnis ist konkret: der Leser kann eine begrenzte Anfrage definieren, die vollständige Beweiskette bis zum Prozesswert verfolgen, eine Abweichung einer Schicht zuordnen und die Grenzen des Browsermodells benennen.

Modbus-Diagnoseplatz mit SPS, dezentraler E-A, serieller und Ethernet-Verbindung sowie einem Browser für Datenzuordnung und Fehlersuche
Eine belastbare Prüfung trennt physische Verbindung, Identität, Anfrage, Rohdaten, technische Bedeutung und Wiederkehr nach einem Ausfall.
Systemkarte / 02

KNOTEN 01beobachtbar

Rollen und Transport

Client und Server sowie RTU, TCP, Unit-ID oder Slave-Adresse eindeutig festlegen, bevor Datenadressen untersucht werden.

KNOTEN 02beobachtbar

Funktionscode und Datenmodell

Coils, Discrete Inputs, Input Registers und Holding Registers nach Funktion, Richtung und Zugriffsrecht unterscheiden.

KNOTEN 03beobachtbar

Adressnotation

Die dokumentierte Referenz und den tatsächlich übertragenen nullbasierten Offset ausdrücklich gegenüberstellen.

KNOTEN 04beobachtbar

Datentyp und Reihenfolge

Ein oder mehrere 16-Bit-Wörter mit Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit als gemeinsamen Vertrag behandeln.

KNOTEN 05beobachtbar

Aktualität und Qualität

Ein zuletzt gültiger Wert darf nach Timeout oder Verbindungsverlust nicht unbemerkt als aktueller Prozesszustand gelten.

KNOTEN 06beobachtbar

Fehler und Wiederkehr

Exception, Timeout, Neustart und Wiederverbindung so testen, dass Anwendung und Bediener einen definierten Zustand erhalten.

Vorgehen / 03

  1. 01

    Vertrag aufschreiben

    Endpunkte, Transport, Identität, Funktion, Startadresse, Anzahl, Datentyp, Reihenfolge, Skalierung und Einheit dokumentieren.

    Nachweis: Beide Seiten beschreiben denselben Datenpunkt ohne stillschweigende Annahmen.

    Vermeiden: Mit zufälligen Einstellungen beginnen, bevor der Vertrag feststeht.

  2. 02

    Physische und Netzwerkschicht prüfen

    Versorgung, Medium, Link, RS-485-Topologie oder IP-Erreichbarkeit kontrollieren.

    Nachweis: Die untere Schicht ist belegt, aber noch nicht mit Anwendungserfolg verwechselt.

    Vermeiden: Ein Link-Licht als Beweis für richtige Daten verwenden.

  3. 03

    Identität bestätigen

    Adresse, Unit-ID, Gerätefamilie, Revision und Serverrolle mit der Zielanlage vergleichen.

    Nachweis: Die Anfrage erreicht das beabsichtigte Gerät.

    Vermeiden: Ein anderes erreichbares Gerät untersuchen.

  4. 04

    Eine bekannte Anfrage senden

    Einen begrenzten Datenpunkt mit dokumentierter Funktion und Adresse lesen.

    Nachweis: Antwortstatus und Rohwörter sind reproduzierbar.

    Vermeiden: Mehrere Adressen und Parameter gleichzeitig ändern.

  5. 05

    Technische Bedeutung prüfen

    Rohdaten in Typ, Reihenfolge, Skalierung und Einheit umwandeln und mit einem bekannten Zustand vergleichen.

    Nachweis: Der Wert stimmt nicht nur syntaktisch, sondern physikalisch.

    Vermeiden: Einen plausiblen Zahlenwert ohne Referenz akzeptieren.

  6. 06

    Ausfall und Wiederkehr testen

    Verbindung kontrolliert trennen, Timeout beobachten und Kommunikation wiederherstellen.

    Nachweis: Stale-Anzeige, sichere Reaktion und vollständige Wiederverbindung sind definiert.

    Vermeiden: Nur den erfolgreichen Start testen.

Diagnosematrix / 04

Diagnosesymptome, Prüfpunkte, Interpretationen und nächste Aktionen für Modbus-Simulator: Datenvertrag, Diagnose und belastbare Nachweise
Beobachtetes SymptomPrüfenInterpretationNächste Beweisaktion
Keine physische VerbindungVersorgung, Leitung, Polarität, Stecker, Switch, Abschluss und BiasDer Fehler liegt unterhalb der Modbus-Anwendung.Zuerst die physische Schicht wiederherstellen.
Gerät erreichbar, aber keine gültige AntwortRolle, Port oder serielle Parameter, Unit-ID, Funktionscode und GeräteprotokollDer Transportweg funktioniert, während Sitzung oder Anfrage scheitert.Exakten Status und Geräteprotokoll auswerten.
Exception-AntwortFunktionscode, Startadresse, Anzahl und ZugriffsrechtDer Server hat die Anfrage verstanden und begründet abgelehnt.Exception-Code statt Timeout-Vermutung verwenden.
Wert ändert sich, ist aber falschAdressbasis, Datentyp, Byte- und Wortreihenfolge, Vorzeichen, Skalierung und EinheitDie Übertragung gelingt, die Interpretation jedoch nicht.Ein bekanntes Bit- oder Wortmuster vergleichen.
Unregelmäßiger TimeoutBuslast, Abfragezyklus, Leitung, Fehlerzähler, Antwortzeit und ServerressourcenZeitreserve, physische Qualität oder Abfragerate kann instabil sein.Zähler und Zeitstempel über ein Ereignisfenster erfassen.
Nach Wiederverbindung bleibt der Wert altTimeout-Regel, Qualitätsstatus, Neuabfrage, Verbindungsaufbau und AnwendungszustandDie Kommunikation ist zurück, aber der Datenvertrag wurde nicht vollständig erneuert.Die gesamte Wiederkehrsequenz als Regressionstest ausführen.

Produktnachweis / 05

Was die Browserpraxis tatsächlich zeigen kann

Die öffentliche Browseroberfläche verbindet protokollnahe Begriffe, Funktionscode-Referenzen, Zuordnungsbeispiele und wiederholbare Diagnosefälle mit den dokumentierten Produktgrenzen. Sie behauptet keine formale Konformität.

Antwortfläche / 07

Was ist ein Modbus-Simulator?

Er bildet Client-Server-Anfragen, Datenbereiche und Antworten in kontrollierten Bedingungen nach, damit Zuordnung und Diagnose ohne Produktionsgerät geübt werden können.

Was ist der Unterschied zwischen Modbus RTU und Modbus TCP?

Beide verwenden verwandte Anwendungsdaten, unterscheiden sich jedoch bei Transport, Adressierung, Rahmenbildung und Inbetriebnahme der Verbindung.

Warum ist die Modbus-Adresse oft um eins verschoben?

Handbücher zeigen häufig Referenznummern, während das Telegramm einen nullbasierten Offset überträgt. Beide Notationen müssen ausdrücklich abgeglichen werden.

Warum ist ein REAL- oder DINT-Wert falsch?

Mehrwort-Typ, Vorzeichen, Byte- oder Wortreihenfolge, Skalierung oder Adresse kann falsch interpretiert sein, obwohl die Anfrage erfolgreich war.

Beweist eine Antwort die richtige Gerätefunktion?

Nein. Zusätzlich müssen technische Einheit, Aktualität und ein unabhängiger Prozess- oder Gerätezustand übereinstimmen.

Wie diagnostiziert man einen Modbus-Timeout?

Von physischer Verbindung und Identität über Transportparameter und Anfrage bis zur Serverlast schichtweise prüfen und Zeitstempel bewahren.

Kann der Browser eine Konformitätsprüfung durchführen?

Nein. Er unterstützt Lernen und Diagnose; formale Konformität und Interoperabilität benötigen aktuelle Spezifikationen und zugelassene Testverfahren.

Welche Nachweise gehören zur Inbetriebnahme?

Topologie, Identitäten, Parameter, Datenpunktliste, Roh- und Engineeringwerte, Zeitverhalten, Fehlerreaktion und Wiederkehrergebnis.