S7-1200与温控仪表的Modbus RTU通信：从接线到调试全流程

1. 通信方案整体设计思路

1.1 为什么是Modbus RTU而不是其他

做自动化项目的人对现场总线肯定不会陌生。S7-1200PLC作为西门子的小型主力控制器，本身支持Profinet、Modbus TCP这类以太网协议，但为什么大量温控仪表现在还在用Modbus RTU？答案很直接：成本低、普及率高、实现简单。

很多温控仪表、数显表、温湿度变送器用的是RS485物理接口，支持Modbus RTU协议。这类仪表通常几十到几百块，现场用一对双绞线就可以把所有仪表串起来，走线成本也低。相比之下，如果每台仪表都换成Profinet或者Modbus TCP版本，设备单价和布线成本就上去了，很多项目压根没这个预算。

另外，Modbus RTU协议本身极其简单，一个请求帧就是“地址+功能码+寄存器地址+数据+CRC校验”，对仪表这种小数据处理设备来说，占用资源少、响应快，可靠性也不差。很多温控仪表支持的最大波特率就是9600或19200bps，这个速度在短距离传输温控数据时完全够用。

有朋友可能会问，直接用模拟量输入模块接仪表的热电偶信号不是更省事？确实，一两个测温点用模拟量模块没问题。但如果现场有十几台甚至几十台温控仪表，或者你需要批量读取每台仪表的当前温度、目标温度、PID参数、报警状态，模拟量方案的成本和接线量就会爆炸。数字通信一条总线串下来，两根线搞定，维护也方便。

1.2 整体方案构成

这个方案的核心链路不复杂，但涉及的知识点比较杂，我从底层往上理一遍：

• 物理层：RS485总线，S7-1200需要配置通信模块或通信板，仪表端出RS485接口
• 数据链路层：Modbus RTU协议帧格式，地址映射、CRC校验
• PLC侧：西门子的Modbus RTU库指令，负责发起请求、接收响应、解析数据
• 仪表侧：设置从站地址、波特率、数据格式等参数，让仪表“听得懂”PLC的话

整个系统可以理解成这样一个场景：PLC是老板（主站），仪表是员工（从站）。老板每隔一段时间挨个问每位员工“你现在的温度是多少”、“你的目标温度是多少”，员工听到自己名字（从站地址）就回话，不是叫自己就保持沉默。这个“点名问答”的循环，就是Modbus RTU轮询通信的本质。

做这个项目之前，建议先把手头的东西列个清单：PLC选型（S7-1200具体型号和通信模块型号）、温控仪表型号和通讯手册、总线线缆和终端电阻、以及调试用的电脑和上位机工具。后面调试过程中你会发现，这些准备直接决定项目进度。

2. Modbus RTU协议核心细节

2.1 链路层与帧结构解析

Modbus RTU的帧结构非常紧凑，没有像TCP那样复杂的包头。一个完整的请求帧由四部分组成：

• 从站地址：1字节，范围1~247，0作为广播地址（温控仪表一般不支持广播）
• 功能码：1字节，告诉从站“我要干什么”
• 数据字段：N字节，具体要读写的寄存器地址和数据
• CRC校验：2字节，对整个帧做循环冗余校验，低字节在前

举个例子，如果PLC要读取地址为3的温控仪表的温度值（寄存器地址假设是0x0001），请求帧是：

03 03 00 01 00 01 CRC_L CRC_H

拆开看就是：从站地址03，功能码03（读保持寄存器），寄存器地址高字节00，寄存器地址低字节01，读取数量高字节00，读取数量低字节01，最后两个字节是CRC16校验码，低字节在前。

仪表收到这个帧之后，如果地址匹配、CRC校验通过，就返回响应帧：

03 03 02 01 2E CRC_L CRC_H

含义是：从站地址03，功能码03，数据字节数02，数据值0x012E（这就是温度原始值），再加CRC。

