1. 项目缘起当标准协议不够用的时候在工业自动化领域Beckhoff的TwinCAT3平台以其强大的实时性和开放性成为了许多复杂、高性能控制系统的首选。我们常常用它来集成伺服驱动器、IO模块、机器人甚至是第三方设备。大多数时候这些集成工作可以依赖成熟的现场总线协议比如EtherCAT、PROFINET或者基于ADSAutomation Device Specification的标准化通讯。这些协议就像高速公路上的标准车道有明确的交通规则和指示牌配置起来相对省心。但现实项目里你总会遇到一些“非标”设备。它们可能是一台老旧的检测仪器一个定制化的传感器盒子或者一个由其他团队开发的、只提供了简单TCP Socket接口的上位机软件。这些设备没有EtherCAT从站芯片也不支持PROFINET它们只认最原始的以太网数据包遵循一套自定义的、写在文档里的“自由协议”。这时候标准化的高速公路就开不进去了你需要自己动手在TwinCAT3里开辟一条能够与这些设备“对话”的专用通道——这就是TwinCAT3基于以太网TCP/IP的自由协议通讯要解决的问题。它本质上是让TwinCAT3这个实时控制核心能够像一个标准的TCP客户端或服务器一样通过网卡收发原始的字节流数据然后由我们编写的PLC程序来解析和打包这些数据。这听起来像是回到了网络编程的“原始时代”但在工业现场这种灵活性恰恰是解决异构系统集成的关键。我最近就在一个视觉引导的抓取项目中遇到了这种情况视觉处理单元运行在一台工控机上通过千兆网口输出坐标和状态信息而执行抓取动作的机器人控制器和伺服轴则由TwinCAT3统一管理。视觉单元提供的通讯库是基于TCP Socket的协议帧头、数据长度、校验和都是自定义的。显然EtherCAT走不通ADS虽然能跨机通讯但效率和实时性对于高频的坐标流传输并非最优。最终我们决定在TwinCAT3 PLC中直接实现TCP/IP客户端与视觉服务器建立连接进行高速、确定性的数据交换。2. TwinCAT3 TCP/IP通讯的两种核心模式在TwinCAT3中实现基于TCP/IP的通讯主要依赖于Tc2_System库中的FB_InitTCP和FB_OpenTCP系列功能块。根据网络角色我们可以分为服务器Server模式和客户端Client模式。选择哪种模式不取决于TwinCAT3本身而取决于你的项目架构和外部设备的角色。2.1 服务器模式守株待兔等待连接当外部设备如HMI、SCADA、或定制化测试软件需要主动连接TwinCAT3控制系统以获取或发送数据时TwinCAT3应配置为服务器。服务器模式的特点是“被动等待”它创建一个监听套接字绑定到指定的IP地址和端口上然后等待客户端来连接。在PLC中我们主要使用FB_OpenTCPServer功能块。你需要给它配置本地监听的IP地址通常是TwinCAT运行所在网卡的IP和端口号。一旦执行它就开始监听。当有客户端连接进来时该功能块会输出一个唯一的ConnectionID用于标识这个特定的连接。后续所有与这个客户端的收发操作都需要使用这个ConnectionID。服务器模式适用于以下场景提供数据服务TwinCAT3作为数据源向多个上位机客户端如看板系统、数据记录软件广播实时生产数据。接受远程指令允许高级调度系统或MES通过TCP连接向TwinCAT3发送生产订单、配方切换等指令。设备状态查询接口为第三方维护工具提供一个标准的TCP查询接口。注意在服务器模式下你需要管理多个可能的客户端连接。这意味着你的程序逻辑需要维护一个连接列表通常用数组或列表管理器并处理连接建立、断开、数据分发等事件复杂度相对较高。2.2 客户端模式主动出击建立连接当TwinCAT3需要主动从外部数据源如数据库、视觉系统、其他PLC或智能传感器获取数据时应配置为客户端。客户端模式的特点是“主动发起”它知道目标服务器的IP地址和端口并主动发起连接请求。在PLC中对应的功能块是FB_OpenTCPClient。你需要配置目标服务器的IP地址和端口号。调用后它会尝试与服务器建立连接。连接成功后同样会获得一个ConnectionID用于后续通讯。客户端模式适用于以下场景从视觉系统获取坐标正如我项目中的例子TwinCAT3作为客户端主动连接视觉处理单元的TCP服务器持续获取检测结果。从数据库读取配方在批次开始时TwinCAT3客户端连接数据库服务器下载当前产品的生产参数。与上级PLC通讯在分布式系统中作为下位机的TwinCAT3控制器主动连接上位主控PLC接收调度指令。提示客户端模式逻辑通常更简单因为通常只维护一个到固定服务器的连接。关键在于处理网络中断后的重连机制确保系统的鲁棒性。2.3 模式选择的核心考量如何选择问自己两个问题1.谁先发起通讯2.谁是数据的主要请求方如果答案是外部设备先发起、并向TwinCAT3请求数据用服务器模式。 如果答案是TwinCAT3需要主动去获取数据用客户端模式。 在很多项目中TwinCAT3可能同时扮演两种角色这就需要你在不同的PLC任务或程序模块中分别实现。3. 构建自由协议通讯的核心功能块详解理解了模式我们深入到具体实现。TwinCAT3的Tc2_System库提供了一套完整的功能块FB来封装TCP/IP Socket操作。下面我结合代码示例和实际配置拆解最关键的几个。3.1 连接管理FB_OpenTCPClient与FB_OpenTCPServer这是通讯的起点。以客户端FB_OpenTCPClient为例其引脚配置至关重要FUNCTION_BLOCK FB_OpenTCPClient VAR_INPUT sHostName : T_MaxString; // 服务器IP地址如 192.168.1.100 nPort : UINT; // 服务器端口如 8080 tTimeout : TIME : T#5S; // 连接超时时间 bEnable : BOOL; // 上升沿触发连接 END_VAR VAR_OUTPUT bBusy : BOOL; bError : BOOL; nErrId : UDINT; hSocket : UDINT; // 成功连接后返回的套接字句柄 ConnectionID : UDINT; // 连接标识符用于后续收发 END_VAR关键配置与避坑点sHostName务必使用目标设备的准确IP地址。在工业现场优先使用静态IP避免DHCP可能带来的地址变化问题。如果是在同一台PC上测试服务器和TwinCAT3同机可以使用127.0.0.1或localhost。nPort端口号需要与服务器端约定一致。注意避开系统保留端口如80、443、502。常用范围在2000~50000之间。tTimeout这个参数经常被忽略。在网络不稳定或服务器未就绪时如果没有超时设置bBusy会一直为TRUE阻塞整个连接逻辑。我一般设置为3-5秒给网络和设备一定的响应时间。bEnable的用法这是一个边沿触发的输入。正确的做法是在需要建立连接时例如设备上电、或收到一个启动命令产生一个上升沿脉冲而不是持续给TRUE。持续给TRUE会导致功能块反复尝试连接可能引发意外行为。服务器端FB_OpenTCPServer的配置类似但它绑定的是本地IP和端口。需要特别注意的是服务器块在一个连接建立后可以继续监听其他连接你需要循环调用它或使用多个实例来处理并发连接。3.2 数据收发FB_ReceiveTCP与FB_SendTCP连接建立后数据的收发依靠FB_ReceiveTCP和FB_SendTCP。它们是通讯数据流的核心。FB_ReceiveTCP接收数据接收数据通常比发送更复杂因为你需要处理数据粘包和半包问题。TwinCAT的接收功能块提供了两种主要模式定长接收你知道每一帧数据的确切长度。在cbLen参数中指定这个长度功能块会收满指定字节数后才置位bReceiveComplete。这适用于协议格式固定的场景。变长接收更常见你的协议帧长度是可变的通常帧头中包含长度字段。这时你需要先接收一个最小的头部例如先收4个字节获取长度信息然后根据解析出的长度再接收剩余的数据体。// 示例先接收4字节的帧头假设包含数据长度 IF NOT fbReceiver.bBusy AND NOT fbReceiver.bReceiveComplete THEN fbReceiver( sNetId: , ConnectionID: nConnID, pDestAddr: ADR(abyHeaderBuffer), cbLen: SIZEOF(abyHeaderBuffer), // 先收4字节 bEnable: bEnableReceive ); END_IF IF fbReceiver.bReceiveComplete THEN // 解析头部获取数据体长度 nBodyLen nBodyLen : ... // 从 abyHeaderBuffer 解析 // 然后启动第二次接收收取数据体 fbReceiver( pDestAddr: ADR(abyBodyBuffer), cbLen: nBodyLen, bEnable: TRUE ); END_IFFB_SendTCP发送数据发送相对直接你需要将组装好的协议数据块字节数组的地址和长度提供给功能块。FUNCTION_BLOCK FB_SendTCP VAR_INPUT ConnectionID : UDINT; pSrcAddr : POINTER TO BYTE; // 指向发送数据缓冲区的指针 cbLen : UDINT; // 发送数据的长度 bEnable : BOOL; // 上升沿触发发送 END_VAR VAR_OUTPUT bBusy : BOOL; bError : BOOL; nErrId : UDINT; END_VAR发送的关键细节数据组装在触发发送前你必须确保你的发送缓冲区例如一个ARRAY [0..MAX_LEN] OF BYTE里已经按自由协议格式填充好了所有数据帧头、长度、命令字、数据域、校验和等。校验和如CRC16、累加和的计算务必在PLC中完成这是保证数据完整性的重要一环。bEnable触发和连接一样发送也应由上升沿触发。常见的做法是当需要发送数据时先将数据填充到缓冲区然后产生一个单周期的脉冲信号来触发FB_SendTCP。发送完成判断通过bBusy信号判断发送是否完成。在bBusy从TRUE变为FALSE之前不要修改发送缓冲区的内容否则可能导致发送数据错乱。3.3 连接控制与清理FB_CloseTCP通讯结束时必须优雅地关闭连接释放系统资源。FB_CloseTCP功能块用于此目的。你需要将需要关闭的连接的ConnectionID传递给它。最佳实践在PLC程序停止或设备进入安全状态时主动关闭所有TCP连接。在检测到通讯超时或严重错误时也应先关闭错误连接然后尝试重新初始化。关闭连接后应将本地的ConnectionID变量重置为0或无效值并将连接状态标志置为断开。4. 自由协议的设计与解析从字节流到工程意义这是自由协议通讯中最具挑战性也最能体现工程师功力的部分。所谓“自由协议”就是你和设备供应商或软件团队共同约定的一套数据编解码规则。你的任务是在TwinCAT3 PLC中用结构体STRUCT和字节操作完美地实现这套规则。4.1 定义协议结构体一个好的起点是在PLC的DUT数据类型中用结构体精确映射协议帧。假设我们与视觉系统约定协议如下字段类型长度(字节)说明HeaderBYTE1固定帧头如 0xAACmdBYTE1命令字0x01坐标数据LengthUINT2后续数据域的长度小端序DataXINT2X坐标整数单位0.1mmDataYINT2Y坐标StatusBYTE1状态位CRC16WORD2从Header到Status的CRC16校验小端序那么在TwinCAT3中可以这样定义TYPE ST_VisionFrame : STRUCT bHeader : BYTE : 16#AA; bCmd : BYTE; wLength : UINT; nDataX : INT; nDataY : INT; bStatus : BYTE; wCRC16 : WORD; END_STRUCT END_TYPE注意这里wLength理论上应该等于DataX、DataY、Status的总长度5。定义好结构体后你可以声明一个该类型的变量stRxFrame。4.2 接收解析字节数组到结构体的转换FB_ReceiveTCP接收上来的是原始的字节流ARRAY OF BYTE。我们需要将其转换到定义好的结构体变量中以便访问各个字段。方法一指针强制转换高效但需谨慎这是最直接的方法利用PLC中指针和内存操作的功能。// 假设 abyBuffer 是接收到的完整字节数组 // pBuffer 是指向该数组的指针 pBuffer : ADR(abyBuffer); // 将指针强制转换为指向协议结构体的指针并解引用赋值 stRxFrame : POINTER TO ST_VisionFrame(pBuffer)^;这种方法瞬间完成“解析”但风险在于你必须确保abyBuffer的大小至少等于ST_VisionFrame的大小并且数据已经完整接收。你必须确保字节序Endianness与协议定义一致。PC和网络通常是大端序Big-Endian而Intel处理器运行Windows的工控机和许多控制器是小端序Little-Endian。如果协议规定是网络字节序大端而TwinCAT运行在x86/x64上小端那么直接内存拷贝会导致wLength、nDataX等多字节整数错乱。这是自由协议通讯中最常见的坑之一。方法二手动解析安全灵活更稳妥的方法是手动从字节数组中提取每个字段并进行必要的字节序转换。// 假设 abyBuffer 索引0开始存放数据 stRxFrame.bHeader : abyBuffer[0]; stRxFrame.bCmd : abyBuffer[1]; // 组合两个字节为UINT注意字节序 stRxFrame.wLength : BYTE_TO_UINT(abyBuffer[3], abyBuffer[2]); // 小端序低字节在前 // 组合两个字节为INT stRxFrame.nDataX : BYTE_TO_INT(abyBuffer[5], abyBuffer[4]); stRxFrame.nDataY : BYTE_TO_INT(abyBuffer[7], abyBuffer[6]); stRxFrame.bStatus : abyBuffer[8]; stRxFrame.wCRC16 : BYTE_TO_WORD(abyBuffer[10], abyBuffer[9]); // 自定义函数 BYTE_TO_UINT, BYTE_TO_INT 等 FUNCTION BYTE_TO_UINT : UINT VAR_INPUT bLow, bHigh : BYTE; END_VAR BYTE_TO_UINT : SHL(TO_UINT(bHigh), 8) OR TO_UINT(bLow);手动解析代码量稍大但你能完全控制解析过程方便处理字节序、位域等复杂情况也便于调试和日志记录。4.3 发送打包结构体到字节数组的转换发送是解析的逆过程。你需要将填充好的结构体stTxFrame转换成一个连续的字节数组然后交给FB_SendTCP。方法一指针拷贝pTxFrame : ADR(stTxFrame); // 计算结构体大小 nTxLen : SIZEOF(stTxFrame); // 将结构体内存拷贝到发送字节数组 MEMCPY(ADR(abySendBuffer), pTxFrame, nTxLen);同样需要注意字节序问题。如果协议要求大端序而你的结构体在内存中是按TwinCAT小端方式存储的直接拷贝发送出去的数据对于接收方来说就是乱序的。你必须在拷贝前或定义结构体时就处理好字节序。一种做法是在填充stTxFrame的wLength、nDataX等字段时就使用已经转换好的、符合网络字节序的数值。方法二手动填充abySendBuffer[0] : stTxFrame.bHeader; abySendBuffer[1] : stTxFrame.bCmd; // 将UINT拆分为两个字节按协议字节序排列 abySendBuffer[2] : TO_BYTE(stTxFrame.wLength AND 16#FF); // 低字节 abySendBuffer[3] : TO_BYTE(SHR(stTxFrame.wLength, 8) AND 16#FF); // 高字节 // ... 依次填充其他字段手动填充确保了每个字节的位置和值都完全符合协议规定是调试阶段最可靠的方式。4.4 校验和的计算与验证校验和是保证数据在传输过程中不出错的最后一道防线。协议中常用的有累加和Sum Check和循环冗余校验CRC。累加和将帧中指定范围的所有字节相加取低8位或低16位作为校验码。计算简单PLC中用循环累加即可实现。CRC16更复杂但检错能力更强。你需要根据协议指定的多项式如CRC16-CCITT, CRC16-MODBUS在PLC中实现CRC计算函数。这通常需要查找表Look-up Table来优化速度。在接收端解析完数据后你需要用同样的算法对收到的数据除校验字段本身重新计算一次校验和然后与帧中自带的校验和进行比较。只有一致这帧数据才被认为是有效的才能用于后续控制逻辑。在发送端你需要在所有数据填充完毕后计算校验和并填入帧的相应位置。5. 工程实战构建一个稳健的TCP/IP通讯功能块将上述所有知识点封装成一个可复用的、健壮的PLC功能块FB是工程化的关键。这个FB应该管理连接生命周期、处理数据收发、解析协议、并提供干净的数据接口给上层应用。5.1 FB设计状态机是核心一个稳健的通讯FB内部应该运行一个清晰的状态机State Machine。典型的状态包括INIT初始化内部变量复位所有标志。IDLE空闲状态等待启动命令。CONNECTING正在尝试建立TCP连接。调用FB_OpenTCPClient/Server并处理超时。CONNECTED连接已建立。启动心跳包发送定时器准备进行数据收发。RECEIVING正在接收一帧数据。可能包含“接收头部”和“接收主体”两个子状态。PROCESSING数据接收完成进行校验和验证、协议解析。SENDING正在发送一帧数据。DISCONNECTING正在主动断开连接。ERROR发生错误如连接失败、校验错误、超时。等待错误恢复或复位命令。状态机使得程序逻辑清晰易于调试和维护。每个状态只做特定的事情状态之间的转换条件明确如bConnectCmd上升沿、fbOpenTCP.bError、接收完成等。5.2 错误处理与重连机制网络通讯不可能100%可靠。你的FB必须能从容应对断线、超时、数据错误。心跳机制在CONNECTED状态定期如每秒向对端发送一个简单的心跳包或空数据取决于协议。同时监测接收超时。如果长时间未收到任何数据或心跳回复则认为连接已失效转入DISCONNECTING和ERROR状态。自动重连在ERROR状态不要立即尝试重连而是等待一个退避时间例如先等2秒再等5秒再等10秒直到一个最大值然后再跳转到CONNECTING状态。这可以避免在网络瞬时故障或服务器重启时产生洪水般的连接请求。错误码映射将FB_OpenTCP、FB_ReceiveTCP等返回的nErrId转换为更有意义的内部错误码或报警信息便于HMI显示和故障诊断。5.3 资源管理与线程安全缓冲区管理为发送和接收分别分配独立的、固定大小的缓冲区。避免在发送过程中修改发送缓冲区。对于接收使用双缓冲区或环形缓冲区策略可以在解析一帧数据的同时接收下一帧数据提高吞吐量。任务周期将这个通讯FB放在一个合适的PLC任务中执行。如果通讯要求高实时性如视觉坐标传输可以放在一个快速循环的任务中如1ms或2ms。如果只是偶尔发送指令放在一个慢速任务中即可。注意任务周期要与通讯频率匹配。互斥访问如果通讯FB解析出的数据如视觉坐标会被多个其他任务或程序访问考虑使用TON定时器或标志位来实现简单的互斥防止数据在更新过程中被读取导致数据不一致。6. 调试技巧与常见问题排查即使设计得再完美第一次调试自由协议通讯也几乎一定会遇到问题。以下是我总结的排查路径和工具。6.1 调试第一步网络连通性测试在写任何PLC代码之前先用系统工具验证基础网络。Ping测试在TwinCAT运行PC的命令提示符中ping目标设备的IP地址。确保物理链路是通的没有防火墙阻拦ICMP包。Telnet测试如果目标设备是服务器在PC上用telnet [IP] [端口]命令尝试连接。如果能连接上即使显示一片黑或立即断开说明端口是开放的服务器基本服务是正常的。这一步能排除至少50%的底层网络问题。6.2 数据抓包用Wireshark看到真相当PLC程序运行起来但通讯失败时Wireshark是你的终极武器。在运行TwinCAT的PC上抓取与目标设备通讯的网卡数据包。看什么TCP三次握手能看到[SYN],[SYN, ACK],[ACK]吗如果看不到说明连接根本没建立检查IP、端口、防火墙。数据流连接建立后能看到你的PLC发出的数据包吗数据内容十六进制是否符合你预期的协议格式帧头、长度、数据对不对方向是只有去的数据包没有回的还是对方有回复但你的PLC没收到这能帮你定位问题是发送端、接收端还是网络。对比分析用一个已知能工作的客户端比如用Python或C#写的一个简单测试程序连接同一个服务器抓取成功通讯的数据包。再抓取你PLC通讯时的数据包。逐字节对比差异点就是问题所在。十有八九是字节序或者校验和算错了。6.3 TwinCAT 系统调试器与日志在线观察将通讯FB内部的关键变量如状态机当前状态、接收到的原始字节数组、解析后的结构体、错误代码添加到在线观察列表。单步执行程序看状态转换是否符合预期。Trace 功能对于高速或偶发问题可以使用TwinCAT的Trace功能持续记录关键变量的变化然后导出分析。添加调试输出在状态机的关键节点如进入CONNECTING、收到完整帧、校验错误时将一个内部字符串变量赋值为调试信息并在线观察。或者将这些信息通过ADSLOGSTR函数写到TwinCAT日志中便于事后查看。6.4 常见问题清单连接被拒绝检查目标IP和端口是否正确确认服务器程序是否已启动并正在监听关闭PC和服务器上的防火墙临时测试。连接成功但收不到数据检查服务器是否真的发送了数据用Wireshark验证检查PLC中FB_ReceiveTCP的ConnectionID是否正确确认接收缓冲区和长度设置是否足够大。数据解析乱码首要怀疑字节序对比Wireshark抓到的原始数据和PLC内存中的数据看多字节整数的高低字节顺序是否反了。校验和不通过确认校验和的计算范围是从帧头开始到校验和前还是只算数据体确认使用的校验算法CRC16有多种多项式用已知正确的数据在PLC外如用在线CRC计算器验证你的PLC校验函数是否正确。通讯速度慢或不稳定检查PLC任务周期是否太慢检查是否在等待bBusy信号时使用了WAIT或循环等待阻塞了任务确认网络交换机是否为工业级是否存在广播风暴。7. 性能优化与高级话题当基本通讯跑通后在一些高性能要求的场景下你可能还需要关注以下方面。7.1 实时性考量TwinCAT的强项是硬实时。但标准的Windows TCP/IP栈是软实时的会受操作系统调度影响。对于要求亚毫秒级确定性的应用可以考虑使用TwinCAT的实时以太网驱动对于某些特定网卡Beckhoff提供了实时以太网RT-Ethernet驱动可以将TCP/IP通讯纳入到TwinCAT的实时任务周期中极大提高确定性。但这需要特定的硬件支持和更复杂的配置。优化任务分配将通讯FB放在一个独立的、周期合适的PLC任务中避免被其他耗时逻辑阻塞。减少数据量优化协议只传输必要的数据。例如视觉坐标是否可以用INT代替REAL状态信息是否可以用位域BIT压缩在一个字节内7.2 多连接与并发处理如果需要同时与多个设备通讯你有两种选择实例化多个通讯FB每个FB管理一个独立的连接。这是最清晰、最易于管理的方式。确保为每个FB分配不同的本地端口如果是客户端或处理好不同的ConnectionID如果是服务器。在单个FB内管理多个连接这需要更复杂的状态机和连接池管理通常只在连接数量动态变化且非常频繁时才考虑。对于大多数工业应用静态的多个FB实例更稳妥。7.3 与ADS通讯的对比你可能会问既然TwinCAT有ADS为什么还要用原始的TCP/IPADS是Beckhoff自家的高层协议基于TCP/IP。它提供了符号访问、数据订阅、事件通知等丰富功能跨语言支持好有C, C#, Python库。但它有额外的协议开销对于需要传输大量原始字节流或自定义二进制协议的场景不够“直接”。TCP/IP自由协议更底层更灵活零开销你的协议就是全部开销。效率极高尤其适合与非Beckhoff体系的设备进行高速、定制化数据交换。代价是你需要自己处理所有事情连接管理、数据打包、解析、错误恢复。选择哪一个如果对方设备支持ADS或者你需要在不同TwinCAT系统之间进行复杂的数据交互ADS是首选。如果你面对的是一个“黑盒”设备它只认你自己的二进制协议那么TCP/IP自由协议是唯一的选择。实现TwinCAT3的以太网TCP/IP自由协议通讯就像为控制系统赋予了一项与外界“说方言”的能力。它打破了标准协议的藩篱让集成各种“非标”设备成为可能。这个过程从理解连接模式开始到熟练运用功能块再到精心设计协议解析最后封装成稳健的工程模块。每一步都充满了细节从字节序的坑到校验和的算法从Wireshark抓包分析到状态机设计都需要耐心和实践。当我第一次看到通过自己编写的PLC程序稳定地从视觉服务器接收到一帧帧坐标数据并驱动机械手准确抓取时那种对系统掌控感带来的满足远超过使用一个现成的驱动。这或许就是工业自动化工程师的乐趣所在——不仅使用工具更创造连接。