倍福PLC RS485自由口通信实战：从硬件连接到状态机编程

简介：本资源是一份面向工业自动化工程师与倍福（Beckhoff）PLC初学者的RS232/RS485自由口通信实战案例，聚焦解决现场设备串口协议对接、非标Modbus变体或自定义ASCII帧通信等典型工程难题。压缩包共4个文件（34KB），含2个TwinCAT 3工程文件（.pro）用于主站逻辑与通信配置、1个封装串口操作函数的库文件（.lib）及1个EL6021串口模块的XML设备描述文件，结构精简、即开即用。已有2065人学习下载，适用于熟悉TwinCAT基础但缺乏串口通信实操经验的开发者。资源提供完整可运行的自由口收发逻辑、BCC校验实现、波特率与帧格式参数配置范例，并隐含对老版本TwinCAT兼容性调试思路，是理解倍福软PLC串口底层控制机制的实用入门参考。

1. 项目缘起：当标准协议遇上“非标”设备

在工业自动化现场，我们常常会遇到一个经典场景：主流的PLC需要与一些“老古董”或“非主流”设备进行数据交换。这些设备可能是一台上世纪90年代的老式仪表，一台没有标准工业总线接口的专用控制器，或者一个只提供了简单串行接口的定制化模块。它们不支持主流的EtherCAT、Profinet、Modbus TCP，甚至连Modbus RTU这种串行总线协议都没有，仅仅提供了一个最基础的RS232或RS485物理接口，以及一份薄薄的、语焉不详的通讯手册，上面写着“数据格式：起始位1，数据位8，停止位1，无校验，波特率9600”。

面对这种情况，很多工程师的第一反应是寻找一个协议转换网关。这当然是一种稳妥的方案，但会增加成本、接线复杂度和故障点。另一种更直接、更经济，同时也更能体现工程师“手艺”的方案，就是利用PLC自身的串行通讯接口，通过编程实现“自由口通信”（Freeport Communication）。简单来说，就是抛开Modbus等标准协议框架，由工程师自己定义数据帧的格式、解析规则和收发时序，直接与设备进行“对话”。

倍福（Beckhoff）的TwinCAT PLC系统以其强大的实时性和开放性著称，其CX系列或嵌入式控制器大多标配了RS232/RS485串口。利用TwinCAT的串口功能块库，我们可以灵活地实现这种底层串行通讯。今天，我就结合一个真实的项目案例，拆解一下如何在倍福PLC中，从零开始构建一个稳定可靠的RS485自由口通信程序，与一台只提供简单ASCII码指令的第三方设备进行数据交互。这个过程，远不止调用几个功能块那么简单，里面充满了对时序、缓冲区、错误处理和工业现场干扰的深刻理解。

2. 硬件准备与电气连接：RS485网络的基石

在敲下第一行代码之前，正确的硬件连接是通讯成功的一半，对于RS485这种差分信号总线尤其如此。一个疏忽就可能导致通讯不稳定甚至损坏接口。

2.1 接口识别与硬件选型

首先，要确认你的倍福控制器具体型号及其串口类型。例如，CX9020自带一个RS232端口，而许多CX51xx或CX52xx系列控制器则提供的是RS485端口。你需要查阅对应控制器的硬件手册。关键参数是：它是RS232（点对点）还是RS485（多点总线）？如果是RS485，是两线制（Data+， Data-）还是四线制（Tx+， Tx-， Rx+， Rx-）？绝大多数工业场景使用的是两线制半双工RS485。

对于只有RS232口的控制器，如果需要连接RS485网络，必须使用RS232转RS485转换器（也称“串口转换器”或“隔离器”）。这里我强烈建议选择带有电源隔离和防雷防浪涌功能的产品。工业现场电磁环境复杂，一个廉价的非隔离转换器很可能成为整个系统的故障源。我个人的经验是，宁愿在转换器上多花一两百元，也能省下后期无数小时的排查时间。

2.2 接线规范与终端电阻

RS485网络的稳定性极大程度上依赖于正确的布线。以下是几个必须遵守的黄金法则：

1. 极性一致：所有设备（PLC、转换器、从站设备）的“A”或“Data+”端子必须接在同一根双绞线上，“B”或“Data-”接在另一根上。接反了通讯肯定不通。
2. 使用双绞线：必须使用屏蔽双绞线（如AWG22的2芯屏蔽线）。双绞可以抵消共模干扰，屏蔽层应在控制器端单点接地，避免形成地环路。
3. 终端电阻：RS485总线在物理上的最远端两个节点（通常是PLC和最后一个从站设备）的A、B线之间，需要并联一个120欧姆的终端电阻，用以匹配电缆的特性阻抗，消除信号反射。很多转换器和设备内置了可通过拨码开关启用的终端电阻，务必根据实际网络拓扑正确设置。一个常见的误区是给网络上的每个设备都启用终端电阻，这会导致总线负载过重，信号幅度严重衰减，通讯距离大幅缩短。
4. 共地问题：如果网络中各设备供电电源的地（GND）电位不一致，可能会产生巨大的共模电压，损坏接口芯片。使用隔离型的RS485转换器或PLC通讯模块，可以有效地将本地的逻辑地与总线上的地隔离开，这是保证长期稳定运行的关键。