这里有个容易出错的地方：CRC校验的低字节在前、高字节在后，很多初次调试的朋友把CRC高字节写在前头，结果仪表根本不搭理。关于CRC16算法的计算方式，网上资料很多，Modbus RTU标准算法是查表法或逐位计算，关键是多项式0xA001，生成时初值0xFFFF。如果你不想自己写，直接用现成的库里函数，西门子的库已经帮你处理好了。

2.2 寄存器模型与功能码对应关系

温控仪表内部的Modbus寄存器一般分四类，实际使用中大部分仪表只用到其中两类：保持寄存器（4x区）和输入寄存器（3x区）。

• 线圈（0x区）：可读写的开关量，比如报警输出状态
• 离散输入（1x区）：只读的开关量
• 输入寄存器（3x区）：只读的模拟量，比如当前温度采集值
• 保持寄存器（4x区）：可读写的模拟量，比如目标温度设定值、PID参数

不同品牌的温控仪表，寄存器地址分配差异很大。有的把当前温度放在保持寄存器的0地址，有的放在输入寄存器的0地址，有的地址是从0开始，有的从1开始。所以拿到一台新的仪表，第一件事就是翻说明书，找到它的Modbus通信寄存器表，看清楚每个参数对应的寄存器地址、数据类型、读写属性。

我用过一款国产仪表，当前温度在保持寄存器地址0x0000，目标温度在0x0001，只支持03功能码读、06功能码写。后来又换了一款进口仪表，当前温度跑到了输入寄存器区，还支持16功能码一次写多个参数。所以千万别凭经验默认，一定要对着仪表的通信说明书来。

功能码这块，温控仪表最常用的就三五个：

2.3 数据格式与字节序问题

Modbus RTU寄存器是16位的，一个寄存器能表示0~65535的无符号整数，或者-32768~32767的有符号整数。但温度值常常带小数，比如123.4℃，这时候就涉及数据格式了。

最常用的方式是“放大倍数法”：温度值乘以10，比如123.4℃存成整数1234，PLC读出来再除以10。有些仪表内部默认就是带一位小数或两位小数，具体看仪表的通信参数设置，比如“温度分辨率0.1℃”对应1位小数，“0.01℃”对应2位小数。这种方式简单可靠，适合精度要求不特别高的场景。

另一种方式是IEEE 754浮点数：用两个16位寄存器拼成一个32位浮点数，比如温度值直接以Float格式存储。这种方式精度高，但字节序问题很容易让人头大。因为西门子PLC内部存储Float的字节序和Modbus协议默认的字节序不一致，直接读出来再按REAL解析，数值往往是乱的。

这里我展开说说字节序。假设一个32位浮点数0x41F40000（表示30.5），在Modbus RTU两个寄存器里通常以“低字在前”或者“高字在前”的顺序存放：

• 有的仪表：寄存器1存0x41F4，寄存器2存0x0000（大端模式）
• 有的仪表：寄存器1存0x0000，寄存器2存0x41F4（小端模式）

而西门子的数据类型结构和Modbus协议默认的映射方式又不同，这就导致你从PLC读取的“两个字的缓冲区”里的顺序，和仪表实际发送的寄存器顺序不一定一致。解决方法有两个：一是用SCL写一个字节交换函数，把双字的高低字交换一下；二是用MOVE指令结合字节偏移处理。我一般建议先用Modbus Poll这类调试工具确认仪表返回的字节顺序，再在PLC里做对应处理，这样最稳。

3. 硬件接线与仪表参数设置

3.1 RS485接线方式和终端电阻

RS485是半双工差分通信，靠A、B两根线的电压差来传输数据。S7-1200的CM1241 RS485模块上，端子A对应TX/RX+，端子B对应TX/RX-，有些模块标注为T+和T-。温控仪表那边一般也是A、B两个端子，不同品牌叫法可能不一样，常见的有A/B、+/-、D+/D-，装的时候务必对着说明书确认。

接线规范上，有几个关键点要留意。

第一，所有设备的RS485 A端子并到一起，B端子并到一起，千万别交叉。这个听起来简单，但现场真的有人把A和B接反。如果仪表没有反光，调试时通信完全不回，第一排查点就是A/B是否接反。

