Modbus-Ausnahmecode - Diagnosehandbuch: 7 Standard-Ausnahmecodes und 26 echte Engineering-Fälle

Wie sieht das ungewöhnlich aus?

Die Modbus-Ausnahme - und normale Antwort unterscheidet sich nur um einen Bit. Nachdem die Master-Station eine Anfrage gesendet hat, legt die Slave-Station den Funktionscode auf die höchste Position 1, gefolgt von einem einzigen Byte-Ausnahmecode, und der Frame ist beendet. Kein Datenbereich.

Strukturvergleich zwischen normalen Frameen und abnormalen Frameen:

请求:     01 03 00 00 00 01  — 读 1 号站，保持寄存器 0x0000
正常响应:  01 03 02 12 34    — 02=数据字节数，0x1234=读回的值
异常响应:  01 83 02          — 83=0x03|0x80，02=异常码 0x02

In diesem Beispiel: Der Funktionscode 0x03 wird nach der höchsten Position 1 zu 0x83. Der Ausnahmecode 0x02 steht für „illegale Datenadresse" - bedeutet, dass die Adresse 0x0000 auf der Slave-Station nicht existiert.

Einen Blick auf die CRC-Prüfungen: Unabhängig von normalen oder abnormalen Antworten wird CRC von der Station-Adresse bis zum letzten Datenbyte (ohne CRC selbst) gezählt. Ich habe absichtlich nicht CRC geschrieben, am Ende des tatsächlichen Frames bleiben noch zwei Bytes.

Es gibt Unterschiede zwischen RTU und TCP-Ausnahme - Frames, die Unterschiede in der Kapselungsschicht sind. Der MBAP-Header von TCP enthält ein 2 - Byte-Längenfeld, das die Einheit-Identifikation + Funktionscode + Ausnahmecode enthält. Die RTU trennt Frames durch 3,5 - Zeichen-Stillstandszeit. Die Protokollschicht ist nicht identisch, aber die Funktions - und Ausnahmecode-Semantik ist identisch - dies ist eines der saubersten Designs von Modbus.

Es gibt noch ein Detail, das leicht übersehen wird: Die Framelange für eine Ausnahmeantwort ist fest. Bei Funktionscodes 0x01 ~ 0x06 ist die Ausnahmeantwort immer nur 3 Byte (Adresse + Funktionscode)| 0x80 + Ausnahmecodes), CRC wird ebenfalls berechnet. Für Multi-Operations - Funktionscodes wie 0x0F und 0x10 beträgt die Ausnahmeantwort ebenfalls 3 Byte. Die Station muss Ihnen nicht sagen, „welcher Teil ist falsch", sondern nur, „die gesamte Anfrage wurde abgelehnt". Das Design ist grob, aber auch sehr einfach - die Hauptstation erhält den Ausnahmecode und versucht es selbst zu versuchen oder einen Fehler zu melden.

Auch auf der Ebene der Zeiten wird gefragt. Die Modbus RTU schreibt vor, dass Slaves innerhalb einer festgelegten Zeit nach Erhalt der Anforderung antworten müssen - aber der Standard gibt keine festgelegten Werte für diese Zeit vor. In der Praxis liegen die Reaktionszeiten der meisten Slaven-Stationen zwischen 5 und 50ms. Wenn eine Antwort nicht mehr als 1 Sekunde empfangen wird (oder ein Ausnahme-Frame nicht empfangen wird), sollte die Master-Station als keine Antwort von der Slave-Station betrachten - dies ist ein Timeout, kein Ausnahmecode. Viele industrielle Steuerungssoftware vermischen „No Response" und „Exception Response", um Ihnen die Illusion zu geben, dass das Gerät einen Ausnahmecode zurückgegeben hat. Tatsächlich kam nichts vom Bahnhof zurück. Die Unterscheidung zwischen diesen beiden Situationen ist entscheidend, um das Problem zu beheben - keine Antwort ist ein Problem auf Linkschicht oder Geräteschicht, und ein Ausnahmecode ist ein Problem, das Ihnen von der Applikationsschicht der Station sagt: „Ich habe es erhalten, aber ich mache es nicht".

Im Folgenden werden sieben Standard-Ausnahmecodes einzeln aufgelöst. Jeder von ihnen ist mit echten Nachrichten und Fälle vor Ort ausgestattet - nicht mit Wireshark simuliert, sondern in der Produktion, Umspannstation, Pumpenraum wirklich getroffen.

0x01 Unzulässiger Funktionscode

Der von der Master-Station angeforderte Funktionscode wird von der Slave-Station nicht unterstützt oder ist im aktuellen Zustand der Slave-Station deaktiviert.

Wenn Sie einen 0x08 - Diagnosecode an ein Standardmodbus-Gerät senden, das 03.06.16 unterstützt, erhalten Sie wahrscheinlich 0x01. Da der Diagnose-Funktionscode optional ist, sind viele billige I / O-Module nicht realisiert.

Beispiel für die Nachricht

请求:     02 08 00 00 AA 55
异常响应:  02 88 01

0x08 = Diagnose, Subcode 0x0000 = Rückschleiftest, Daten 0xAA55. Zurück zur Station 0x88 (0x08| 0x80) + 0x01.

Fall 1: Die SPS der Delta DVP-Serie unterstützt keine Diagnose-Funktioncodes

Delta DVP-SX2 - Serie, Firmware-Version V3.8. Im Projekt wird der RS - 485 - Leitungsqualitätstest durchgeführt, das Testcenter von Modbus Poll verwendet, um 0x08 Diagnose zu senden, und das Ergebnis gibt den Ausnahmecode 0x01 zurück. Bestätigung: DVP implementiert nur sechs Funktionscodes 01/03/05/06/0F/10, 0x08 ist nicht in der Liste. Die Diagnose der Leitungsqualität kann nur mit einer 0x01 - Lesespule oder einem 0x03 - Lesegister durchgeführt werden, die indirekt durch die Reaktionszeit und die kontinuierliche Erfolgsrate beurteilt werden. Diese Sache sagt uns, dass der Diagnose-Funktioncode zwar in den Modbus-Standard geschrieben ist, aber nicht alle Hersteller kaufen.

Fall 2: Siemens S7 - 1200 unterstützt Modbus-Server ohne Lesespule

Der Siemens S7 - 1200 unterstützt seit TIA Portal V14 den Modbus TCP Server. Die Implementierung aber zugeordnet nur den DB-Block in das Hold-Register (0x03/0x06/0x10), die Spule 0x01/0x05/0x0F tut es nicht. Beim Debugging mit dem Obercomputer verwendet SCADA 0x01, um das Gerätestatuswort zu lesen, und S7-1200 wirft direkt eine 0x81 + 0x01 zurück. Lösung: Mappen Sie die Spule-Adresse in den Registerbereich und lesen Sie stattdessen mit 0x03 aus.