在我的案例中，使用的是倍福CX5140控制器自带的RS485端口（两线制），连接一台距离约50米外的智能电表。我选用了一款带隔离的RS485转换器（放置在电表侧），并在PLC侧和转换器侧分别启用了120Ω终端电阻。接线完成后，用万用表测量A、B线之间的电阻，应该在60Ω左右（两个120Ω电阻并联），这是一个快速验证终端电阻是否正确的土办法。

3. TwinCAT串口通讯核心：FB_Serial功能块深度解析

硬件准备妥当后，我们来深入软件核心。TwinCAT 3的Tc2_System库中提供了FB_Serial功能块，它是我们实现自由口通信的“瑞士军刀”。这个功能块功能强大但参数众多，理解其工作模式至关重要。

3.1 功能块初始化与模式选择

FB_Serial支持同步和异步两种操作模式，对于PLC的循环任务，我们通常使用同步模式。初始化时，需要调用FB_Init方法（或直接在声明时初始化结构体）来配置串口参数。一个典型的配置结构体ST_Serial如下：

stSerialConfig : ST_Serial; stSerialConfig.sPort := 'COM1'; // 端口号，在TwinCAT System Manager中查看 stSerialConfig.baudRate := 9600; stSerialConfig.dataBits := 8; stSerialConfig.parity := eParity.NONE; stSerialConfig.stopBits := eStopBits.ONE; stSerialConfig.rxBufferSize := 1024; // 接收缓冲区大小，根据帧长度设置 stSerialConfig.txBufferSize := 512; // 发送缓冲区大小 stSerialConfig.flowControl := eFlowControl.NONE; // 自由口通常不用流控

这里有几个关键点：

• sPort：不是Windows意义上的COM1，而是TwinCAT运行时下的串口设备名。你需要在TwinCAT System Manager的“Serial”下查看并激活对应的端口，才能在这里引用。
• rxBufferSize：这个参数经常被低估。如果接收缓冲区设置过小，而你的程序解析速度跟不上数据接收速度，就会导致缓冲区溢出，数据丢失。对于不定长或较长的数据帧，建议设置得大一些，例如1024或2048字节。
• flowControl：在自由口通信中，硬件流控（RTS/CTS）基本用不上，因为我们完全通过软件逻辑来控制收发时序。

3.2 数据收发方法与状态机设计

FB_Serial提供了Read，Write，ReadEx，WriteEx等方法。对于自由口通信，我强烈建议使用ReadEx和WriteEx，因为它们可以指定读取/写入的字节数，更适合处理定长或已知长度的数据帧。

自由口通信程序的核心是一个清晰的状态机。一个典型的状态流程如下：

1. IDLE（空闲）：等待发送触发条件。
2. SEND（发送）：调用fbSerial.WriteEx，将组装好的指令帧（例如ASCII字符串“READ_DATA\r\n”）写入串口。这里必须注意：WriteEx方法是非阻塞的，调用后它会立即返回，但数据可能还在发送缓冲区中。需要通过fbSerial.txCount等状态变量或等待一个固定延时（如10ms）来确保一帧数据发送完成，再切换状态。盲目切换状态可能导致两帧数据在总线上“粘”在一起。
3. WAIT_RESPONSE（等待响应）：发送完成后，启动一个接收超时定时器（例如200ms），并切换到等待状态。同时，可以开始尝试读取数据。
4. RECEIVE（接收）：在等待状态下，循环或定时调用fbSerial.ReadEx尝试读取数据。这里有两种策略：
   • 定长帧：如果你知道响应帧的固定长度（例如20字节），可以直接请求读取20字节。ReadEx会等待直到收到指定数量的字节或超时。
   • 不定长帧：更常见的情况是响应帧以特定字符结尾（如回车换行\r\n）。这时，你可以先读取1字节或若干字节，检查是否收到结束符。更好的做法是利用fbSerial.bytesReceived属性判断当前缓冲区有多少数据，然后一次性读取出来，再在程序里进行帧的切割和解析。切记，不要在一个PLC周期内频繁调用Read，应间隔几个毫秒，避免过度占用CPU。
