西门子S7-1200主从PLC通信编程实战：Modbus RTU从零到联调

两台S7-1200各管一个工艺段，中央控制柜还要把数据汇总；或者一台1200带了一堆远程设备，需要轮询采集模拟量、开关量，再下发执行信号——这种现场在中小型自动化项目里实在太常见了。"西门子1200主从PLC编程与应用指南"这个需求，说到底就是要把主站和从站之间的数据链路打通，并且打得足够稳。我自己在项目里反复做过几次从零到联调的双1200通信，今天把踩过的坑和最终跑通的方案一起整理出来，不讲虚的，全是能直接抄作业的东西。

我会从方案选型讲起，再到硬件组态、主站从站两侧的程序骨架，最后是联调排错和性能优化。不管你是第一回接触1200通信，还是在现场已经被通信故障折磨了好几天，这篇文章都能给你一条清晰的排查路径。

1. 先想清楚：两台1200之间到底该走哪条通信链路

1.1 主从架构解决的真实问题

主从通信的典型场景有三种：第一种是分布式数据采集，若干台从站 PLC 分布在车间不同位置，主站统一轮询；第二种是主控与子站的联动，一台主机控制多台设备，每个子站独立运行但需要主机下发配方、启停指令；第三种是"镜像站"式的主备切换，两台 PLC 互为冗余，通过主从通信同步关键数据。不管是哪一种，核心诉求都指向同一点：用最低的接线成本换取可预测的通信时序。

Modbus 这类主从协议最大的优势在于总线仲裁简单。总线上只有一个主动发起通信的主站，从站永远被动应答，不存在碰撞和竞争问题，时序是可计算的。这也是为什么即便以太网方案已经很普及，RS485 总线在主从场景里依然是很多项目的第一选择。

1.2 四种常见方案的取舍对比

S7-1200 做主从通信，现实世界里主要就四条路：Modbus RTU、Modbus TCP、PROFINET I-Device、S7 协议（PUT/GET）。选型时我从四个维度去卡：物理层接线、实时性、开发量、后续维护。

只看表格，很多人会倾向 Modbus TCP，毕竟不用查接线。但实际项目中 Modbus RTU 依然占大头，核心原因不只是距离，而是接入设备的兼容性。现场很多变送器、仪表、变频器都只带 RS485，你不可能为了这些老设备非得额外加网关；而且 1200 的通信模块成本可控，RS485 双绞线敷设也远比网线省事。

1.3 为什么大多数项目把 Modbus RTU 当作默认答案

选 Modbus RTU 还有一个经常被忽略的好处：它不依赖 IP 地址分配。从站只需要一个 1~247 的站号，不存在网段冲突、IP 被占、网关隔离这些网络问题。这对现场维护非常友好，新换一台从站设备，拨码设好站号就能顶上，不用拿着笔记本去改IP。

当然它的短板也明显：半双工通信，同一时刻只能一问一答；数据量大的时候轮询一圈周期会偏长；距离超过一千米需要加中继。但这些短板在"两台1200之间交换几十个字"这种需求面前完全不是问题。我的原则很简单：距离超100米、现场干扰大的，优先 RTU；距离短、又有现成交换机的，才考虑走 Modbus TCP。

2. 硬件扩展与组态准备：1200的串口不是想用就有

2.1 确认CPU与通信模块：本体的PN口不能跑RS485

第一次做1200通信的人最容易犯的第一个错误，就是以为 CPU 本体自带串口。实际上绝大多数 S7-1200 CPU（1211C/1212C/1214C/1215C）本体只有一个 PROFINET 网口，默认没有RS485接口，Modbus RTU 必须靠通信模块扩展。常用的是 CM 1241 RS485 和 CB 1241 RS485 两款，前者是标准通信模块，后者是板载模块，区别主要在安装方式和价格，编程接口完全一致。

选型时还要留意 CPU 的扩展能力限制：1211C 和 1212C 因体积限制，右侧只能扩展一块通信模块；1214C 及以上的型号可以挂多块。如果项目确定要做双主站或者一主+其它通讯，建议早期就直接选 1214C，别为了省几百块钱把自己框死。