Fall 3: Verbot des Schreibparameter während des Betriebs des Frequenzumrichters

Der HSBC MD500 Frequenzumrichter versucht im Betriebszustand, die angegebene Register 0x2000 mit der Frequenz 0x06 zu schreiben. 0x01 zurückgegeben. Es ist nicht, dass der Umrichter den 0x06 - Funktionscode nicht unterstützt, sondern dass der aktuelle Zustand nicht schreiben darf. Im Handbuch von HSBC wird dies als "Laufgeschriebene Verbote" bezeichnet, aber die Protokollschicht verwendet den Standard-Ausnahmecode 0x01. Diese semantische Erweiterung ist auf vielen inländischen Geräten zu sehen - Standard-Ausnahmecodes, die von Herstellern definierte Einschränkungen ausdrücken.

Fall 4: Modbus Plus-spezifischer Funktionscode wird auf dem TCP-Gateway abgelehnt

Eine alte Modicon Quantum SPS konvertiert Modbus Plus in Modbus TCP über die BM85 - Brücke. Modbus Plus verfügt über einen eigenen Satz von erweiterten Funktionscodes (0x14 ~ 0x18 für die Netzwerkverwaltung), aber die BM85 - Brücke überträgt nur den Standardmodbus-Funktionscode. Der Host-Computer hat versehentlich eine 0x14 - Anforderung zum Lesen von PLC-Statistiken gesendet, und die Brücke gibt 0x81 + 0x01 direkt nach der Überprüfung in der Anwendungsschicht zurück. Beachten Sie, dass der Ausnahmecode hier vom Gateway und nicht vom PLC zurückgegeben wird - das PLC unterstützt 0x14, aber das Gateway nicht. Es gibt keine Analyse-Routing für diesen Funktionscode in der Brücke-Log, direkt abgelehnt. Gateways, die Sicherheitsfilterung von Funktionscodes durchführen, sind in praktischen Projekten üblich, insbesondere in industriellen Routern mit Firewall-Funktionen.

0x02 - Ungültige Datenadresse

Der Slave unterstützt diesen Funktionscode, aber die Anzahl der angeforderten Startadressen + überschreitet den gültigen Adressbereich des Slaves. Dies ist eine der meisten Ausnahmecodes, die bei der Debugging vor Ort begegnet sind, keine.

Schlüsselfunkt: Die Adresse, die in der Masterstation-Software ausgefüllt wird, und die tatsächlich gesendete Adresse der Protokollschicht haben einen Offset. Das Modbus-Protokoll sieht vor, dass Adressen bei 0 nummeriert werden. Sie füllen 40001 (1 - based Hold-Register) in Modbus Poll, die Protokoll-Ebene ist 0x0000. Die Adress-Berechnungslogik läuft umgekehrt, liest die Fehlerdaten und löst 0x02 aus.

PLC/SCADA 地址表示:   40001 (1-based, 保持寄存器)
协议层 PDU 地址:      0x0000 (0-based)

Nachricht Beispiel

请求:     01 03 00 64 00 0A  — 读 0x0064 = 400101，读 10 个
异常响应:  01 83 02

Der gültige Hold-Register - Bereich der Slave-Station ist 40001 ~ 40090 (d.h. PDU-Adressen 0x0000 ~ 0x0059), die Anforderung Start-Adresse 0x0064 überschreitet, direkt 0x02.

Fall 1: Die Adresse des Schneider TM3 - Erweiterungsmoduls ist nicht ausreichend

Die Schneider Modicon M221 ist mit zwei TM3 - Erweiterungen verbunden. Der erste Block TM3DI16 ist% IW0 ~% IW1 und der zweite Block TM3AI4 ist% IW2 ~% IW5. SCADA liest%IW10 mit 0x04 (Lese-Eingabe - Register) und gibt 0x02 von der Station zurück. Der Grund ist einfach - M221 zugewies nur%IW0 ~%IW5,%IW10 ist nicht in der physischen E / A-Mappe. Ein Blick auf die I / O-Tabelle in SoMachine lässt sich verstehen. Dieses Problem ist eine Konfigurations - und tatsächliche Hardware-Unpassung, nicht ein Protokollfehler.

Fall 2: Pit mit Modbus Poll-Adressen 40001 und 400001

Ein Anfänger Ingenieur mit Modbus Poll Punkt Tabelle kopiert die Adresse ist 40001, Modbus Poll tatsächlich sendet 0x0000, das Gerät als erstes Halten Register gelesen, kein Problem. Aber später wechselte ich eine andere inländische Konfigurationssoftware, die Software analysiert 40001 in 4000 + 1 Offset, die tatsächliche Sendung ist 0x0FA0. Die Slave-Station hat überhaupt nicht so viele Register, und gibt 0x02 zurück. Die gleiche Punkt-Tabelle, die gleiche Slave-Station, verschiedene Master-Station - Software-Adresse Vereinbarung ist nicht identisch, das Ergebnis ist anders. Dies ist nicht ein Problem mit dem Modbus-Protokoll, sondern ein Problem mit den einzelnen Spielern der Toolkette. Es wird empfohlen, direkt mit der PDU-Adresse (0 - basiert) mit Kollegen zu kommunizieren, nicht zu sagen, was die 4 - Zone 5 - Zone, das sind die alten Kalender von Modicon.

Fall 3: Endadresse beim Lesen mehrerer Registers überschritten

Ein Modbus-Zähler mit den Registern 0x0000 ~ 0x003F (64 Register). Die Masterstation verlangt, 10 Register (0x0038 ~ 0x0041) ab 0x0038 zu lesen.Überprüfen Sie von der Station: Letzte Adresse 0x0038 + 9 = 0x0041 > 0x003F, werfen Sie 0x02 direkt. Viele von der Station, wenn die Adresse Legitimität überprüfen, wird zuerst berechnen, ob die Start + Anzahl im Bereich ist, solange eine Adresse überschreitet die Grenze wird das Paket abgelehnt. Kein Register überschreitet die Grenze, um teilweise Daten zurückzugeben - der Modbus-Standard hat kein Konzept für eine teilweise Antwort.

Fälle 4: Diskrete Eingänge und Spule-Adressen - Verwechslung