5. PARSE（解析）：收到完整数据后，进行校验（如CRC、求和校验）和解析，将有效数据提取到PLC变量中。
6. ERROR（错误处理）：在任何阶段，如果发生超时、校验失败、fbSerial报告错误（bError为TRUE），都应跳转到错误状态，进行重试或报警记录。

这个状态机需要用一个CASE OF语句或专门的FB来实现，确保逻辑清晰，避免时序混乱。

4. 实战案例：与智能电表的ASCII协议通讯

现在，我将上述理论应用到一个具体案例：通过RS485读取一台智能电表的电压、电流、功率数据。电表协议是一个简单的ASCII码协议，查询指令为“#01\r\n”，响应格式为“>01,U=220.5,I=10.2,P=2249.1\r\n”。

4.1 指令组装与发送

首先，我们需要将查询指令字符串转换为字节数组。在Structured Text (ST)中，可以这样做：

PROGRAM MAIN VAR fbSerial : FB_Serial; stConfig : ST_Serial := (sPort:='COM1', baudRate:=9600, dataBits:=8, parity:=eParity.NONE, stopBits:=eStopBits.ONE); aTxBuffer : ARRAY[1..10] OF BYTE; // 发送缓冲区 aRxBuffer : ARRAY[1..128] OF BYTE; // 接收缓冲区 nRxLength : UINT := 0; eState : (IDLE, SENDING, WAITING, RECEIVING, PARSING, ERROR) := IDLE; tSendTimeout : TON; // 用于确保发送完成 tResponseTimeout : TON; // 接收超时 sCommand : STRING := '#01' + CR + LF; // CR LF 对应 \r\n END_VAR // 在初始化或需要发送时 sCommand := '#01' + CR + LF; STRING_TO_BYTES(sCommand, ADR(aTxBuffer), SIZEOF(aTxBuffer)); // 将字符串转换为字节数组 CASE eState OF IDLE: IF bStartRead THEN fbSerial.WriteEx(pData:=ADR(aTxBuffer), cbLen:=LEN(sCommand)); tSendTimeout(IN:=TRUE, PT:=T#50MS); // 给予50ms发送时间 eState := SENDING; END_IF SENDING: IF tSendTimeout.Q THEN // 发送时间到，认为已完成 tSendTimeout(IN:=FALSE); tResponseTimeout(IN:=TRUE, PT:=T#200MS); // 开始等待响应超时 eState := WAITING; END_IF WAITING: // 检查接收缓冲区是否有数据 IF fbSerial.bytesReceived > 0 THEN tResponseTimeout(IN:=FALSE); eState := RECEIVING; ELSIF tResponseTimeout.Q THEN // 超时处理 eState := ERROR; END_IF RECEIVING: // 尝试读取数据，假设一次性能读完 fbSerial.ReadEx(pData:=ADR(aRxBuffer), cbLen:=SIZEOF(aRxBuffer), cbRead=>nRxLength); IF nRxLength > 0 THEN eState := PARSING; END_IF PARSING: // 解析aRxBuffer中的字节，转换为字符串后查找‘U=‘， ‘I=‘， ‘P=‘等关键字 // ... 解析逻辑 ... eState := IDLE; // 回到空闲，等待下次查询 ERROR: // 记录错误，复位超时定时器，可能尝试重试几次后回到IDLE nErrorCount := nErrorCount + 1; IF nErrorCount >= 3 THEN bCommFault := TRUE; eState := IDLE; ELSE eState := IDLE; // 简单重试 END_IF END_CASE

4.2 数据解析与校验

收到字节数组aRxBuffer后，需要将其转换回字符串进行解析。这里可以使用BYTES_TO_STRING功能。解析时，要特别注意字符串操作的效率，避免在快速循环中使用复杂的字符串查找。对于固定格式，可以直接按位置截取。例如，知道“U=”从第6个字符开始，电压值长度为5个字符。

一个至关重要的环节是校验。虽然这个ASCII协议看起来没有校验，但为了工业可靠性，我们可以在程序内部增加一层软件校验。例如，在解析出数值后，检查其是否在合理范围内（电压>0且<300V）。更严谨的做法是，如果设备支持，发送带校验和的指令，并验证响应的校验和。

4.3 超时与重试机制

工业网络充满不确定性。因此，超时机制是自由口通信程序必须拥有的“保险丝”。在上述状态机中，我们设置了两个超时：

1. 发送超时(tSendTimeout)：用于保守估计一帧数据发送完成所需的时间。这个时间可以根据波特率和帧长度计算（字节数*10/波特率 * 1000 ms），并留有余量。
2. 响应超时(tResponseTimeout)：这是最重要的。从发送完毕到开始接收，必须设定一个合理的等待时间。时间太短，可能截断慢速设备的响应；时间太长，系统响应会变迟钝。通常需要根据设备手册和测试来调整，200ms-500ms是常见范围。

