西门子S7-1200 PLC串口通讯实战：从Modbus RTU到自由口调试指南

很多人在第一次接触西门子S7-1200PLC串口通讯时，往往不是被程序难住，而是被“硬件选型、电气接线、组态方式、协议参数”这几层信息弄乱。看似简单的一根RS485线，实际项目里可能调试一整天都不通，最后发现只是AB接反或者校验位不一致。

这篇文章会把S7-1200PLC串口通讯的完整链路拆开讲：先看应用场景和硬件选型，再讲Modbus RTU主从通讯和自由口通讯两种最常用的实现方式，最后给出真正到现场联调时需要的参数、判断标准和排查顺序。适合刚接触S7-1200的工程师，也适合已经有基础但被非标设备或第三方仪表卡住的人。

我个人的建议是：不要急着背指令，先把“现场设备是什么协议、PLC这边做什么角色、线怎么接、一帧报文长什么样”这四个问题想清楚，后面的编程只是把方案落地而已。

1. 先看应用场景：S7-1200串口通讯到底适合接什么设备

1.1 S7-1200串口通讯解决的典型问题

S7-1200是一台以以太网和Profinet为核心优势的中小型PLC，但在大量改造项目和单机设备里，现场仍然有非常多“只有串口、不支持网口”的老旧设备。比如：

• 电子秤、地磅、称重仪表
• 扫码枪、条码设备
• 变频器、软启动器、伺服驱动器
• 温控表、流量计、压力变送器
• 老式上位机、组态软件、串口打印机
• 第三方的数据采集模块

这些设备的通讯接口最常见的就是RS232或RS485，协议则可能是Modbus RTU、自由口非标协议，甚至是某个厂家自定义的帧格式。S7-1200PLC串口通讯要解决的核心问题，就是让PLC能够稳定地和这一类设备交换数据，并把数据转成PLC内部可用的变量。

1.2 三条主流路线：Modbus RTU、自由口、USS

S7-1200做串口通讯，从协议层面看通常有三条路线。

第一条是Modbus RTU。这是工业现场最通用的串口协议之一，大多数变频器、仪表、温控器都支持。即使没有说明书，只要知道从站地址、寄存器地址、功能码和寄存器数据类型，就可以完成通讯。

第二条是自由口通讯。当设备不是标准Modbus协议，而是自定义报文格式时，就需要PLC按照对方协议来收发字节。典型场景包括扫码枪、非标仪表、老式称重设备，以及需要和某个上位机自定义协议对接的项目。

第三条是USS协议。这是西门子驱动类设备常用的一种串口通讯协议，主要用在与西门子变频器或驱动产品连接时。如果现场只是接西门子驱动，并且通讯数据量不大，USS比Modbus RTU更贴近驱动自身的数据结构。

在多数实际项目中，Modbus RTU的使用比例最高。因为第三方设备即使不做公开协议，也通常会预留Modbus RTU从站功能。对一些品牌变频器，虽然厂家主推自己的总线协议，但通过RS485接口走Modbus RTU也已经是常规做法。

1.3 什么情况不建议硬走串口

串口不是万能的。如果项目是S7-1200与S7-1200通讯，首选绝对是Profinet或S7通讯；如果项目是PLC与上位机之间大数据量、高频率交换，也建议用网口或OPC UA，而不是串口。

串口适合的是“数据量小、报文帧短、距离不远、实时性要求中等”的场景。硬把串口用在高速大批量数据上，只会让自己陷入频繁调参和排查的困境。选型阶段就决定通信方式，比后期用程序拼命补救更省时间。

2. 硬件与软件准备：先确认模块选型再谈组态

2.1 S7-1200通常不会自带串口引脚

S7-1200的标准CPU本体上，常见的编程口是Profinet以太网口，很多型号并没有直接引出的RS232或RS485串口。所以接到仪表、变频器、扫码枪之前，先要确认PLC是否配备了串口扩展模块。

通常有几种扩展方式：

• 通信模块CM1241 RS232：提供标准的RS232点对点串口，适合短距离、单设备通讯。
• 通信模块CM1241 RS485：提供RS485接口，适合长距离、多设备总线连接。
• 通信板CB1241 RS485：插在CPU本体前端的扩展板上，型号不同支持情况不同。

选型时最粗暴的第一判断方法是：先看设备侧接口是RS232还是RS485，再看现场距离和站点数量。RS232只能一对一，一般传输距离在十几米到二十米以内；RS485可以一对多，传输距离在几百米甚至更远，但在接线时要考虑终端电阻和总线拓扑。

