Kurz erklärt
Bei einer instabilen Modbus-RTU-Verbindung hilft es, vier Ebenen getrennt zu prüfen: Verdrahtung, elektrische Signalqualität, serielles Timing und Bedeutung der übertragenen Daten. Ändern Sie jeweils nur eine Einstellung und sichern Sie einen bekannten, funktionierenden Vergleichsfall.
Mit einem reproduzierbaren Minimalaufbau beginnen
Verbinden Sie zunächst einen Initiator mit einem Teilnehmer und verwenden Sie eine bekannte Anfrage. Halten Sie Adresse, Baudrate, Parität, Stoppbits, Versorgung und Kabelbelegung fest. Wenn dieser Aufbau stabil funktioniert, erweitern Sie ihn schrittweise um weitere Geräte und Leitungsabschnitte.
Verlassen Sie sich bei A/B-Bezeichnungen nicht allein auf die Buchstaben. Vergleichen Sie die Herstellerunterlagen und die tatsächliche Pinbelegung beider Geräte. Ein Verdrahtungsplan mit Signalnamen und Steckerkontakten ist hilfreicher als eine mündliche Angabe zur Kabelfarbe.
Abschluss und Ruhezustand prüfen
Der RS-485-Leitfaden von TI behandelt Leitungsabschluss, Topologie und Fail-safe-Beschaltung. Prüfen Sie den tatsächlich aufgebauten Bus gegen das gewählte Leitungskonzept; ein Abschlusswiderstand an jedem Teilnehmer ist keine allgemeine Lösung. Texas Instruments — The RS-485 Design Guide
Dokumentieren Sie, welche Geräte bereits Abschluss- oder Bias-Widerstände enthalten. Schaltbare Widerstände müssen mit ihrer aktuellen Stellung erfasst werden. Beobachten Sie Fehler getrennt bei ruhendem Bus, Datenübertragung und Schalten benachbarter Lasten, statt alle Störungen derselben Ursache zuzuordnen.
Die Richtung und das Timing sichtbar machen
Bei Halbduplex kann eine zu frühe Freigabe oder zu späte Abschaltung des Senders die Kommunikation stören. Erfassen Sie Anfrage und Antwort mit Zeitstempel. Wenn möglich, vergleichen Sie das UART-Signal mit der Treiberfreigabe, um verlorene Anfangs- oder Endzeichen einzugrenzen.
Ein längeres Timeout kann fehlende Antworten überdecken, löst jedoch keine beschädigten Telegramme. Unterscheiden Sie keine Antwort, fehlerhafte Prüfsumme, unvollständige Antwort und eine gültige Fehlerantwort des Geräts. Diese Fälle führen zu unterschiedlichen nächsten Prüfschritten.
Korrekte Telegramme können falsche Werte liefern
Wenn die Übertragung fehlerfrei aussieht, prüfen Sie Funktionscode, Registeradresse, Datentyp und Skalierung anhand der Gerätedokumentation. Die Darstellung einer Adresse im Handbuch kann von der im Telegramm verwendeten Zahl abweichen. Auch die Anordnung mehrerer Register für größere Datentypen muss ausdrücklich geklärt werden.
Beispiel: Ein Temperaturwert ist stabil, aber unplausibel. Lesen Sie zunächst die Rohregister und vergleichen Sie sie mit einem definierten Gerätezustand. Ändern Sie nicht gleichzeitig Byte-Reihenfolge, Skalierung und Registeradresse, da sonst unklar bleibt, welche Annahme falsch war.
Ein brauchbares Fehlerprotokoll enthält
- Busplan mit Leitungsabschnitten, Teilnehmern und Widerständen.
- Geräteversionen und vollständige serielle Einstellungen.
- Anfrage und Antwort als Rohdaten mit Zeitstempel.
- Fehlerhäufigkeit und Betriebszustand der angeschlossenen Lasten.
- Genau eine dokumentierte Änderung pro Vergleichstest.
Häufige Fragen
Warum funktioniert der Bus auf dem Tisch, aber nicht in der Anlage?
Leitungslänge, Verzweigungen, Bezugspotenziale und Störumgebung können sich unterscheiden. Vergleichen Sie diese Randbedingungen systematisch, bevor Sie ausschließlich die Firmware ändern.
Beweisen CRC-Fehler einen Softwarefehler?
Nein. Sie können unter anderem durch beschädigte Übertragung oder fehlerhafte Telegrammbehandlung entstehen. Ein Mitschnitt hilft, die Stelle einzugrenzen, an der die Daten abweichen.
Technische Quellen
Passende Entwicklungsleistung