通信模块的信息不是靠 I/O 地址读写的，而是靠"硬件标识符"（HW ID）来寻址。组态完成后，在 TIA Portal 的设备视图里选中模块，属性里能看到这个 ID，后续 MB_COMM_LOAD 指令的 PORT 参数填的就是它。我见过有人在这里填成 IP 地址或者站号，结果通信块一直报错，这是典型的参数错位。

2.2 TIA Portal 装载 Modbus 库的正确姿势

S7-1200 的 Modbus 指令不是 CPU 系统自带的，需要从 TIA Portal 的指令库中单独装载。打开软件后，在"全局库"面板中打开 Something like "Modbus" 库模板，确认库版本和你的 TIA Portal 版本匹配。不同 TIA 版本装载的库文件不一样，V15、V16、V17 之间库版本混乱是家常便饭，装了之后指令块显示成黄色叹号，多半是版本问题。

Modbus 库中核心指令有三个：MB_COMM_LOAD 负责通信模块的串口参数初始化，MB_MASTER 负责作为主站发起请求，MB_SLAVE 负责作为从站响应请求。需要注意，在同一通信模块上，不能同时运行 MB_MASTER 和 MB_SLAVE，模块只能确定一种角色；但一个项目里多块通信模块可以分别做主站和从站。

另一个细节是背景 DB 必须独立。MB_MASTER 和 MB_SLAVE 指令都会要求分配背景 DB，这个背景 DB 会作为 MB_COMM_LOAD 的 MB_DB 参数被绑定。换句话说，通信模块初始化时就要告诉系统"我这块模块上的主站/从站指令用的是哪个背景数据块"，一旦绑定，运行过程中就不要再改动，否则容易出现指令冲突或通信中断。

2.3 地址规划：Modbus寄存器类型与PLC内存的对应关系

做主从通信，首要任务是建立一张"地址对照表"。Modbus 协议里寄存器分四种：线圈（Coil）、离散输入（Discrete Input）、输入寄存器（Input Register）、保持寄存器（Holding Register）。实际项目中最常用的是两种：保持寄存器（可读可写，16位）和输入寄存器（只读，16位），线圈偶尔用于开关量下发和状态回读。

S7-1200 作从站时，这些寄存器不直接对应 I/Q/M 区，而是通过 MB_SLAVE 指令参数映射到数据块（DB）内部的数组。也就是说，你得先在 DB 里规划保存区的结构，再告诉 MB_SLAVE 哪个数组当保持寄存器区、哪个数组当输入寄存器区。

我一般按下面的结构做从站地址规划：

规划的原则是"读写分区、状态与数据分区"。命令区和状态区不要混在同一个连续段里，否则主站写命令时容易误覆盖状态字。这些地址规划敲定后，再去写程序，后面联调会顺畅得多。

3. 主站侧编程：MB_COMM_LOAD初始化与MB_MASTER轮询的完整套路

3.1 MB_COMM_LOAD只在启动时做一次成功初始化

主站程序的第一个功能块是 MB_COMM_LOAD，它负责把通信模块的串口参数（波特率、校验、停止位）配置到协议栈。这个块只在 PLC 首次运行或模块重新上电后需要执行一次，不需要在扫描周期里反复调用。

典型的调用方式是用一个启动标志。我用 SCL 写的话大致是这样：

#InitDone := FALSE; // 初始化完成标志，可在OB100里初始赋值 IF NOT #InitDone THEN #InitReq := TRUE; END_IF; "MB_COMM_LOAD_DB"( REQ := #InitReq, PORT := 269, // 通信模块的硬件ID，在设备视图属性中查 BAUD := 9600, // 波特率，和从站必须一致 PARITY := 2, // 2=偶校验，0=无校验，1=奇校验 MB_DB := "MB_MASTER_DB", // 绑定主站指令背景DB ERROR => #InitError, STATUS => #InitStatus ); IF "MB_COMM_LOAD_DB".DONE THEN #InitReq := FALSE; #InitDone := TRUE; END_IF;

这段代码的关键在于DONE 位出现后才撤销 REQ，不能一上电就一直保持 REQ 为真。DONE 是初始化完成的脉冲，靠它复位请求信号，既保证初始化只做一次，又避免反复触发初始化导致模块复位。