不要只看PLC选型册上的“支持串口”，还要看支持的是哪种物理接口。RS232和RS485虽然都叫串口，但电平和接线方式完全不同，不能直接互相替换。如果现场原来跑的是RS232，一定需要一个RS232转RS485的转换器，而且转换器质量会直接影响稳定性。

2.2 硬件组态和TIA Portal版本准备

S7-1200PLC串口通讯的软件环境主要是TIA Portal。项目新建之后，需要在“设备组态”中把串口模块拖到CPU对应的插槽位置。如果设备列表里找不到对应模块的订货号，通常有两种可能：

• 当前TIA Portal版本太旧，没有包含这个模块的设备描述。
• 模块需要安装额外的硬件支持包，也就是HSP。

HSP的处理方式并不复杂，关键是要提前做。不要把程序写完之后才开始找模块，那样会连带程序无法离线验证。

在组态串口模块时，第一个需要理解的要点是：串口通讯不只是“插上模块、填一个波特率”那么简单，还需要把通讯协议、数据格式、是否需要CRC校验、数据长度和触发方式一起规划好。

2.3 接线之前先确认公共端和信号定义

电气接线是S7-1200PLC串口通讯中非常容易出错的一环。RS485通常使用A、B两线，但不同厂家的端子命名可能不同，有的标A+和B-，有的标D+和D-，还有的标485A和485B。PLC侧模块的端子定义和设备侧说明书必须同时看，不能只看一边就接线。

我曾经在现场遇到过一个问题：PLC和变频器距离很近，接线也按A、B对应接好了，但通讯始终不稳定。后来用万用表检查，发现变频器侧实际是把信号线接到了RS232电平的调试口，而不是真正的RS485通讯口。这类问题靠程序是查不出来的，只能回到图纸和端子定义。

接线顺序上也建议养成习惯：断电接线，确认无误再上电；不要在通讯过程中带电插拔RS485线。带电插拔虽然不一定马上损坏设备，但容易造成通讯瞬间异常，长期看也可能损伤模块引脚。

3. Modbus RTU主从通讯的落地步骤

3.1 通讯成功的第一前提：两侧参数完全一致

如果是Modbus RTU通讯，不管PLC做主站还是从站，两侧的通讯参数必须完全一致。最常见的参数组合是9600波特率、8个数据位、1个停止位、无校验，也就是很多设备默认的9600 8N1。

如果从站设备要求偶校验，而PLC侧设置了无校验，那么即使地址正确、报文格式正确，通讯也很难稳定。因为Modbus RTU帧中的校验位不仅影响数据位数，也影响从站对帧的解析方式。

建议在开始写程序之前，先把下面这张表填写完整：

参数项	本侧设定值	对端设备要求	备注
波特率	9600	9600	必须一致
数据位	8	8	常见8位
停止位	1	1	多数设备支持1或2
校验方式	无	无	无校验/偶校验/奇校验
从站地址	1	1	主站不需要，从站必须
寄存器地址	40001	40001	取决于点位表
数据类型	16位无符号	16位无符号	区别单寄存器还是双寄存器
通讯超时	1000ms	不适用	建议先给较大值

这步如果跳过，后面大概率会出问题。先花十分钟确认参数表，比实际调试省下几个小时。

3.2 先做端口初始化，再触发主站读写

在西门子TIA Portal的Modbus RTU库中，典型流程是先用端口配置功能块完成串口参数初始化，然后循环调用主站或从站功能块。

端口初始化只需要执行一次。常见的参数包括：

PORT : 当前模块对应的端口识别字 BAUD : 9600 PARITY : 无校验 / 偶校验 DATABITS : 8 STOPBITS : 1 RESP_TIMEOUT : 1000

这里最容易犯的错是在每一轮循环里反复调用端口初始化。有些工程师为了让程序“启动即生效”，把初始化功能块放在主循环里周期执行，看起来模块参数被反复写入，实际上会导致正在处理的串口报文被打断。正确的做法通常是使用首次扫描标志，或者冷启动后只调用一次。

初始化完成后，主站功能块才被激活。它的核心逻辑并不复杂：PLC发出一帧请求，等待从站返回，得到结果后更新数据区。但很多人会忽略“等待上一帧完成后再触发下一帧”这个条件。

3.3 多从站轮询时的防覆盖处理

S7-1200做串口主站，如果只带一台从站，程序相对简单；真正麻烦的是带多台从站，比如一条生产线上有十台仪表，PLC每隔几百毫秒要轮询一次。

轮询逻辑的核心是“按顺序触发”，而不是“每个站都独立自由发送”。如果多个触发条件同时满足，就可能出现两个主站请求在总线上交叠，导致从站无响应或返回错误数据。

