现场调 485 通讯，十个里有八个卡在同一个地方：线接对了、模块灯也闪，PLC 这边数据一动不动，或者干脆报个不明不白的错误码。你要问我最常见的症结，多半是指令用错了、格式字没配对、软元件占用没算清这三件事之一。这篇就把adprw 指令、FX3U 的 485 无协议通讯这两条最容易混淆的技术路线拆开讲清楚，从硬件选型、D8120 格式字计算、ADPRW 的报文时序，一直到无协议 RS2 的自定义帧收发，全部按现场能直接抄的结构来写。不管你是刚接手第一台变频器通讯的新手，还是被某个老仪表折腾过几轮的老手，下面这些内容应该都能对得上你的现场。
1. 概念先分清：ADPRW 与无协议通讯压根是两套东西
1.1 两条技术路线的本质差异
很多人搜"ADPRW 无协议通讯"，是因为被标题里的字面意思带偏了。ADPRW 严格来说不是无协议指令，它是一条走 MODBUS RTU 标准的专用指令。你在梯形图里写ADPRW K1 H03 H0000 K2 D100，PLC 内部会自动帮你拼帧头、算 CRC16 校验、等应答、把回包拆成数据字放好，你拿到的就是干净的寄存器值。整个过程你连 CRC 长什么样都不用管。
无协议通讯（也常被叫自由口、自由协议、Free Protocol）走的是另一条路：RS2 指令负责把一串原始字节发出去，再把回来的原始字节收进来。帧头是什么、数据几位、校验怎么算、什么时候算一帧结束，全部由你自己在程序里定义。设备手册给你一张"命令帧格式表"，你就照着拼，它让你发0xAA 0x55 ...，你就得发这八个字节，一个都不能少。
两条路线的差别，用生活里的场景类比就很清楚：ADPRW 像是寄快递用标准面单，收发两端都认这套规则，你只管填地址；无协议像是自己写信，信封、邮票、暗号全得自己约定，万一对方理解的暗号和你不一样，信就丢了。所以选型的判断标准也很简单——对方设备手册里有没有明确写"支持 MODBUS RTU"。写了，优先 ADPRW；没写，或者写了但只有一张自定义帧表格，那就只能走 RS2。
1.2 选型判断：翻设备手册的哪一页
我在现场翻手册有个固定顺序：先找"通讯协议"章节，看有没有"MODBUS"字样；再找"通讯地址表"，看是40001这种寄存器编号，还是0x10 命令码 + 数据这种自定义格式。前者基本能确定是标准 MODBUS，后者就是私有协议。
有个容易被忽略的点：很多设备的"通讯地址表"是从 1 开始编号的，而 ADPRW 的地址操作数是从 0 开始的协议地址。手册上写"40001 对应温度值"，你在 ADPRW 里填的是H0000（也就是 K0），不是K40001，也不是K1。这个差一位的问题，我在现场见过太多次——数据读回来了，但是始终是隔壁那个参数的值，怎么调都不对，最后发现是地址偏移了一位。
还有一类设备更"拧"：协议是 MODBUS 没错，但只支持功能码 03 不支持 04，或者线圈写单个支持、写多个不支持，再或者对帧间隔时间有严格要求。这类情况我在第 4 章会专门讲怎么用轮询和超时兜底。
至于方案的影响范围，说个实在的边界：一台 FX3U 最多两块 485 模块（通道 1 和通道 2），每个通道下面挂 32 个从站是比较稳的量级，再多就要考虑响应时间和轮询周期了。如果你的项目是十几台温控表、几台变频器这种规模，单通道轮询完全够用；上百个点位又要保证实时性，那就该考虑换更强的控制器或者走总线了，这不是硬凑能解决的。
2. 硬件与接线：485 现场最容易翻车的地方
2.1 模块型号决定指令能不能用
这一条必须先说，因为它决定了你后面所有的努力有没有意义。FX3U-485BD 这块板子不支持 ADPRW 指令，它只能做无协议或者专用协议通讯。要用 ADPRW，必须上 FX3U-485ADP-MB 这个带 MB 后缀的适配器，或者用通讯扩展板转接的方式挂在通道上。我见过有人拿着 485BD 照着网上的 ADPRW 例程抄，编都编不过去，或者编过了运行起来状态字一直报错，折腾一整天才发现型号不对。
硬件上还有一个细节：485ADP-MB 接通道 1 还是通道 2，对应的特殊寄存器完全不一样。通道 1 用 D8120、通道 2 用 D8420；通道 1 的接收完成标志是 M8123，通道 2 是 M8433。这个对应关系写错了，程序表面上看不出任何问题，就是收不到数据，非常隐蔽。
我的习惯是：程序开头就写注释把"本程序使用通道 X"标清楚，配上对应的特殊寄存器列表。项目交接的时候能省下后来人半小时。
2.2 双绞、屏蔽、终端电阻的实操处理
485 是差分信号，A、B 两根线必须用双绞。现场最常见的错误是拿了两根普通单芯线或者平行线接了事，短距离可能能通，线一长或者旁边有变频器，误码就上来了。屏蔽层的处理也有讲究：单点接地，一般选在 PLC 这一侧接屏蔽，从站侧屏蔽层悬空，别两头都接，否则地电位差会形成环流，反而把信号搅乱。
终端电阻是另一个高频问题。线长超过 50 米或者波特率上到 19200 以上，总线两端（最远的两台设备）各接一个 120Ω 电阻。中间节点不需要接。有些模块自带拨码开关或跳线，直接拨上去就行；没有的话就外挂电阻在接线端子上。反过来，如果线只有三五米、波特率 9600、就挂两三台设备，终端电阻不接通常也没什么问题，硬接反而增加负载。
还有一点经验：A、B 线接反是 485 现场第一大户。有的设备标 A/B，有的标 D+/D-，有的标 +/−，各家定义还不完全统一。现象是通信完全无响应，但模块指示灯可能还在闪。处理办法很简单——先测一下两根线之间的静态电压差，正常应该在 0.2V 到 1V 量级，然后用排除法反接试试，两分钟的事，不要在那怀疑程序。
3. 通信格式字：D8120 与 D8420 的逐位拆解
3.1 位定义与常用组合计算
格式字是一条 16 位的数据，每一位管一件事。低字节管物理层参数，高字节管协议和帧结构。我把它拆成表，方便你对着算：
| 位区间 | 名称 | 取值含义 |
|---|---|---|
| b0 | 数据长度 | 0=7 位，1=8 位（MODBUS 必须 8 位） |
| b1~b2 | 校验方式 | 00=无，01=奇校验，10=偶校验 |
| b3 | 停止位 | 0=1 位，1=2 位 |
| b4~b7 | 波特率 | 1000=9600，1001=19200，1010=38400，1011=57600，1100=115200 |
| b8 | 起始符 | 0=无起始符 |
| b9 | 终止符 | 0=无终止符 |
| b13 | 校验和 BCC | 0=无 |
| b14~b15 | 协议选择 | 与模块型号、固件版本相关，按手册设定 |
低字节的算法其实很直接。举个最常见的组合：9600 波特率、8 位数据、无校验、1 位停止位。8 位数据 → b0=1；无校验 → b1b2=00；1 位停止位 → b3=0；9600 → b4~b7 是二进制1000。把它们拼起来，低字节就是1000 0001，写成十六进制是H0081。
再举一个：19200、8 位、偶校验、1 位停止位。b0=1，b1b2=10，b3=0，b4~b7=1001。拼起来是1001 0111，也就是H0097。你可以拿这个规律去算任何组合，比翻手册查表快得多。
高字节这块我要提醒一句：b8 以上的含义在不同固件和不同模块上是有差异的，特别是协议选择位。所以我不建议你手算整个 16 位字，工程上更稳妥的做法是只关心低字节的物理参数，协议模式交给参数设置界面处理。
3.2 两种设置途径与踩坑提醒
设置格式字有两条路：
第一条是在编程软件的 PLC 参数里设串行通信，选好通道、波特率、数据位、校验、停止位，再选通讯模式（MODBUS RTU 或专用/无协议）。下载程序时参数一起写进去，D8120 会被自动赋值。这条路最省心，我强烈推荐新手走这条。
第二条是在程序里用MOV H0081 D8120直接写。这条路灵活，适合需要运行时切换参数或者做多套配置的场合，但要求你自己把高字节也配对。
这里有个非常经典的坑：只改了波特率和数据位，没改协议模式位，ADPRW 指令执行后状态字一直报错。因为 ADPRW 内部要求通道处于 MODBUS 模式，如果你还是无协议模式，指令根本发不出去。表现就是状态字非 0 而且数值固定不变。我个人的做法是：涉及 ADPRW 的工程，一律用参数设置界面的方式配 MODBUS 模式，程序里不再写 D8120，减少一层出错的可能。
还有一个时序问题：如果确实要在程序里写 D8120，必须在通讯指令执行之前完成赋值，而且要留出一个扫描周期以上的间隔。我一般在初始化段用 M8002（首次扫描脉冲）触发一个 MOV，后面挂个定时器延时 100ms 再允许通讯，稳一点。
提示：格式字改完必须断电重启或者让模块重新初始化一次，有些参数不是立即生效的。改完参数不重启就测，很容易误判成"设置无效"。
4. ADPRW 指令实操：读一台温控表的保持寄存器
4.1 操作数逐个拆解与软元件占用
ADPRW 有五个操作数，按顺序是：从站站号、功能码、地址、点数、数据区起始软元件。拿一条典型的读取指令举例：
ADPRW K1 H03 H0000 K2 D100K1是从站站号，范围 1 到 247，其中 0 是广播地址，一般不用它读。H03是功能码，读保持寄存器用 03，读输入寄存器用 04，读线圈用 01，读离散输入用 02，写单个寄存器用 06，写多个寄存器用 10（十六进制的 H10，也就是十进制的 16）。H0000是协议地址，对应手册上的 40001。K2是点数，读 2 个寄存器。D100是数据落地的地方。
软元件占用是最容易算错的部分，必须单独说。读取时，数据放在 D100 到 D101（共 2 个字），完成状态放在D102，也就是"起始地址 + 点数"的那一个位置。所以这条指令实际占用了 D100、D101、D102 三个字。写入时，D100 到 D101 是你要发出去的数据，完成状态在 D102。
我强调这个是因为踩过坑：有一次程序里 D100 往后正好是 PID 参数区，读回两个寄存器后把 D102 的积分时间给覆盖了，现象是温度控制偶尔抽风，查了两天才定位到。ADPRW 的数据区后面一定要留出一个字的空位，而且这个字不要用于其他逻辑。
另外还有一个区分位软元件和字软元件的细节：功能码 01 和 02 是读线圈状态的，数据按位处理，起始软元件要填 M 区这类位软元件；功能码 03、04 是读寄存器的，按字处理，填 D 区。填错了不会报语法错，但数据全乱。
4.2 报文帧结构与时序
要真正理解 ADPRW 在干什么，得看一眼它发出去的报文长什么样。以站号 1、读地址 0 开始 2 个保持寄存器为例，总线上跑的是这样一串字节：
| 方向 | 字节内容 | 说明 |
|---|---|---|
| 请求 | 01 | 从站站号 |
| 请求 | 03 | 功能码 |
| 请求 | 00 00 | 起始地址高字节在前 |
| 请求 | 00 02 | 寄存器数量 |
| 请求 | CRC 低 | 校验低字节 |
| 请求 | CRC 高 | 校验高字节 |
| 响应 | 01 | 从站站号 |
| 响应 | 03 | 功能码 |
| 响应 | 04 | 后续数据字节数 |
| 响应 | xx xx xx xx | 4 个字节即 2 个寄存器 |
| 响应 | CRC 低 | 校验低字节 |
| 响应 | CRC 高 | 校验高字节 |
整个过程分成"发请求—等应答—解析入库"三段。ADPRW 的驱动条件给一个上升沿之后，指令内部会自己走完这三段，不需要你保持条件为 ON。用脉冲触发是关键，如果驱动条件一直保持 ON，指令在完成后会再次执行，总线上就会出现连续的重复请求，从站可能还没处理完就收到下一帧，导致丢包。
等应答的时间，模块内部有超时监控，超了之后会往状态字里写一个异常代码。但我建议外部再加一个定时器兜底，比如给 500ms 的监视时间，超时就置一个"通讯异常"标志，让画面报警，同时跳过去轮询下一个站。因为如果某一台设备掉电或者线断了，全靠内部超时的话，整个轮询链会长时间卡在这里，其他站的数据全都不刷新了。
4.3 可复用的轮询程序框架
下面这套框架我在好几个项目里都用过，结构简单，改站号就能复用：
// 1. 参数初始化（首次扫描） LD M8002 MOV H0081 D8120 // 通道1：9600, 8位, 无校验, 1位停止（MODBUS模式建议用参数界面设置） MOV K0 D200 // 轮询步序号清零 // 2. 定时触发一轮轮询 LD M8000 OUT T0 K50 // 500ms 触发一次 LD T0 PLS M10 // 3. 轮询步进：站号 1 -> 2 -> 3 -> 回到 1 LD M10 AND= D200 K0 MOV HFFFF D102 // 预置状态字，防止"未执行"被误判成"成功" ADPRW K1 H03 H0000 K2 D100 MOV K1 D200 LD M10 AND= D200 K1 MOV HFFFF D112 ADPRW K2 H03 H0000 K2 D110 MOV K2 D200 LD M10 AND= D200 K2 MOV HFFFF D122 ADPRW K3 H03 H0000 K2 D120 MOV K0 D200 // 4. 结果判断：状态字为 0 表示正常 LD M8000 AND= D102 K0 MOV D100 D300 // 1号站数据转存 LD M8000 AND<> D102 K0 SET M500 // 通讯异常报警这套写法的核心思路是：用状态字代替"等待完成"。传统写法是盯着完成位等，容易死等；用状态字 + 定时轮询的方式，每一轮都会重新发起，即使某一次失败，下一轮还会重试，系统自愈能力更好。
预置HFFFF这个动作看着不起眼，但实实在在解决了一个隐蔽问题：D102 上电默认是 0，如果第一轮指令还没来得及执行，程序读到 0 就认为"通讯成功"，把初始的 D100（也是 0）当成真实温度值送进画面，操作工会以为温度真的是 0 度。预置非 0 之后，未执行的状态就是"异常"，逻辑上干净很多。
5. 无协议 RS2 指令：自定义帧的收发
5.1 自由口适用的场景
有些设备就是不走 MODBUS。比如一些老款称重仪表，帧格式是02 xx xx xx 03（STX + 数据 + ETX），校验就是一个简单的和校验；再比如某些扫码枪、打印机、条码秤，协议是厂家自己定的。这类设备 ADPRW 完全派不上用场，只能走自由口。
自由口的好处是什么帧都能拼，坏处是什么都得自己算。帧头、长度、数据、校验、帧尾、超时、粘包处理，一个环节没照顾到，数据就串位了。
用 RS2 之前，格式字必须设成无协议模式。我一般用H0081（9600、8 位、无校验、1 位停止），如果是 7 位数据加偶校验的老设备，就设成H00A1之类的组合，按第 3 章的算法自己推。8 位数据模式下一个字放两个字节，高位在前低位在后，拼帧的时候要特别注意字节序，这是新手最容易写反的地方。
5.2 发送、接收、超时三段式写法
RS2 指令的操作数是：发送数据起始、发送字节数、接收数据起始、接收字节数、接收完成标志。
// 拼帧：把 6 个字节装进 D400 开始的 3 个字 LD M8002 MOV H02AA D400 // 帧头 0x02 + 命令码 0xAA MOV H0100 D401 // 数据高字节 0x01 + 数据低字节 0x00 MOV H0300 D402 // 校验 0x03 + 帧尾 0x00 // 发送 + 接收 LD X10 PLS M20 LD M20 RS2 D400 K6 D410 K10 M30 // 发 6 字节，最多收 10 字节，完成标志 M30 // 接收完成处理 LD M30 MOV D410 D420 // 转存首字 RST M30 // 手动复位完成标志 // 超时兜底：发了之后 300ms 没收到就报警 LD M20 OUT T10 K30 LD T10 AND= M30 K0 SET M501这里有三个细节值得展开说。
第一，接收完成标志 M30 必须手动复位。它是电平型的，一旦置位就保持，你不复位，下一帧来的时候它一直是 ON，程序没法区分"新的完成了"还是"老的还挂着"。所以每次处理完立刻 RST 一下。
第二，发送字节数按字节算，不是按字算。D400 到 D402 是 3 个字，但实际发出去 6 个字节。填 K3 只会发出前三个字节，剩下的丢了，对方回的帧自然对不上。
第三，接收缓冲区要留余量。你填 K10，意思是"最多收 10 个字节"，实际收到 6 个字节也是正常的，不要去数"为什么没收满"。反过来说，如果你填的 K 值比实际帧短，超出的部分会被截掉，校验位就没了。
5.3 变长帧和校验处理
固定长度的帧好办，麻烦的是变长帧。比如仪表回02 LEN DATA... CRC 03，其中 LEN 字节告诉你后面有几个数据字节。这种帧不能靠"收满 N 个字节"来判断结束，要靠帧尾特征字节。
我的处理套路是：接收缓冲区设得比最大帧长还要大一点，接收完成标志置位后，在程序里逐字节扫描找帧头和帧尾，找不到帧尾就说明这帧不完整（可能是被拆成了两次），直接丢弃重来。这个"扫描 + 丢弃"的逻辑用 ST 或者梯形图的循环指令都能写，代码大概二三十行。
校验这块分类处理：
- 和校验 / 异或校验：简单，累加或者异或一遍就行，用 FOR 循环或者手写几段 ADD 都能搞定。
- CRC16：如果是标准 MODBUS CRC，而你又用自由口，那就要自己算。这种情况我的建议是——能回退到 ADPRW 就回退，因为手写 CRC 查表要占不少程序步，而且容易写错初值和多项式。真躲不开的话，用预置的 256 项查表法，网上常见的算法改一改就能用，别自己硬推公式。
还有一个隐形坑：帧间隔时间。MODBUS RTU 要求帧之间至少 3.5 个字符时间的静默，自由口设备往往也有"两帧之间要隔多久"的要求。如果轮询得太快，从站会认为这是同一帧的延续，数据就乱了。解决办法就是在每次发送后加一个小延时，9600 波特率下 10ms 到 20ms 通常够用。
6. 排查实录：485 通讯最常踩的坑
6.1 现象、原因、对策速查表
下面这张表基本覆盖了我这些年遇到的九成问题，调试时可以照着对：
| 现象 | 大概率原因 | 排查动作 |
|---|---|---|
| 完全无响应，模块灯不闪 | A/B 接反、线路断路 | 反接线试；测 A/B 间静态电压差 |
| 模块灯闪但数据不更新 | 站号填错、波特率不一致 | 核对从站面板上的站号和波特率 |
| ADPRW 状态字固定报同一错误 | 通道未设为 MODBUS 模式 | 查 PLC 参数里的通讯模式设置 |
| 数据能读但全是 0 或固定值 | 地址偏移一位、软元件类型填错 | 地址减 1 试；检查 M/D 软元件 |
| 读回来的数值高低字节颠倒 | 字节序问题 | 用 SWAP 或者 XCH 交换字节 |
| 多站轮询时偶发丢数据 | 轮询过快、无超时兜底 | 加间隔时间；加超时跳步 |
| 通讯几小时后突然中断 | 干扰、终端电阻缺失、接地问题 | 加屏蔽单点接地；两端加 120Ω |
| 写入成功但设备不动作 | 功能码不对、只写了单寄存器 | 确认设备支持的写功能码 |
| 上电后必须断电重启才通 | 格式字未生效 | 参数改完断电重新初始化 |
6.2 几条不写在手册里的经验
第一条：先用手册例程通一次，再上自己的程序。我见过太多人一上来就直接写完整程序，调试时怀疑程序逻辑、怀疑地址、怀疑接线，变量太多反而找不到原因。正确姿势是：裸线接好，一段最简的读取指令，一个站号，读一个寄存器，通了之后再把框架套上去。通了说明物理层和基本配置没问题，后面所有问题都在程序逻辑里，排查范围一下缩小百分之八十。
第二条：状态字是唯一可信的判据。不要靠"灯在闪"判断通讯正常，也不要靠"数据看着像对"判断成功。ADPRW 的状态字为 0 才算这一帧成功，其他数值都是异常。养成先把状态字读出来看、再去看数据的习惯，能省下大量时间。
第三条：把异常代码抄下来查。ADPRW 状态字返回的不是 0 的时候，那个数值是有具体含义的（比如从站无响应、CRC 错误、功能码不支持），手册上有对照表。很多人一看非 0 就重启，重启不好就蒙了。抄下来查一次，下次再见就有数了。
第四条：扫描周期暴涨往往就是通讯卡住。一台 PLC 之前跑得好好的，加了通讯之后扫描周期从 5ms 涨到 30ms，多半是某个指令在死等应答。检查一下是不是驱动条件一直保持 ON、是不是没加超时兜底。通讯类指令一定要当成"可能失败的外部交互"来设计，不能假设它一定成功。
第五条：多站轮询的周期要算一下。9600 波特率下，一次读 2 个寄存器大约 15 个字节的往返，加上帧间隔和从站响应时间，保守估 50ms 一站。挂了 20 个站，一轮就是 1 秒。如果你的工艺要求每个点 200ms 刷新一次，那这套方案本身就不成立，得换思路或者减少点位。
我个人在实际项目里的体会是，485 通讯这东西，难点从来不在指令语法上——ADPRW 五个操作数，看十分钟手册就会填了。真正耗时间的是那些看不见的地方：一根接反的线、一个没生效的格式字、一位错位的地址、一处被覆盖的软元件。这些内容手册上不会单独拎出来讲，只能靠现场一个一个撞过去。所以每次开新项目，我都会先把"物理层验证 → 单站单点通讯 → 多站轮询 → 异常兜底"这四步按顺序走完，一步不跳，后面能省下的时间远比这四步花的多。