初始化的状态字 STATUS 值得盯一次。如果 STATUS 返回非 0 的错误代码，PLC 在线状态和通信模块都不太可能正常。常见错误包括 PORT 参数填成了 CPU 网口的硬件ID、波特率超过模块支持范围、MB_DB 没有关联到 MB_MASTER 的背景数据块。这些错误在初始化阶段就会暴露，所以不要急着往下写轮询，先把这条指令的状态跑到 0 再说。

3.2 MB_MASTER轮询：一次只能做一个请求

MB_MASTER 的机制可以理解成"一次只做一件事"。它通过 REQ 上升沿发起一个 Modbus 请求，之后 BUSY 位会保持为真，直到本次请求完成（收到应答或超时）。在这个 BUSY 期间，你不能再次给 REQ 上升沿，否则指令会报错。因此主站程序的核心任务是轮流给不同的请求产生上升沿。

轮询队列我通常用一个"轮询计数器 + CASE 语句"的结构实现。每个请求占一个编号，计数器每隔一个周期递增，递增后只触发一次当前请求对应的 REQ，然后等待其 BUSY 取消。以读取从站保持寄存器为例：

#CycleCounter := #CycleCounter + 1; IF #CycleCounter >= 3 THEN #CycleCounter := 0; END_IF; CASE #CycleCounter OF 0: #MB_ADDR := 5; // 从站站号 #MODE := 0; // 0代表读保持寄存器 #DATA_ADDR := 0; // Modbus地址偏移，对应40001 #DATA_LEN := 10; // 读10个字 #DATA_PTR := "Main_Data".ReadBuf[0]; // 注意指向数组首元素 1: #MB_ADDR := 6; #MODE := 0; #DATA_ADDR := 0; #DATA_LEN := 20; #DATA_PTR := "Main_Data".ReadBuf2[0]; 2: // 写操作等其他请求 END_CASE; IF NOT #Busy AND NOT #NewReq THEN #NewReq := TRUE; #ReqCmd := #CycleCounter; END_IF; IF #ReqCmd = #CycleCounter AND NOT #Busy THEN "MB_MASTER_DB"( REQ := #NewReq, MB_ADDR := #MB_ADDR, MODE := #MODE, DATA_ADDR := #DATA_ADDR, DATA_LEN := #DATA_LEN, DATA_PTR := #DATA_PTR, BUSY => #Busy, ERROR => #Error, STATUS => #Status ); #NewReq := FALSE; END_IF;

这段代码的重点是 DATA_PTR 的写法。很多人把 DB 的符号名直接填进去，结果 MB_MASTER 一直报指针错误。正确做法是指向数据块中数组的首元素，而且该数据块必须关闭"优化的块访问"属性。

一个请求完成判断不能只等 BUSY 变 FALSE，还要结合状态字：STATUS 为 0 表示正常完成，非 0 表示错误。超时是最常见的错误，特别是总线上同时挂着多台从站时，某台从站在轮询周期内没有应答，主站 STATUS 会报出一个超时错误码，此时程序应该记录故障并跳过这一次，继续轮询其它从站，而不是停在整个轮询队列里不动。

3.3 主站程序的整体架构建议

完整的主站程序，我会分成三个部分：

• 启动段：MB_COMM_LOAD 初始化串口参数；
• 轮询段：MB_MASTER 依次对不同从站、不同寄存器区发起请求；
• 数据处理段：把读到的原始字按规划表解析为实际工程值，写入公共数据区。

数据处理段容易被忽略，其实这才是主站 PLC 真正干活的部分。从站读到的是原始 Modbus 字，比如一个4~20mA 信号经过从站 AI 模块转换后，存进去的是一个 0~27648 的整数。主站侧如果不做线性换算就把这个值拿去用，后面画面和报表全是莫名其妙的小数。我通常会在读取完成后立即根据量程上下限做换算，并把结果存成 REAL 类型，放到 HMI 可以直接访问的 DB 里。

这里要提醒一个很隐蔽的坑：MB_MASTER 的 DATA_LEN 单位是"字"，不是字节。读 10 个字，DATA_LEN 就填 10。有次我在现场看到同事填了 20，理由是"10个字等于20字节"，结果从站一直报地址越界。从站的保持寄存器是按字编址的，请求长度就得按字数算，千万别自行换算。

