西门子博途SCL实战：RS485自由口轮询程序设计与现场调试

前几天帮朋友排查一个数据采集项目，PLC挂在RS485总线上轮询12台温控表，其中一台总是偶发超时，查到最后发现是A/B线在接线端子处和屏蔽层搭在了一起。这种问题不亲自跑现场真的很难想到。RS485轮询程序写起来不难，但要把时序、超时、容错都处理到位，再把现场各种隐性干扰排掉，这里面的门道确实值得单独写一篇。

本篇是西门子博途SCL学习笔记的第三篇，前两篇分别讲了SCL的基础语法、数据类型和UDT/数组的使用，这篇就集中聊自由口通讯里的RS485轮询程序。目标读者是已经在博途里写过基础SCL程序、想用PLC的串口模块去采集第三方仪表数据的朋友。文章以S7-1200 + CM1241 RS485为硬件基础展开，思路可以平移到S7-1500和其他支持自由口通讯的模块上。

1. 从现场需求说起：自由口+RS485轮询到底解决什么问题

1.1 为什么是RS485而不是Profinet或现成的Modbus库

做自动化项目的人都清楚，现场设备永远是五花八门的。国产温控表、电表、变频器、称重仪表、扫码枪、环境传感器，这些设备里带Profinet接口的少之又少，带RS485接口的倒是几乎成了标配。RS485这个物理层标准出现几十年了，至今还在工业现场大量使用，原因无非三点：距离远、抗干扰、便宜。理论传输距离1200米，用普通双绞线就能组网，一主多从最多挂32个标准负载，配上隔离器还能更多。

那有人会问，博途自带了Modbus RTU库指令，直接调库不就行了吗？确实，如果所有从站都是标准Modbus RTU协议，MB_MASTER指令是首选。但现实是，很多仪表厂商用自定义协议，或者协议里加了私有命令、特殊帧头帧尾、加密算法，这时候Modbus库派不上用场，只能走自由口通讯——由用户程序自己组装帧、发送、接收、解析。所谓“自由口”，就是PLC串口模块直接收发原始字节流，协议层完全由PLC程序说了算。

1.2 自由口“自由”在哪里：协议层自己说了算

自由口通讯的核心价值就是把“通讯协议”这个问题的决定权交给工程师。PLC把RS485收发器打开，发送缓冲区里的任意字节，接收缓冲区里出现的任何数据，程序都可以自行解释。这意味着你既可以用它实现Modbus RTU，也可以实现DL/T645电表协议，甚至可以写一个只有自家设备能懂的简单协议。

代价就是一切都要自己做：帧怎么组、校验用什么算法、超时设多少、收到错帧怎么处理、总线异常怎么恢复。这其实就是一个最简单的主从轮询协议栈。把这件事想清楚了，Modbus RTU的本质也就理解了——它就是一套成熟的轮询协议，只是把地址、功能码、CRC、异常码这些都标准化了。所以这篇文章虽然叫“自由口通讯”，实际写的这套轮询框架，稍加改造就能兼容Modbus RTU设备，两者的架构完全一致。

2. 硬件基础与总线接线：A/B线、终端电阻、隔离与EMC

2.1 串口模块选型：CM1241 RS485与CB1241怎么选

S7-1200系列支持两种RS485硬件方案：一种是通信板CB1241，插在CPU正面的扩展槽里，占用空间小，适合从站数量少、距离近的场景；另一种是通信模块CM1241 RS485，通过CPU左侧总线扩展，有独立的处理器和电气隔离，抗干扰能力和驱动能力更强，适合现场总线距离长、从站多、环境复杂的情况。

我个人在超过8个从站的现场项目里基本都用CM1241 RS485，模块本身带电气隔离，电源需求也更宽容。CB1241虽然便宜，但毕竟和CPU靠得太近，现场变频器一启动，偶尔会把CPU的通讯状态带出问题。S7-1500系列一般用ET200SP的RS485模块或CM PtP模块来实现，原理一样，指令略有差异，这里不展开。

