简介：围绕汇川伺服电机在Modbus RS485总线下的通信控制，这份文档面向工控调试人员、自动化设备工程师及学习伺服通信的进阶读者，重点解决伺服使能、点动与通信参数配置之间的对应关系。文档结合H17组与H31组参数，梳理VDI1伺服使能、VDI2正向点动、VDI3反向点动等端子功能分配，以及H31.00在停止、正向点动、反向点动下的取值逻辑，便于理解端子逻辑选择与运行控制流程。压缩包共1份doc技术文档，约893KB，篇幅紧凑，适合作为现场调试时的参数速查与通信控制思路参考。已有1805人学习下载，在汇川伺服RS485控制场景中具有一定参考价值。读者可获得端子功能配置、点动参数设置及Modbus通信调试的对照线索，用于排查使能与点动无响应、参数对应不清等问题。

1. 先别急着接 A/B 线：伺服控制里最容易被跳过的一层

给汇川伺服电机做 Modbus RS485 通信控制，第一次上电最容易卡住的地方往往不在通信本身：线接对了，串口助手也能收到正常回帧，可一发点动命令，电机就是不转，轴还是松的。通信控制只解决了“喊话”问题，真正决定电机使能、正转和反转的，是 VDI 端子被分配成了什么功能。H17 组那几个偶数位和奇数位一旦配错，上位机把报文发得再标准，驱动器也只当没听见。这套环境适合三类人：第一次用总线带伺服的开发者、要把手动脉冲控制改成总线控制的产线调试人员，以及手上有一台闲置驱动器、想先跑通点动再谈工艺的人。装不好最典型的后果，就是误以为通信坏了，去改波特率、换转换器，越调越远。

2. 物理层落地：RS485 两线制接线、终端电阻与通信参数固化

通信跑不起来，八九成的根子在物理层。上位机侧通常是一根 RS485 转 USB 的转换器，驱动器侧是端子上的 A/B 两线加一个公共端，中间可能还有一段几米到几十米的线缆。这一层的目标是：让上位机发出去的每一帧，在驱动器侧都是干净、可判别的电平。所以在打开任何配置软件之前，先把线接对、把终端电阻的位置想清楚、把两侧的串口参数固定成同一组数字，后面所有关于 H17、H31 的配置才有意义。

2.1 A/B 两线、屏蔽层与 DI 公共端的接法

我一般按下面这个顺序动手，不跳步：

1. 断电。驱动器主回路和控制电源都断，等面板指示灯全灭再碰端子。
2. 转换器的 A 接驱动器通信端子的 A（有的丝印写 A+ / D+），B 接 B（B- / D-）。不要凭颜色判断，不同厂家的线序不统一。
3. 把转换器的 GND 和驱动器的通信 GND 连起来。两线制不等于只接两根线，共模电压没有参考点，长线下很容易出现时通时不通。
4. 屏蔽层只在控制柜一侧接地，驱动器侧剪断悬空，或者按手册要求接屏蔽夹。两端都接地会形成地环流，通信质量反而更差。
5. VDI 端子这侧单独走一组 24V。伺服使能和点动都是通过 VDI 端子触发的，端子要形成回路才有信号，光靠通信写参数、端子悬空，功能分配得再对也不会动作。

提示：DI 是漏型还是源型接法，直接决定公共端接 24V 还是接 0V。这一步查驱动器手册的端子接线图，别照抄别的项目。

这一步做完先别上电发报文，用万用表量一下 A/B 之间有没有异常压降，确认没有短路再继续。

2.2 拓扑与终端电阻：手拉手串下去，不要拉成星形

多站挂在同一条 485 总线上时，拓扑只有一种正确形态：从转换器出发，一站一站串下去，每个节点的 A 并 A、B 并 B。星形接线在低速、短线、台数少的时候可能侥幸能通，一旦波特率上到 19200 以上或者线超过十几米，反射就会让帧错误率飙升，表现为“十帧里错一帧”，非常难查。

终端电阻的做法：总线最远端的两个物理端点各并一只 120Ω，中间节点不装。只有一台驱动器、线又很短的时候，可以不装，但一旦出现偶发超时，第一件事就是补上。

2.3 通信参数固化成一张表

