前阵子做一个产线改造现场分成两个控制柜各装了一台S7-200 SMART。甲方要求两台柜子必须联动A柜的出料完成信号要送到B柜B柜的故障和急停状态要实时回传到A柜产量数据两边还要互相抄读。第一反应是拉硬线数了数信号二十几个点两个柜子之间加一大排端子以后改信号还要重新布线这方案实在不划算。好在两台PLC都自带以太网口直接走TCP通信做数据互传就成了最自然的选择。整个过程不算复杂但我在配置过程中踩了不少坑从固件版本到库存储区从连接时序到重连策略今天干脆把完整流程和避坑记录一次写清楚。这篇文章不是泛泛讲原理而是把双PLC数据互传从选型到落地完整走一遍。无论你是刚接触PLC以太网通信的电气工程师还是已经在现场被TCP连接问题折腾过的设备维护人员都可以把这份流程当作一份可落地的参考。1. 双PLC数据互传先摸清S7-200 SMART有几条通信路线1.1 三条路线和它们各自的脾气S7-200 SMART自带以太网口所以两台PLC之间做以太网通信硬件上不需要加任何模块但软件层面的实现方式却有好几条其中最常被拿出来用的有三条。第一条是Modbus TCP。说白了就是一台PLC做Modbus TCP客户端另一台做Modbus TCP服务器两边通过保持寄存器来交换数据。S7-200 SMART提供MB_CLIENT和MB_SERVER两个库指令配置相对简单尤其是和上位机、触摸屏、第三方仪表通信时Modbus TCP是兼容性最好的方案。但它的局限也很明显数据交换要走寄存器而寄存器数量、功能码这些都要按Modbus规则来如果你想传输一段结构比较复杂的自定义数据就会觉得被框住了。第二条是GET/PUT向导。这是西门子自家设备之间通信的特快通道在Micro/WIN SMART软件里通过向导配置可以直接读远程PLC的V区、M区甚至Q区也可以写远程PLC的数据。配置起来非常快基本上点点鼠标就能生成调用代码两个S7-200 SMART之间简单交换几十个字节毫无压力。但它的问题在于这个向导生成的是固定逻辑通信过程对程序员来说是个黑盒一旦出现异常定位问题相对麻烦而且在数据量较大或通信周期较短的场景下灵活性也不够。第三条就是本篇文章的主角——开放式TCP通信。S7-200 SMART从V2.5固件开始提供了一组开放式用户通信库指令包括TCP_CONNECT、TCP_LISTEN、TCP_SEND、TCP_RECV、TCP_DISCONNECT等。这组指令让PLC的以太网口变成一个真正意义上的TCP终端你可以主动连接对方、被动等待对方连接、按自己的协议格式收发数据。想传什么、传多长、什么时候传全部由程序说了算。1.2 选型对比什么时候用哪条路很多初学者一上来就问哪个方案最好其实没有最好只有最合适。我整理了一个对比表直接说清楚各自的适用场景。通信方式配置难度数据灵活性协议开放性适用场景Modbus TCP低中寄存器读写高工业标准协议与HMI/上位机/第三方设备通信GET/PUT向导低低向导固定格式低西门子私有西门子PLC之间简单快速互读数据开放式TCP通信较高高自定义帧格式高标准TCP/IP需要自定义协议、双向灵活收发、后期扩展上位机从这个表能看出来如果只是两台S7-200 SMART之间简单交换几个数据点GET/PUT向导最省事如果对面是第三方设备、仪表或者上位机软件Modbus TCP最稳而当你需要完全掌控通信过程、自己定义数据帧、甚至将来要和自己的上位机软件对接时开放式TCP通信才是正解。1.3 为什么我这次选了开放式TCP通信回到我那个项目选开放式TCP通信主要有三个原因。第一我需要传的数据不只是一两个点。除了状态位之外还有产量数据、故障代码、设备参数这些数据打包成一帧传过去比拆成几十个寄存器要清晰得多。第二两边的PLC都要主动发数据而不是一个只读一个只写。Modbus TCP虽然也能双向但主从结构下从站一般是被动响应做互传总觉得有点别扭。第三后续甲方还要在办公室加一台数据监控电脑用自定义TCP协议把这些数据全部收上去开放式TCP通信正好为这个扩展留好了口子。当然如果只是做极简单的信号互锁GET/PUT向导就够了没必要为了炫技把简单问题复杂化。选型这事永远是需求说了算。1.4 硬性门槛固件和软件版本这是我要强调的第一道门槛。开放式TCP通信不是S7-200 SMART所有固件版本都支持的。我最早手头有一台CPU固件版本还是V2.3在软件里翻遍了指令树都找不到TCP_CONNECT这些指令块后来查资料才确认这组指令需要固件V2.5及以上版本才提供。检查固件版本的方法很简单在Micro/WIN SMART软件里双击项目树中的PLC或者通过菜单PLC→信息查看CPU固件版本。如果版本不够就需要做固件升级。流程大概是先从西门子官网下载对应CPU型号的固件文件一般是.upd或者.bin格式。用网线把电脑和PLC连起来PLC切到STOP状态。在Micro/WIN SMART中执行PLC→固件升级选择固件文件按提示操作。升级过程不能断电否则PLC可能变砖所以现场升级前一定确认供电稳定。软件方面STEP 7-MicroWIN SMART也要V2.5以上软件版本不够同样看不到这些指令块。2. 开工前把网络基础打好IP、网线和连通性验证2.1 IP规划一个表格搞定PLC通信和电脑联网一样IP地址规划是第一道关。很多通信问题其实不是程序问题而是IP不在同一网段导致的。我这个项目用的是两组网的规划很简单设备IP地址子网掩码角色A站PLC192.168.1.10255.255.255.0服务器端被动监听B站PLC192.168.1.20255.255.255.0客户端主动连接调试电脑192.168.1.30255.255.255.0联调临时使用既然两台PLC直接通信不经过路由器网关可以直接留空或者填一个不存在的地址问题都不大。子网掩码统一用255.255.255.0保证两台PLC在同一个网段内。有一点要注意S7-200 SMART的以太网口默认IP一般是192.168.2.1如果你直接把两台PLC插上电用默认IP通信两台设备IP就冲突了。所以下载程序之前第一步一定是分别在Micro/WIN SMART里修改IP地址再下载到PLC。2.2 直连和交换机的取舍双PLC通信的物理连接有两种方式一条网线直连或者通过交换机连接。直连的好处是省一个交换机线缆最少。现在的S7-200 SMART以太网口基本都支持自适应交叉所以直通线和交叉线一般都能用不用太纠结线序。但直连也有明显缺点两台PLC之间没有多余的网络节点以后想接电脑调试就得把其中一根网线拔下来插电脑比较麻烦。过交换机的好处是网络拓扑灵活调试电脑随时可以接入以后加第三台PLC、加上位机都很方便缺点是现场多一个有源设备多一个故障点而且交换机质量不好的话可能会引入干扰问题。我的建议很直接如果只是两台PLC长期固定互传数据项目预算又紧直连就行但凡有一点扩展需求上交换机最好是工业级的。我自己那次用的是直连因为现场柜子挨得近一根网线搞定但调试的时候确实感觉不太方便每次都要换来换去。2.3 先PING通再写程序这句话我想写在最前面不PING通别急着写程序。网络链路不通程序写得再完美也白搭。最简单的验证方式是把调试电脑接到网络上在电脑的命令提示符里分别PING两台PLC的IP地址例如ping 192.168.1.10 ping 192.168.1.20如果都能PING通说明电脑到两台PLC的链路都没问题但要注意这还不能证明两台PLC之间一定通因为电脑是单独接上去的。要验证两台PLC之间的物理链路最稳妥的办法是先让电脑分别和A、B两台PLC通信确认两台PLC都独立在线然后把电脑撤掉让两台PLC用网线连起来或者都接到交换机上再通过程序验证连接状态。如果PING不通排查顺序建议是这样的检查电脑网卡的IP地址是否修改到了192.168.1.X网段子网掩码是否是255.255.255.0。这是最常见的低级错误。检查网线是否插好交换机/网口指示灯是否正常亮起。确认PLC的IP是否真的设置了成功。用Micro/WIN SMART的通信扫描功能看能否搜到PLC双击搜索到的设备软件会显示它的当前IP。如果是过交换机确认交换机端口是否被划了VLAN或者网口是否封闭了管理功能。这一步花五分钟能省下后面五小时的排查时间。3. 服务器端程序A站怎么监听、收数据和回数据3.1 服务器端的角色划分先明确一下什么叫服务器端。在TCP通信里主动发起连接的一方叫客户端被动等待连接的一方叫服务器端。在我的设置里A站PLC是服务器端它要做三件事一是开放一个监听端口等待B站来连接二是接收B站发来的数据三是把需要回传的数据发送给B站。这里有一件事新手容易搞混服务器端不等于只收不发。TCP是全双工通信服务器端既可以收数据也可以主动发数据。双向互传的互字就是靠两边都既收又发实现的。3.2 TCP_LISTEN把端口开起来服务器端第一件事是把端口开放出来等待连接。这个动作由TCP_LISTEN指令完成。TCP_LISTEN的引脚在不同版本的库文件里可能会有细微差别但核心参数是固定的REQ触发沿需要给一个上升沿来启动监听。Connect_ID连接编号相当于这个连接的本地标识我用的是1。Loc_Port_Num本地端口号也就是PLC对外开放的端口。这个端口号要和客户端的远程端口号对应上我用了2000。Max_Conn最大允许连接数量双PLC互传填1就够。连接ID这个概念一开始我有点绕弯后来想明白了它就是一个你给这个连接起的代号PLC通过这个代号区分不同的连接。只有一条连接的时候统一填1就不会错。TCP_LISTEN的REQ不需要一直给我给一个上升沿就够比如在首次扫描时触发一次后面除非连接断开否则不重复触发。触发之后指令进入忙状态DONE到位后表示监听建立成功。补充一个细节如果连接已经建立你再重复触发TCP_LISTEN是会有问题的。所以我的做法是用一个位记录当前是否有连接有连接的时候不去碰TCP_LISTEN连接断开后才重新触发。3.3 TCP_RECV和TCP_SEND收数据和发数据监听建立之后服务器端就进入了收发数据的环节。TCP_RECV的引脚同样不算复杂REQ接收请求触发沿。Connect_ID连接编号和TCP_LISTEN保持一致。Data_Len接收数据长度单位是字节。这个长度要在调用前写清楚我一般固定为接收缓冲区的大小比如32字节。Data_Ptr接收缓冲区的起始地址指针用VB100这样的格式填意思是把收到的数据放到从VB100开始的一段V区里。DONE完成标志收到一帧数据且处理完成后DONE会亮一个扫描周期。BUSY忙标志指令正在执行时BUSY为1。ERROR错误标志。Status状态字具体错误码可以查指令帮助里的错误代码表。这里有个关键细节要专门说TCP_RECV的REQ不能简单粗暴地用SM0.0常通去触发。我第一次写程序时就是把REQ接在SM0.0上结果数据接收时有时无偶尔还会出现一帧数据被拆成两段的情况。原因在于库指令执行期间BUSY会置位如果BUSY期间不断给REQ指令的触发节奏就乱了。我后来换了种写法用M1.0作为接收允许位连接建立成功后置位M1.0用M1.0的上升沿去触发TCP_RECV等DONE或者ERROR到位之后再把M1.0复位。这样就形成了收完一帧 → 允许下一次接收的节奏非常规律。TCP_SEND的用法和TCP_RECV对称REQ发送请求触发沿。Connect_ID连接编号。Data_Len要发送的字节数。Data_Ptr发送缓冲区的起始地址指针比如VB200。DONE/BUSY/ERROR/Status状态输出和TCP_RECV一样。发送的时机可以自己控制。我在服务器端用的是收到客户端数据后顺便回一帧状态数据的方式这样发送节奏跟着接收走不会出现两边同时狂发导致缓冲区堆叠的情况。3.4 服务器端的完整逻辑组织把上面这些搭起来服务器端程序的网络结构大概是这样网络1首次扫描时SM0.1置位监听启动请求位M0.0。网络2M0.0的上升沿触发TCP_LISTEN启动监听。当DONE为1且无错误时把M0.0复位同时置位监听已建立标志M0.1。如果ERROR为1保持M0.0为1等待下一个扫描周期重新触发。网络3当监听已建立且连接正常时置位接收允许位M1.0。网络4M1.0的上升沿触发TCP_RECV。当DONE为1时说明一帧数据已经存到了接收缓冲区此时可以处理数据、复位M1.0准备下次接收。网络5当收到新数据时需要回传数据先把要回传的数据搬到发送缓冲区VB200开始的一段区域然后置位发送请求位M2.0。网络6M2.0的上升沿触发TCP_SEND。DONE到位后复位M2.0。网络7用一个定时器做连接看门狗。每2000毫秒检查一次如果超过设定时间没有收到任何数据判定连接可能存在异常断开连接并重新触发监听。这一步不是必须的但对工业现场来说很有价值。实际编写时这些网络之间要加一些互锁和状态清零的逻辑但骨架就是上面这样。照着这个思路搭梯形图比东一句西一句拼指令要清晰得多。3.5 连接断开之后的自动恢复TCP连接在工业现场不是永远稳定的。对方重启、网线松动、电磁干扰都可能导致连接断开。如果程序没有自动恢复机制一旦断连就得人工去重启PLC或者重新下载程序这在生产现场是不可接受的。我的建议是服务器端程序要有一个连接状态监测逻辑。最简单的方式就是前面提到的看门狗定时器——每2000毫秒检查一次接收数据或连接状态如果超时没收到任何数据就把当前连接断开重新触发TCP_LISTEN。这样客户端那边如果还挂着旧连接感知到对端关闭后也会触发自己的重连逻辑。两边配合连接就能在几十秒内自动恢复。4. 客户端程序B站怎么建连、发数据和收数据4.1 TCP_CONNECT主动连接的几个关键引脚客户端和服务器端最大的区别就是客户端要主动发起连接。这个动作由TCP_CONNECT完成。TCP_CONNECT的引脚里有几个特别容易填错的地方专门拿出来说第一个是Active_Est。这个参数决定当前是主动连接还是被动连接。客户端这边要填TRUE表示主动去连对方。如果把服务器端和客户端的这个参数填反了两边都在等对方连自己连接永远建立不起来。第二个是Server_IP_Addr。这个参数填的是对端PLC的IP地址但注意它不是直接填192.168.1.10这种点分格式而是要填成32位十六进制常数。比如对方IP是192.168.1.10换算方法如下192 C0 168 A8 1 01 10 0A按顺序拼起来就是16#C0A8010A。这个换算对不熟悉十六进制的电工朋友来说是第一个坎我一开始也在这里卡了半天。第三个是Loc_Port_Num和Rem_Port_Num。Rem_Port_Num填对端服务器的端口号也就是对方TCP_LISTEN里设置的2000。Loc_Port_Num是本地端口号这里我的建议是填0表示由PLC自动分配一个可用端口。如果你手动指定一个固定端口断开重连时这个端口可能还处于TCP协议的TIME_WAIT状态导致新的连接绑定失败反而给自己找麻烦。TCP_CONNECT的REQ同样用上升沿触发。DONE为1且ERROR为0时表示连接建立成功。4.2 客户端收发逻辑发送和接收的节奏连接建立成功后客户端的收发逻辑和服务器端大同小异也是TCP_SEND加TCP_RECV的组合。区别在于触发节奏。服务器端我建议收完再回客户端这边则有两种常见玩法一种是周期发送用定时器每隔几百毫秒把一帧状态数据发给服务器端另一种是事件触发某个信号变化了才发一帧。现场调试时我一般先用周期发送这样连接是否正常、数据是否在流动一眼就能看出来。客户端的TCP_RECV和服务器端一样也推荐用接收允许位上升沿的方式触发。有一点要提醒客户端连接建立成功的那一瞬间服务器端可能已经在给你发数据了所以客户端一定要尽快打开接收允许位否则对方发过来的第一帧数据可能会丢。最稳妥的做法是在TCP_CONNECT的DONE置位且无错误后紧接着一个扫描周期就置位接收允许位M1.0。4.3 断开之后的重连策略别把自己堵死重连策略是整个客户端程序里最容易写崩的地方。问题出在TCP协议的一个特性上一个TCP连接断开后本地端口会进入TIME_WAIT状态在一段时间内不能被复用。如果程序在断开后立刻又重新发起连接不停循环很快你可能会发现连接请求发出去了但从来没成功过。我第一次现场调试就踩了这个坑。程序里逻辑很勤奋一检测到连接断开就马上重连结果两台PLC之间的连接不仅没恢复客户端PLC这边的资源反而被占满了最后只能重启PLC才恢复。正确的做法是加延时。断开后等5秒、10秒再发起重连。5秒这个值是我自己的经验太短了端口还在TIME_WAIT太长了现场设备状态恢复慢。用S7-200 SMART的TON定时器很容易实现就是断开标志→启动定时器→定时器时间到→触发TCP_CONNECT这样一个链路。另外如果客户端PLC是上电后自动连接而服务器端PLC上电晚了几秒客户端第一次连接必然失败。这种场景靠的就是重连机制所以客户端重连一定要做成自动循环的而且最好在HMI上能看到连接状态方便运维人员判断。5. 联调实测从模拟到真机的完整验证流程5.1 先用网络调试助手空跑一遍双PLC联调之前我强烈建议先用电脑装一个网络调试助手工具把其中一边先模拟掉。这样做的好处是能把问题隔离先确认PLC这一端的程序没问题再去做两边的联调不然两边都有疑问时排查工作量翻倍。具体操作很简单。以测试服务器端A站为例把电脑IP改成192.168.1.30网络调试助手开启TCP Server模式监听端口2000模拟B站。A站PLC上电程序进入监听状态。用网络调试助手去连接A站的192.168.1.10:2000。连接成功后往A站发一串测试数据看A站接收缓冲区是否有对应变化。A站往电脑发数据看网络调试助手能否收到。反过来测试客户端B站时网络调试助手开启TCP ServerB站的TCP_CONNECT里把IP指向电脑的192.168.1.30端口2000连接后B站发数据电脑收。这一步跑通了就说明PLC程序侧没有大问题可以放心进入真机联调。5.2 双PLC联调的标准流程两边程序都验证过之后把A、B两台PLC按实际网络接好开始联调。我习惯的验证顺序是保持调试电脑在线分别确认两台PLC都能在Micro/WIN SMART里在线监控。看客户端B站TCP_CONNECT的状态字确认连接是否建立成功。连接成功后状态字应该无错误DONE出现过。在B站程序里加一个手动置位按钮触发一次TCP_SEND然后到A站监控VB200接收缓冲区看数据是否按预期到达。反过来在A站手动触发TCP_SEND到B站看接收缓冲区。验证完单向再做自动周期收发连续跑30分钟以上观察数据是否稳定。这里有件事一定要做把两边PLC里的监控表都建好。接收缓冲区、状态字、收发计数全部加进状态表里一边在线监控一边操作任何异常都能第一时间看到。5.3 一个实用的数据帧设计既然用了开放式TCP通信数据帧格式就完全自己定了。我一般会定义一个简单的帧结构别用裸数据直接传否则以后排查问题会哭的。这里分享一个我常用的简单帧格式以8字节为例偏移字节长度内容说明01帧头0xA5用于识别帧起始11功能码区分数据类型22数据1例如状态字42数据2例如产量数据61校验字节前面字节的累加和71帧尾0x5A用于识别帧结束帧头帧尾的作用是防止数据错位。万一通信中出现一帧丢了一个字节接收方可以通过帧头帧尾快速重新同步。校验字节能发现数据被干扰的情况。虽然TCP协议本身有CRC校验但应用层的校验仍然有意义——它可以防住数据经过了正确TCP传输但你的发送端填数据时就把字节填错了这类逻辑错误。这个帧格式很朴素但足够应对大多数双PLC互传场景。后续要扩展比如加设备编号、加时间戳都是在这8字节的基础上往里加。6. 避坑实录这些坑每一个我都踩过6.1 指令块都找不到大概率是版本问题这个前面已经说过但值得再强调一次。如果你在Micro/WIN SMART的指令树里翻遍了都找不到TCP_CONNECT、TCP_LISTEN这些块先别怀疑人生90%的情况是固件版本不够需要V2.5及以上或者软件版本太老。我遇过一位同行PLC买了没几年但固件一直没升级过折腾了一整天最后一步升级固件指令块全出来了。另外这些库指令在指令树中的位置一般在库分组下面不在基本指令区。如果库分组是空的可能需要从西门子官网下载对应的通信库文件再导入到Micro/WIN SMART中路径一般是文件→添加/移除库。软件版本和库文件版本对不上导入也会失败。6.2 库存储区不分配程序会神秘出问题这是S7-200 SMART系列最容易踩的一个经典坑而且坑得很隐蔽。S7-200 SMART的库指令不只是TCP通信的库包括Modbus TCP、PID都算在执行时需要占用一段V区作为内部数据存储区。这段V区不会自动分配需要你手动指定。操作路径是在项目树里右键程序块选择库存储区弹出一个地址范围设置框给它指定一段V区起始地址。如果你不分配软件会在下载时提示你如果你分配了但分配的区域和程序里自己用的V区冲突了程序运行起来就会出现神秘问题——某个数据突然变了某个输出突然动了看起来完全没规律。实际上就是库指令把你自己定义的V区数据覆盖了。我的经验是先把PLC的V区整体规划好把用户数据区固定在一个范围比如VB0到VB399然后库存储区从VB400开始往后分配尽量给足比如分配100个字节。这样两边井水不犯河水。6.3 连接建好了但数据只通一半联调时最抓狂的问题是连接状态显示正常发送也触发了但对方就是收不到数据。或者更诡异的是A发给B正常B发给A不通。遇到这种情况我的排查思路是这样的先看对方TCP_RECV的DONE有没有亮过。如果DONE从来没亮过说明数据根本没进PLC。检查接收允许位的逻辑是不是一直处于复位状态。再看数据长度。TCP_SEND里的Data_Len如果有一次填错了比如发送的是10字节但缓冲区只定义了6字节多余字节可能会把缓冲区后面的V区数据覆盖掉引发连锁故障。看连接ID。两端连接ID不一致收发会走错通道。我的习惯是两端统一用1省心。看指针。Data_Ptr填的是VB100这种指针形式不是VB100本身。有些刚上手的同行在这里填错导致数据写到了未知地址。这一套查下来大多数半通问题都能定位到。6.4 高频重连把自己堵死了前面在讲客户端重连策略时已经提到过一次这里再展开说说背后的原理。TCP协议为了保证数据可靠传输连接断开后属于这个连接的端口会在一段时间内保持TIME_WAIT状态操作系统包括PLC里的协议栈不会立刻把这个端口分配给新连接使用。如果程序在断连后立刻重连第一次重连可能失败然后程序再重试又失败每次失败都会产生一个处于TIME_WAIT状态的碎连接积累起来本地可用的端口资源就越来越少最终表现为连接永远建立不起来。解决思路就是两个一是重连加延时5秒起步二是本地端口填0让TCP协议栈自己分配可用端口而不是程序里固定写死一个端口。这两个措施加在一起基本能杜绝自堵问题。6.5 现场电磁干扰导致的偶发断连最后说一个现场才会遇到的坑。在实验室里怎么跑都稳定一到现场就偶发断连尤其是变频器启动、大电机动作的瞬间。这是典型的电磁干扰问题TCP通信虽然用的是网线但网线上的干扰依然存在。对策分硬件和软件两层。硬件上柜内布线时以太网线和动力线不要平行走保持足够的间距能用屏蔽网线就用屏蔽网线而且屏蔽层要可靠接地如果条件允许换成一个工业级交换机做中转比两台PLC直连的抗干扰能力要强一些。软件上就是我前面反复强调的连接断开的自动恢复机制必不可少。现场不可能保证网络永远稳定但程序要保证断了能自己接回来。我见过一些项目PLC程序里完全没有重连逻辑网络闪断一次操作工就只能打电话叫维修来重启设备这种体验是灾难级别的。6.6 我的几个调试习惯最后分享几个我自己的调试习惯算是个人的土办法但有的时候真的很管用。第一在HMI上加一页通信监视界面显示两端连接状态字、收发计数器、最后接收数据的刷新时间。现场报故障时看屏幕就能判断是网络断了还是数据没更新不用拿电脑到处插来插去。第二改程序之前先导出一份V区地址分配表把用户区、库存储区、TCP收发缓冲区各自划开标好起始地址和长度。这个习惯帮我避免了好几次数据覆盖事故。第三收发缓冲区里固定留两个字节给计数器。每次收到一帧数据就把计数器加一。联调时看计数器是否在涨比看状态字直观得多。第四程序里所有的触发位都做成交替换位的逻辑复位条件写得清清楚楚不要留模糊地带。PLC程序是实时循环执行的模糊的逻辑早晚会在某个特殊的时序下出问题。