Diese Grube ist besonders häufig in Unternehmen, die die alte Modicon-Fünfstellar - Adressmarkierung verwenden. 1xxxx ist ein diskreter Eingang (nur Lesebits) und 0xxxx ist eine Spule (Lese - und Schreib-Bits). In der Konfiguration des Host-Computers wurde die Adresse 10001 konfiguriert, um den Geräteszustand zu lesen, aber tatsächlich sollte die Slave-Station den Geräteszustand in den Spule-Bereich platzieren (0xxxx entspricht 0x01 Funktioncode). Der Host-Computer benutzt 0x02 (Lese diskrete Eingabe) um die Adresse 0x0000 von der Station zu beantragen, 0x0000 existiert nicht in der diskreten Eingabe-Bereich - es gibt insgesamt 8 diskrete Eingaben (Adressen 0x0000 ~ 0x0007), aber diese 8 wurden anderen DI zugewiesen. 0x02 von der Station zurückgegeben. Ein Wechsel des Funktionscodes oder eine Wechsel der Adresse kann gelöst werden, aber nur wenn Sie wissen müssen, wie die Adresstabelle von der Station aussehen soll. Viele Ingenieure zugeordneten alle diskreten Signale direkt in die Spule oder in die Register, um den Benutzer zu verwirren - aber nur, wenn Sie die Slave-Station in der Hand, die es Ihnen erlaubt.

0x03 - Illegale Datenwerte

Die Adresse ist gültig, der Funktionscode ist gültig, aber der Datenwert, der im Anforderungskörper enthalten ist, liegt außerhalb des zulässigen Bereichs.

Dies ist ein Ausnahmecode, der leicht ignoriert werden kann. Oftmals werden Sie zuerst vermuten, dass die Adresse falsch konfiguriert ist, aber in Wirklichkeit ist der geschriebene Wert überschritten.

Beispiel-Nachricht

请求:     01 06 00 10 FF FF  — 写单个寄存器，地址 0x0010，值 0xFFFF
异常响应:  01 86 03            — 功能码 0x06|0x80 = 0x86，异常码 0x03

Warum ist 0xFFFF(65535) illegal? Da das Register ein Ingenieurwert im Bereich von 0 bis 10000 ist. 65535 ist in der 16 - Bit-Darstellung legal, aber in der Geschäftslogik illegal.

Fall 1: Schreiben von EEPROM-Parametern außerhalb des Konfigurationsbereichs

Umron E5CC-Temperaturregler, Register 0x0103 (PID-Skalaband). Der gültige Bereich für diesen Parameter beträgt 0,1 bis 9999, und wird in 0,1 ° C gespeichert, d. h. im Registerwert 1 bis 9999. Der Host-Computer sendet 0x0000 (d. h. 0,0 ° C) aus, und der Wert von der Station ist kleiner als die untere Grenze 1 nach der Verifizierung gefunden, und gibt 0x03 zurück. Im Handbuch wurde der Bereich geschrieben, aber der Code des Oberplatzes war faul, ohne die Grenzen zu überprüfen. Es dauerte eine halbe Stunde, bis ich feststellte, dass der Wert über den Bereich geschrieben wurde - dieser Fehler auf niedrigem Niveau kann jeder machen, und es ist wichtig, sich daran zu erinnern, das Handbuch zu lesen, bevor Sie den Ausnahmecode lesen.

Fall 2: Schreibvorgang in ein Read-Only Register

ABB ACS580 Frequenzumrichter, Register 0x2104 (Real Drehzahlfeedback, Read-Only). Der Host hat versucht, mit 0x06 auf 1500 zu schreiben (wir wollen den Drehzahlwert manuell geben) und hat von der Station 0x03 zurückgegeben. 0x2104 Diese Adresse existiert selbst, und der Funktionscode 0x06 wird ebenfalls unterstützt, aber die Adresse ist als Lese-nur - Eigenschaft innerhalb des Slaves markiert.„Illegale Datenwerte" bedeutet hier „Sie haben Daten an eine Adresse geschrieben, die kein Schreiben akzeptiert" - nicht der Wert selbst ist illegal, sondern der Schreibvorgang ist illegal. In der Modbus-Spezifikation steht der 0x03 für "Value is not permitted", was dem Slave eine Freiheit gibt. Viele Hersteller haben den Lese-Schutz auf 0x03 gesetzt.

Fall 3: Multi-Register - Schreiben - - Teilweise Feld-Werte illegal

5 Register mit 0x10 Batch-Schreiben, die ersten 4 Werte sind gut, der fünfte Register erfordert einen Wert zwischen 0 und 100, Sie haben 200 geschrieben. Einige Slaves werden alle Daten überprüfen, bevor sie antworten, 5 vollständig legal ausgeführt werden, jede unrechtmäßige wird insgesamt abgelehnt, um 0x03 zurückzugeben. Einige von ihnen prüfen nach und stellen fest, dass die erste nicht legal ist. Die Regel sagt nicht, welche Art und Weise es sein muss, und die Umsetzung ist von jedem Haus anders. Ich empfehle Ihnen, einen Grenztest für Ihr eigenes Gerät durchzuführen, das Sie wissen.

Fall 4: Registrierung der Berechtigungen für die Nachfrage-Reset - Registrierung für Modbus-Zähler

Im Schneider PM800 - Serie-Zähler kann das Register 0x2F01 (Befehl für die Nachfrage-Reset - Registrierung) nur in eine bestimmte Kombination von Steuernwörtern geschrieben werden (0x1234 oder 0x5678). Der Host hat 0x0001 falsch geschrieben, während der Versuch, die Nachfrage zu löschen, gibt das Gerät 0x03 zurück. Im Handbuch steht klar: Gültige Werte für das Register des Reset-Befehls sind 0x1234 und 0x5678, und jeder andere Wert löst 0x03 aus. Dieses Design soll Fehloperationen verhindern - schließlich ist es nicht so einfach, dass manche Register falsch schreiben, sondern tatsächlich Parameter verändern.

Es gibt auch eine Falle im Zusammenhang mit 0x03: Wenn der Funktionscode 0x06 in ein einzelnes Register schreibt, kann die Station 0x03 zurückgeben, wenn das Register 32 - Bit-Wert hat, nur die unteren 16 - Bit geschrieben werden und die oberen 16 - Bit nicht initialisiert sind. Zum Beispiel für AB ACS580 Parameter 0x1000 (32 - Bit Fließkomma), müssen Sie mit 0x10 zwei Register auf einmal schreiben, nicht in zwei 0x06 aufgeteilt. Wenn es getrennt geschrieben wird, gibt der Slave bei der ersten 0x06 0x03 an - weil er weiß, dass die Adresse 32 - Bit-ausgerichtet ist und keine 16 - Bit-Schreibvorgänge akzeptiert.

0x04 Ausfall von Station-Geräten

Bei der Verarbeitung der Anforderung ist bei der Slave-Station ein unwiederherstellbarer interner Fehler aufgetreten, der dazu führte, dass der Befehl nicht ausgeführt wurde. Dieser Ausnahmecode sagt Ihnen: „Es ist nicht Ihre Anfrage, die fehlerhaft ist, sondern ich selbst."

0x04 ist der am meisten angespannte Ausnahmecode. 0x01 ~ 0x03 Sie können die Konfiguration ändern, 0x04 bedeutet, dass Sie möglicherweise in die Werkstatt zu gehen, um die Leiter zu steigen.

