Modbus異常コード完全診断マニュアル：7つの標準異常コードと26の実際のエンジニアリングケース

異常フレームとは？

Modbusの例外応答と通常応答のdifferenceは1桁だけです。マスターステーションが要求を発行した後、スレーブステーションは機能コードの最高位置を1に置き、その後にシングルバイトの例外コードが続き、フレームが終了します。データエリアがない。

通常フレームと異常フレームの比較：

を要求     0 1 0 3 0 0 0 0 0 0 0 1-ステーション1を読み取り、レジスタ0 x 0000を保持
通常の応答01 03 02 12 34    - 0 2 =データバイト数、0 x 1234=読み返された値
例外応答01 83 02          - 83= 0 × 0 3| 0 x 80，0 2 =例外コード0 x 0 2

上の例では、関数コード0 x 0 3の最上位位置 1は0 x 83になります。例外コード0 x 0 2は“不正なデータアドレス”を表し、0 x 0000アドレスがスレーブにexistenceしないことを示します。

CRCチェックを詳しく見る：通常または異常応答にかかわらず、CRCは局のアドレスから（CRC自体を除く）最後のデータバイトまでカウントされます。CRCは意図的に書かなかったので、フレームの最後には2バイトがあります。

RTUとTCPの例外フレームには違いがあり、違いはカプセル化層にあります。TCPのMBAPヘッダには、ユニット識別子+機能コード+例外コードを含む2バイトの長さフィールドがあります。RTUは3.5文字の沈黙時間でフレームを分割する。プロトコル層は異なりますが、関数コードと例外コードのセマンティクスはまったく同じです。Modbusの最もクリーンな設計の1つです。

無視しがちなもう一つの詳細は、例外応答のフレーム長が固定されています。関数コード0 x 0 1 ~ 0 x 0 6の場合、例外応答は常に3バイト（アドレス+関数コード）です。|0 x 80 +例外コード）、CRCは別のもの。0 x 0Fや0 x 10のようなマルチオペレーショナルファンクションコードでは、例外応答も3バイトです。スレーブは“どの部分が間違っているか”を伝える必要はなく、“リクエスト全体が拒否されました”と伝えるだけです。この設計は粗野ですが、非常にシンプルです。マスターステーションは例外コードを受信した後、再試行またはエラーを報告します。

シリアルレベルでのタイミングも重要です。Modbus RTUでは、スレーブはリクエストを受信してから指定された時間内に応答を開始しなければならないが、規格はこの時間の正確な値を規定していない。実際には、ほとんどのスレーブの応答時間は5 - 50msです。応答が1 秒以上受信されない（または例外フレームが受信されない）場合、マスターステーションはスレーブが応答していないとみなす必要があります。これは例外コードではなくタイムアウトです。多くの産業用ソフトウェアは“No Response”と“Exception Response”を混ぜて報告し、デバイスが異常コードを返したような錯覚を与えます。駅からは何も戻ってこない。この2つの状況を区別することは、問題のトラブルシューティングに不可欠です。応答がない場合はリンク層またはデバイス層の問題であり、例外コードはスレーブアプリケーション層が“受信しましたが、実行しませんでした”と伝えます。

以下は7つの標準異常コードの分解です。Wiresharkシミュレーションではなく、生産ライン、変電所、ポンプハウスで実際に遭遇した実際のメッセージと現場のケースが付属しています。

0 x 0 1-不正な機能コード

マスターが要求した機能コードをスレーブがサポートしていないか、スレーブが現在の状態で無効になっている場合。

0 3/0 6/16をサポートする標準Modbusデバイスに0 x 0 8診断機能コードを送信すると、0 x 0 1が受信されます。診断関数コードはオプションであるため、多くの安価なI/Oモジュールは実装されていません。

メッセージの例

を要求     0 2 0 8 0 0 0 AA 55
異常応答02 88 01

0 x 0 8 =診断、サブコード0 x 0000 =ループバックテスト、データ0 x AA 55。ステーションから直接0x88 ~ 0x08に戻る|0x80 + 0x01.

ケース1：デルタDVPシリーズPLCが診断機能コードをサポートしていない

デルタDVP-SX2シリーズ、ファームウェアバージョンV3.8。プロジェクトでは、RS-485回線品質テストを行い、Modbus Pollのテストセンターで0 x 0 8診断を行い、結果は異常コード0 x 0 1を返しました。DVPのマニュアルを読んで確認してください：DVPは0 1/03/05/0 6/0F/10の6つの機能コードしか実装しておらず、0 x 0 8はその列にはありません。ライン品質を診断するには、応答時間と連続成功率によって間接的に判断する0 x 0 1リードコイルまたは0 x 0 3リードレジスタのみを使用します。このことから、診断関数コードはModbus規格に書かれていますが、すべてのベンダーが購入していません。

ケース2：Siemens S 7 -1200はModbusサーバでリードコイルをサポートしません。

Siemens S 7 -1200は、TIA Portal V 14からModbus TCP Serverをサポートしている。しかし、実装はDBブロックをホールドレジスタ（0 x 0 3/0 x 0 6/0 x 10）にマッピングするだけで、コイル0 x 0 10 x 0 5/0 x 0Fはマッピングしません。ホストコンピュータとデバッグすると、SCADAはデバイスステータスワードを読み取るために0 x 0 1を使用し、S 7 -1200は0 x 81 + 0 x 0 1を直接送り返します。解決策：コイルアドレスを保持レジスタセクションにマップし、ホストコンピュータは0 x 0 3読み取りに切り替えます。