写多站轮询时，我会先把每个从站的数据区独立存在不同的数据块或不同的数组元素里，不要所有站的数据都写到同一个地址。这样即使某一次从站响应延迟，也不会把前一个站的数据覆盖掉。

常见代码结构类似：

上电初始化 -> 配置串口端口 周期轮询 -> 触发从站1的读取请求 -> 等待DONE或ERROR -> 若第1站完成，触发从站2 -> 若第2站完成，触发从站3 -> 全部完成后，回到从站1

这里有两个要点：

1. 每个站触发前都要确认上一个站已经结束。
2. 第1站到最后一站之间的循环间隔要稳定，不要因为某个站异常导致总线死锁。必要时给每个站设置超时上限，超时后强制跳到下一站。

轮询慢不一定是坏事。如果现场从站本身是简单仪表，几十毫秒响应很正常，但上位机要求的数据采集周期是200毫秒，那么PLC完全没有必要把轮询速度调到极限。稳定优先。

3.4 Modbus从站模式：S7-1200给第三方上位机提供数据

当S7-1200作为Modbus RTU从站时，一般是PC组态软件、触摸屏或第三方网关通过串口主动读取PLC中的数据。PLC侧需要配置从站地址，并把对应保持寄存器映射到PLC变量区。

这种模式最需要注意的是“数据区映射关系”。上位机读的是40001，不代表PLC内部就是DB1.DBW0。中间那个寄存器地址偏移量，必须查指令库帮助或者根据功能块的输入输出参数做正确换算。

如果现场有多个上位机同时想读取PLC数据，不要试图让一台PLC串口从站同时连接多台上位机。RS485虽然支持一主多从，但总线上如果同时出现两个主设备主动发起通讯，就会冲突。正确做法是确定唯一主站，其余设备作为从站或通过网关连接。

4. 自由口通讯：处理非标协议时的一组可靠套路

4.1 什么时候必须用自由口通讯

自由口通讯在S7-1200里经常被理解成“随便发字节”。这种理解不准确。自由口不是没有协议，而是把“一帧报文如何解析”这件事交给工程师自己处理。

举几个常见场景。

某台扫码枪每次扫描后会上传一串ASCII码，帧头是STX，帧尾是CR。PLC要做的不是告诉扫码枪“你可不可以把数据发到DB10”，而是自己接收字节、判断帧头和帧尾、把中间内容保存成字符串。

某台老式称重仪表每秒主动发送一串数字，例如“+=000.500kg\r\n”。PLC收到后需要解析出数字部分并转换为重量值。

某台设备供应商只提供了一份通讯协议文档，规定报文长度、功能码、检验方式。PLC要做的是拼帧、发送、等待回帧、校验、解析。

这些场景都不能直接用Modbus RTU库，只能通过自由口收发指令，自己处理协议。

4.2 接收完成判断：这是自由口最容易出问题的环节

自由口通讯时，很多初学会问：PLC怎么知道一帧数据已经接收完了？

答案不是“收到最后一个字节后自动停止”，而是自己定义接收完成条件。常见方式有三种：

按固定长度判断。如果协议规定每次回帧固定是8个字节，PLC就在字节数达到8时认为一帧结束。这个方法最简单，但要求帧长必须固定，不能出现半包。

按帧头帧尾判断。比如协议规定以AA开头、以0D 0A结尾。PLC持续接收，直到检测到帧头后的数据中出现帧尾，才认为完整。

按接收空白时间判断。当收到一个字节后，如果超过一定时间没有新字节，就认为当前帧结束。这个时间通常设置成单字节传输时间的几倍。

第三种方法在实际项目中很常用，因为它不依赖于具体帧长和复杂的帧尾判断。比较常见的做法是：每收到一个字节就重置一个定时器，定时时间到了就认为接收结束。

串口波特率越低，单字节耗时越长。9600波特率下，一个字节大约1毫秒多，我一般会把接收结束时间设置在10到20毫秒。不能设置得太短，否则设备两条报文之间稍有间隔就会导致合并接收；也不能设置得太长，否则PLC判断完成的时间滞后，影响循环响应。

注意：在自由口通讯中，不要把所有字节都放到一个很大的全局缓冲区里不做边界处理。长期运行后缓冲区越积越乱，最终会导致解析错位。

4.3 发送帧的拼装与校验

自由口发送相对容易，通常只需要按照协议文档拼好一个字节数组，然后调用发送功能块发送。