Beispiel für die Nachricht

请求:     03 03 00 20 00 04  — 读 4 个保持寄存器
异常响应:  03 83 04

Die gleiche Anforderung, die vor zehn Minuten normal Daten zurückgab, gibt jetzt kontinuierlich 0x04 zurück. Die Wahrscheinlichkeit von Hardware-Fehlern ist groß.

Fall 1: Modbus-Sensor EEPROM Schreibfehler

Ein Kunlun Küsten JWSK - 6 Temperatur-Feuchtigkeit - Transmitter, Modbus-RTU - Schnittstelle. Die Gerätadresse wurde von 0x01 auf 0x05 geändert und die Stromversorgung schüttelte während des Schreibens von EEPROM ein wenig. Schreibfehlgeschlagen, die Geräte-Firmware erkannte eine Fehlvereinbarkeit der EEPROM-Prüfsumme und wechselte in den fail-safe - Modus Alle Funktionscode-Anfragen (unabhängig davon, ob 0x03 Lesen oder 0x06 Schreiben) werden dann 0x04 zurückgegeben. Das Handbuch wurde überprüft, um zu bestätigen: Der Sensor sperrt die Kommunikation nach einem Fehlschlag der EEPROM-Selbstprüfung und kann nur physisch ausgeschaltet werden, um die Werkseinstellungen wiederherzustellen. Das gehört zum Schutz von Firmware - besser als dazu, dass Sie Fehlerwerte lesen.

Fall 2: Kurzschluss der Sonde des Temperature Controllers verursacht eine Anomalie der AD-Umwandlung

RKC CB100 Temperature Controller, Thermocouple-Eingang ist kurzschlussfähig, weil der Anschluss Wasser eintritt. Der AD-Konverter - Chip liest den Überlaufwert, die Firmware entscheidet, dass der Sensor fehlerhaft ist, und alle 0x03 - Anfragen zum Lesen des PV-Werts geben 0x04 zurück. Diese 0x04 ist nicht ein Modbus-Kommunikationschip schlecht, sondern ein Sensor-Front - End-Fehler, der sich in die Protokollschicht über den Anomalienübertragungsmechanismus der Firmware widerspiegelt. Ein Thermoelement gewechselt, die Anschlüsse trocknet, 0x04 verschwindet.

Fall 3: Erweiterter E / A-Modul - Ausfall

Der Siemens ET200SP dient als Modbus TCP Server über das Schnittstellenmodul. Ein DI-Modul wurde aufgrund eines schlechten Kontakts des Backplate-Anschlusses abgeschaltet. Für die Registeradresse des Abfallmoduls wird von der Station einheitlich 0x04 zurückgegeben. Die Registeradresse anderer normaler Module wird jedoch normal gelesen. Dies zeigt, dass die Fehlerisolierung vom Inneren der Station gut funktioniert - ein schlechter Stück hat keine Auswirkungen auf die globale Situation.

Fall 4: Analog-Eingangsmodul Überspannungsschutz Trigger

Analog-Eingangsmodul ADAM - 4117 von Renhua, Messbereich 0 ~ 5V. Ein Kanal wurde versehentlich mit einem 12V-Signal verbunden, die Überspannungsschutzschaltung im Modul wurde gestartet und der Kanal ging in den Ausfallzustand. Alle 0x04 - Anfragen zum Lesen des Kanalwertes geben 0x04 zurück, wobei die Konfigurationsdatei ein Fehler-Flag - Position-Bit anzeigt. Entfernen Sie das Überspannungssignal und wiederherstellen Sie den Strom nach dem Einschalten. Die Wurzel dieser 0x04 liegt in der physischen Verdrahtung und nicht in einem Kommunikationsprotokoll. Wenn Sie das Kabel zuerst werfen, dann mit einem analogen Signal testen - aber ich erinnere mich, dass ADAM - 4117 manchmal weich zurücksetzen muss, allein durch das erneute Einschalten reicht nicht aus.

0x05 - Bestätigung (ACK)

0x05 ist kein Fehler. Es ist vom Bahnhof an die Hauptstation zu sagen: „Es ist empfangen, es ist gerade vorhanden, drängen Sie nicht."

Das Standardwort lautet „Acknowledge". Die Slave-Station hat die Anfrage akzeptiert, aber die Verarbeitung dauert länger (z. B. Flash schreiben, Ausführen von Self-Tuning), um eine 0x05 zurückzugeben, um die Master-Station zu wissen, dass die Verbindung nicht unterbrochen ist, und die anschließende Verarbeitung ist abgeschlossen, um das Ergebnis durch eine normale Antwort oder Status-Bit zu teilen.

Dies ist der speziellste der sieben Standard-Ausnahmecodes - es ist der einzige Ausnahmecode, der kein Problem darstellt.

Beispiel-Message

请求:     01 06 0F A0 00 00  — 写寄存器 0x0FA0 = 0x0000，触发参数保存
异常响应:  01 86 05

Fall 1: Parameter-Wandler - Schreiben in EEPROM

Delta VFD-M - Umrichter, Schreiben 0x2000 (Befehlsregister) = 0x0010 Auslöser des "Parameter-Schreibens in EEPROM" - Vorgangs. Der Schreibzyklus von EEPROM beträgt ca. 10 - 30 ms. Wenn Sie einen Befehl von der Station erhalten, gibt es 0x86 + 0x05 zurück, um "Ich weiß, dass Sie Parameter speichern, Flash schreiben wird". Nach ca. 20 ms kann das Befehlregister erneut abfragen und 0x0000 wird gelesen, um das Schreiben abgeschlossen zu sein. Wenn es innerhalb von 50 ms nach 0x05 nicht abgeschlossen ist, werden einige Umrichter überschritten.

Fall 2: Temperature Controller PID Self-Tuning

Omron E5CC, Schreiben 0x0101 (AT Ausführen / Stoppen) = 0x0001 Start Self-Tuning. Dieser Vorgang dauert einige Minuten. E5CC kehrt zuerst 0x05 zurück, dann kann der PV - und SV-Wert normal gelesen werden, nur dass die AT-Flag - Bit ON ist. Nach Abschluss der Einstellung wird AT automatisch ausgeschaltet. Der Host muss den Timeout-Timer starten, nachdem er 0x05 empfangen hat, und nicht warten - manche Geräte können 30 Minuten lang laufen.

Fall 3: Slave-Stationen am Backend des Gateways reagieren langsam