ケース3：インバータ動作中のパラメータ書き込み禁止

Edituan MD 500インバータは、0 x 0 6の書き込み周波数でレジスタ0 x 2000を実行してみてください。0 x 0 1を返す。周波数コンバータが0 x 0 6機能コードをサポートしていないのではなく、現在の状態は書き込みができません。Edituanのマニュアルではこれを“Running Undo Write”と呼んでいるが、プロトコル層は標準例外コード0 x 0 1を使用する。このセマンティック拡張は、標準例外コードを使用してメーカー定義の制限を表現する多くの国内デバイスで見られます。

ケース4：Modbus Plus固有の機能コードがTCPゲートウェイで拒否される

BM85ブリッジを介してModbus PlusからModbus TCPへの変換を行う古いModicon Quantum PLC。Modbus Plusには独自の拡張機能コード（ネットワーク管理用の0 x 14~ 0 x 18）がありますが、BM85ブリッジは標準のModbus機能コードのみを透過します。ホストコンピュータが誤ってPLC統計情報を読み取るために0 x 14要求を発行し、ブリッジはアプリケーション層チェック後に0 x 81+ 0 x 0 1を直接返します。例外コードを返すのはPLCではなくゲートウェイです。PLCは0 x 14をサポートしますが、ゲートウェイはサポートしません。ブリッジログにはこの関数コードのParseルートがなく、直接拒否されました。ゲートウェイが機能コードのセキュリティフィルタリングを行う状況は、特にファイアウォール機能を備えた産業用ルータでは、実際のプロジェクトでは一般的です。

0 x 0 2-不正なデータアドレス

スレーブはこの機能コードをサポートしていますが、要求された開始アドレス+数がスレーブの有効なアドレス範囲を超えています。これは、フィールドデバッグで遭遇した最も多くの例外コードの1つです。

キーポイント：マスターソフトウェアに入力されたアドレスとプロトコル層が実際に送信したアドレスはオフセットです。Modbusプロトコルでは、アドレスは0から番号付けされる。Modbus Pollに40001（1ベースの保持レジスタ）を入力すると、プロトコル層は0 x 0000を発行します。アドレス計算ロジックが反転し、ライトは間違ったデータを読み取り、ライトは0 x 0 2をトリガーします。

PLC/アドレス表示   40001 1-based、保持レジスタ
プロトコル层アドレス      0x0000 0-based

メッセージの例

を要求     0 1 0 3 0 0 6 4 0 0 0 A-読み取り0 x 0 0 64 = 4001 01、読み取り10個
例外応答01 83 02

スレーブの有効な保持レジスタ範囲は40001から40090（すなわちPDUアドレス0 x 0000から0 x 0 0 59）であり、要求の開始アドレス0 x 0 0 64は直接0 x 0 2を超えている。

ケース1 Schneider TM3拡張モジュールのアドレスが不十分

シュナイダーモディコンM221はTM3拡張機能を2つ搭載している。構成は、No.1ブロックTM3 DI16が% IW0 〜 % IW1を占め、No.2ブロックTM3 AI4が% IW2 〜 % IW5を占める。上位SCADAは% IW10を0 x 0 4（読み取り入力レジスタ）で読み取り、スレーブは0 x 0 2を返します。その理由は単純です。M 221は% IW0 ~ % IW5のみを割り当て、% IW10は物理 I/Oマップにはありません。SoMachineでI/Oマッピングテーブルを見てください。この問題は、プロトコルの欠陥ではなく、構成と実際のハードウェアの不一致です。

ケース2：Modbus Pollアドレス40001と400001の穴

初心者のエンジニアがModbus Pollを使ってコピーしたアドレスは40001で、Modbus Pollは実際に0 x 0000を発行し、デバイスの最初の保持レジスタを読み取ります。しかし、その後、別の国内構成ソフトウェアを変更し、ソフトウェアは40001を4000 + 1オフセットにParseし、実際には0 x 0FA0を発行しました。スレーブにはレジスタがなく、0 x 0 2が返されます。同じポイントテーブル、同じスレーブステーション、異なるマスターソフトウェアアドレス規約は同じではなく、結果は異なります。これはModbusプロトコルの問題ではなく、ツールチェーンが異なるプロトコルをプレイすることによるものです。PDUアドレス（0ベース）を使用して同僚と直接通信することをお勧めします。ゾーン4とゾーン5は言うまでもなく、それはすべてModiconの古い黄色のカレンダーです。

ケース3：複数のレジスタを読み込むときに末尾アドレスが範囲外に出る

Modbusメーターは、レジスタ0 x 0000~ 0 x 0 0 3 F（64レジスタ）を保持します。プライマリ局は0 x 0 0 3 8から10個のレジスタ（0 x 0 0 3 8 ~ 0 x 0 0 41）の読み取りを要求します。ステーションからチェックする：最後のアドレス0 x 0 0 3 8 + 9 = 0 x 0 0 41 0 x 0 0 3 F、0 x 0 2を直接投げます。アドレスの正当性チェックを行う多くのスレーブは、最初に開始+ Quantityが範囲内であるかどうかを計算し、いずれかのアドレスが範囲外である限り、パケット全体を拒否します。一部のデータを返すレジスタの範囲外ではなく、Modbus規格には部分応答の概念はない。

