很多人在第一次接触西门子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、自由口、USSS7-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帧中的校验位不仅影响数据位数也影响从站对帧的解析方式。建议在开始写程序之前先把下面这张表填写完整参数项本侧设定值对端设备要求备注波特率96009600必须一致数据位88常见8位停止位11多数设备支持1或2校验方式无无无校验/偶校验/奇校验从站地址11主站不需要从站必须寄存器地址4000140001取决于点位表数据类型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站到最后一站之间的循环间隔要稳定不要因为某个站异常导致总线死锁。必要时给每个站设置超时上限超时后强制跳到下一站。轮询慢不一定是坏事。如果现场从站本身是简单仪表几十毫秒响应很正常但上位机要求的数据采集周期是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或异或校验环节能直接复制现成算法模块就尽量复制。但要确认校验的数据范围尤其注意是从帧头开始校验还是从功能码开始校验。范围错了后面全错。收到回帧后建议先做三个判断再处理数据帧长度是否符合预期。地址或帧头是否匹配。校验是否正确。只有这三个条件都满足才认为这一帧有效。否则直接丢弃什么都不做。不要让无效数据进到业务逻辑里。5. 现场联调的关键参数与判断标准5.1 不同设备类型的常用参数参考下面是S7-1200PLC串口通讯联调时最常见的几类设备参数但仅作参考。实际参数必须以现场设备说明书为准。设备类型接口类型常见协议典型波特率典型寄存器或报文特征变频器RS485Modbus RTU9600 / 1920040001起步F000/F002地址常见称重仪表RS232/RS485自定义ASCII9600连续发送重量字符串扫码枪RS232自由口ASCII9600 / 115200回车结尾温控表RS485Modbus RTU9600保持寄存器读取测量值流量计RS485Modbus RTU9600寄存器点位按说明第三方上位机RS485Modbus 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侧、设备侧、上位机软件里的波特率、校验位、停止位全部对照一遍任何一侧不一致都可能导致全部失败。第三步看从站地址和寄存器地址。如果从站设备本来地址是2PLC却发地址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的仪表或变频器开始跑通主站单次读取再扩展到多从站轮询。串口通讯这东西只要链路稳定后面扩展就只是程序问题。
西门子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、自由口、USSS7-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帧中的校验位不仅影响数据位数也影响从站对帧的解析方式。建议在开始写程序之前先把下面这张表填写完整参数项本侧设定值对端设备要求备注波特率96009600必须一致数据位88常见8位停止位11多数设备支持1或2校验方式无无无校验/偶校验/奇校验从站地址11主站不需要从站必须寄存器地址4000140001取决于点位表数据类型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站到最后一站之间的循环间隔要稳定不要因为某个站异常导致总线死锁。必要时给每个站设置超时上限超时后强制跳到下一站。轮询慢不一定是坏事。如果现场从站本身是简单仪表几十毫秒响应很正常但上位机要求的数据采集周期是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或异或校验环节能直接复制现成算法模块就尽量复制。但要确认校验的数据范围尤其注意是从帧头开始校验还是从功能码开始校验。范围错了后面全错。收到回帧后建议先做三个判断再处理数据帧长度是否符合预期。地址或帧头是否匹配。校验是否正确。只有这三个条件都满足才认为这一帧有效。否则直接丢弃什么都不做。不要让无效数据进到业务逻辑里。5. 现场联调的关键参数与判断标准5.1 不同设备类型的常用参数参考下面是S7-1200PLC串口通讯联调时最常见的几类设备参数但仅作参考。实际参数必须以现场设备说明书为准。设备类型接口类型常见协议典型波特率典型寄存器或报文特征变频器RS485Modbus RTU9600 / 1920040001起步F000/F002地址常见称重仪表RS232/RS485自定义ASCII9600连续发送重量字符串扫码枪RS232自由口ASCII9600 / 115200回车结尾温控表RS485Modbus RTU9600保持寄存器读取测量值流量计RS485Modbus RTU9600寄存器点位按说明第三方上位机RS485Modbus 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侧、设备侧、上位机软件里的波特率、校验位、停止位全部对照一遍任何一侧不一致都可能导致全部失败。第三步看从站地址和寄存器地址。如果从站设备本来地址是2PLC却发地址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的仪表或变频器开始跑通主站单次读取再扩展到多从站轮询。串口通讯这东西只要链路稳定后面扩展就只是程序问题。