Modbus TCP zu RTU-Gateway (wie MOXA MGate MB3170), Master-Station über das Gateway lesen eine Slave-Station auf einem 9600bps-Blow - Speed-Bus. Die Masterstation hat eine Anforderung zum Lesen von 125 Registeren gesendet, das Gateway leitet diese Anforderung an den RTU-Bus weiter, aber aufgrund der großen Datenmenge und der niedrigen Baudrate braucht die RTU-Slavestation 200 ms +, um die Daten zurückzugeben. Bevor das Gateway eine vollständige RTU-Antwort erhält, gibt es dem TCP-Master eine 0x05 - Reservierung zurück - dies ist die übliche "pending" - Methode für Gateways. Die Modbus-TCP - Spezifikation gibt keine explizite Verwendung von 0x05 in diesem Szenario, aber viele Gateway-Hersteller tun dies.

Ein Design-Detail, das beachtet werden sollte: 0x05 Trigger nach der Warte-Richtlinie auf der Seite der Hauptstation. Die gleiche Anforderung sollte nicht sofort erneut gesendet werden - das würde wiederholte Befehle von der Station erhalten. Die richtige Vorgehensweise ist: ein Statusregister abfragen (wenn es von der Slave-Station bereitgestellt wird) oder einen Timeout-Timer einrichten, der nach Ablauf einen neuen Abfragebefehl ausgibt. Einige SCADA-Treiber (wie der Modbus-Treiber von Kepware) verfügen über eine integrierte Verarbeitungslogik mit 0x05, während andere direkt einen Timeout signalisieren. Wenn Sie selbst einen Modbus-Treiber schreiben, ist die Verarbeitungslogik von 0x05 ein Muss.

0x06 - Von der Station

Die Station ist zu beschäftigt, um Ihre Anfrage zu bearbeiten. Der Befehl wurde akzeptiert, kann aber nicht ausgeführt werden, die Hauptstation sollte es später erneut versuchen.

Der Unterschied zwischen 0x05 und 0x06 ist: 0x05 bedeutet "Empfangen, in Bearbeitung, warten auf das Ergebnis"; 0x06 bedeutet "Jetzt nicht verfügbar, komm später wieder". 0x05 bedeutet, dass der Slave bereits mit der Ausführung begonnen hat, und 0x06 bedeutet, dass der Slave überhaupt nicht mit der Ausführung begonnen hat.

Beispiel für die Nachricht

请求:     01 06 20 00 07 D0  — 写寄存器 0x2000 = 0x07D0(2000)
异常响应:  01 86 06            — 忙，没空处理

Fall 1: Sofort nach dem Schreiben von Parametern lesen

Nach dem Schreiben eines Parameters, das ein EEPROM schreiben muss, wird die nächste Anforderung innerhalb von 10 ms ausgegeben. Der Flash-Controller der Slave-Station hat den Bus noch nicht freigegeben und kehrt direkt zurück zu 0x06. Viele Ingenieure senden im Debugging-Skript eine Anforderung für mehrere Millisekunden kontinuierlich, die von der Station einfach zu spät verarbeitet werden. Nicht die Geräte sind langsam, sondern Sie sind zu schnell. Modbus hat keinen Flusssteuerungsmechanismus, die Masterstation muss ihren eigenen Rhythmus steuern - nach dem Schreiben von Flash-bezogenen Registeren, lassen Sie 30 ~ 50 ms und senden Sie die nächste Lese - und Schreibanforderung.

Fall 2: Hochgeschwindigkeits-Polling verursacht eine Überflutung des niedriggeschwindigkeitsgerätepuffers

Mit Modbus Poll wurde ein 9600bps RTU-Temperatur - Feuchte-Sensor in Abständen von 20ms abfragt. Normal beim Start, eine Minute nach dem Laufen begann intermittierend 0x06 zu erscheinen. 9600 bps Übertragung eines Bytes ca. 1 ms, eine minimale Lesesanfrage + Antwort ca. 30 ~ 40 ms hin und her. Das Abfrageintervall von 20 ms ist bereits kleiner als die minimale Antwortzeitraum des Geräts. Der Empfangspuffer von der Station ist voll, und er ist damit beschäftigt, überflutete Frames zu verwerfen und hat keine Energie, neue Anfragen zu verarbeiten. Das Abfrageintervall sollte auf 100ms angepasst werden. Um 115200bps zu ersetzen, kann die Geschwindigkeit weiter verkürzt werden, aber viele industrielle Steuerungsgeräte unterstützen nur bis zu 38.400bps oder sogar 19.200bps.

Fase 3: Zugriff auf mehrere Master-Stationen gleichzeitig

Modbus RTU Slave Station auf einem RS - 485 - Bus, gleichzeitig verbunden mit PLC und Host-Computer SCADA zwei Master Stationen. Es gibt keine Koordination zwischen den beiden Master-Stationen, die jeweils in 500ms und 300ms Abständen abfragen. Die Kollisionswahrscheinlichkeit steigt - zwei Anforderungsframes überlappen sich, und das von der Station empfangen wird, ist ein Chaoscode. Einige Slave-Stationen werden einen Frame-Fehler ignorieren, nachdem sie erkannt haben, und einige Slave-Stationen werden Zeit für die Fehlerbehandlung verbringen, was dazu führt, dass der Frame der nächsten Master-Station kommt, wenn der Empfangspuffer leer ist. Ich bin noch nicht bereit, neue Frames zu empfangen, kann nur 0x06 zurückkehren. RS - 485 Multi-Master - Station Konfliktbehandlung, empfiehlt es sich, die Hardware-Flow - Steuerung oder gegenseitig ausschließende Sperren auf der Seite der Master-Station zu tun, erwarten Sie nicht, dass die Slave-Station selbst fertig wird.

Fall 4: Anforderung während der Initialisierung von der Station

Die meisten Modbus haben eine Initialisierungszeit von mehreren Dutzend Millisekunden bis zu wenigen Sekunden nach dem Einschalten von der Station. Anforderung in diesem Fenster, die Modbus-Stack von der Station ist noch nicht bereit. Einige von ihnen haben keine Antwort (No Response), andere von der Station haben 0x06 zurückgegeben. Dieses Verhalten hängt mit der spezifischen Firmware-Implementierung zusammen. Der Danfoss VLT FC302 Frequenzumrichter gibt 0x06 innerhalb von etwa 2 Sekunden nach dem Einschalten zurück und kehrt nach Abschluss der Initialisierung wieder normal zurück. Wenn Ihre SCADA-Start - Station liest, können die ersten Anfragen 0x06 erhalten - Sie können 0x06 umgehen, indem Sie einen Power-On - Delay in den Host-Code hinzufügen oder 0x06 automatisch erneut versuchen (bis zu 3 Mal in 500ms).

0x06 und 0x05 können leicht verwechselt werden, hier ist klar: 0x05 bedeutet „Deine Anfrage wird verarbeitet", und die Verarbeitung wird normal zurückgegeben. 0x06 „Es ist keine Zeit, Ihre Anfrage zu bearbeiten, die Anfrage wurde verworfen" Die Masterstation empfängt 0x05 sollte warten, empfängt 0x06 sollte es erneut versuchen. Wenn Sie 0x06 als 0x05 behandeln - Warten warte, warte die Zeitüberschreitung.