第二，屏蔽层要单端接地。RS485线建议使用带屏蔽的双绞线，屏蔽层在PLC这一端接地，仪表端悬空。这样可以把共模干扰导入大地，避免干扰信号叠加在通信线上。

第三，终端电阻。RS485总线两端各加一个120Ω左右的终端电阻，用来匹配线路阻抗，减少信号反射。如果总线上就两台设备——PLC和一台仪表——只需要在仪表那一端加120Ω终端电阻，PLC这端用通信模块内置的终端电阻（如果有的话）。很多CM1241模块上有个旋钮开关可以切换是否接入终端电阻，出厂默认是断开状态，单台仪表时把它打开。

对于多台仪表的组网，总线的走线也要注意别走成星型结构。RS485最好是一条菊花链级联，从PLC一路串下去，中间不要分叉，分叉会造成信号反射，距离长了容易误码。虽然理论上RS485是总线型，但星型拓扑长度超过几百米时问题会非常明显。

3.2 温控仪表通信参数设置

仪表侧需要设置的参数大致有这几项：从站地址、波特率、数据位/停止位/校验位、数据格式、通信使能。

从站地址一定不能重复，这是最核心的一条。如果你在一条总线上挂了8台仪表，地址从1到8设置好，PLC轮询时按地址依次请求。地址重复会导致总线上两台设备同时回数据，帧冲突，通信一定故障。

波特率和校验位必须和PLC侧设置一致。仪表常见的默认波特率是9600bps，8数据位、1停止位、无校验（8N1）。有的仪表是8E1（偶校验），也有的支持2个停止位。这些参数不匹配的话，仪表连帧头都识别不了，自然不会回应。

还有一项容易忽略的是“通信协议选择”。有些仪表同时支持Modbus RTU和Modbus ASCII，或者支持Modbus和自有协议，需要在仪表参数中选择“rEAL”或者类似选项，把通信协议切到标准Modbus RTU，否则数据帧格式对不上。

我在现场见过一台仪表，即使地址、波特率都设对了，还是不通信，折腾了半天发现仪表的通信协议误设成了“本地协议”。这类问题藏在参数里，不看说明书很难察觉，所以拿到仪表先通读通信章节，把参数总表过一遍。

3.3 S7-1200通信模块选型

S7-1200本身没有集成RS485接口，要么用通信模块，要么用通信板。

• CM1241 RS485模块：插在PLC左侧扩展槽上，标配一个RS485接口，支持Modbus RTU主站或从站
• CB1241 RS485通信板：插在CPU本体上方的扩展板上，占一个信号板槽位，功能类似CM1241
• CM1241 RS422/485模块：提供RS232和RS485两种接口，适合需要多接口的场合

选型上一般就看两点：一是CPU型号是否有扩展槽位（1211C型的CPU左侧还能加一个通信模块，1214C以上可以加多个）；二是预算和空间。CB1241比CM1241便宜，但它占的是信号板槽位，如果你还计划用信号板扩展模拟量或数字量输出，就得权衡了。

另外要注意，CM1241 RS485模块的固件版本和CPU固件版本要匹配，否则博图中组态可能报错。我建议在购买时直接问供应商最新固件版本，拿到手先在博图中确认兼容性，避免装好了才发现固件不匹配的尴尬。

4. S7-1200侧组态与编程实现

4.1 硬件组态和通信模块配置

在TIA博图（TIA Portal）里组态S7-1200和通信模块，步骤比较直观。

首先，新建项目，添加CPU型号。然后在左侧的设备组态中，从硬件目录里找到“通信模块”，拖入CM1241 RS485。双击通信模块，在属性里面可以设置波特率、奇偶校验等通信参数，但这里设置的参数严格来说只是给模块的“默认配置”，真正让Modbus指令生效的参数，是在程序里通过MB_COMM_LOAD指令重新配置的。