拼帧时要特别注意十六进制数值和ASCII字符之间的区别。比如协议要求发送一个十六进制字节0x41，那发送缓冲区里就不能写字符“41”。这个错误在扫码枪和仪表调试中很常见，看起来发送的数据差不多，实际完全不对。

CRC或异或校验环节，能直接复制现成算法模块就尽量复制。但要确认校验的数据范围，尤其注意是从帧头开始校验，还是从功能码开始校验。范围错了，后面全错。

收到回帧后，建议先做三个判断再处理数据：

1. 帧长度是否符合预期。
2. 地址或帧头是否匹配。
3. 校验是否正确。

只有这三个条件都满足，才认为这一帧有效。否则直接丢弃，什么都不做。不要让无效数据进到业务逻辑里。

5. 现场联调的关键参数与判断标准

5.1 不同设备类型的常用参数参考

下面是S7-1200PLC串口通讯联调时最常见的几类设备参数，但仅作参考。实际参数必须以现场设备说明书为准。

设备类型	接口类型	常见协议	典型波特率	典型寄存器或报文特征
变频器	RS485	Modbus RTU	9600 / 19200	40001起步，F000/F002地址常见
称重仪表	RS232/RS485	自定义ASCII	9600	连续发送重量字符串
扫码枪	RS232	自由口ASCII	9600 / 115200	回车结尾
温控表	RS485	Modbus RTU	9600	保持寄存器读取测量值
流量计	RS485	Modbus RTU	9600	寄存器点位按说明
第三方上位机	RS485	Modbus RTU主站	取决于上位机	PLC作为从站

表格只是帮你建立预期。真正的项目里，某些仪表虽然支持9600和19200，但实际使用19200时抗干扰能力明显变差，说明书写“都支持”，不代表“都稳定”。工程师在现场应该优先采用设备手册推荐值，如果手册没写，9600 8N1是最不容易出错的起步组合。

5.2 联调顺序：先让PLC和设备“单独对话”

我一般不会一上手就把所有设备都挂到RS485总线上。S7-1200PLC串口通讯联调有个很实用的顺序：先单点、再多点；先短距离、再长距离；先手动触发、再自动循环。

用调试表或变量监控表把发送请求标志改为1，手动触发一次Modbus RTU读取。如果这一帧成功，说明从站地址、寄存器地址和通讯参数都正确。如果手动触发都无法成功，就不要急着写自动轮询，因为自动轮询只会让错误更快地重复出现。

如果PLC作为Modbus从站，我通常会让电脑上先装一个Modbus调试工具，通过USB转RS485连接到PLC，然后由电脑主动读取PLC数据。电脑侧能读到，说明PLC从站功能正常；电脑侧读不到，优先排查PLC从站地址、寄存器映射和线路。

建议：在PLC程序里把通讯状态和最后的错误代码传到上位机显示或写到触摸屏报警区，不要只在程序内部看。否则现场出了异常，操作工只能看到“数据不动”，无法判断是没触发、一直在错误重试，还是数据本来就是旧值。

5.3 怎么样才算“真正跑通”

判断S7-1200PLC串口通讯成功，不能只看“有一个值显示出来”。要看三个方面：

• 数据更新连续：连续观察多个周期，数值不是偶尔刷出来一次，而是持续更新。
• 刷新周期符合预期：轮询一帧需要多长时间，心里要有数。如果设置200毫秒轮询，结果实际每秒只能更新一次，说明时序有问题。
• 无错误码累积：观察错误码或错误状态，如果程序看起来在通讯，但错误码每隔一段时间就出现一次，说明链路不稳定。

如果只是测试，跑通几次就算成功；如果是生产设备，我建议至少连续运行半小时以上，确认没有周期性掉线或偶发数据跳变，再交付。

6. 调试与故障排查链路

6.1 最常见问题排查顺序

S7-1200PLC串口通讯出问题时，很多人的第一反应是调整程序。但在多数现场，程序其实没问题，问题出在硬件接线、参数设置或第三方设备配置上。

我建议严格按下面顺序排查：

第一步，先看硬件接线。确认RS485的A、B是否接对，确认模块型号是否支持当前接口类型，确认屏蔽层和大地如何处理。

第二步，看通讯参数。把PLC侧、设备侧、上位机软件里的波特率、校验位、停止位全部对照一遍，任何一侧不一致都可能导致全部失败。

第三步，看从站地址和寄存器地址。如果从站设备本来地址是2，PLC却发地址1，设备根本不会应答。

第四步，看发送频率。是否有连续触发导致总线重叠，是否上一帧还没结束就开启了下一帧。