ケース4：離散入力とコイルアドレスの難読化

このピットは、Modiconの古い5ビットアドレスマークを使用する企業では特に一般的です。1 xxxxは離散入力（読み取り専用ビット）、0 xxxxはコイル（読み取り専用ビット）です。ホストコンピュータ構成は、デバイスステータスを読み取るためにアドレス10001を設定しますが、実際にはスレーブステーションはコイル領域にデバイスステータスを配置します（0 xxxxは0 x 0 1機能コードに対応します）。ホストコンピュータは0 x 0 2（読み取り離散入力）を使用してアドレス0 x 0000を要求し、ステーション0 x 0000は離散入力領域にexistenceしません。離散入力は合計8つあります（アドレス0 x 0000 〜 0 x 0 0 0 7）が、8つのルートは他のDIに割り当てられています。ステーションから0 x 0 2に戻ります。関数コードやアドレスを変更することはできますが、スレーブのアドレスマップテーブルがどのように見えるかを知っている場合に限ります。多くの産業制御エンジニアは、すべてのディスクリート信号をコイル領域に直接マッピングするか、ホールドレジスタに完全にマッピングするため、ユーザーの混乱を避けることができますが、それは手元にあるスレーブステーションがそれを許可する場合に限ります。

0 x 0 3-不正なデータ値

アドレスは有効で機能コードは有効ですが、リクエストボディ内のデータ値は許容範囲外です。

これは簡単に無視できる例外コードです。多くの場合、アドレス設定が間違っていると疑うかもしれませんが、実際には範囲外の値を書き込みます。

メッセージの例

を要求     0 1 0 6 0 0 10 FF FF-アドレス0 x 0 010、値0 x FFFFの単一レジスタに書き込む
例外応答01 86 03            - 機能コード0 x 0 6| 0 x 80 = 0 x 86、例外コード0 x 0 3

なぜ0 x FFFF（655 3 5）は違法ですか？そのレジスタは0 〜 10000の工程値范囲だからです。655 3 5は16ビット表現では合法だが、ビジネスロジックでは合法ではない。

ケース1：EEPROMパラメータが設定範囲外に書き込まれる

オムロンE 5 CCサーモスタット、レジスタ0 x 0 103（PIDスケールバンド）。このパラメータの有効範囲は0.1~999.9で、0.1°C単位で格納されます。つまり、レジスタ値は1~9999です。上位マシンは0 x 0000（すなわち0.0°C）を発行し、ステーション検証後に値が下限 1未満であることがわかり、0 x 0 3を返します。マニュアルには範囲がありますが、上位コンピュータのコードには境界チェックがありません。30分後、オーバーレンジを書くことがわかりました。誰もが犯す低レベルの間違いです。例外コードを見る前にマニュアルを読むことを忘れないでください。

ケース2：読み取り専用レジスタへの書き込み

ABB ACS 58 0インバータ、レジスタ0 x 2104（実回転速度フィードバック、読み取り専用）。マスターコンピュータは1500を0 x 0 6で書き込もうとし（手動で回転速度を与えたい）、ステーションから0 x 0 3を返します。0 x 2104このアドレスはexistenceし、関数コード0 x 0 6もサポートされていますが、スレーブ内部では読み取り専用としてマークされます。ここでの“不正なデータ値”とは、“書き込みを受け付けないアドレスにデータを書き込んだ”という意味です。値自体が違法ではなく、書き込みが違法です。Modbusプロトコルでは、0 x 0 3は“Value is not allowed”と呼ばれ、スレーブに実装の自由度を与えている。多くのベンダーは読み取り専用保護を0 x 03に分類している。

ケース3：マルチレジスタ書き込み-一部のフィールド値が不正です。

5つのレジスタを0 x 10で一括して書き込むと、最初の4つの値は問題なく、5番目のレジスタは0~100の値を要求し、200を書き込みます。一部のスレーブは応答する前にすべてのデータを検証し、5つは完全に合法的に実行され、いずれかが違法であれば0 x 0 3を返すことを拒否します。一部のスレーブは1つずつチェックし、最初のものが違法であることを拒否します。規範はどのような方法で行うべきかを言わず、達成はそれぞれ異なります。使用する機器の境界テストを行うことをお勧めします。

ケース4：Modbusメーターのデマンドリセットレジスタ権限制御

Schneider PM800シリーズパワーメータ、レジスタ0 x 2 F 0 1（デマンドリセットコマンド）は、制御ワードの特定の組み合わせ（0 x 1234または0 x 56 78）のみを書き込むことができます。マスターコンピュータは0 x 0001を誤って書き込み、メーターは0 x 03を返します。マニュアルでは、リセットコマンドレジスタの有効な値は0 x 1234と0 x 56 78であり、それ以外の値は0 x 03をトリガーすると明記されています。この設計は誤動作を防ぐためです。結局のところ、一部のレジスタが間違って書き込まれても、エラーを報告するほど簡単ではなく、実際にパラメータを変更します。