2.2 一主多从接线：A/B、屏蔽层与终端电阻的讲究

RS485是差分信号，两条线分别叫A和B（有的设备标D+和D-，还有的标T+和T-，本质一样）。接线规则只有一个：主站的A接从站的A，主站的B接从站的B，所有设备并联在一条总线上。

实际接线有个很隐蔽的坑：很多国产设备会把“A/B”相对调换，尤其是不知名品牌的仪表，丝印标A的其实是B。遇到过不止一次，新接一台仪表，从站地址、波特率全对，就是没回应，把A和B对调后立刻通了。所以配新设备时，先别着急怀疑程序，拿万用表量一下线的通断，再把A/B顺序确认一遍，这个习惯能省很多事。

终端电阻也是老生常谈但总是出问题的地方。RS485总线需要在物理最远的两个端点各并联一个120欧姆电阻，用来吸收信号反射。注意是总线最远的两端，不是每台设备都接。很多仪表和PLC模块本体上带终端电阻拨码开关，如果已经在总线的两端打开，中间设备一律关闭，否则并联电阻太多，总线负载过重，波形反而变差。

屏蔽层用单端接地，一般建议在主站侧接地。有些项目图省事，屏蔽层两头都接，结果形成接地环路，工频干扰直接耦合进总线，数据错得莫名其妙。正确的做法是屏蔽层在PLC侧接到接地端子，从站侧的屏蔽层悬空。

2.3 把硬件底子打好：共地、隔离和防雷

RS485虽然号称差分信号，理论上不依赖公共地，但总线上所有设备之间必须有共同的电位参考，否则共模电压超出发送器允许范围，轻则数据乱码，重则烧毁芯片。典型场景是：PLC用开关电源供电，仪表用另一路220V供电，两路电源的负极又没有连通，A/B间的共模电压飘到几十伏，通讯自然不稳定。

解决方式有两种。一是把各设备的信号地/电源负极做等电位连接，也就是“共地”；二是用带隔离的RS485接口，让总线侧和逻辑侧完全电气隔离，从源头上切断共模回路。CM1241 RS485模块本身带隔离，但如果从站是裸板设备，建议在总线上加一个RS485隔离中继器或隔离器，成本不高，稳定性提升非常明显。

防雷方面，室外走线时总线入口处要加RS485防雷器，选响应时间在纳秒级的TVS方案。自己做电路板时，A/B线上要并联TVS管（比如SMBJ6.5CA）和自恢复保险丝，有的还会在A/B线之间加一个12欧姆电阻做匹配。热搜词里有个“rs485自动收发电路图”，这主要针对单片机自制的RS485节点：MAX485的RE/DE引脚通常由单片机的TX信号经三极管取反后自动控制，发送时DE拉高，发送完自动拉低释放总线。这个电路在9600bps以下问题不大，波特率提高到19200以上时，时序延迟容易导致帧头和帧尾异常，更稳妥的做法还是用独立的GPIO控制收发方向。

3. 轮询程序的架构设计：为什么状态机是这种场景的标准答案

3.1 顺序阻塞式写法的坑

初学者最容易写出来的轮询逻辑是这样的：第1步发送请求，第2步延时等待，第3步读取数据，第4步解析，然后循环到第2台从站。乍看逻辑通顺，但放进PLC里就是灾难。原因在于PLC程序是循环扫描执行的，OB1的一个周期里如果执行了一个长延时，整个PLC程序都被阻塞了，运动控制、报警处理、HMI通讯全部跟着卡顿。比如轮询16台从站，每台延时300毫秒，一轮下来将近5秒，这5秒内CPU都在“死等”，其他逻辑全部停摆。

就算用RPT或者带延时的系统函数硬扛，程序维护性也非常差。现场从站数量一变、某台设备故障、上位机要求动态调整轮询顺序，这种线性写死的代码改起来牵一发动全身。所以，RS485轮询必须用状态机，把一个从站的完整交互拆解成多个扫描周期可以持续执行的状态。