0x0A - Der Gateway-Pfad ist nicht verfügbar

Dieser Ausnahmecode erscheint nur in der Gateway-Szene. Die Kommunikation zwischen dem Gateway und dem nachgelagerten Slave-Stationen läuft nicht gut - das Gateway selbst ist in Ordnung, aber das Gerät hinter ihm ist nicht verbunden.

Die Definition des Modbus-Standards lautet „Gateway Path Unavailable" - ein Pfad zum Zielgerät kann nicht erstellt werden. Das Zielgerät ist hier nicht der Slave-Ontologie mit der Adresse 0x01, sondern der "Routing" innerhalb des Gateways zum nachgelagerten Slave-Ontario.

Beispiel für die Nachricht

请求:     01 03 00 00 00 01  — 通过网关读下游从站
异常响应:  01 83 0A            — 网关：后面那个从站没响应

Fall 1: Ableitung von Serial-Server am Backend

USR-N510 Serial-Server ist ein Modbus TCP-in - RTU-Gateway, unten sind 3 Modbus RTU-Sensoren (Adressen 0x01, 0x02 und 0x03) angehängt. 0x02 Von der Station, weil das Strommodul verbrannt ist, vollständig ausgeschaltet. Wenn die Master-Station 0x02 Slave-Station über das Gateway liest, versucht der Serienserver, die Anfrage auf dem RS - 485 - Bus zu übertragen, wartet eine 500ms-Zeitüberschreitung, um die Antwort zu erhalten, und gibt dann 0x0A an die Master-Station auf der TCP-Seite zurück. 0x01 und 0x03 Die Kommunikation zwischen den Slaven-Stationen war völlig normal - das Gateway selbst war am Leben, nur ein Pfad war unterbrochen.

Fall 2: Das Gateway konfiguriert den falschen Downstream-Parameter

MOXA MGate MB3170, der mit 9600bps, 8N1 Downstream konfiguriert ist. Das Gerät auf dem tatsächlichen RS - 485 - Bus beträgt jedoch 19200 bps, 8E1 (Paritätsprüfung). Das Gateway sendet einen Frame nach 9600bps, der von der Station empfangen wird, ist ein Chaoscode und antwortet nicht. 0x0A zurückgegeben, nachdem das Gateway Zeitüberschreiten. Dieses Problem ist besonders häufig auf mehreren Geräten gemischt RS - 485 - Bus - die Standardkommunikationsparameter von verschiedenen Herstellern sind nicht identisch, die Anfangsphase des Projekts nicht einheitlich zu tun, wird eine Grube treten.

Fall 3: Modbus TCP Kaskaden-Gateway

Ein großes verteiltes Szenario: Zentrales SCADA → Modbus TCP Master Gateway → Glasfaserringnetz → Lokal-Sub - Gateway → RS - 485 - Slave-Station. Die Glasfaser zwischen dem Primär-Gateway und dem Sub-Gateway ist unterbrochen, und alle Anfragen des Primär-Gateways an die Slave-Stationen unter dem Sub-Gateway geben 0x0A zurück. Zu diesem Zeitpunkt ist die Idee der Prüfung Stufe-für-Stufe - Ping: Zuerst bestätigen Sie die TCP-Verbindung des Primär-Gateways zum Unter-Gateway, dann bestätigen Sie das Unter-Gateway zum RS - 485 - Bus und schließlich das serielle Portgerät selbst.

Hersteller benutzerdefinierte Ausnahmecodes

Zusätzlich zu den sieben Standard-Ausnahmecodes definieren viele Hersteller private Ausnahmecodes im Bereich 0x80 ~ 0xFF. Das ist kein Standardverstoß - die Modbus-Spezifikation erlaubt es Anbietern, es zu skalieren. Wenn der Code nur 01 bis 0A erkennt, wird bei 0x90 eine "Unbekannte Ausnahme" gemeldet oder die Frames verliert.

Einige gängige Herstellererweiterungen:

Diese Ausnahmecodes haben keine einheitlichen Standards, müssen Sie jedes Handbuch durchlaufen. Einige Hersteller werden im Modbus-Kommunikations - Abschnitt des Handbuchs eine vollständige Ausnahme-Liste auflisten, einige werden im Anhang versteckt, andere werden einfach nicht geschrieben - man kann es nur debuggen, wenn man es erwischt hat.

Es gibt einen Schlupf: Einige inländische SPS werden auch 0x03 zurückgeben, wenn sie 0x02 - Bedingungen treffen (ohne Unterscheidung zwischen illegalen Adressen und illegalen Datenwerten), da ihre interne Ausnahmebehandlung "Adresse nicht vorhanden" und "Wert illegal" als die gleiche Fehlerroute bezeichnet. Sie erwarten, dass es 0x02 ist, aber Sie erhalten 0x03 - nicht wahr, schauen Sie einfach in der Registermap-Tabelle des Handbuchs.

Es gibt noch eine weitere, die leicht übersehen werden kann: Das Verhalten von Ausnahmecodes im CPU-Ausfallmodus. Viele SPSs führen den Modbus-Protokollstack im STOP-Zustand aus, verhalten sich jedoch anders. Beim Modbus-Server von Siemens S7-1200 wechselte die CPU von RUN zu STOP und ließ den zugeordneten DB-Block 0x04 ("Device Failure") anstatt 0x01 zurückgeben. Die Semantik ist subtil - die PLC ist nicht kaputt, aber die DB-Daten sind im STOP-Modus nicht verfügbar. Im STOP-Zustand reagiert der Schneider M221 weiterhin auf Modbus-Anfragen, nur dass die Daten nicht aktualisiert werden. Mit Mitsubishi FX5U Modbus Server, antwortet STOP-Zustand nicht direkt auf jede Anforderung, der Host-Computer sieht eine Zeitüberschreitung, nicht Ausnahme-Code. Das gleiche SCADA-System, um das STOP-Verhalten von verschiedenen PLC-Marken anzupassen, muss die Antriebsebene differenziert behandelt werden.

Herstellererweiterte Ausnahmecodes werden häufig auch in Sicherheitsszenarien verwendet. Einige Gateway-Geräte, die Modbus Security (TLS-basiert) unterstützen, geben zum Beispiel benutzerdefinierte Ausnahmecodes 0xE0 ~ 0xEF zurück, wenn die Authentifizierung fehlschlägt, um eine Ablehnung der Sicherheitsschicht zu bedeuten. Dies ist nicht im Modbus-Standard definiert, aber es gibt es. Wenn Ihre Modbus-TCP - Kommunikation plötzlich anfängt, 0xE1 zu empfangen, ist es nicht der Fehler des Protokollstacks, sondern das Gateway, das Ihnen sagt, dass der TLS-Handshake nicht überstanden ist.