関数コード0 x 0 6が単一のレジスタに書き込まれた場合、レジスタが32ビット値の下位16ビットで、下位16ビットのみが書き込まれ、上位16ビットが初期化されていない場合、スレーブは0 x 0 3を返す可能性がある。例えば、AB ACS580の引数0 x 1000（32ビット浮動小数点）では、2つのレジスタを2つの0 x 0 6に分割することはできません。別々に書き込むと、スレーブは最初の0 x 0 6で0 x 0 3を報告します。これはアドレスが32ビットアライメントされており、16ビットの書き込みを受け付けないことを知っているためです。

0 x 04 -スレーブデバイスの障害

スレーブが要求を処理中に回復不能な内部エラーが発生し、コマンドを実行できなくなりました。この例外コードは、“あなたの要求に問題があるのではなく、私が壊れている”と伝えます。

0 x 0 4はシーンで最もストレスの多い異常コードです。0 x 0 1 ~ 0 x 0 3設定を変更すれば解決できますが、0 x 0 4はワークショップではしごを登る必要があります。

メッセージの例

を要求     0 3 0 3 0 0 20 0 0 4 - 4つの保持レジスタを読み込む
例外レスポンス03 83 04

10分前に正常にデータを返した同じリクエストは、0 x 0 4を返し続けています。ハードウェア障害の可能性が高い。

ケース1：ModbusセンサのEEPROM書き込み失敗

Kunlun Coast JWSK-6温湿度トランスミッタ、Modbus RTUインタフェース。デバイスアドレスをリモートで0 x 0 1から0 x 0 5に変更すると、EEPROMの書き込み中に電源がジッタしました。書き込みが失敗し、デバイスのファームウェアがEEPROMチェックサムの不一致を検出し、fail-safeモードに入ります。その後、すべての関数コードリクエスト（読み取り0 x 0 3または書き込み0 x 0 6）は0 x 0 4を返します。マニュアルを確認してください：EEPROMセルフテストに失敗した後、センサはCommunicationをロックし、物理的な電源オフと再起動のみが工場出荷時設定に復元できます。これはファームウェア保護メカニズムであり、間違った値を読み取るよりもはるかに優れています。

ケース2：サーモスタットプローブ短絡によるAD変換異常

RKC CB100サーモスタット、熱電対入力が端子からの入水により短絡しています。AD変換チップはオーバーフロー値を読み取り、ファームウェアはセンサー障害を判定し、PV値を読み取る0 x 0 3要求はすべて0 x 0 4を返します。この0 x 0 4はModbus Communicationチップの不良ではなく、ファームウェアの異常伝達メカニズムを介してプロトコル層に反映されたセンサフロントエンドの障害です。熱電対を交換し、端子を乾かし、0 x 0 4が消えました。

ケース3拡張I/Oモジュールが切断されます

Siemens ET200SPはModbus TCPサーバとしてインタフェースモジュールを使用する。バックプレーンコネクタの接触不良によりDIモジュールが切断されました。スレーブ局は、ドロップモジュールのレジスタアドレスに対して0 x 0 4を一意に返します。しかし、他の正常モジュールのレジスタアドレスは正常に読み取られます。これは、ステーション内からの障害分離がうまく機能していることを示します。

ケース4：アナログ入力モジュールの過電圧保護トリガ

ADAM-41 17アナログ入力モジュール、範囲は0~ 5 Vです。チャネルが誤って12V 信号に接続され、モジュール内の過電圧保護回路が起動し、チャネルが障害状態になります。このチャンネル値を読み取るすべての0 x 0 4リクエストは0 x 0 4を返し、設定ファイルはエラーフラグ位置ビットを表示します。過電圧信号を抜き、再起動します。この0 x 0 4のルートは物理配線にあり、Communicationプロトコルではありません。トラブルシューティングでは、最初にラインをダンプしてからシミュレーション信号をテストしますが、ADAM-4117はソフトリセットが必要で、再起動だけでは不十分なことがあります。

0 x 0 5-確認応答（ACK）

0 x 0 5はエラーです。それは駅から駅に向かって言った。“はい、やっています。先に急ぐな。

標準的な表現は“Acknowledge”。スレーブはリクエストを受け入れましたが、処理に時間がかかります（Flashへの書き込み、セルフチューニングの実行など）。最初に0 x 0 5に戻り、マスターに接続が切断されていないことを知らせ、その後の処理が完了した後、通常の応答またはステータスビットを介して結果を通知します。

これは7つの標準例外コードの中で最も特殊なものであり、問題を示さない唯一の例外コードです。

メッセージの例

を要求     0 1 0 6 0F A 0 0 0 0 0-書き込みレジスタ0 x 0FA0 = 0 x 0000，トリガパラメータ保存
異常応答01 86 05

ケース1：インバータパラメータをEEPROMに書き込む

デルタVFD-Mコンバータ、書き込み0 x 2000（コマンドレジスタ）= 0 x 0 010は、“EEPROMへのパラメータ書き込み”動作をトリガします。EEPROM書き込みサイクルは10~30ms程度です。コマンドを受信した後、0 x 86 + 0 x 0 5に戻り、“パラメータを保存したいことがわかっています。Flashを書いています”と言います。コマンドレジスタは約20ms後に再度ポーリングされ、書き込み完了を示す0 x 0000まで読み取られます。0 x 0 5から50ms以内に完了しないと、一部のドライブはタイムアウトしてフォールバックします。