这里有一个初学者容易混的地方：在硬件组态里设了波特率9600，程序里MB_COMM_LOAD也设了9600，结果通信还是不通。原因可能是模块上有一个DIP开关或旋钮，用来选择终端电阻和通信模式，如果硬件上的开关状态和组态不一致，也会导致异常。CM1241模块侧面有个小面板，可以设置是否使能终端电阻，接线之后记得检查这个开关。

硬件组态完成之后，下载配置到PLC，硬件部分就基本就绪了。剩下的工作在程序里完成。

4.2 MB_COMM_LOAD指令配置参数

S7-1200的Modbus RTU库函数在博图的“指令”面板里可以找到，常用的是两个：MB_COMM_LOAD（通信端口初始化）和MB_MASTER（主站请求发送）。

MB_COMM_LOAD的作用是初始化通信模块的端口参数。它需要分配一个背景数据块和一块“端口缓冲区”（一般建议至少256字节），然后在程序里调用。关键参数有：

• PORT：指定通信模块的硬件标识符，组态后自动生成（例如269）
• BAUD：波特率，要和仪表一致，比如9600
• PARITY：校验方式，0=无校验，1=奇校验，2=偶校验
• RTS：是否启用RTS控制，RS485一般设为1（自动控制发送方向）

MB_COMM_LOAD只需要在程序启动时触发一次，通常用第一次扫描周期或OB100里置位一个保持位来触发。不要每个扫描周期反复调用，频繁初始化会导致通信口短暂释放，影响通信稳定。

我在实际调试中遇到过一个问题：MB_COMM_LOAD的REQ用普通常开触点一直置TRUE，结果通信口每隔一段时间就重新初始化一次，导致总线上的通信一卡一顿的。后来改成第一次扫描脉冲触发，问题立刻消失。所以这块一定按照“只初始化一次”的逻辑来写。

4.3 MB_MASTER指令实现读写

MB_MASTER是S7-1200作为Modbus主站发送请求的核心指令。每调用一次MB_MASTER，PLC就往总线上发一个请求帧，然后等待从站响应。它的关键参数：

• REQ：请求触发信号。上升沿触发一次请求，可以用定时器做周期性脉冲，比如每500ms读一次当前温度
• MB_ADDR：从站地址，要访问的温控仪表的站号
• MODE：0=读，1=写
• DATA_ADDR：寄存器地址（对应仪表的寄存器号）
• DATA_LEN：数据长度，单位是“寄存器个数”（16位寄存器数量）
• DATA_PTR：指向PLC内部存储区（一般为全局DB块或M区）的指针，接收或发送的数据都放在这里

举个例子，读取地址为1的仪表的当前温度（寄存器地址0x0001），每2秒读一次，程序逻辑可以是这样：

定时器产生2秒脉冲 → MB_MASTER的REQ MB_ADDR := 1 MODE := 0 // 读 DATA_ADDR := 1 // 寄存器地址 DATA_LEN := 1 // 读取1个寄存器 DATA_PTR := "DB_Data".CurrentTemp // 数据存到DB块的CurrentTemp变量

执行之后，MB_MASTER的DONE位输出一个TRUE脉冲，表示本次请求完成；ERROR和STATUS管脚可以读出错误码。如果本次请求失败（从站无响应、CRC错误等），ERROR位会置TRUE，STATUS输出的错误码可以快速定位问题，具体编码含义在西门子手册里有对照表。

如果需要在一条指令里连续读取多个寄存器，比如把当前温度、目标温度、PID值一次全读出来，可以设置DATA_LEN为3，DATA_PTR指向一个长度为3个字（或6字节）的存储区。不过要注意，不同仪表的寄存器地址是连续的，才可以合并读取。如果地址是跳跃的，就只能分几次读，或者把不用的寄存器也一次性读出来再丢弃。

4.4 数据解析与工程量换算

温控仪表反馈的数据通常是原始整数值，需要做工程量换算才能变成人类能看懂的温度值。

对于放大倍数格式，比如温度值乘以10存储，PLC读出来是整型1234，实际温度就是123.4℃。计算方法很简单：

CurrentTemp_Real := INT_TO_REAL(CurrentTemp_Int) / 10.0;