Ausnahmeframe mit Wireshark

Wireshark kann das Modbus-Protokoll unabhängig von RTU oder TCP direkt analysieren. Voraussetzung ist, dass Sie sich im richtigen Netzwerk befinden.

TCP-Szenario

Wenn Modbus TCP den Port 502 verwendet, wird es von Wireshark standardmäßig aufgelöst. Geben Sie `modbus` in die Filterleiste ein, und der Ausnahmerahmen wird als roter Hintergrund angezeigt.

Erweitern Sie den Ausnahme-Reaktion - Frame und schauen Sie sich diese wichtigen Felder an:

Modbus/TCP
  Transaction Identifier: 1
  Protocol Identifier: 0
  Length: 3               ← 注意这个长度
  Unit Identifier: 1
Modbus
  Function Code: 131 (0x83)  ← 83 = 03 | 0x80，Wireshark 直接显示了
  Exception Code: 2 (Illegal Data Address)

`Length: 3` ist das Längefeld im MBAP-Header, es ist = Unit Identifier (1) + Function Code (1) + Exception Code (1) = 3 Bytes. Normalerweise ist dieser Wert größer (da es Daten gibt). Nur die Länge kann vorläufig feststellen, ob es sich um eine Ausnahme - oder normale Antwort handelt - die TCP-Lastlast einer Ausnahmeantwort beträgt normalerweise nur 3 Byte.

RTU-Szenario

Für RTU-Frapping - Pakete ist ein Monitoring-Knoten mit einem RS - 485 - USB-Adapter erforderlich. Wireshark unterstützt RTUs nicht so gut wie TCP und erfordert eine manuelle Angabe der Portkonfiguration (Baudrate, Verifikation usw.). Das gefangenene Ausnahme-Frame - Format ist ähnlich wie TCP, aber ohne MBAP-Header:

01 83 02 xx xx  — 地址 01，功能码 83，异常码 02，CRC xx xx

Das RTU-Grabpaket hat keine Transaktions-ID, Sie können nur den Zeitstempel verwenden, um die Korrespondenz zwischen Anforderung und Antwort zu bestimmen. Beim Debuggen eines komplexen Multi-Slaven - RTU-Buses empfiehlt es sich, in Wireshark nach Modbus-Adresse zu filtern, um den Traffic von jedem Slave-Station getrennt zu betrachten.

Der Modbus-Parser von Wireshark unterstützt ab Version 3.x die chinesische Anzeige von Ausnahmecodes. Wählen Sie unter Preferences → Protocols → Modbus die Ausnahme-Option. Hinweis: Wireshark kann nur die Standard-Ausnahmecodes 01 bis 0A analysieren, und Hersteller-definierte Codes zeigen Zahlen anstatt Beschreibungstext an.