ケース2：temperatureコントローラのPID自己調整

オムロンE5CC，書き込み0 x 0 1 01（AT実行/Stop）= 0 x 00 01セルフチューニングを開始します。このOperationは数分かかります。E 5 CCは最初に0 x 0 5に戻り、ATフラグがONになっている場合を除き、チューニング中にPVとSVの値を通常通り読み取ることができます。調整完了後、ATは自動的にオフになります。ホストコンピュータは0 x 0 5を受信した後にタイムアウトタイマーを起動する必要があり、そこで死ぬのではなく、一部のデバイスのセルフチューニングは30分実行できます。

ケース3ゲートウェイのバックエンドでのスレーブの応答が遅い

Modbus TCP to RTUゲートウェイ（MOXA MGate MB3170など）では、マスターはゲートウェイを介して9600bpsの低速バス上のスレーブを読み取る。マスターステーションは125個のレジスタを読み取る要求を送信し、ゲートウェイはこの要求をRTUバスに転送しますが、データvalueが多くボーレートが低いため、RTUスレーブステーションはデータを返すのに200ms+かかります。ゲートウェイは、完全なRTU応答を受信する前に、TCPマスターに0 x 0 5プレースホルダーを返します。これはゲートウェイの一般的な“ペンディング”処理です。Modbus TCP仕様はこのシナリオでの0 x 0 5の使用を明示的に規定していないが、多くのゲートウェイベンダーが行っている。

注意すべき設計上の詳細：0 x 0 5トリガ後のマスター側の待機ポリシー。同じリクエストをすぐに再送信しないでください。スレーブは繰り返しコマンドを受け取ります。正しい方法は、ステータスレジスタ（スレーブから提供されている場合）をポーリングするか、タイムアウトタイマーを設定して新しいクエリコマンドを実行することです。一部のSCADAドライバ（KepwareのModbusドライバなど）には0 x 0 5処理ロジックが組み込まれており、他は直接タイムアウトを報告している。独自のModbusドライバを書く場合は、0 x 0 5の処理ロジックが必要です。

0 x 0 6-駅からビジー

あなたのリクエストを処理するには忙しすぎます。コマンドは受け入れられたが実行できず、マスターは後で再試行する必要があります。

0 x 0 5と0 x 0 6の違い：0 x 0 5は“受け取った、処理中、結果を待つ”、0 x 0 6は“今利用できない、後で戻ってくる”です。0 x 0 5はスレーブがコマンドの実行を開始したことを意味し、0 x 0 6はスレーブがまったく実行を開始しなかったことを意味する。

メッセージの例

を要求     01 06 20 00 07D 0 -书き込みレジスタ0x2000 = 0x 07D 0 2000
例外応答01 86 06            - 忙しくて対処できない

ケース1：パラメータをすぐに読む

EEPROMに書き込む必要があるパラメータを書き込むと、10ms以内に次のリクエストが送信されます。スレーブフラッシュコントローラはバスを解放せず、0 x 0 6に戻ります。多くのエンジニアはスクリプトをデバッグし、数ミリ秒ごとにリクエストを送信し、ステーションから処理するには遅すぎます。デバイスが遅いのではなく、速すぎるのです。Modbusにはフロー制御メカニズムがなく、マスターステーションは自分でリズムを制御する必要があります。フラッシュ関連レジスタを書き終えた後、次の読み書き要求を送信する前に30~50msを残します。

ケース2高速ポーリングにより低速デバイスバッファがオーバーフローする

Modbus Pollを使用して、9600bps RTU温度湿度センサを20ms間隔でポーリングします。起動時は正常に動作し、1分後に断続的に0 x 0 6が発生し始める。9600bpsの転送は1ワードを1ms節約し、最小読み取りリクエスト+レスポンスの往復は約30~40msです。20msのポーリング間隔は、デバイスの最小応答期間よりも既に小さくなっています。スレーブのシリアルポート受信バッファがいっぱいになり、オーバーフローしたフレームを破棄するのに忙しく、新しいリクエストを処理する時間がありません。ポーリング間隔を100msに設定するとよい。115200bpsに切り替えるとさらに短縮できますが、多くの産業用機器は38400bpsまたは19200bpsまでしかサポートしていません。

ケース3：複数のマスターが1つのスレーブに同時にアクセスする

RS-485バス上のModbus RTUスレーブは、PLCと上位SCADAの2つのマスターマスターステーションに接続されます。2つのプライマリ局間には協調はなく、それぞれ500msと300ms間隔でポーリングされます。衝突確率が上昇します。2つのリクエストフレームが重なり合い、局から受信されたものは文字化けします。一部のスレーブはフレームエラーを検出した後に無視し、一部のスレーブはエラー処理に時間を費やし、受信バッファを空にした直後にプライマリ局のフレームが到着します。新しいフレームを受信する準備ができておらず、0 x 0 6しか返さない。RS-485マルチマスターステーションの競合処理は、ハードウェアフロー制御またはマスターステーション側でミューテックスロックを行うことをお勧めし、ステーションから自分で解決することを期待しないでください。

ケース4：電源投入時にリクエストを受信