RS485 能通不代表能识别，两侧的串口参数必须逐项对齐。驱动器侧一般有一组通信参数（不同系列组号不一样，以手册为准），上位机侧就是串口初始化那几个参数。我习惯先把它写成一张表，改之前先对一遍：

参数固定在 19200、8E1 这一组是比较稳的选择：比 9600 快，又不至于像 115200 那样对线材和转换器挑剔。全部站点用同一组参数，站号唯一，别出现两台都是 1 的情况。

2.4 用一段最小脚本验证链路通不通

线接完、参数写完，先别碰 H17 和 H31，用最简单的读寄存器动作确认链路。这段脚本只做一件事：读回 8 个保持寄存器，能读回来就说明物理层和串口参数没问题。

# -*- coding: utf-8 -*- # 最小连通性测试：只读不写，读回 8 个保持寄存器 from pymodbus.client import ModbusSerialClient # 3.7 之前用 slave=，3.7 及以后改成 device_id=，报 TypeError 时换一下关键字 client = ModbusSerialClient( port="COM3", # Linux 下一般是 /dev/ttyUSB0 baudrate=19200, # 必须和驱动器通信参数组里的波特率一致 bytesize=8, parity="E", # 偶校验，设成 N 要和驱动器一起改 stopbits=1, timeout=1, # 给 1s，太短会把慢响应误判成断线 ) if not client.connect(): raise SystemExit("串口打不开：查端口号、驱动、是否被别的软件占用") try: rr = client.read_holding_registers(address=0x0000, count=8, slave=1) if rr.isError(): print("从站返回异常：", rr) else: print([hex(v) for v in rr.registers]) finally: client.close()

代码里几个参数值得单独说。port是转换器枚举出来的串口号，插拔一次可能变，脚本里写死之前先确认。timeout不要给 0.2 秒这种值，驱动器在写 EEPROM 或者内部有任务时响应会慢半拍，超时太短会把正常响应判成断线。address这里是占位，实际要换成手册 Modbus 地址表里对应的起始地址。读回来是一串十六进制数就算通过，读不回来按第 5 章的排查顺序走。

3. 端子功能分配：H17 组偶数管功能、奇数管逻辑的配置顺序

物理层通了，接下来才是这套环境真正的核心：H17 组。它决定了 VDI 端子插上 24V 之后，驱动器认为你在让它干什么。这一组参数的编号规则很清楚：偶数位是功能选择，奇数位是逻辑选择。功能选择决定“这个端子做什么”，逻辑选择决定“什么电平算有效”。两件事分开配，配错任意一个，表现都是端子有信号但动作不对。

3.1 H17 组的编号规则：偶数选功能，奇数选逻辑

把 H17 组想成一组成对的参数，一对管一个 VDI 端子：

记住一句话：功能码是“这个端子叫什么名字”，逻辑是“按下去还是松开算数”。新手最常犯的错是把功能码写到奇数位上去，或者把逻辑值当功能值填，结果端子看着配了，动作完全对不上。

3.2 伺服使能 VDI1：H17.00 = 1，配套改 H17.01

伺服使能是整条链路的第一道开关。H17.00 写 1，意思是 VDI1 这个端子被赋名为“伺服使能”。但赋名不等于生效，还要看 H17.01 的逻辑选择：现场如果是常开按钮，按下才使能，逻辑配成常开有效；如果是安全回路串进来、断开才停机，逻辑要反过来。

常见做法是先按常开有效配，手动短接一下 VDI1 和 DI 公共端，看驱动器面板的使能状态位有没有变化。有变化说明端子和逻辑都对了，没变化就别往下配点动了，先解决这一层。

使能生效之后，电机轴会从自由状态变成锁死状态，用手转不动。这个手感变化是最直接的确认方式，比看面板状态位还快。

3.3 正反向点动：H17.02 = 18、H17.04 = 19

点动是两个端子配合的结果：VDI2 给正向点动，功能码 18；VDI3 给反向点动，功能码 19。写法就是 H17.02 写 18、H17.04 写 19，对应的 H17.03 和 H17.05 配逻辑。

这里有个容易忽略的细节：两个端子的逻辑要配成一致的有效方式。如果一个配常开有效、一个配常闭有效，现场用两个按钮控制时会出现“正转按钮松开才转、反转按钮按下就转”的怪现象。统一成同一种，调试的时候心不慌。