Ein weiterer Wireshark-Tipp: Verwenden Sie `modbus.exception _ code` für einen Anzeigefilter. modbus.exception_code = = 2 `Filtert alle 0x02 - Ausnahme-Frames aus.` modbus.exception_code > = 1 & & & modbus.exception_code < = 10 `Filtern Sie alle Standard-Ausnahmen. Wenn Sie sich die globalen Statistiken ansehen - Statistics → Protocol Hierarchy → Modbus, können Sie den Prozentsatz der abnormalen Frames am Gesamtverkehr sehen. Wenn ungewöhnliche Frames mehr als 10% betragen, gibt es eine hohe Wahrscheinlichkeit, dass Ihre Konfiguration ein Problem hat. Wenn es nur gelegentliche 0x06 gibt, ist das ein zeitungsproblem. Wenn 0x04 andauert, bereiten Sie das Gerät aus.

Ungewöhnliche Hinweise in der Modbus Poll

Modbus Poll ist das am häufigsten verwendete Debugger-Tool. Seine Ausnahme-Informationen werden direkt in der Statusleiste am unteren Rand des Fensters angezeigt, wie folgt:

Modbus Exception Response
Function: 3, Exception: 2 (Illegal Data Address)

Wenn Sie auf den ersten Blick das rote Zeichen sehen, nicht in Panik, sehen Sie zuerst, was Function ist, und dann sehen Sie, was Exception ist. Der Funktionscode sagt Ihnen, welcher Vorgang fehlerhaft war, und der Ausnahmecode sagt Ihnen, warum.

Öffnen Sie Display → Kommunikation, um die vollständige Nachricht zu sehen. Ausnahme-Frame mit rot markiert, klicken Sie auf die ursprüngliche Hexadezimalzahl:

Tx: 01 03 00 00 00 01 84 0A
Rx: 01 83 02 C0 F1

Das zweite Byte von `Rx` ist 0x83 (= 0x03| 0x80), das dritte Byte 0x02 ist ein Ausnahmecode. C0F1 steht für CRC. Modbus Poll hilft Ihnen dabei, das zu analysieren, aber es ist eine grundlegende Fähigkeit, die ursprünglichen Frames selbst zu betrachten - Sie haben die Modbus Poll nicht immer verfügbar, wenn Sie online bereitstellen.

Die gleiche Anforderung meldet 0x02, ändern Sie die Adresse nicht, bestätigen Sie zuerst, ob Ihre Startadresse und die Anzahl im gültigen Bereich im Handbuch der Slave Station aufgeführt sind. Oftmals ist es die Logik der Adresse falsch, nicht die Adresse falsch geschrieben wurde. Besonders beim Wechsel von einer 1 - basierten Registeradresse zu einer 0 - basierten PDU-Adresse - eine Grube, die fast jeder Neuling einmal betreten muss.

Debugging-Methode: Checkliste nach Erhalt eines Ausnahmecodes

Die Szene der Ausnahme-Code, folgen Sie der folgenden Reihenfolge - nicht der Standard-Betriebsfluss, ist die Erfahrung des alten Ingenieurs Blut und Tränen.

* * Erster Schritt: Bestimmen Sie, welcher Slave, welcher Funktionscode, welcher Ausnahmecode * *

In der Regel gibt es mehr als eine Station. Mit Modbus Poll oder Wireshark greifen Sie die ursprüngliche Nachricht und erhalten Sie die drei Zahlen von der Station-Adresse + Funktionscode + Ausnahmecode. Wenn Sie das Skript verwenden, fügen Sie eine Zeile `print(hex(response[0]), hex(response[1]), hex(response[2]))` hinzu und schauen Sie nicht nur auf „Kommunikationsfehler" im Protokoll.

* * Schritt 2: Klassifizierung von Ausnahmecodes - Software - oder Hardware-Ursache? * *

0x01 / 0x02 / 0x03 Wahrscheinlich gibt es ein Problem mit Ihrer Anfrage.Überprüfen Sie die Konfiguration, die Adresskarte, den Datenabschnitt. 0x04 / 0x0A Wahrscheinlich gibt es ein Problem mit der Station oder der Links. Versuchen Sie, den Strom auszuschalten und die Station neu zu starten - wenn 0x04 normal ist, bedeutet dies, dass das Gerät eine interne Fehlerwiederherstellung ist, aber nicht, dass die Ursache gelöst wurde. 0x06 ist ein Problem mit der Zeitreihenfolge, das das Abfrageintervall verlangsamt.

* * Schritt 3: Isolieren von Variablen * *

Versuchen Sie es mit einer anderen Slave-Adresse auf der gleichen Master-Station. Die Kommunikation kann von der Station aus gelöst werden. Kann nicht kommunizieren → Problem am Hauptplatz oder am Bus. Probieren Sie die gleiche Adresse mit Modbus Poll aus. Es gibt ein Problem mit Ihrem Code. Kann nicht kommunizieren → Problem von der Station oder der Verbindung. Dies ist die am häufigsten verwendete Dichotomierung, aber viele Leute überspringen diesen Schritt und vermuten direkt, dass die Hardware defekt ist.

* * Schritt 4: Betrachten Sie das Handbuch * *

Der Ausnahmecode kommt aus dem Modbus-Kommunikations - Abschnitt des Station-Handbuchs. Einige Anbieter werden alle Ausnahmecodes und Auslöser auflisten, die möglicherweise zurückgegeben werden. Wenn das Handbuch keine Ausnahme-Code - Tabelle hat, suchen Sie nach der Adress-Zuordnung Tabelle und überprüfen Sie manuell, ob Ihre angeforderte Adresse im gültigen Bereich liegt. Viele der „Kommunikationsfehler" auf der Website sind in Wirklichkeit, dass Sie eine Reservierung Adresse lesen oder nur eine Adresse schreiben.

* * Schritt 5: Paket erfassen * *

Erfassen Sie die ursprüngliche Nachricht mit Wireshark oder einem seriellen Portüberwachungstool. Und was hat die Hauptstation eigentlich gemacht? Was antwortet man vom Bahnhof? Gibt es CRC-Fehler? Gibt es einen unvollständigen Rahmen? Viele Male schauen Sie sich die Logs an und denken, dass es 01 03 00 00 00 01 ausgeschickt wurde, und tatsächlich fangen Sie das Paket, um festzustellen, dass die Porter-Rate falsch warf von der Station, wenn der Lärm warf. Vertrauen Sie nicht Ihrem Code-Log, vertrauen Sie dem Grab-Tool.

* * Schritt 6: Ersetztests * *

Ersetzen Sie ein neues Gerät des gleichen Modells von der Station, die gleiche Anfrage, um das Ergebnis zu sehen. Wenn das neue Gerät normal ist, gibt das ursprüngliche Gerät einen Ausnahmecode zurück - Hardwarefehler des Geräts. Wenn das neue Gerät denselben Ausnahmecode zurückgibt - es gibt ein Problem mit Ihrer Anfrage. Wenn Sie keine Ersatzgeräte zur Verfügung haben, ersetzen Sie eine Adresse der Slave-Station, die normal funktioniert, um die Kommunikationsverbindung zu messen. Der Verdacht auf die Links ist ausgeschlossen, das Problem liegt auf dem spezifischen Gerät.

*

S enden Sie die urspr üng liche Nach richt (he x ade c imal), das Mod ell und die Fir m ware - Ver sion der Sla ve - Station und die Informationen zur Master - Station - Pla tt form an die FA E des Sla ve - Station - Hersteller s . Vers enden Sie keine Screen sh ots des Protokoll s , sondern eine urspr üng liche Nach richt - FA E scha ut auf die urspr üng liche Nach richt viel gena uer als auf Ihre Besch reib ung . Wenn die FA E nicht zurück kom mt ,modbus.cnDas Forum hat die urspr üng liche Nach richt um Hilfe geb eten Die De bu gging - Er fahr ung der Gemeinschaft ist manch mal noch zu ver lä s si ger als das Hand buch des Hersteller s , weil das Hand buch The orie ist und die Gemeinschaft Blut und Tr änen ist .

* * Zusatz: Vorlage zur Ausnahmebehandlung beim Schreiben von Modbus-Treiber * *

Wenn Sie einen Modbus-Hoster - Treiber schreiben (mit C/Python/Node.js usw.), sollte die Ausnahmeframe-Handhabung mindestens diese Fälle abdecken:

1.Überprüfen Sie, ob das erste Byte der Antwort der angeforderten Slave-Adresse entspricht (Adresse nicht übereinstimmt = keine Antwort für Sie, verworfen) 2. Ob Bit 7 des Funktionscodes 1 ist (1 wird der Ausnahmecode extrahiert, 0 wird der Datenbereich normal analysiert) 3. 0x05 Sonderbehandlung: Keine Ausnahme auswerfen, in den Wartezustand gehen, Statusregister abfragen oder Timeout erneut senden 4. 0x06 Sonderbehandlung: Verspätung von 50 ~ 100 ms erneut, maximal 3 mal erneut 5. Weitere Ausnahmecodes: Protokollierung, Benachrichtigung der höheren Ebene für die Fehlerbehandlung (Warnung, erneuter Versuch, Wechsel des Alternativverbindens usw.) 6. 0x80 ~ 0xFF: Benötigt ein Wörterbuch für das Gerätmodell, sonst drücken Sie Unbekannte Ausnahme.

Der Fehler besteht darin, alle Ausnahmecodes als "Kommunikationsfehler" zu behandeln und es erneut zu versuchen - 0x02 Zehntausendmal erneut zu versuchen ist auch 0x02, eine falsche Adresse ist falsch. Die richtige Praxis besteht darin, unterschiedliche Strategien basierend auf der Klassifikation von Ausnahmecodes zu verfolgen. Wenn diese Logik gut geschrieben ist, kann Ihr Laufwerk 90% der Modbus-Sklavenanlagen auf dem Markt passen. Die restlichen 10% sind Hersteller, die keine Ausnahme-Codes zurückgeben - sie ersetzen die Ausnahme-Antworten durch normale Antworten und stecken Fehlermeldungen in die Registerdaten. Bei solchen Geräten kann nur ein spezielles Handbuch durchlaufen.

Ungewöhnliche Schnelligkeit

Diese Tabelle wird empfohlen, sie neben dem Debugger-Computer auszudrucken. Auf der Szene kommt der ungewöhnliche Code nicht brauchen, um das Handy zu suchen, einen Blick auf die Uhr, um die ungefährliche Richtung zu kennen. Die spezifische Diagnose Methode, zurück zu jedem Fall von Ausnahmecodes oben zu suchen - alle Fälle sind vor Ort berührt, nicht erfunden.