3.2 用UDT把轮询参数表做成数据驱动

状态机的代码结构是死的，可变的只有“下一台从站发给谁、发什么内容”。所以要把轮询参数从程序逻辑里抽出来，放进一张数据驱动的参数表。这张表用UDT定义，每个从站对应一条记录，字段包括站号、功能码、起始地址、读取长度、是否启用等。

TYPE UDT_PollItem STRUCT SlaveAddr : Byte; // 从站地址 FuncCode : Byte; // 功能码，如03读保持寄存器 StartAddr : Word; // 起始寄存器地址 ReadLen : Byte; // 寄存器数量 Enabled : Bool; // 该从站是否参与轮询 TimeoutMs : Int; // 超时时间(毫秒) END_STRUCT END_TYPE

再用一个全局DB创建一个数组，比如1到32条记录，对应32台从站。以后现场加设备、改地址，直接在DB里维护数据行，程序一行都不用动。这是数据驱动设计的基本功，也是SCL相对于梯形图的一个巨大优势：用数组+UDT管批量参数，比在梯形图里一个个拉地址清晰太多。

3.3 整体状态流转：空闲、等待应答、解析、错误处理

轮询状态机我习惯分成4个状态，用整数常量定义：

• 空闲（0）：上电后从第1台从站开始，构造发送帧，触发Port_Write，切到等待应答
• 等待应答（1）：持续调用Port_Read接收数据，同时检查超时定时器，收到完整帧就切到解析，超时未收到就切到错误处理
• 解析（2）：校验帧头、站号、校验码，提取数据写入缓存，然后切到空闲准备下一台
• 错误处理（3）：错误计数累加，决定是否跳过当前从站、是否报故障，然后返回空闲

核心思想：每个扫描周期只往下推进一个状态，状态之间的切换由“硬件标志位”和“定时器”驱动，不依赖任何延时指令。这样无论OB1扫描周期怎么波动，整个轮询节奏都由状态机自己控制，不会卡住程序，也不会因为扫描周期不均匀导致超时误判。

4. SCL实现拆解：发送、接收、超时与CRC校验

4.1 串口指令的调用方式：Port_Config、Port_Write、Port_Read

在TIA Portal中，S7-1200的串口自由口通讯指令是Port_Config、Port_Write、Port_Read。首次调用前需要先调用Port_Config配置串口参数：端口号、波特率、数据位、停止位、奇偶校验和流控。配置可以在PLC启动时执行一次，也可以运行时动态修改。

// 串口参数配置：9600, 8, 1, 无校验 "Port_Config_DB"( REQ := #xConfigReq, PORT := #iPortId, // 模块在硬件组态中的端口号 BAUD := 3, // 9600波特率对应的枚举值 PARITY := 0, // 无校验 DATABITS := 8, // 8数据位 STOPBITS := 1, // 1停止位 FLOW_CTRL := 0, // 无流控 DONE => #xCfgDone, ERROR => #xCfgErr, STATUS => #wCfgStatus);

Port_Write用于发送数据，需要在REQ上升沿触发，发送完成后DONE置位。Port_Read则要长期使能，持续把接收缓冲区里的数据搬运到用户程序指定的字节数组里。

// 发送 "Port_Write_DB"( REQ := #xWrReq, PORT := #iPortId, BUFFER := #abSendBuf, // 发送缓冲区 LEN := #iSendLen, // 发送长度 DONE => #xWrDone, ERROR => #xWrErr, STATUS => #wWrStatus); // 接收 "Port_Read_DB"( EN_R := #bEnable, // 常开接收 PORT := #iPortId, BUFFER := #abRcvBuf, // 接收缓冲区 DONE => #xRcvDone, // 有数据到达 DATA_LEN => #iRcvLen, // 本次接收到的字节数 ERROR => #xRcvErr, STATUS => #wRcvStatus);

