Source: Modbus Chinese Network（modbus.cn） —— China leadingModbuscommunication protocol technical community
本記事：渐进式解決Modbusコミュニケーションの問題：从物理層は到应用完全に。排マニュアルを参照。 · Author：modbus Technical Team · 发布于 2026-07-01
摘要：Modbus RS-485 通信通信不可怎么办？本記事从物理層は到アプリケーション層，経由真实报文分析和トラブルシューティング工具演示，给出完全的渐进式排障方法。关键词：Modbus 通信故障トラブルシューティング、RS-485 排障、Modbus デバッグ方法、Modbus RTU 応答なし。、CRC verificationError。
在工业自動化领域，Modbus 通信出問題是最让人头疼的事——ではない因为它复杂，而是因为故障点太分散。物理層は、データ链路层、アプリケーション層，任何一个环节出問題，现象可能一样：マスター发リクエスト，スレーブ不回。
这件の記事ではない教你 Modbus protocol基础。我假设你已经在用 Modbus，现在的問題是「通信不可」，你需要一份能照着操作的排障清单。我们就从最底层开始，一层一层往上查。
核心关键词：Modbus 通信故障トラブルシューティング、RS-485 排障、Modbus RTU 応答なし。、CRC verificationError。More Modbus テクニカル記事一覧ご訪問ください。 modbus.cn。
一、典型的現場での障害长什么样
先看三个真实场景，もし你遇到过类似的，这件の記事就是写给你的。
Scenarios 1：某污水処理站，16 个 Modbus RTU スレーブ挂在一条 RS-485 バス上。每天下午三点准时すべて掉线，十分后自动恢复。查了三个星期，最后发现是隔壁泵房的PVインバータ每天下午三点启动，EMI 干渉耦合到 485 线上，把信号淹了。
Scenarios 2：一台三菱周波数変換器経由 RS-485 接入ゲートウェイ，マスター发機能コード 03 读频率，偶尔能读到，偶尔报 CRC Error。ボーレート是 9600。折腾了两天最后发现是 A/B ライン·リバース了——マスター的 A 接到了スレーブ的 B。但なぜか。偶尔还能读到データ？因为 RS-485 收发器有一定的共模容限，在信号质量好的时候真通信可能，一有干渉就 CRC 报错。
Scenarios 3：产线上新加了一台サーモスタット，アドレス设成 05，挂上去之后 05 号没反应，但原来的一台 07 号也通信不可了。拔掉新デバイス，07 号恢复正常。查到最后，新デバイスデフォルト設定了 120Ω 終端抵抗，バス上一共挂了三个終端抵抗——阻抗不マッチング，信号の反射导致すべての駅から。时断时续。
这三个场景指向同一个道理：Modbus 通信不可，不能猜，要一层一层排除。 下面就是这个トラブルシューティング完全に。路径。
二、トラブルシューティング综述：从物理層は到アプリケーション層的四层模型
Modbus コミュニケーションの問題的トラブルシューティング路径，按层次从低到高：
┌────────────────────────────────────────────┐
│ 第四层：アプリケーション層 │
│ slave address、Register Mapping、function code、endianness │
│ 现象：スレーブ回異常コード。，或データ值明显正しくない │
├────────────────────────────────────────────┤
│ 第三层：データ链路层 │
│ Baud rate、check digit、CRC/LRC check │
│ 现象：CRC Error、フレーム不完全、偶发性丢フレーム │
├────────────────────────────────────────────┤
│ 第二层：电气层 │
│ A/B 线接法、終端抵抗、バイアス抵抗体、接地 │
│ 现象：全く通じない、データ全是乱码、断続的な断连 │
├────────────────────────────────────────────┤
│ 第一层：物理连接 │
│ 线缆通断、接头氧化、シールド層、布线路径 │
│ 现象：マスター发データ，スレーブ完全无反应 │
└────────────────────────────────────────────┘排障铁律：永远从第一层开始トラブルシューティング，確認没問題再往上走。 不知道有多少人在第三层（改ボーレート、改タイムアウト時間）上浪费了三天，最后发现是第一层的 A/B ライン·リバース了。もし你只记住一句话，记住这句。
三、第一层：物理连接チェック
3.1 マルチメータ打线——最基本的最初のステップ
先把全装備。停電。マルチメータ调到抵抗レンジ或通断ファイル，测：
- A 线从マスター到最も遠い端。スレーブ是否导通（电阻应 < 10Ω，取决于线长和线径） - B 线同样 - A 和 B 之间不能ショート（电阻应为无穷大或接近无穷大） - A/B 分别对 GND 不能ショート
もし通断都正常，再把电送上，マルチメータ调到DC電圧レベル：
- A 对 GND：静止ステータス下约 2.5V ~ 3.5V（取决于偏置电路） - B 对 GND：静止ステータス下约 1.5V ~ 2.5V - A-B 差動電圧：静止ステータス下约 0.2V ~ 2V，A 应高于 B
もし A-B 差動電圧接近 0V，甚至 A 低于 B，你的偏置电路有問題。 很多廉价 USB-485 変換器です。ない内置バイアス抵抗体，挂在一根长バス上工作时，空闲ステータス下 A-B 差分会漂移到不確かなことステータス，导致スレーブ的 UART 收到随机垃圾データ。
3.2 A/B 线到底怎么接——这个坑踩的人最多
RS-485 的 A/B 配線ない统一的業界タグ標準。不同デバイス厂商对 A 和 B 的定义可能是反的。以下是你可能会遇到的标记方式和它们的对应关系：
| 常见标记 | 另一种标记 | 空闲电压 | 説明 |
|---|---|---|---|
| A / + / D+ / TX+ / 正 | Non-Inverting | 高于 B | 同相端 |
| B / - / D- / TX- / 负 | Inverting | 低于 A | 反相端 |
快速判定方法：停電ステータス下用マルチメータダイオードレンジ测。 红表笔接 GND，黑表笔接 A——大多数 RS-485 收发器芯片（如 MAX485、SN75176）的 A 脚对 GND 有一个反向保护二极管，会测出正向压降约 0.6V。B 脚对 GND 也一样。もし测不出来，换个极性再测。
还有一个更暴力的方法：もし接了通信不可，把 A 和 B 交換一下试试。ではない笑话——这在现场是最もよく使われる「排障手段」。因为很多周波数変換器的 RS-485 端子标注就是反的。
3.3 終端抵抗——什么时候接、接在哪
終端抵抗 120Ω，接在バス的最两端。这句话每个人都听过。但实际工程中这些细节才决定成败：
什么时候必须接。 バスの長さ超过 50 米，或ボーレート ≥ 19200。判断標準ではない長さ，是你用オシロスコープを参照。信号波形——もし有明显的过冲或反射台阶，加終端抵抗。
什么时候可以不接。 测试台上，一米短线，Baud rate 9600。这时候加終端抵抗反而可能因为ドライブ能力。不足导致信号幅值下降。
一个容易被忽略的坑。 很多 RS-485 デバイス内部已经集成了終端抵抗，経由跳线或拨码开关有効。もし你不知道这一点，在バス上手动加了 120Ω，而デバイス上也开着 120Ω，等于并联成了 60Ω——信号幅度大幅下降，反而更通信不可了。这就是前面的场景 3。
トラブルシューティング方法：全装備。停電，マルチメータ抵抗レンジ测 A-B 之间的直流电阻。正常应该是几 kΩ 到几十 kΩ（バイアス抵抗体决定）。もし测出来是 60Ω 或 120Ω，説明至少有一个終端抵抗在起作用。逐个拔デバイス，看哪个デバイス拔掉后阻抗变了。
3.4 屏蔽和接地——主に。人做错的地方
RS-485 シールド層应该シングルエンド接地，在マスター或ゲートウェイ侧接大地。もし两端都接地，地電位差会在シールド層上形成环流，反而把干渉引入信号线。
另外，不要用ネットワークケーブル的空闲线对做 RS-485。ネットワークケーブル是 100Ω 特性インピーダンス，RS-485 电缆是 120Ω 特性インピーダンス，不マッチング会导致高速率下信号の反射严重。ショート·ディスタンス（< 10 米）凑合能用，但不要作为正式工程方案。正规的 RS-485 电缆是一对ツイストペア加シールド層，特性インピーダンス 120Ω，比如 Belden 3105A 或等效型号。
四、第二层：电气层チェック
物理连接確認没問題之后，もしまだ意味がない或有误码，进入电气层。
4.1 用オシロスコープを参照。波形
オシロスコープ探头挂在 A 线对 GND 和 B 线对 GND，观察：
- 空闲ステータス下 A 和 B 的电压值是否稳定（A 应高于 B 至少 200mV） - 有データ传输时，A 和 B 是否呈现標準的差動信号です（A 和 B 镜像对称） - 波形アップサイド·エッジ和ダウン·エッジ是否干净（不应该有明显的台阶或圆弧）
もし波形边缘很圆，可能是线缆电容太大（線が長すぎる或线径太细），或者ドライブ能力。不足。ボーレートの低下通常能缓解。
4.2 バイアス抵抗体（Fail-Safe 偏置）
RS-485 標準要求差分入力电压 ≥ 200mV 时判定为逻辑 1，≤ -200mV 时判定为逻辑 0。但在バス空闲（全装備。都不驱动）时，差分電圧かもしれない落在 -200mV to +200mV 的不確かなこと区间内，导致受信器出力随机データ。
这就是なぜか。需要バイアス抵抗体：在バス的某一个位置（通常在マスター或偏置电路所在处）用2つ电阻把 A 上拉到 VCC、B 下拉到 GND，保证空闲ステータス下 A > B 且差值 > 200mV。
常见的バイアス抵抗体取值是 680Ω 或 560Ω（上拉和下拉各一个）。但要注意：バイアス抵抗体和終端抵抗是并联关系。もし你的終端抵抗是 120Ω，バイアス抵抗体各 680Ω，实际的空闲差動電圧是：
V_diff = VCC × R_term / (R_term + R_pullup + R_pulldown)
= 5V × 120 / (120 + 680 + 680) ≈ 0.405V = 405mV这个值 > 200mV，满足要求。但もし你把終端抵抗换成了 60Ω（2つ 120Ω 并联），差動電圧就只剩约 210mV，卡在临界点上。所以終端抵抗的数量和位置是规划バイアス抵抗体的前提。
五、第三层：データ链路层チェック
电气层没問題，但通信まだ正しくない——进入协议本身的排障。这一层需要シリアルポート抓包工具。
5.1 確認スレーブ是否サポート Modbus
这里ではない让你看デバイス説明书——説明书写了サポート不代表固件真的开了。Serial Assistantとは发一条最简单的リクエストフレーム，看スレーブ回不回。
以 Modbus RTU 为例，发機能コード 03（read holding registers）：
slave address: 01
function code: 03
starting address: 00 00（register 40001）
レジスタの数: 00 01（读 1 个）
CRC: 84 0A
完全フレーム: 01 03 00 00 00 01 84 0A把你的 USB-485 変換器です。接駅から。的 RS-485 口上，シリアルアシスタント设好ボーレート/data bit/check digit/stop bit，发上面这フレーム。もしスレーブ回了：
01 03 02 00 2A 39 9B説明スレーブサポート Modbus，register 40001 里的值是 0x002A（decimal 42）。もしない任何レスポンス，继续查下面几项。
5.2 ボーレート和フレーム形式
Modbus RTU 的デフォルトフレーム形式通常是：9600-8-N-1（Baud rate 9600，8 data bit，検証なし。，1 stop bit）。但很多老デバイス用 9600-8-E-1（even parity）或 19200-8-N-1。还有一些国产デバイスデフォルト 4800。
もし你的 USB-485 変換器です。ボーレート设对了，スレーブ会回应。もしボーレート正しくない，スレーブ会收到乱码。スレーブ看到乱码后的行为取决于其固件実装——有的デバイス直接丢弃，有的デバイス会尝试解析の失敗后复位受信バッファ。，表现为完全沉默。
不要猜ボーレート。 もし手头ないデバイス手册，用一个笨办法：USB ロジックアナライザ（几十块钱的那种就行）挂在 A、B 线上，看スレーブ上电后有ない发データ。一部の駅からスタート。后会主动发一段标识信息，测量这段データ的位宽就能逆推論ボーレート。
5.3 check digit、stop bit、data bit
9600-8-N-1 vs 9600-8-E-1 違いはありません不仅是一个チェックビット。フレーム总長さ变了：
- 8-N-1：1 スタート地点。 + 8 data bit + 1 stop bit = 10 位/byte - 8-E-1：1 スタート地点。 + 8 data bit + 1 check digit + 1 stop bit = 11 位/byte
もし你用 8-N-1 发，スレーブ用 8-E-1 收，スレーブ会把你的ストップ·ビット当チェックビット来验证。反之亦然。这会导致偶发性的検証エラー而非すべてエラー——因为ストップ·ビット是固定的逻辑 1，有 50% 的概率碰巧「検証済み。」。
这就是なぜか。ボーレート、check digit、ストップ·ビット的配列组合要从デバイス手册里確認，而ではない凑出来。 16 个スレーブ，7 种ボーレート × 3 种チェック × 2 种ストップ·ビット = 42 种组合。凑出来纯粹是折磨自己。
5.4 バッグの分析。——区分「送信しない。去」「没回应」「回了エラー」
用シリアルポートモニタリング软件（比如 Device Monitoring Studio、Serial Port Monitor，或者简单粗暴地用2つ USB-485 変換器です。背靠背接在バス上）抓实际的收发データ。
看三个关键指标：
マスター发出的フレーム是否正确。 用 CRC calculation器验证你发出的フレーム内の CRC そうですね。。一个よくある間違い是 CRC high低バイト数反了——Modbus RTU 规定 CRC lowバイト前に，ハイバイト在后。比如フレーム 01 03 00 00 00 01 的 CRC 是 0x840A，フレーム里应该是 84 0A 而ではない 0A 84。
スレーブ有没応答がある。。 もしマスターフレーム正确发出但在合理的时间内（比如 200ms）ない任何データ回来，チェック駅からの住所一致するかどうか、バス上是否只有一台デバイスオンライン（加另一台后可能アドレス冲突）、スレーブ是否处于「监听」モード。
スレーブレスポンス了什么。 もしスレーブ回了異常フレーム，機能コード最高位置 1 再加異常コード。（比如 01 83 02 C0 F1，83 = 03 + 0x80，Exception Code 02 = Illegal data address），那至少链路层是通的，問題在アプリケーション層。
5.5 CRC verificationエラー的正確トラブルシューティング
CRC verificationエラー是最も一般的な的链路层問題，可能的原因有这些，按频率从高到低：
1. A/B ライン·リバース。 差分極性は逆。，すべてのデータ·ビット反转，CRC 大概率正しくない。但有共模容限时偶尔能对——这就是场景 2。 2. ボーレート偏差。 2つデバイス的时钟偏差导致采样点漂移。もしボーレート偏差超过 ±2%，受信端 UART 会采样到エラー的位值。特别是在高温环境下，MCU 内部 RC 振荡器的温漂可能达到 ±5%。 3. 配線松动或接触不良。 一个位的丢失会导致后续すべてのバイト移位，CRC 必错。 4. 電磁干渉による干渉。 周波数変換器启动瞬间、電気溶接機工作时的强 EMI 会直接改变传输线上的电平，导致位エラー。もし CRC エラーのみ特定デバイス启动时出现，基本可以锁定干渉源。
六、第四层：アプリケーション層チェック
链路层通了（スレーブ応答がある。且 CRC correct），但戻る的データは間違ってる或功能不如预期。
6.1 slave address
Modbus RTU フレーム的第一个byteは駅からの住所。アドレス範囲 1-247。
address 0 是放送アドレス——マスター用 0 发写命令，すべての駅から。执行但不回应。もし你用アドレス 0 发了读命令，不会有任何スレーブレスポンス。
很多新デバイス出厂デフォルトアドレス是 1。もし你バス上已经有了一台アドレス 1 equipment，又加上一台出厂デフォルトアドレス也是 1 的新デバイス，两台デバイス会在マスター寻址 1 时同时レスポンス——バス冲突，マスター收到的データ是两路信号的叠加，表现为 CRC エラー或乱码。
トラブルシューティング方法：一次只往バス上接一个スレーブ，逐个测试。 这是最笨但最有效的方法。一次测通了再加下一个。
6.2 レジスタアドレスオフセット
Modbus 的レジスター·アドレス有2つ概念，搞混了就会读到エラー的データ：
- プロトコルアドレス： フレーム里填的 16 位数值，从 0 开始。function code 03 Read the hold register时，プロトコルアドレス 0 对应的是第 1 レジスタを保持する。。 - PLC address： 厂商在手册里写的编号，可能从 1 开始，也可能从 40001 开始。
举例：デバイス手册写「频率设定值在レジスタ 40003」。这个 40003 可能有三种含义：
| 厂商习惯 | プロトコルアドレス | 你在フレーム里填的值 |
|---|---|---|
| 40003 就是プロトコルアドレス | 40003 | 40003（超出单バイト範囲，看厂商怎么処理） |
| 40003 表示レジスタを保持する。区第 3 个 | 2 | 00 02 |
| 40003 表示レジスタを保持する。区第 3 个（从 0 开始） | 3 | 00 03 |
もし你不確かなこと，从プロトコルアドレス 0 开始，读 10 个连续レジスタ。看哪アドレスはこちら。戻る了你认识的值（比如デバイス型号编码、固件版本号、或者当前频率这些已知データ），逆推論厂商的编址方式。
6.3 功能和機能コード
Modbus 標準関数コードと对应的データ区：
- 01：リードコイルを読む（0xxxx） - 02：read discrete inputs（1xxxx） - 03：read holding registers（4xxxx） - 04：read input registers（3xxxx） - 05：シングルコイルを書く。 - 06：単一書き込みレジスタを保持する。 - 15：マルチコイルを書く - 16：複数書き込みレジスタを保持する。
但并ではない每个スレーブ都実装了すべての機能コード。一台简单的サーモスタット可能只サポート 03 和 06——你发 16（マルチレジスタの書き込み）它不认识，回異常コード。 01（違法な機能コード）。
もしスレーブ回了異常コード。，異常コード。含义如下：
| Exception Code | 含义 | 常见原因 |
|---|---|---|
| 01 | Illegal function | スレーブサポートなし。这个機能コード |
| 02 | Illegal data address | レジスター·アドレス超出範囲 |
| 03 | Illegal data value | 写入的值不可接受（超出量程等） |
| 04 | Substation equipment malfunction | スレーブ自检失敗 |
| 05 | Confirm | 命令已受信但需要时间処理 |
| 06 | The slave station equipment is busy | 処理中です。上一个命令 |
異常コードを受信是好事——説明链路层通了，物理層は没問題，你可以把注意力集中在アプリケーション層。
6.4 bytes序（ビッグエンディアン/リトルエンディアン）
Modbus protocol规定多Bytesのデータ以ビッグエンディアン序传输（前の高さ。）。但 32 ビット浮動小数点数怎么传？標準里ない定义。于是各家厂商各搞一套：
- 一些厂商用 ABCD 序（最前の高さ。） - 一些厂商用 CDAB 序（2つ言葉の交換位置，每个字内部仍然ビッグエンディアン） - 一些厂商用 BADC 或 DCBA
もし你读2つ连续保持レジスタです。拼成一个 32 ビット浮動小数点数，读到的值和期待値は差好几个数量级，大概率是バイトオーダー反了。用已知值——比如把频率设成 50.0Hz（IEEE 754 表示是 0x42480000）——读回来，看十六进制配列顺序，逆推論厂商的バイトオーダー。
七、逐步追加スレーブ的正确方法
现在假设你トラブルシューティング完了一个スレーブ，通信は正常。接下来要加もっと見るスレーブ——这是最容易出幺蛾子的环节。
正确做法：
1. バス上只留一个スレーブ（slave A），Confirm A 通信は正常。 2. 断开スレーブ A，只接スレーブ B，Confirm B 通信は正常。 3. A 和 B 同时接上，確認两者都通信は正常。 4. もし A+B 正常，断开すべての，只接スレーブ C，Confirm C 正常。 5. A+B+C 同时接上，確認三者都正常。 6. 以此类推。
もし在第 3 步 A+B 同时接上后出問題，チェック这两件事：
- アドレス冲突： A 和 B 駅からの住所是ではない相同。 - 終端抵抗累积： A 和 B 是ではない都内部有効了 120Ω 終端抵抗。参见 3.3 节。
もし在第 5 步 A+B+C 同时接上后出問題（前两步都正常），大概率是：
- バス駆動能力の不足。 每个スレーブ的 RS-485 收发器在受信ステータス下都有一个入力阻抗（標準 ≥ 12kΩ）。按照 RS-485 標準，一条バス上最多 32 个単位負荷。もし你用的是 1/4 或 1/8 負荷的收发器，数量可以もっと見る。但もし用最便宜的 MAX485 级别芯片，挂 30 个スレーブ后信号の減衰会很明显。ソリューション：选 1/4 或 1/8 負荷的收发器，或者加 RS-485 リピーター。 - バス·トポロジの問題。 RS-485 必须是菊花链（Daisy Chain），不能星星形分支。星形トポロジー会产生信号の反射，反射位置刚好在分支点。もし现场布线已经星星形了且没法改，加 RS-485 Hub 或リピーター来絶縁各分支。
八、メインステーションのポーリング策略与タイムアウトの設定
8.1 タイムアウト時間怎么算
Modbus RTU 的タイムアウト分2つ层面：
文字间タイムアウト（t1.5）： 2つ连续バイト之间的最大允许間隔，设为传输 1.5 个文字的时间。用来判断一フレーム是否结束。在 9600 ボーレートで，一个文字（11 位）约 1.15ms，t1.5 ≈ 1.75ms。
フレーム间タイムアウト（t3.5）： 2つ连续フレーム之间的最小間隔，设为传输 3.5 个文字的时间。在 9600 ボーレートで，t3.5 ≈ 4ms。
もし你的マスター发完リクエスト后等 30ms 还ない收到レスポンス，不能简单地认为スレーブ坏了。一部のスレーブ（尤其是低速 MCU 驱动的サーモスタット、Energy Meter）処理一个リクエスト需要 50-100ms。把这个值设成至少 200ms 作为起始值，確認通信は正常后再根据实际応答時間调短。
8.2 先读后写
在尝试写任何レジスタ之前，先读一个已知的レジスタ（比如デバイス型号、固件版本号、或者一个你已知当前值的レジスタ）。確認読み取り操作。正常后，再尝试写。
不要一上来就往コイル里写 1。 你不知道那1つのコイル控制的是什么——可能是急停信号。用 06 機能コード写レジスタを保持する。同理，先想清楚你写的レジスタ是干什么的。
九、トラブルシューティング清单クイックチェック·テーブル
在工控现场，你可能ない条件一步一步按本記事顺序来。把这张表拍照存手机里，デバッグ时对着查。
| Serial number | チェック项 | Tools | 経由標準 |
|---|---|---|---|
| 1 | A/B 线通断 | マルチメータ抵抗レンジ | A 线导通，B 线导通 |
| 2 | A/B 线不ショート | マルチメータ抵抗レンジ | A-B 电阻 > 1kΩ |
| 3 | 空闲电压 | マルチメータ DC 电压档 | A > B，差值 > 200mV |
| 4 | 終端抵抗 | マルチメータ抵抗レンジ（デバイス停電） | A-B 电阻 120Ω 或 > 1kΩ（取决于是否有効） |
| 5 | バイアス抵抗体 | マルチメータ抵抗レンジ（デバイス停電） | A-VCC 和 B-GND 各约 680Ω |
| 6 | Baud rate/check/stop bit | デバイス手册 | 与スレーブ手册一致 |
| 7 | 发空フレーム测试 | シリアルアシスタント | スレーブ对 01 03 00 00 00 01 84 0A 答えがあります |
| 8 | CRC correct | CRC calculation器 | マスター发出的 CRC 与計算一致 |
| 9 | Response CRC correct | CRC calculation器 | スレーブレスポンス的 CRC 与計算一致 |
| 10 | 駅からの住所唯一 | 逐个接入测试 | バス上ない重复アドレス |
| 11 | レジスター·アドレス正确 | 从 0 読み始めました连续 10 个 | 戻るデータ含已知值 |
| 12 | バイトオーダー正确 | 读已知值对照 | 32 位值解析符合厂商规范 |
十、FAQ：高频排障問題
Q1：マスター发データ，スレーブ偶尔回偶尔不回，Baud rate 9600。なぜか。？
A：偶尔性問題最も一般的な的原因是 A/B ライン·リバース、終端抵抗設定不当、或电源干渉。先查 A/B 极性，再查終端抵抗の位置和数量，最后用オシロスコープを参照。波形。
Q2：USB-485 変換器です。在测试台上正常，一到现场就不行。换了好几个変換器です。都一样。
A：2つ可能。一是现场的 RS-485 线路上有强コモンモード干渉，普通 USB-485 変換器です。的共模抑制比不够。换一个孤立している。工业级 USB-485 Converters（比如宇泰 UT-890A 或同等产品）。二是现场的电脑 USB 口接地和 RS-485 デバイス的地之间有电位差，経由変換器です。形成回路。絶縁型変換器です。能解決这个問題。
Q3：多个スレーブポーリング时，第一个总是通，后面几个经常通信不可。
A：チェックマスター的ポーリング間隔。もし你在发完上一个リクエスト后立即发下一个，而バス上的上一个レスポンス还没传完，就会发生冲突。确保两次ポーリング之间的間隔 ≥ スレーブ数量 ×（リクエスト时间 + 応答時間 + t3.5）。在 9600 ボーレートで，もし每个スレーブ的平均応答時間是 15ms，10 个スレーブ的ポーリング間隔至少设 200ms。
Q4：CRC 总是报错，チェック了 A/B 极性和ボーレート都没問題。
A：用ロジックアナライザ或オシロスコープチェック信号质量。看アップサイド·エッジ和ダウン·エッジ的斜率，もし过于平缓（> 30% 位宽），可能是线容太大或ドライブ能力。不足。ボーレートを下げる。 4800 试试。もし通信可能，説明信号质量确实是問題根源。
Q5：怎么知道スレーブ到底支サポートなし。 Modbus？
A：发 01 03 00 00 00 01 84 0A 过去。もし不回，再用 9600/19200/4800 三种ボーレート各试一遍（8-N-1 和 8-E-1 各一遍）。もし全都不回，チェック以下可能——デバイス根本没通电、RS-485 接口未使能需要跳线或設定、device RS-485 只サポート ASCII モード、デバイス需要特殊的唤醒序列。
有問題再聊。オンサイトデバッグ这种事，文字能说清楚八成，剩下两成靠你自己去试。不过只要按这个顺序来，不走回头路，一个下午足够把大多数 Modbus コミュニケーションの問題搞定了。
Leave a Reply