ほとんどのModbusは電源投入後数十ミリ秒から数秒の初期化時間を持つ。このウィンドウでリクエストを送信するには、スレーブのModbusプロトコルスタックがまだ準備ができていません。一部のスレーブは直接戻らないNo Response、一部のスレーブは0x06に戻ります。この動作は特定のファームウェア実装に関連します。ダンフォスVLT FC 30 2ドライブは、電源投入後約2 秒で0 x 0 6に戻り、初期化後に正常に戻ります。SCADAが起動してスレーブを読み取る場合、最初の数回のリクエストは0 x 0 6を受信する可能性があります。これは、マスターコードにパワーオン遅延を追加するか、0 x 0 6を自動再試行することによって回避されます（500ms間隔で最大3回）。

0 x 0 6と0 x 0 5を混同するのは簡単ですが、0 x 0 5は“リクエストを処理中”で、処理が完了すると通常のデータに戻ります。0 x 0 6は“リクエストを処理できません。リクエストは破棄されました。プライマリ局は0 x 0 5を受信し、0 x 0 6を受信して再試行する。0 x 0 6を0 x 0 5として処理すると、待つとタイムアウトになります。

0x0A-ゲートウェイパスが使用できません。

この例外コードはゲートウェイシナリオでのみ発生します。ゲートウェイと下流のスレーブ間のCommunicationに問題があります。ゲートウェイ自体は問題ありませんが、その背後にあるデバイスは接続できません。

Modbus規格では、“Gateway Path Unavailable”という表現があります。つまり、ターゲットデバイスへのパスを確立できません。ここでのターゲットデバイスはアドレス0 x 0 1のスレーブ本体ではなく、ゲートウェイ内部の下流スレーブへの“ルーティング”経路である。

メッセージの例

を要求     0 1 0 3 0 0 0 0 0 0 1-ゲートウェイ経由でダウンストリームスレーブを読み取る
異常応答01 83 0A            - ゲートウェイ：後ろのステーションは応答しない

ケース1：シリアルサーバのバックエンドからスレーブが切断された

USR-N 510シリアルサーバはModbus TCP RTUゲートウェイとして動作し、3つのModbus RTUセンサ（アドレス0 x 0 1、0 x 0 2、0 x 0 3）が取り付けられています。0 x 0 2スレーブ電源モジュールが燃え尽き、完全に切断されました。マスタがゲートウェイ経由で0 x 0 2スレーブを読み取ると、シリアルサーバはRS-485バス上でリクエストをブロードキャストしようとし、500msのタイムアウトで応答を受信できないのを待ち、TCP側でマスタに0 x 0 Aを返します。0 x 0 1と0 x 0 3スレーブ間のCommunicationは完全に正常です。ゲートウェイ自体は生きていますが、パスの1つが壊れています。

ケース2：ゲートウェイがダウンストリームパラメータを誤って設定している

MOXA MGate MB3170は、ダウンストリーム96 00 bps、8 N 1に設定されます。しかし、実際のRS-485バス上のデバイスは19200bps、8 E 1（偶数チェック）です。ゲートウェイは9600bpsのリクエストフレームに従って送信され、局から受信したものは文字化けし、応答しません。ゲートウェイはタイムアウト後に0 x 0 Aを返します。この問題は、複数のデバイスが混在しているRS-485バスでは特に一般的です。異なるメーカーのデフォルトCommunicationパラメータは異なり、プロジェクトの初期段階で均一に調整しないとピットを踏むことができます。

ケース3：Modbus TCPカスケードゲートウェイ

大規模分散シナリオ：中央SCADA → Modbus TCPマスターゲートウェイ→ファイバリング→インプレースサブゲートウェイ→ RS-485スレーブ。マスターゲートウェイとサブゲートウェイの間のファイバーが切断され、マスターゲートウェイはサブゲートウェイの下のすべてのスレーブ要求に0 x 0 Aを返します。この時点で、トラブルシューティングのアイデアは、ステップバイステップpingです。まず、メインゲートウェイからサブゲートウェイへのTCP接続を確認し、次にサブゲートウェイからRS-485バスへの確認を確認し、最後にシリアルデバイス自体を確認します。

ベンダー定義例外コード

7つの標準例外コードに加えて、多くのベンダーは0 x 80~ 0 x FFセグメントでプライベート例外コードを定義しています。Modbus仕様はベンダーの拡張を可能にしている。しかし、ホストコードが0 1 ~ 0 Aしか認識していない場合、0 x 90に達すると“Unknown Exception”またはフレームドロップが発生します。

一般的なベンダー拡張：

これらの異常コードには統一規格がなく、マニュアルを参照する必要がある。マニュアルのModbus Communicationセクションに完全な例外テーブルをリストしているメーカーもあれば、付録に隠されているものもあれば、書かないものもあります。デバッグしてから経験によって判断することしかできません。

穴があります：内部例外処理が“アドレスがexistenceしない”と“値が不正”を同じエラールートに分類するため、一部の国内PLCは0 x 0 2条件に遭遇したときに0 x 0 3に戻ります（不正アドレスと不正データ値を区別しません）。標準的には0 x 0 2を期待していましたが、実際には0 x 0 3を受け取りました。マニュアルのレジスタマップテーブルを見てください。