4.2 发送帧构建与CRC16校验

以类Modbus RTU的请求帧为例，发送帧格式是：站号、功能码、起始地址（2字节）、寄存器数量（2字节）、CRC16低字节、CRC16高字节。帧构建的SCL代码可以写成一个独立的FC函数，输入站号、功能码、起始地址、数量，输出字节数组和帧长度。

// 帧构建函数示意图 FUNCTION "BuildFrame" : Int VAR_INPUT SlaveAddr : Byte; FuncCode : Byte; StartAddr : Word; Cnt : Byte; END_VAR VAR_IN_OUT Frame : Array[0..7] Of Byte; END_VAR VAR_TEMP wCRC : Word; bTmp : Byte; END_VAR BEGIN Frame[0] := SlaveAddr; Frame[1] := FuncCode; Frame[2] := Byte_IN(StartAddr) / 16#100; // 地址高字节 Frame[3] := Byte_IN(StartAddr) AND 16#FF; // 地址低字节 Frame[4] := 0; // 数量高字节 Frame[5] := Cnt; // 数量低字节 // 计算CRC16，结果放到Frame[6]和Frame[7] wCRC := 16#FFFF; FOR i := 0 TO 5 DO wCRC := wCRC XOR Frame[i]; FOR j := 1 TO 8 DO IF (wCRC AND 16#0001) <> 0 THEN wCRC := SHR(IN := wCRC, N := 1) XOR 16#A001; ELSE wCRC := SHR(IN := wCRC, N := 1); END_IF; END_FOR; END_FOR; Frame[6] := Byte_IN(wCRC AND 16#00FF); // CRC低字节在前 Frame[7] := Byte_IN(SHR(IN := wCRC, N := 8)); RETURN 8; // 帧长度 END

CRC16的A001多项式是Modbus RTU的标准多项式，迭代计算9600波特率下8字节帧耗时极少，可以放心用。很多初学者会在这里抄一个查表法优化版，实际PLC里位运算法完全够用，不必追求极致速度。注意Modbus寄存器地址的高低位顺序，以及CRC低位在前，这两个顺序弄反了，从站不会给你任何回应。

4.3 等待应答与超时判定

发送完成后状态切到等待应答，在这个状态里做两件事：持续接收、判断超时。这里的关键是“一帧数据必须完整接收”。因为Port_Read的机制是缓冲区里有多少数据就返回多少，不一定刚好是一整帧，可能一帧被拆成两个扫描周期到达。如果收到半帧就进解析，解析必然失败。

我的处理方式：启动一个超时定时器，并在每次收到数据时刷新“最后收到数据的时间”。发送完请求后，如果收到第一包数据，认为从站开始响应了，继续累加后续数据；当连续若干个扫描周期没有新数据到达，且接收缓冲长度不为0，才认为这一帧完整了。这个“静默窗口”按3.5个字符时间算，波特率9600时约为4毫秒，所以一般以20毫秒或者一个扫描周期作为窗口即可。为便于理解，代码里直接用一个等待状态：

CASE #iState OF 0: // 空闲 #iIdx := #iIdx + 1; IF #iIdx > #iMaxSlave THEN #iIdx := 1; END_IF; // 跳过未启用的从站 IF NOT #audo_Poll[#iIdx].Enabled THEN #iState := 0; ELSE // 构建发送帧 #iSendLen := "BuildFrame"(SlaveAddr := #audo_Poll[#iIdx].SlaveAddr, FuncCode := #audo_Poll[#iIdx].FuncCode, StartAddr := #audo_Poll[#iIdx].StartAddr, Cnt := #audo_Poll[#iIdx].ReadLen, Frame := #abSendBuf); #iRcvCnt := 0; #xWrReq := TRUE; #iState := 1; END_IF; 1: // 等待应答 IF #xWrDone THEN // 发送完成，开放接收窗口 #tonWait(IN := TRUE, PT := T#300MS); // 超时时间 IF #xRcvDone AND #iRcvLen > 0 THEN // 把本次收到的数据追加到接收数组 // 刷新静默定时器，继续等待下一包 END_IF; IF #tonWait.Q THEN // 超时未收到完整帧 #iState := 3; END_IF; END_IF;