配完先别用通信发命令，直接短接端子试一次。端子动作正常，再去查 H31 组的通信命令，这样能把问题锁在通信侧，不用两边同时猜。

3.4 写入顺序、生效时机与掉电保存

参数写入顺序我建议是：先 H17.00/H17.01 这组使能，确认有效后再写 H17.02/H17.04 两个点动端子。一次性全写完，出问题时你不知道是哪一组的问题。

生效方式有两种：部分参数在线改立即生效，部分要断电重启。写完之后先读回来核对一遍，读回值和写入值不一致，多半是写了没保存，或者写到只读区去了。参数区写入有擦写时间，连续写多个参数时中间留 50ms 以上的间隔，不要一口气连着发。

注意：参数核对完再断电重启一次，重启后再读一遍。掉电丢失这件事，只在重启之后才暴露。

4. 动作链路配置：H31.00 的 0/3/5 与上位机写寄存器时序

端子配好之后，动作指令从哪来？H31.00 就是这条指令入口，它有三个值：0 停止、3 正向点动、5 反向点动。这个参数是电平保持型，不是脉冲型，写进去什么值，驱动器就按什么状态走，直到你再写一次。很多“电机停不下来”的情况，根子都在这里。

4.1 H31.00 的三个值：0 停止、3 正向点动、5 反向点动

点动的速度一般由单独的点动速度参数决定，不走正常运行的速度环。调试阶段先把点动速度压得很低，几十转每分钟的量级，等方向、使能、停止三件事都确认对了，再往上提。

一个必须养成的习惯：任何一次点动之后，无论中间是否报错，都要把 H31.00 写回 0。脚本里用 try/finally 包住，异常退出也保证回 0。

4.2 报文拆解：功能码 06 与寄存器地址换算

写单个保持寄存器用功能码 06，一帧是：站号 + 06 + 寄存器地址高字节 + 低字节 + 数据高字节 + 低字节 + CRC 低字节 + CRC 高字节。站号 1、地址占位 0x0000、写值 3 的时候，帧长这样：

01 06 00 00 00 03 CRC_L CRC_H

CRC 是整个帧除了 CRC 自身以外所有字节算出来的 16 位值，低字节在前。手算容易错，调试阶段别手搓，用工具生成。如果一定要看原始字节，串口助手切到 HEX 模式，与脚本对照着看。

寄存器地址这一步最容易翻车。手册里给的是参数号（比如 H31.00），Modbus 地址表里给的是保持寄存器偏移，两者之间还有一个“协议地址”和“PLC 地址”差 1 的老问题。做法是查手册的 Modbus 地址表，找到 H31.00 对应的偏移量，把它写进脚本里的常量，读到值不对就 ±1 试一次。

4.3 上位机时序：使能、点动、回 0 的三段式

完整的点动时序是三段：确认使能有效、发点动命令并保持一段时间、写 0 停止。下面这段脚本把三段串起来：

import time from pymodbus.client import ModbusSerialClient STATION = 1 ADDR_H31_00 = 0x0000 # 占位：换成手册里 H31.00 对应的保持寄存器地址 client = ModbusSerialClient( port="/dev/ttyUSB0", baudrate=19200, bytesize=8, parity="E", stopbits=1, timeout=1, ) client.connect() def write_param(addr, value): rq = client.write_register(address=addr, value=value, slave=STATION) if rq.isError(): raise RuntimeError(f"写 {hex(addr)} 失败: {rq}") time.sleep(0.05) # 参数写入有擦写时间，连续写要留间隔 def jog(direction, hold=1.0): cmd = 3 if direction > 0 else 5 # 3 正向点动，5 反向点动 write_param(ADDR_H31_00, cmd) time.sleep(hold) # 保持时间就是点动持续时间 write_param(ADDR_H31_00, 0) # 必须回 0，否则一直转 try: jog(+1, 1.0) time.sleep(0.5) jog(-1, 1.0) finally: write_param(ADDR_H31_00, 0) # 异常退出也保证停止 client.close()