当超时发生时，不能简单地报错并停止。一个健壮的程序应该有重试机制。例如，在ERROR状态中，计数器nErrorCount累加，连续失败3次后才置位通讯故障bCommFault。在每次重试前，可以加入一个短暂的延时（如100ms），并考虑发送一个“通讯复位”指令（如果设备支持）或重新初始化FB_Serial功能块。

5. 高级议题与避坑指南

掌握了基础框架后，还有一些深水区需要小心趟过。

5.1 半双工冲突与收发切换延迟

RS485是半双工总线，同一时刻只能有一个设备发送。PLC发送完毕后，必须从“发送模式”切换到“接收模式”，才能听到总线上其他设备的响应。这个切换是由FB_Serial底层或RS485芯片的“方向控制引脚”（DE/RE）完成的。

关键陷阱：切换需要时间！芯片的收发切换延迟通常在微秒到毫秒级。如果你在发送完最后一字节的指令后，立即切换为接收并尝试读取，很可能因为芯片还未完全切换到接收状态，而错过了响应帧开头的几个字节。这就是为什么我在状态机中使用了tSendTimeout，并给予了50ms的保守延时。对于高速通讯，这个延时可以缩短，但必须通过示波器或逻辑分析仪来精确测量和验证。

有些高级的FB_Serial实现或专用的RS485通讯模块（如倍福的EL6001）会自动管理方向控制，你只需要关注数据逻辑即可，这大大简化了编程。

5.2 接收数据粘包与断帧处理

在异步串行通讯中，如果接收方处理速度慢，或者发送方连续发送多帧数据，就可能发生“粘包”——即两帧或多帧数据在接收缓冲区中连在一起。我们的程序必须有能力将它们正确分开。

对于以特定结束符（如\r\n）定界的协议，处理粘包的标准方法是：

1. 将每次ReadEx读出的数据追加到一个自定义的、足够大的环形缓冲区或字符串变量中。
2. 在这个缓冲区中搜索结束符\r\n。
3. 如果找到，则将从缓冲区开头到结束符（含）之间的数据截取出来，作为一帧完整的报文进行解析。
4. 将已处理的数据从缓冲区中移除，保留剩余的不完整数据，等待下次接收。

这需要你在PLC中维护一个比FB_Serial内部缓冲区更灵活的报文缓冲区。

5.3 干扰与数据错误的应对

工业现场的电焊机、变频器、大功率电机启停都会产生强烈的电磁干扰，可能导致串口线上产生毛刺，进而引发数据错位、帧错误等。FB_Serial功能块的bError输出和nErrorId可以报告一些硬件错误（如奇偶校验错、帧错误）。

除了依赖硬件校验（如设置奇偶校验位），在软件层面可以：

• 增加软件校验：即使协议本身没有，也可以在应用层为数据增加CRC或求和校验。发送方计算并附加，接收方验证，不通过则丢弃。
• 关键数据回读验证：对于写入类的指令，执行后最好再发送一次读取指令，验证数据是否真正生效。
• 增加信号滤波：在硬件上，确保使用屏蔽双绞线，屏蔽层良好接地。在软件上，可以对连续读取的模拟量值进行滑动平均滤波，消除偶然的跳变。

5.4 性能优化与多任务协同

如果你的PLC需要与多个串口设备通信，或者同一个串口需要轮询多个地址（在RS485总线上），就需要考虑任务调度。

• 避免阻塞：ReadEx在等待指定长度数据时是阻塞的（直到超时）。不要在主循环任务中直接使用阻塞式读取，这会导致整个PLC周期卡住。应该使用非阻塞的状态机方式，如前文所示，在每个周期只进行少量操作（检查状态、读取可用数据）。
• 任务周期匹配：为串口通讯创建一个独立的、周期较慢的PLC任务（例如50ms或100ms），专门处理状态机和数据解析。这可以避免高速的主任务（如1ms的运动控制）被通讯任务拖慢。
• 轮询调度：对于一条RS485总线上的多个设备，需要设计一个轮询表。依次与每个设备进行“发送-等待-接收”的完整交互，一个设备处理完毕后再处理下一个。务必为每个设备设置独立的超时和重试计数，避免一个设备的故障阻塞整个总线。

实现一个稳定可靠的倍福PLC自由口通信程序，是一个从硬件到软件、从理论到实践的完整闭环。它考验的不仅是编程语法，更是对通讯底层原理、工业现场环境和系统稳定性的综合理解。每一次成功的通讯握手，背后都是对这些细节的精心把控。当你亲手搭建的系统在嘈杂的工厂环境中稳定运行数月而无一次通讯中断时，那种成就感，远非调用一个现成的协议库所能比拟。这或许就是工控编程的“手艺”所在。

本文还有配套的精品资源，点击获取