Protokolladresse verwenden
Die Referenz 40001 wird häufig als Adresse 0 übertragen. Die Gerätekonvention ist im Handbuch zu prüfen.
Protokoll-Labor
Wähle Funktion, Protokolladresse und Menge. Der Server kontrolliert Funktionsgrenzen und erzeugt die PDU als reproduzierbaren Nachweis.
Anfrage prüfenWähle Funktion, Protokolladresse und Menge. Der Server kontrolliert Funktionsgrenzen und erzeugt die PDU als reproduzierbaren Nachweis.
Die Referenz 40001 wird häufig als Adresse 0 übertragen. Die Gerätekonvention ist im Handbuch zu prüfen.
Bit- und Registerfunktionen besitzen unterschiedliche Grenzen für Lesen und Schreiben.
Eine normale Antwort beweist nicht, dass Motor, Ventil oder Prozess physisch reagiert haben.
Praxisleitfaden für Modbus im Browser
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.

Client und Server sowie RTU, TCP, Unit-ID oder Slave-Adresse eindeutig festlegen, bevor Datenadressen untersucht werden.
Coils, Discrete Inputs, Input Registers und Holding Registers nach Funktion, Richtung und Zugriffsrecht unterscheiden.
Die dokumentierte Referenz und den tatsächlich übertragenen nullbasierten Offset ausdrücklich gegenüberstellen.
Ein oder mehrere 16-Bit-Wörter mit Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit als gemeinsamen Vertrag behandeln.
Ein zuletzt gültiger Wert darf nach Timeout oder Verbindungsverlust nicht unbemerkt als aktueller Prozesszustand gelten.
Exception, Timeout, Neustart und Wiederverbindung so testen, dass Anwendung und Bediener einen definierten Zustand erhalten.
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.
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.
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.
Einen begrenzten Datenpunkt mit dokumentierter Funktion und Adresse lesen.
Nachweis: Antwortstatus und Rohwörter sind reproduzierbar.
Vermeiden: Mehrere Adressen und Parameter gleichzeitig ändern.
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.
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.
| Beobachtetes Symptom | Prüfen | Interpretation | Nächste Beweisaktion |
|---|---|---|---|
| Keine physische Verbindung | Versorgung, Leitung, Polarität, Stecker, Switch, Abschluss und Bias | Der Fehler liegt unterhalb der Modbus-Anwendung. | Zuerst die physische Schicht wiederherstellen. |
| Gerät erreichbar, aber keine gültige Antwort | Rolle, Port oder serielle Parameter, Unit-ID, Funktionscode und Geräteprotokoll | Der Transportweg funktioniert, während Sitzung oder Anfrage scheitert. | Exakten Status und Geräteprotokoll auswerten. |
| Exception-Antwort | Funktionscode, Startadresse, Anzahl und Zugriffsrecht | Der Server hat die Anfrage verstanden und begründet abgelehnt. | Exception-Code statt Timeout-Vermutung verwenden. |
| Wert ändert sich, ist aber falsch | Adressbasis, Datentyp, Byte- und Wortreihenfolge, Vorzeichen, Skalierung und Einheit | Die Übertragung gelingt, die Interpretation jedoch nicht. | Ein bekanntes Bit- oder Wortmuster vergleichen. |
| Unregelmäßiger Timeout | Buslast, Abfragezyklus, Leitung, Fehlerzähler, Antwortzeit und Serverressourcen | Zeitreserve, physische Qualität oder Abfragerate kann instabil sein. | Zähler und Zeitstempel über ein Ereignisfenster erfassen. |
| Nach Wiederverbindung bleibt der Wert alt | Timeout-Regel, Qualitätsstatus, Neuabfrage, Verbindungsaufbau und Anwendungszustand | Die Kommunikation ist zurück, aber der Datenvertrag wurde nicht vollständig erneuert. | Die gesamte Wiederkehrsequenz als Regressionstest ausführen. |
Produktnachweis / 05
Die öffentliche Browseroberfläche verbindet protokollnahe Begriffe, Funktionscode-Referenzen, Zuordnungsbeispiele und wiederholbare Diagnosefälle mit den dokumentierten Produktgrenzen. Sie behauptet keine formale Konformität.
Er bildet Client-Server-Anfragen, Datenbereiche und Antworten in kontrollierten Bedingungen nach, damit Zuordnung und Diagnose ohne Produktionsgerät geübt werden können.
Beide verwenden verwandte Anwendungsdaten, unterscheiden sich jedoch bei Transport, Adressierung, Rahmenbildung und Inbetriebnahme der Verbindung.
Handbücher zeigen häufig Referenznummern, während das Telegramm einen nullbasierten Offset überträgt. Beide Notationen müssen ausdrücklich abgeglichen werden.
Mehrwort-Typ, Vorzeichen, Byte- oder Wortreihenfolge, Skalierung oder Adresse kann falsch interpretiert sein, obwohl die Anfrage erfolgreich war.
Nein. Zusätzlich müssen technische Einheit, Aktualität und ein unabhängiger Prozess- oder Gerätezustand übereinstimmen.
Von physischer Verbindung und Identität über Transportparameter und Anfrage bis zur Serverlast schichtweise prüfen und Zeitstempel bewahren.
Nein. Er unterstützt Lernen und Diagnose; formale Konformität und Interoperabilität benötigen aktuelle Spezifikationen und zugelassene Testverfahren.
Topologie, Identitäten, Parameter, Datenpunktliste, Roh- und Engineeringwerte, Zeitverhalten, Fehlerreaktion und Wiederkehrergebnis.