超时时间的整定很有讲究。设太短，从站稍慢就被误判为超时；设太长，坏从站会拖慢整个轮询周期。保守的做法是先按从站手册标注的最大响应时间乘以1.5倍，同时考虑波特率下的传输时间。下面是9600波特率下粗略的帧传输时间表，超时时间至少要覆盖它再加余量。

上表按10位一个字节（1起始位+8数据+1停止位）估算。实际项目里从站的响应时间往往远大于传输时间，所以通用做法是响应超时设200到500毫秒，帧间隔静默窗口设20到50毫秒。

4.4 响应帧解析与数据入库

收到完整帧后进入解析状态。解析的第一步是校验站号和功能码，防止总线上其他设备的数据串入；第二步是校验CRC，确认帧在传输过程中没有被干扰；第三步才是提取数据。

// 解析响应帧 IF #abRcvBuf[0] <> #audo_Poll[#iIdx].SlaveAddr THEN // 站号不匹配，丢弃 #iState := 3; ELSIF #abRcvBuf[1] <> #audo_Poll[#iIdx].FuncCode THEN // 功能码错误，可能从站返回异常码 #iState := 3; ELSE // 校验CRC通过后，把数据区按字存入结果DB // 例如Modbus RTU响应：Addr Addr Func ByteCount Data... CRC Lo CRC Hi FOR i := 0 TO (#iRcvLen - 5) / 2 - 1 DO #aDataArr[#iIdx * 50 + i] := Byte_TO_Int(#abRcvBuf[3 + 2*i]) * 256 + Byte_TO_Int(#abRcvBuf[4 + 2*i]); END_FOR; #iErrCnt := 0; // 通讯成功，错误计数清零 #State := 0; // 回到空闲，轮询下一台 END_IF;

这里有个高频问题：收到的数值和仪表面板显示对不上。多数情况是寄存器数据的高低位顺序问题。不同厂家的Modbus实现，有的寄存器高字节在前，有的低字节在前，有的32位整型还要考虑字序和字节序。解析时先用串口助手抓原始帧确认字节顺序，再写解析逻辑，不要想当然按大端模式处理。下面是常见的数据顺序对照：

5. 现场调试链路与高频坑位

5.1 三步调试法：串口助手、PLC仿真、逻辑分析仪

遇到通讯调不通，我调试的顺序永远是：先用电脑代替PLC，再用PLC代替电脑。

第一步，把USB转RS485接到总线上，串口助手选择从站协议，发送一帧标准的Modbus RTU请求，看从站有没有应答、应答帧长什么样。这一步能确认从站本身工作正常、参数配置正确。如果你手里有Modbus Poll这类软件，可以测试多台从站。

第二步，把PLC程序下载进去，用TIA的监控表或者调试面板看状态机变量：iState是否在0和1之间正常切换、接收帧长度是否和串口助手一致、错误计数是否增长。这一阶段能暴露发送帧构建和接收解析的代码问题。

第三步，如果以上都正常但现场还是偶发故障，就要动用逻辑分析仪或者示波器看RS485的A/B差分波形，重点看沿是否陡峭、有没有振铃、波形幅度够不够。绝大多数偶发通讯故障，最终都能在波形里找到答案。

5.2 五个必查坑位：从接线反了到缓冲区残留

根据这几年现场排查经验，RS485轮询程序跑不稳定的原因，90%集中在这几个地方：

第一，A/B线接反。前面说过，别迷信设备丝印，用万用表量或者A/B对调试一下就知道。

第二，终端电阻位置不对。有人见设备上有个拨码就拨，结果几十台设备全部开启终端电阻，信号衰减严重。记住只有总线最远两端要接。