这里要注意数据类型的转换。MB_MASTER的DATA_PTR指向的变量如果是INT类型，那么在程序里直接除以10.0会得到错误结果，因为INT除以REAL的结果是REAL，但前提是把INT先转换成REAL。很多新手卡在这里，读出来的数值翻倍、减半或者变成负数，很大程度上就是类型转换没做对。

对于浮点数格式，读到的两个寄存器要先拼成一个32位的值。如果仪表是按高字在前（大端），PLC里读到的字序列可能是低字在前（小端），需要交换。交换的方法有很多种，最直接的是用SCL写一个函数：

// 将两个16位寄存器拼接并交换字节序 #Temp_Int_Low := #Data[0]; #Temp_Int_High := #Data[1]; #Temp_Real := INT_TO_REAL(#Temp_Int_High) * 65536.0 + INT_TO_REAL(#Temp_Int_Low);

注意，如果仪表的寄存器顺序和PLC内部字节序完全一致，直接REAL解析即可，不一致才需要交换。具体哪种情况，以Modbus Poll读取结果为准，我在后面调试部分会说具体方法。

5. 常见问题与排查技巧实录

5.1 通信超时问题的排查思路

通信超时是最常见的故障，MB_MASTER的STATUS报16#8185之类的错误码，翻译过来就是“从站无响应”。遇到这种情况，别急着重启设备，按顺序排查：

第一步，检查接线。A/B是否反接、端子是否松动、屏蔽层是否接地。用万用表量一下总线电压，正常空闲状态下A和B之间的电压应该在2V到5V之间（差分电压），如果电压几乎为0，多半是总线短路或某设备掉线。

第二步，检查仪表参数。从站地址是否和程序里一致、波特率校验位是否匹配、通信协议是否选到Modbus RTU。这些可以对照仪表面板或上位机软件确认。

第三步，检查终端电阻。如果现场线缆很长，而总线两端没有终端电阻，可能出现信号反射，通信时断时续。在总线的两个末端各加120Ω电阻。

第四步，用Modbus Poll软件测试。把PLC从总线上摘下来，直接用USB转485转换器接仪表，跑一下Modbus Poll请求，如果Poll能读到数据，说明仪表和总线下层没问题，问题大概率出在PLC的组态或程序配置上；如果Poll也读不到，问题就在仪表侧或接线侧。这一步可以把问题快速定位到“PLC以上”还是“仪表以下”。

我做过的几个项目，通信超时最终的原因分布大概是：接线错误占四成、仪表参数配置错误占三成、PLC程序配置错误占两成、剩余是干扰和硬件故障。所以别一开始就怀疑PLC程序，先从物理层和参数层排查，大部分问题都能快速解决。

5.2 数据错误的字节序问题

如果通信通了，但读出来的温度数值完全不对，比如应该是30.5℃，读出来变成19000多，或者是负数，那就大概率是字节序或者数据类型解析问题。

调试步骤是这样：先借助Modbus Poll工具，直接读仪表的原始寄存器值，确认仪表返回的16位数值是否符合预期。如果仪表说明书上写着当前温度的寄存器值是“0x1331”，而Poll读到的正好是0x1331，说明仪表侧没问题。

然后看PLC侧。如果PLC读到的是0x3113（高低字节反了），说明PLC在接收时把仪表返回的字节顺序颠倒了。很多RS485总线在传输过程中是按字节流传输的，仪表先发高字节还是先发低字节，取决于仪表的实现。西门子库函数默认的处理方式有时会和部分仪表的Byte Order不匹配，这时候就得手动交换。

我常用的交换方法是：在读到的数据Dword中，把低两个字节和高两个字节互换，也就是执行“字节交换”。在SCL里可以这样写：

#Temp_Dword := #Dword_Data; // 交换低字和高字 #Temp_Dword := ( #Temp_Dword AND 16#FFFF ) * 16#10000 + SHR( #Temp_Dword, 16 );

如果还不正确，再检查是否还要在16位内部做高低字节交换。这部分调试看起来繁琐，但一旦确认了仪表的数据字节序规则，后续所有寄存器都可以统一处理。