hold是点动持续时间，调试时给 0.5 到 1 秒就够，看得到动作又不会撞到限位。write_param里那 50ms 的 sleep 不是凑数，EEPROM 擦写期间对下一条指令的响应会变慢，连续写不加间隔，偶发的写入失败非常难复现。finally块是必须的兜底，脚本被 Ctrl+C 打断时，这个块照样执行。

5. 排查：通信超时、端子不动作、点动反向的 5 个坑

这套环境的问题分布很有规律：物理层的问题表现为完全没回帧，参数层的问题表现为偶发错误，端子层的问题表现为命令发了没动作。按顺序排查，比乱改参数快得多。

5.1 通信层：三根线引发的三类超时

坑一：串口一开就超时，一个回帧都没有。

现象：脚本直接抛异常，串口助手发任何帧都没反应，转换器的收发指示灯也不闪。

原因：A/B 接反，或者只接了 A/B 没接 GND。也有一种情况是转换器的驱动没装好，端口号是假的。

解决：先对调 A/B 试一次；再把 GND 补上；最后换一个串口助手确认端口本身能打开。三步做完还没反应，换一只转换器，别在驱动上耗太久。

坑二：偶尔通，帧错误率高，十帧错一帧。

现象：同一个读命令，连续发十次，有八九次成功，一两次超时或返回乱码。

原因：终端电阻没装、星形拓扑、屏蔽层两端接地。这三种都指向信号反射和共模干扰。

解决：改成手拉手、首末端各并一只 120Ω、屏蔽层只在一端接地。改完把波特率降到 9600 再测一轮，如果 9600 稳定、19200 不稳，说明还是线的问题。

坑三：参数写进去了，断电重启又回默认值。

现象：写完 H17 组读回来是对的，断电再上电，值全变回去了。

原因：参数只写进了运行区，没触发保存；或者写入时正在使能状态，部分参数拒绝写入。

解决：先断使能再写参数，写完执行保存动作或者按手册要求断电重启，重启后读回核对。这一步不做，前面配的全白费。

5.2 端子与动作层：使能不上、单方向、停不下来

坑四：H17.00 写了 1，电机轴还是松的。

现象：参数读回来是 1，面板状态位没变化，手还能转动电机轴。

原因：VDI1 端子没有形成回路，DI 公共端没接 24V；或者 H17.01 逻辑配反了，实际是常闭有效。

解决：万用表量 DI 公共端对 0V 的电压，量不到 24V 就先解决供电；有电压就把 H17.01 逻辑改一次再试。

坑五：点动只往一个方向转，或者松手停不下来。

现象一：正向点动能转，反向点动没反应。

原因：只配了 H17.02 没配 H17.04，或者 H17.04 写成了功能码之外的值。

现象二：点动结束电机一直转。

原因：H31.00 没写回 0，通信断了但驱动器还保持着上一条命令。

解决：两个端子功能码逐项核对，H17.02 = 18、H17.04 = 19；停止靠脚本的 finally 兜底，另外在驱动器侧配一个通信超时保护，断线若干毫秒后自动停机。

6. 装完怎么验证跑通：三步联调与一份可复用的点检表

验证不靠“看着像是好了”，靠三步走完，每一层都有明确的通过标准。

第一步，空载通信验证。不发任何动作命令，只读寄存器，连续读 30 次，要求零超时。这一步过不了，后面所有验证都没有意义。

第二步，端子手测。用短接线直接短接 VDI1 和 DI 公共端，确认电机轴锁死；短接 VDI2，确认正向转；短接 VDI3，确认反向转。三个动作都对，说明 H17 组配完了。

第三步，通信点动联调。用第 4 章那段脚本，正向点动 1 秒、停 0.5 秒、反向点动 1 秒、回 0。要求转向和端子手测一致，停止指令之后电机立刻停住，不回 0 不会自己继续转。

联调的时候把每次的报文和现象记在表里，出问题直接对照，比凭记忆回想要可靠。我吃过一次亏：现场调好的参数没记录，第二天断了一次电，重启后点动不动作，从接线开始重查了一遍，最后发现是保存那一步漏了。从那以后我每次配完 H17 和 H31，都强制走一遍“读回、断电、再读回”的流程，不省这一步。希望帮到你。

本文还有配套的精品资源，点击获取