第三，校验位设置不一致。PLC这边配置了偶校验，仪表那边默认无校验，结果每个字节的校验都失败，表现出来就是完全没数据，或者收到一堆乱码。这类问题用串口助手调试时最容易发现，因为电脑串口助手能显示原始字节。

第四，接收缓冲区残留。前一轮的响应帧没有完全清空，下一轮的接收把两帧数据拼在一起解析，帧尾CRC必然报错。所以发送下一帧之前，一定要把接收数组和接收长度清零。

第五，波特率不匹配导致的“能通但错”。9600和19200这类倍率关系下，报文偶尔能过，偶发错位。表现为读回来的寄存器值偶尔整个翻倍或者错乱。这点特别容易迷惑人，因为不是完全不通。排查方法也简单：串口助手确认从站波特率，再看PLC配置，两边不一致就统一。

6. 轮询参数整定，以及我踩过的那几个坑

6.1 轮询周期、超时与重试次数的匹配

轮询程序的最终效果，体现在两个指标上：整轮周期和单站故障恢复时间。整轮周期等于所有启用从站的响应时间之和，加上每站之间的调度间隙。假设16台从站，每台响应时间是100毫秒，那整轮周期就是1.6秒左右。如果上位机要求数据刷新频率是1秒，就需要提高波特率、减少从站数量，或者把响应慢的设备单独分组轮询。

超时和重试次数是一对组合。我喜欢把重试次数设为2到3次。第一次超时，立即重发当前从站一次，如果第二次成功，错误计数清掉；如果第二次也超时，就跳过当前从站继续轮询后面的，同时把错误计数累加。这样一台从站故障最多拖慢两台次的超时时间，不会让整条总线瘫痪。这里有个小技巧：把超时时间和重试次数做成全局DB里的变量，HMI上可以调整。现场调试的时候你就能体验到不用反复下载程序、直接在触摸屏上改参数的快感。

6.2 上位机交互：让轮询参数可调

轮询程序稳定之后，下一步就是把“轮询参数”和“通讯状态”暴露给上位机或触摸屏。通讯状态至少包含三样东西：最近一次通讯时间、当前从站号、每个从站的历史错误计数。这样现场出了故障，操作工看一眼触摸屏就知道是哪台表失联，而不是一头雾水来找工程师。

数据解析结果放到全局DB里，用数组按从站号索引存储，上位机通过S7通讯、OPC UA或者Profinet直接读取即可。我这里习惯把“轮询调度逻辑”和“数据访问接口”分开：轮询FB只负责把数据写进结果DB，上位机只读结果DB，不直接访问轮询FB内部变量，避免外部读写干扰状态机。

6.3 稳定运行一年后回头看，什么最重要

回看处理过的RS485项目，真正决定成败的往往不是SCL代码本身，而是总线物理层和容错机制。代码写得再漂亮，A/B线压接不牢、屏蔽层悬空、从站电源不共地，照样随机掉线。而容错机制做得好不好，决定了某台从站故障时，整个系统是一声不吭地跳闸停机，还是报警提示同时继续稳定运行。

另一个容易被忽略的点是日志。建议在轮询FB里做简单的通讯统计：总请求次数、成功次数、超时次数，存成全局变量。项目投运后这些数据是排查问题的第一手证据。我曾经遇到一个客户说“通讯每天下午三点准时断”，后来查看统计发现故障从站集中在某一台新加的仪表上，而它的电源来自和变频器同一路，下午三点正是车间最大负载运行时间，问题定位就很快。

RS485轮询程序写到这里基本完整了，这套状态机框架加上数据驱动的参数表，是我在多个项目里反复用、反复打磨的结果。它不一定是最聪明的写法，但一定是最容易维护、最经得起现场折腾的写法。如果你正在为自己的项目写自由口轮询，建议先拿串口助手把协议完全摸透，再动手写代码。协议数据手册里往往只有帧格式，没有超时参数和字节序说明，这些只能靠实测拿到，而实测才是自由口通讯调试的真正开始。