5.3 仪表返回异常码的处理

Modbus协议规定，从站如果无法处理请求，不会保持沉默，而是会返回一个异常响应帧。这个帧的功能码是把原始功能码的最高位置1（比如读请求是03，异常响应就是0x83），后面跟一个异常码。

当PLC报错时，如果STATUS显示“从站返回异常响应”，你需要把仪表返回的异常码读出来，而不是再去调PLC程序。比如异常码02，说明你读写的寄存器地址在仪表上根本不存在，可能地址算错了、偏移量不对，或者这块仪表没有这个参数。

我最开始做仪表通信时，有一次PLC一直报错，以为是程序问题，后来把MB_MASTER的STATUS错误码详细展开，发现是异常码02——仪表上根本没有地址为1的寄存器。后来把寄存器地址改到说明书上对应“当前温度”的地址，问题马上解决。所以遇到通信问题的第一反应应该是“看错误码”，而不是“瞎改程序”。

5.4 提高通信可靠性的几个小技巧

最后分享几个实战中非常有效的可靠性技巧。

一是轮询间隔不要太短。很多温控仪表的数据更新周期本身就慢，串口通信又是半双工的，PLC发一帧、等一帧，如果总线上有多台仪表，每台都读好几个寄存器，一轮下来需要几秒钟很正常。如果把轮询间隔设到100ms，总线上冲突倒不会，但仪表响应不过来，容易出现超时。稳妥的做法是先按默认500ms~1s去轮询，等所有数据都能稳定读到了，再根据需要缩短间隔。

二是用定时器做轮询，不要用PLC扫描周期宽度来卡时间。比如你写一个2秒的定时器周期脉冲，驱动MB_MASTER的REQ。因为Modbus请求必须在上一帧完成后才能发下一帧，如果你用扫描周期驱动REQ，可能会出现上一帧还没处理完，下一帧就来了。西门子的库函数内部有忙检测，但如果自己调度不当，还是容易出问题。更好的做法是判断上一帧的DONE位或者错误位之后，再发下一帧。

三是给每台仪表的数据单独开辟一个DB变量。比如DB_Data下有CurrentTemp_1、CurrentTemp_2、SetPoint_1、SetPoint_2……这样调试时方便监控，程序引用数据也更直观。虽然用数组也能做，但数组的地址管理对新手不友好，用数组读出来的数据还要再做偏移换算，容易搞混。

四是定期检查总线干扰。如果通信隔一段时间就断一次，但又会自动恢复，多半是电磁干扰或接地不良。现场有大功率变频器、伺服驱动器时尤其需要注意。RS485线要远离动力线，至少要保持在30cm以上，如果空间受限，用屏蔽双绞线加屏蔽层接地，通常能解决大部分干扰问题。

五是用Modbus Poll的“自动轮询”功能。这个工具不仅能测仪表，还能把仪表的离线点表导入进去，用图形化方式观察每个寄存器的值。我调试时习惯先用Modbus Poll把仪表的寄存器地址全部验证一遍，记录下正确地址，再到博图里写程序。这样可以大幅减少在PLC侧反复在线监控的调试时间。

在我实际做过的设备改造项目中，有一套设备现场有12台温控仪表，用S7-1200读取清洗槽温度。测了将近一天，发现其中有两台仪表的寄存器地址给错了，程序里的地址映射配错，导致读回来的温度变成了旁边那台浴槽的温度，缺陷产品率三天才降下来。后来把地址表重新核对，用Modbus Poll逐一验证所有仪表之后，才彻底稳定下来。这类项目经验告诉我们：通信协议本身不难，真正花时间的永远是地址映射和字节序这些细节。

如果后续你还需要扩展，比如从单台仪表扩展到多台仪表轮询，或者把读到的温度数据上传到上位机屏显示，可以在现有的MB_MASTER调用基础上，增加一个轮询数组控制逻辑。但万变不离其宗，核心就是把“读哪个仪表、读哪个寄存器、读几个寄存器、放在哪”这四要素理清楚，Modbus RTU就拿下了一大半。