見落とされがちなのは、CPUダウンモードでの例外コードの動作です。多くのPLCはSTOP状態でModbusスタックを実行しますが、動作は異なります。Siemens S 7 -1200がModbus Serverを実行すると、CPUがRUNからSTOPに切り替わり、マッピングされたDBブロックを読み取り、0 x 0 1ではなく0 x 0 4（“Device Fault”）を返す。PLCは壊れていませんが、DBデータはSTOPモードでは使用できません。Schneider M221は停止状態でModbusリクエストに応答しますが、データは更新されません。三菱 FX5UがModbus Serverを実行すると、STOP状態では直接リクエストに応答せず、ホストコンピュータは例外コードではなくタイムアウトを見ます。同じSCADAシステムは、異なるブランドのPLCのSTOP動作に適応する必要があり、駆動レベルを差別化する必要があります。

ベンダー拡張例外コードはセキュリティシナリオでもよく使われます。例えば、Modbus Security（TLSベース）をサポートする一部のゲートウェイデバイスは、認証失敗時にセキュリティレイヤ拒否を示すカスタム例外コード0 xE 0~ 0 xEFを返す。Modbus規格では定義されていませんがexistenceしますModbus TCPトラフィックが突然0 xE 1を受信し始めた場合、スタックのParseが間違っているのではなく、ゲートウェイが“TLSハンドシェイクが失敗しました”と伝えているのです。

Wiresharkで異常フレームをキャプチャ

RTUとTCPの両方で、WiresharkはModbusプロトコルを直接解析できます。ネットワーク上の適切な場所にあることを確認します。

TCPシナリオ

Modbus TCPはポート502で、WiresharkはデフォルトでParseします。フィルターバーに`modbus`と入力すると、例外フレームが赤色の背景で表示されます。

例外応答フレームを展開して、以下のキーフィールドを見てください。

Modbus/TCP
  Transaction Identifier 1
  Protocol Identifier 0
  Length 3               この長さに注目
  Unit Identifier 1
Modbus
  Function Code 131 0x83 ← 83 = 03| 0 x 80、Wiresharkが直接表示
  Exception Code 2 Illegal Data Address

`3`はMBAPヘッダーの长さフィールドで、= Unit ier 1 + Code 1 + Exception Code 1 = 3バイトです。通常の応答は（データが続くため）より大きくなります。長さだけで例外応答か正常応答かを判断できます。例外応答のTCPペイロードは通常3バイトです。

RTUシナリオ

RTUパケットキャプチャには、RS-485-USBコンバータを使用したリスニングノードが必要です。WiresharkのRTUサポートはTCPほど優れておらず、ポート設定（ボーレート、検証など）を手動で指定する必要があります。キャプチャされた例外フレームのフォーマットはTCPに似ているが、MBAPヘッダはない。

0 1 83 0 2 xx xx -アドレス0 1、機能コード83、例外コード0 2、CRC xx xx

RTUパケットにはトランザクションIDはなく、タイムスタンプだけでリクエストとレスポンスの対応関係を判断できます。複雑なマルチスレーブRTUバスをデバッグする場合は、WiresharkでModbusアドレスフィルタリングを行い、各スレーブのトラフィックを分離することをお勧めします。

WiresharkのModbusパーサはバージョン3.xから例外コードの中国語表示をサポートした。Preferences → Protocols → ModbusでException解決オプションを選択します。Wiresharkは標準例外コード01~ 0 AのみをParseし、ベンダーのカスタムコードは説明テキストの代わりに数字を表示します。

Wiresharkのトリックもあります：`modbus. exception_code`で表示フィルタを作ります。modbus.exception_code == 2`すべての0 x 02例外フレームをフィルタリングします。modbus.exception_code = 1 modbus.exception_code = 10`すべての標準例外をフィルタリングします。オンサイトトラブルシューティングでは、まずグローバル統計（Statistics → Protocol Hierarchy → Modbus）を見ると、異常フレームがトラフィック全体に占める割合を確認できます。異常フレームが10%を超えると、設定に問題がある可能性があります。0 x 0 6が時折ある場合は、タイミングの問題です。0 x 0 4が続く場合は、デバイスを交換します。

Modbus Pollの例外

Modbus Pollは最も一般的なデバッグツールです。その例外情報は、ウィンドウ下部のステータスバーに直接表示されます。

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

最初に赤い文字を見て、まず関数を見て、次に例外を見てください。関数コードはどのOperationが間違っているかを示し、例外コードはその理由を示します。

Display → Communicationを開き、完全なメッセージを表示します。例外フレームは赤でマークされ、元の16進数を見てください。

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

`Rx`の2バイト目は0x83 = 0x03です。|0x80），3番目のバイト0x02は例外コードである。` C0F1 `はCRCである. Modbus PollはParseに役立ちますが、元のフレームを自分で見ることを学ぶことは基本的なスキルです。展開後にModbus Pollが使えるわけではありません。

同じリクエストを連続して0 x 0 2に送信し、アドレスを変更せずに、開始アドレスとQuantityがスレーブマニュアルに記載されている有効範囲内であることを確認します。多くの場合、アドレス計算ロジックが間違っています。特に、1ベースのレジスタアドレスから0ベースのPDUアドレスに切り替える場合、このピットは基本的に初心者が一度は踏む必要があります。

デバッグ方法論：例外コード受信後のチェックリスト

現場では異常コードが発生し、次の順序ではなく、標準的な操作手順ではなく、古いエンジニアの血と涙の経験です。

