Modbus RTU读保持寄存器异常 接收响应与请求报文一致

你看到的接收报文是主站自身发送数据的回显，并非从站返回的真实响应，所谓「FC6写操作正常」是协议格式巧合导致的误判：

• Modbus RTU协议规定FC6（写单个保持寄存器）的从站正常响应，与主站发送的8字节请求报文结构、内容完全一致。当主站自发自收收到自己发出的报文时，CRC校验、报文格式均符合FC6响应要求，pymodbus会直接判定操作成功，但实际上从站从未收到有效请求、也未返回过应答，数据并未真正写入从站。
• 你抓到的FC3请求回显可以直接佐证这一点：发送报文为8字节0x32 0x3 0x1 0x30 0x0 0x1 0x80 0x3a，收到的7字节报文是发送报文的前7位，第三个字节为0x01，而正常FC3读1个寄存器的响应第三个字节必须是0x02（表示后续返回2字节寄存器值），完全不符合协议规范，因此pymodbus返回无响应异常。
• 该故障本质是RS485收发方向控制异常，主站发送完报文后未及时切回接收模式，一直占用总线发送权，从站根本无法向总线发送响应数据。

• MAX13487E自动方向切换时序不匹配：MAX13487E是自动收发控制芯片，逻辑为检测到DI引脚的发送起始位（低电平）时自动切为发送模式、驱动总线；DI引脚持续保持高电平（空闲态）超过1个位时间后切回接收模式。如果硬件RC延时参数配置不当、或软件未留足切换延时，会导致发送完成后芯片迟迟不切回接收模式，错过从站响应，同时自身发送的数据会通过RX引脚回灌到UART。
• BeagleBone UART配置错误：UART1引脚（p9_24/TX、p9_26/RX）复用配置错误、或开启了UART内部回环、串口终端模式开启了ECHO回显标志，都会导致发送数据直接被本地接收缓冲区捕获，出现自发自收。
• 总线硬件异常：MAX13487E的A/B引脚缺少上下拉电阻、终端电阻不匹配，会导致总线空闲电平不稳定，从站响应无法被正确识别。

• 第一步：验证硬件基础通路。断开所有从站，短接MAX13487E的A、B引脚，做自发自收测试，如果发送数据能被完整接收，说明芯片焊接、引脚复用基本正常；接上从站后用示波器测量A/B总线电平，确认主站发完请求后，总线上是否出现从站返回的波形，如果没有从站波形，说明主站一直占用发送通道。
• 第二步：正确配置BeagleBone UART1。执行以下命令临时配置引脚复用，长期使用需写入设备树overlay：

  config-pin p9_24 uart
  config-pin p9_26 uart
  

  配置时确认关闭UART内部回环功能，引脚模式设置为上拉。
• 第三步：修正pymodbus串口与通信参数。初始化ModbusSerialClient时，明确关闭串口回显、规范模式，增加收发切换延时：
  • 串口参数设置为8位数据位、1位停止位、无校验，波特率与从站保持一致
  • 关闭termios的ECHO、ECHONL、ICANON标志位
  • 设置turnaround_delay=0.002（2ms），给MAX13487E留足从发送切回接收的时间，避免发送完立刻读取接收缓冲区
• 第四步：校准MAX13487E硬件参数。检查芯片外围RC电路参数，RC时间常数需匹配当前波特率：以9600波特率为例，单字节传输时间约1ms，RC时间常数设置为0.8~1ms即可，保证最后一个字节发送完成后立刻切回接收模式，不会错过从站响应的第一个字节；A/B引脚间加120Ω终端电阻，A引脚接10k上拉到3.3V、B引脚接10k下拉到GND，保证总线空闲时电平稳定。
• 第五步：重新验证FC6操作真实性。完成上述配置后，执行FC6写操作后，用第三方正常主站读取对应寄存器值，确认数据确实写入从站，而非回波导致的假成功。

内容的提问来源于stack exchange，提问作者Charkrit_A