第五步，才轮到看程序逻辑和数据解析。前面问题排除后，如果仍然异常，再检查接收缓冲区、数据处理和字节顺序。

实际工作中，我见过很多工程师把时间花在改程序上，最后发现是485转换器质量太差或者线太长。所以遇到故障，不要先怀疑PLC。

6.2 用串口调试助手辅助判断

如果现场条件允许，最有效的定位方法是用一根USB转RS485线把从站设备单独接出来，和电脑上的串口调试助手先通讯一遍。

电脑发送Modbus RTU报文，如果设备正常返回，说明设备侧没问题；如果设备不返回，那问题就在设备参数或接线上，和PLC无关。这个步骤能在几分钟内把问题范围压缩到“PLC侧”还是“设备侧”。

在PLC做主站读不到数据时，用串口调试助手监听总线上的报文也是一个办法。但需要注意：监听工具并联在总线上会影响电平，而且对于S7-1200与从站之间已经很微弱的信号，额外挂一个负载可能会导致信号更差。监听更多用于实验室，现场紧急排查时不要长时间挂着。

6.3 自由口和Modbus RTU的报错差异

在调试时容易忽略的是：Modbus RTU报文本身有两层错误。第一层是电气错误，例如总线上完全没信号；第二层是协议错误，例如地址不匹配、功能码不支持、CRC不正确或从站处于异常状态。

有时候PLC明明发送了请求，从站也收到了，但返回的是异常帧0x83或0x02，不一定代表线路断。也可能从站不支持这个功能码，或者寄存器地址越界。此时不要反复调PLC程序，要去看从站的说明书，确认功能码和寄存器范围。

自由口通讯的排查会更难，因为没有标准错误码。我通常会先把接收到的原始报文做一个十六进制显示，再看数据是否符合预期。比如明明发送了“READ”,设备应该返回“OK”，结果PLC收到一堆乱码。先别急着改解析逻辑，用调试助手确认设备返回内容到底是什么。

6.4 程序长时间运行后不稳定怎么办

S7-1200PLC串口通讯还有一类问题：刚开机时正常，运行几个小时或几天后开始丢数据，或者重启后恢复。

这类问题常见原因有三个。

第一个原因是总线干扰。现场有大电机、变频器或变频电缆，RS485布线离动力线太近或屏蔽层接地不当，都会导致偶发错误。排查方法是改变波特率观察错误率变化，或临时用短线路测试。

第二个原因是轮询逻辑中的超时处理不够。如果Modbus主站请求发出后一直等待从站返回，而从站偶尔异常没有回应，PLC程序就会卡在等待状态，后续任务全部排不上。处理办法是给每一帧通讯设置超时时间，超过规定时间后强制放弃当前请求，继续下一站。

第三个原因是缓冲区数据没有清理。自由口接收时如果接收完成判断不准确，上一帧残留数据会和新一帧混在一起。长期运行后数据错位越来越大，直到彻底无法解析。

遇到这种问题，我会把轮询周期拉大一点，把超时时间加长一点，然后连续观察通讯状态。不要一次性把所有参数都改成“看起来更快”的值。

6.5 先解决稳定，再追求速度

很多人调试串口时总希望把刷新速度调到最快。但串口本身是低速总线，Modbus RTU一个请求加一个响应，按9600波特率算，一帧十几二十个字节，耗时通常在十几毫秒到几十毫秒。即使把波特率从9600改成19200或38400，实际提升也有限，却可能引入更多干扰。

所以稳定才是首位。S7-1200PLC串口通讯真正落地时，建议把重点放在：

• 通讯参数是否长期稳定
• 错误码是否有累积
• 轮询是否能跳过坏站
• 接收缓冲边界是否清晰
• 数据和日志是否可追溯

把这几点做到位，哪怕现场只有9600波特率，也能可靠运行很多年。

一些经验性收尾

回到S7-1200PLC串口通讯这个主题，我最后想说的是：别指望一个标准功能块解决所有项目。Modbus RTU适合大多数标准设备，自由口适合非标协议，USS适合西门子驱动。真正让项目可靠运行的不是某个高级库，而是你把每一帧报文、每一根接线、每一个判断条件都理解清楚。

我自己做这类项目时，会先把设备说明书里的通讯协议打印出来，把关键参数抄在表格里，再动手写程序。很多时候，问题不是“PLC不会做”，而是“现场设备到底要什么”还没弄清楚。

如果你是第一次做S7-1200串口通讯，建议先从一台支持Modbus RTU的仪表或变频器开始，跑通主站单次读取，再扩展到多从站轮询。串口通讯这东西，只要链路稳定，后面扩展就只是程序问题。