📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。（旧サイトでは記事を追加しておりません）
編集の要約なし |
編集の要約なし |
||
| 33行目: | 33行目: | ||
<br><br> | <br><br> | ||
== Modbus RS-485 と Modbus RS-232C | == Modbus RS-485 と Modbus RS-232C の比較 == | ||
<center> | <center> | ||
{| class="wikitable" | {| class="wikitable" | ||
| 61行目: | 61行目: | ||
*: ASCII文字形式でデータを送信 | *: ASCII文字形式でデータを送信 | ||
*: デバッグが容易だが、RTUより速度が遅い | *: デバッグが容易だが、RTUより速度が遅い | ||
<br><br> | |||
== Modbus RTU メッセージ構造 == | |||
Modbus RTUでは、全てのデータがバイナリ形式で送信される。<br> | |||
<br> | |||
メッセージは、デバイスアドレス、ファンクションコード、データ、CRCチェックサムで構成される。<br> | |||
CRCは下位バイトが先に送信されるリトルエンディアン形式である。<br> | |||
<br> | |||
[[ファイル:Modbus RTU Message 1.png|フレームなし|中央|600px]] | |||
<br><br> | |||
== 通信シーケンス == | |||
==== Modbus RTU 基本通信シーケンス ==== | |||
Modbus RTU通信では、マスターがリクエストフレームを送信し、スレーブが応答する。<br> | |||
RS-485のHalf Duplex方式では、送信開始時にDE-ONでドライバを有効化して、送信完了後はDE-OFFで受信モードに切り替える。<br> | |||
<br> | |||
スレーブは、T3.5 (フレーム間無通信時間) を経過後にリクエストを受信したと判断して、CRCチェックとデータ処理を行った後、応答フレームを返信する。<br> | |||
正常応答を受信できない場合、マスターはタイムアウト処理を実行する。<br> | |||
<br> | |||
[[ファイル:Modbus RTU Message 2.png|フレームなし|中央|600px]] | |||
<br> | |||
==== Modbus ASCII 基本通信シーケンス ==== | |||
Modbus ASCII通信では、各バイトが16進数のASCII文字として送信される。<br> | |||
メッセージは開始文字 (:) で始まり、スレーブアドレス、ファンクションコード、データ、LRCチェックサム、終了文字 (CR LF) で構成される。<br> | |||
<br> | |||
ASCII形式は人間が読みやすく、デバッグ作業が容易であるというメリットがある。<br> | |||
<br> | |||
通信シーケンスはRTUと同様に、マスターからのリクエストに対してスレーブが応答する形式である。<br> | |||
<br> | |||
[[ファイル:Modbus ASCII Message 3.png|フレームなし|中央|600px]] | |||
<br> | |||
==== マルチドロップ接続時の通信フロー ==== | |||
RS-485のマルチドロップ接続では、1台のマスターが複数のスレーブと通信を行う。<br> | |||
<br> | |||
各スレーブには固有のアドレスが割り当てられ、マスターはリクエスト時に対象スレーブのアドレスを指定する。<br> | |||
バス上の全てのスレーブがメッセージを受信するが、指定されたアドレスのスレーブのみが応答を返す。<br> | |||
他のスレーブは受信したメッセージを無視して、待機状態を維持する。<br> | |||
<br> | |||
この方式により、単一のバスで多数のデバイスを効率的に制御できる。<br> | |||
<br> | |||
[[ファイル:Modbus Multiple Slave 4.png|フレームなし|中央|600px]] | |||
<br><br> | |||
== マスター・スレーブ状態遷移 == | |||
==== マスター側状態遷移 ==== | |||
マスター側は、アイドル状態からポーリングを開始して、リクエスト生成、フレーム生成、送信中、応答待ちの順に遷移する。<br> | |||
<br> | |||
応答を受信した場合、CRCまたはLRCチェックを行い、正常であれば検証状態に進む。<br> | |||
応答がない場合はタイムアウトとなり、再送判定を行う。<br> | |||
<br> | |||
エラーが確定した場合は、アイドル状態に戻る。<br> | |||
<br> | |||
この状態遷移により、通信の信頼性が確保される。<br> | |||
<br> | |||
==== スレーブ側状態遷移 ==== | |||
スレーブ側は、受信待ち状態でフレームの到着を監視する。<br> | |||
フレームを受信すると、受信中状態に遷移して、アドレスを確認する。<br> | |||
自身のアドレスと一致すれば、アドレス判定、検証、処理中、応答生成、応答送信の順に進む。<br> | |||
<br> | |||
アドレスが不一致の場合やCRCまたはLRCエラーが検出された場合は、受信待ち状態に戻る。<br> | |||
<br> | |||
この動作により、マルチドロップ環境で適切なスレーブのみが応答を返す仕組みが実現される。<br> | |||
<br> | |||
[[ファイル:Modbus Master Slave StateMachine 5.jpg|フレームなし|中央]] | |||
<br><br> | |||
== 通信エラーと対策 == | |||
==== アドレス衝突とバス競合 ==== | |||
マルチドロップ環境で設計ミスやアドレス重複が発生すると、複数のスレーブが同時に応答を送信して、バス競合 (データ衝突) が発生する。<br> | |||
この場合、マスターは破損したデータを受信して、CRCエラーが発生する。<br> | |||
マスターは、タイムアウトまたはCRCエラーを検出すると、再送処理またはエラー処理を実行する。<br> | |||
<br> | |||
システム設計時には、各スレーブに重複しない固有のアドレスを割り当てることが必須である。<br> | |||
<br> | |||
また、定期的なアドレス確認と衝突検出機能の実装が推奨される。<br> | |||
<br> | |||
[[ファイル:Modbus Collision 6.png|フレームなし|中央]] | |||
<br> | |||
==== 通信エラーと対策 ==== | |||
Modbus通信における代表的なエラーとして、タイムアウト、CRCまたはLRCエラー、フレーミングエラー、アドレス不一致が挙げられる。<br> | |||
タイムアウトは、スレーブの応答遅延やケーブル断線、ノイズによる応答消失が原因である。<br> | |||
<br> | |||
対策として、適切なタイムアウト時間の設定と再送処理の実装が必要である。<br> | |||
* CRCまたはLRCエラー | |||
*: ノイズやケーブル劣化、インピーダンス不整合により発生する。 | |||
*: シールドケーブルの使用、適切な終端抵抗の配置、ケーブル長の遵守が有効である。 | |||
*: <br> | |||
* フレーミングエラー | |||
*: ボーレート設定の相違やパリティ設定の不一致が原因であり、通信パラメータの統一が必要である。 | |||
*: アドレス不一致は、設定ミスや重複により発生するため、システム構築時のアドレス管理が重要である。 | |||
<br><br> | <br><br> | ||