** 最初のステップ：どのスレーブ、どの機能コード、どの例外コードを確認する **

通常、複数の駅があります。Modbus PollまたはWiresharkで生のメッセージをキャプチャし、スレーブアドレス+機能コード+例外コードの3つの数字を取得します。你是用

** ステップ2：例外コード分類-ソフトウェアまたはハードウェアの原因？

0 x 0 1/0 x 0 2/0 x 0 3リクエストに問題がある可能性があります。チェック構成、チェックアドレスマップ、チェックデータ範囲。0 x 0 4/0 x 0 Aスレーブまたはリンクに問題がある可能性が高い。電源を切って再起動してください。0 x 0 4が正常になった場合、デバイスの内部障害復旧ですが、根本原因が解決されたわけではありません。0 x 0 6はタイミングの問題であり、ポーリング間隔を遅くする。

** ステップ3：変数の分離 **

同じマスターステーションで、スレーブアドレスを変更してみてください。元のスレーブステーションでCommunicationできます。Communicationできない→マスタ側またはバス側の問題。同じスレーブアドレスをModbus Pollで試してください。Communicationできます→ホストコンピュータのコードに問題があります。Communicationできない→スレーブまたはリンクに問題がある。これは最も一般的な2つのスクリーニング方法ですが、多くの人はこのステップをスキップし、ハードウェアが壊れていると直接疑います。

** ステップ4：マニュアルを読む **

例外コードが出てきて、スレーブマニュアルのModbus Communicationセクションを開きます。一部のベンダーは、返される例外コードとトリガー条件をリストします。マニュアルに異常がない場合は、アドレスマップテーブルを探し、リクエストアドレスが有効範囲内かどうかを手動で照合します。多くの“通信障害”は、実際には予約アドレスを読んだり、アドレスを書いたりすることです。

** ステップ5：バッグをつかむ **

Wiresharkまたはシリアルモニタで生のメッセージをキャプチャします。主に何が起こったのか。駅から何が返ってきたのか。CRCエラーはありますか？不完全なフレームはありますか？多くの場合、ログを見て、0 1 0 3 0 0 0 0 0 0 0 1を送信したと思って、実際にパケットをキャッチして、ノイズがスローされたときにステーションからボーレートが間違っていることがわかります。コードログを信頼するのではなく、パッケージキャプチャツールを信頼してください。

** ステップ6：テストの置き換え **

同じモデルの新しいスレーブに切り替えると、同じリクエストが結果を表示します。新しいデバイスが正常な場合、元のデバイスは異常コードを返します-デバイスハードウェア障害。新しいデバイスが同じ例外コードを返す場合-リクエストに問題があります。バックアップ機器がない場合は、動作していることが確認されたスレーブアドレスを使用してCommunicationリンクを測定します。リンクの疑いは除外され、問題は特定のデバイスにあります。

** ステップ7：まだ不可能な場合 **

生のメッセージ（16進数）、スレーブモデルとファームウェアバージョン、マスタープラットフォーム情報をスレーブベンダーのFAEに送信します。ログのスクリーンショットを送信しないで、オリジナルメッセージを送信する-FAEは説明よりもオリジナルメッセージを見ます。FAEが戻ってこない場合は、modbus.cnフォーラムに元のメッセージを投稿してください。マニュアルは理論であり、コミュニティは血と涙であるため、コミュニティのデバッグ経験はベンダーのマニュアルよりも信頼性が高いことがあります。

** 補足：Modbusドライバを記述する際の例外コード処理テンプレート **

メインフレーム用のModbusマスタドライバ（C/Python/Node.jsなど）を書いている場合、例外フレーム処理は少なくとも以下のケースをカバーします。

1.レスポンスの最初のバイトがリクエストのスレーブアドレスと等しいかどうかを確認します（アドレス不一致=レスポンスではない、破棄）。 2.機能コードのビット7が1であるかどうか（1の場合は例外コードを抽出し、0の場合はデータ領域を正常にParse） 3.例外コード0 x 0 5特別処理：例外を投げない、待機状態に入る、ステータスレジスタをポーリングする、または再送信をタイムアウトする。 4.例外コード0 x 0 6特殊処理：50~100msの遅延後に再試行（最大3回） 5.その他の例外コード：ログを記録し、エラー処理（アラーム、再試行、代替リンクの切り替えなど）のために上位層に通知する。 6.ベンダー定義コード0 x 80~ 0 x FF：デバイスモデルに依存する辞書が必要です。

間違った方法は、すべての例外コードを“通信失敗”とみなして再試行することです。0 x 0 2 10，000回の再試行も0 x 0 2で、間違ったアドレスは間違っています。正しいアプローチは、例外コードの分類に基づいて異なる戦略を採用することです。このロジックが記述されていると、ドライバは市場のModbusスレーブデバイスの90%に対応できます。残りの10%は、標準的な例外コードを返さないベンダーです。例外応答を通常の応答に置き換え、エラーメッセージをレジスタに詰め込みます。このデバイスは専用のマニュアルにのみアクセスできます。

異常コードクイックチェック

印刷してデバッグコンピュータの横に置くことをお勧めします。携帯電話を検索せずに現場異常コード、時計を見ておおよその方向を知っている。特定の診断方法は、上記の各異常コードのケースに戻ります。すべてのケースは、プログラムされていない現場で触れられています。