4. 从站侧编程：MB_SLAVE的地址映射与程序骨架

4.1 MB_SLAVE的基本用法

从站侧比主站简单得多，核心就是一个 MB_SLAVE 指令，每个扫描周期调用一次。它的工作方式是：通信模块硬件收到主站的请求后自动应答，MB_SLAVE 指令只负责把主站请求读写的地址与 PLC 数据区做映射。

从站初始化同样走 MB_COMM_LOAD，只是绑定的 MB_DB 参数换成 MB_SLAVE 的背景 DB。如果你的 PLC 只做从站，初始化块和 MB_SLAVE 块放在同一个 OB1 里持续扫描即可；如果 PLC 某块通信模块作主站，另一块作从站，就要单独为每块模块调用对应的通讯指令和各自的背景DB，互不干扰。

4.2 从站数据DB的结构设计：取消优化访问是关键

从站的寄存器映射区需要独立规划。我喜欢定义一个专门的 DB，结构大致如下：

DATA_BLOCK "Modbus_Slave_Data" { HoldReg_ReadWrite : Array[0..49] OF Word; // 对应40001-40050 InputReg_ReadOnly : Array[0..29] OF Word; // 对应30001-30030 Coil_ReadWrite : Array[0..15] OF Bool; // 对应00001-00016 }

然后在 FB 里把数组首元素的地址传给 MB_SLAVE：

"MB_SLAVE_DB"( MB_ADDR := 5, // 本站站号 MB_HOLD_REG := "Modbus_Slave_Data".HoldReg_ReadWrite[0], MB_INPUT_REG := "Modbus_Slave_Data".InputReg_ReadOnly[0], MB_COILS := "Modbus_Slave_Data".Coil_ReadWrite[0], MB_MODE := 0, // 0=允许读写访问 ERROR => #SlaveError, STATUS => #SlaveStatus );

之所以必须取消"优化的块访问"，是因为 Modbus 指令通过指针访问 DB 内部的物理连续存储区。优化访问的数据块经过编译器重新排列，无法保证数组元素在内存中连续并按字对齐。做法是在 DB 属性里把"优化的块访问"勾选框去掉，或者建 DB 时直接选择标准 DB。这个坑我在项目里遇到过不止一次，症状是 MB_SLAVE 指令能运行但数据完全不刷新，或者通信状态字报地址错误。

4.3 从站内部的数据刷新与一致性处理

从站程序除了挂 MB_SLAVE，还得有真正的业务逻辑：把传感器信号写入输入寄存器区，把主站下发的保持寄存器区命令解析成本地输出。这里最容易出现的问题就是数据一致性和通信标志。

典型例子：主站写 10 个保持寄存器，包含"启停命令、设定转速、回零点位置"，从站程序每秒读取一次这个数组并送去做逻辑判断。若主站分两次写（先写命令字再写参数），从站可能读到"命令=启动，参数还没来得及更新"的中间状态。解决办法有两种方向：一是主站侧先写参数、最后写命令字，保证命令字是"最后一笔"；二是从站侧增加"新数据标志位"，主站写完整个数据区后单独写一个"生效"寄存器，从站检测到生效位变化才解释命令。工程上我推荐后者，可移植性更强，排查也直观。

通信状态上报也很重要。从站应该定期把"通信正常"这个事实反馈给主站，最简单的办法是把一个毫秒级计数器写入输入寄存器区，主站每次读到该寄存器数值变化就认为从站在线。计数器的数值变化本身就是一个活体信号，比单纯给一个"对/错"布尔量可靠得多，我习惯称之为心跳字。所有主从通信项目，无论 RTU 还是 TCP，我都会加这个心跳字，离线判断一做一个准。

5. 联调排错：从物理层到协议层的完整排查链路

5.1 第一步先查物理层：RS485接线和终端电阻

通信调不通，第一个排查对象永远是物理层，而不是急着改程序。RS485 接线看着简单（就 A、B 两根线），但坑极多。

首先是 A/B 反接。模块和从站设备的 A、B 端子可能标号不一致，有的设备标 D+、D-，有的标 A、B，接反后通信表现为完全不通，或者时断时续。判断方法是：接好后用万用表测量 A-B 之间的直流电压，正常应该在 2V~6V 之间；如果接近 0V 或乱跳，大概率接反或者有短路。

其次是终端电阻。虽然 1200 通信模块内部通常已经有 120 欧姆电阻可选配，但总线上如果只有两台设备，两端必须各有一个终端电阻才能保证信号反射可控。很多 RS485 设备上一排微型开关，出厂默认全是 OFF，接完线就以为万事大吉，结果通信时好时坏。正确做法是总线两端设备拨到"终端电阻 ON"，中间设备保持 OFF。

还要注意通信地。RS485 虽然是差分信号，但设备之间如果没有共同参考地，共模电压一旦超过收发器承受范围，轻则误码，重则烧芯片。主干线选屏蔽双绞线时，屏蔽层单端接地；如果通信距离超过一百米或现场有大功率变频器，建议在通信线两端并联一只小电容做共地处理。电平细节不多展开了，记住"屏蔽层单端接地，别两端都接"这个原则，能避免大多数莫名其妙的干扰故障。

5.2 对协议参数：站号、波特率、校验位、从站运行状态

物理层确认无误后，把两端协议参数逐项对一遍。Modbus RTU 标准是 8 数据位、1 停止位，可配无校验、奇校验或偶校验。S7-1200 的 MB_COMM_LOAD 中 PARITY 参数：0 无校验、1 奇校验、2 偶校验。主站和从站必须完全一致，尤其是校验位，两端一个设偶校验一个设无校验，CRC 永远算不对。

站号也容易出问题。从站 MB_SLAVE 的 MB_ADDR 设的是 5，而主站轮询时 MB_ADDR 写的却是 6，这种低级错误在联调时反而最常见。我在写轮询程序前会先做一张"站号-设备-数据区"清单，联调时一条条打勾，避免翻来覆去改程序。

最后一个"参数"是从站的运行状态。很多 S7-1200 从站程序把 MB_SLAVE 放在 OB1 里，但如果 PLC 处于 STOP 状态，这个指令不执行，通信模块就会一直不应答。主站侧看到的现象就是超时。所以联调前先确认从站已经 RUN，且通信指令正在被扫描执行，可以用 TIA 在线监控看一眼 MB_SLAVE 的 STATUS 有没有周期性变化。

5.3 用上位机通信调试软件隔离问题端

我联调时最喜欢的一招：在总线上临时挂一个"主站模拟器"。具体做法很简单，找一台带 USB-RS485 的电脑，运行 Modbus Poll 之类的调试软件，把电脑当主站去读从站。

如果电脑能正常读写从站寄存器，说明从站侧硬件、组态、MB_SLAVE 程序都没问题，问题一定在主站侧程序或主站通信模块；如果电脑也读不通，问题就在从站侧或总线物理链路。这一步能在五分钟内把双端问题缩小到单端，比盲改程序高效太多了。

使用同样的思路，也可以在从站端临时把 PLC 切到"电脑模拟从站"来验证主站。不过我建议优先做"电脑模拟主站读真实从站"这一侧，因为从站程序结构简单，问题容易暴露。等到这一步完全跑通了，再让真实的两个 PLC 牵手，成功率高得多。

5.4 状态代码定位的三个高频错误

S7-1200 Modbus 通信块的状态字是排查问题的关键。常见的几个错误码：

• 16#8186：请求超时。从站没应答，先查站号、接线、从站是否运行。
• 16#818B / 16#818C：数据长度非法。请求的字数与从站寄存器区实际长度不匹配。
• 16#818A：目标设备无响应，多与物理层问题相关。
• 16#80xx 系列：底层硬件错误，通信模块初始化或固件问题。

有一次排查超时错误，从站侧监控完全正常，上位机也能读写，但真实主站就是超时。最后发现是主站轮询队列里同时给两个不同的从站发起了 REQ，BUSY 逻辑没做互锁，导致指令状态一直混乱。把 REQ 生成逻辑改成"当前请求完成前不允许生成下一请求"之后，问题立即消失。这就是为什么我在 3.1 节特意强调轮询请求的串行控制。

6. 稳定性和性能进阶：轮询节奏、故障重试与高可靠性替代

6.1 轮询周期的时间估算与实测参考

Modbus RTU 的轮询周期不是越快越好。半双工总线上，每一帧通信都包含主站请求帧、从站应答帧、以及帧间间隔。波特率影响字节传输时间，数据长度决定帧长，轮询周期与这两者强相关。

以 9600 波特率、8 数据位 1 停止位为例，每字节大约 1ms；读取 10 个保持寄存器，请求帧约 8 字节、应答帧约 25 字节，来回路程时间加帧间隔，一帧大约 40~60ms。如果轮询 4 台从站，每台读 10 字，一圈下来大约 0.2~0.3 秒。这个速度对常规工艺监控完全够用。

如果要求更快的刷新率，直接提高波特率是最简单的办法，大多数 RS485 设备支持 19200 甚至 38400。但要注意，仪表类设备在高速率下可能出现响应不稳定，现场实测下来，19200 是兼顾可靠性和速度的甜点值。我大多数项目默认按 19200 设计，只有老设备明确不支持才降回 9600。

6.2 故障重试与离线报警逻辑

通信不可能永远零故障，关键是要让系统知道"通信暂时坏了"并且自己恢复。我在主站侧会加一套简单的故障计数器逻辑：

• 正常完成一次轮询，离线重试计数清零；
• 某一从站连续超时 N 次（一般取 3 次），置位"该从站离线"标志位；
• 离线标志位置位后，主站继续轮询但跳过该从站的数据写入区，避免把旧的错误数据下发给执行器；
• 从站心跳字恢复变化后，自动清除离线标志，系统无扰动恢复。

这套逻辑最大的价值在于防止误动作。很多项目通信断了以后，主站还在用最后一次收到的错误数据做控制，风险极大。离线标志一旦置位，所有联动控制逻辑都应该切换到"安全预设值"或"保持原输出并报警"的模式，具体策略由工艺定，但不做离线判断肯定是不行的。

6.3 高可靠场景下的备选方案：PROFINET I-Device

如果两台 1200 之间需要的是真正周期性的高速数据交换，比如伺服轴联动、张力控制这类实时性要求在几十毫秒以内的场景，Modbus RTU 的轮询机制就不够看了，这时候应该考虑 PROFINET I-Device 方案。

I-Device 的大致思路是：把一台 S7-1200 配置成"智能从站"，另一台 PLC 作为 IO 控制器，两边通过组态分配输入输出数据区，数据交换由 PROFINET 协议自动周期完成，不需要写轮询逻辑，周期可设在 1~8ms 量级，实时性远优于 Modbus RTU。

配置上，在从站 CPU 的"设备组态"里勾选"允许作为 I-Device"，然后创建一个智能设备通信关系，把要交换的数据定义到固定的 IO 区；主站侧只需要把该设备作为 IO 设备组态进来，填写设备名和 IP 就能映射数据。这个方案的缺点是要花时间理解 PROFINET 组态概念，前期学习曲线比 Modbus 陡，但一旦配通，稳定性和实时性都不是 Modbus 能比的。

实战建议很直接：超过 50 个字的周期交换、或者实时要求高于 50ms 的，直接上 I-Device；只是开关量命令和稀疏模拟量采集的，Modbus RTU 绰绰有余。别为省几根网线，把一个简单的需求硬生生做成通信性能瓶颈。

7. 最终落地的心得

如果让我给一个初次做西门子1200主从PLC编程的人排执行顺序，我会说：先把从站程序写好，用上位机模拟主站验证通过；再把主站初始化写好，单跑主站确认串口配置成功；最后才写轮询队列，让两个真实的 1200 对话。每一步都把状态字记下来，再进下一步，这样即便出问题，你知道问题出在哪一步，而不用对着两个 CPU 的几十个变量抓瞎。

另一个小技巧：调试阶段在数据区里塞几个"钢印值"——比如从站某个固定寄存器里永远放一个 16#5A5A，主站读到了就说明链路通，读不到就能立刻区分是地址映射错误还是通信故障。这个小习惯帮我在现场省下过大量时间，现在分享给你，希望你下次做双 PLC 主从项目时也一样顺手。