FX5UJ PLC Socket通信实战:TCP客户端连接、收发与断线重连 📅 发布时间:2026/9/20 11:02:05 👁 浏览次数: 1. 为什么要在FX5UJ上折腾Socket通信三菱FX5UJ这台PLC用过的人都知道它自带以太网口支持MC协议、SLMP、Modbus TCP这些标准答案。但实际项目里经常遇到一种尴尬局面上位机不是三菱自家的组态软件而是一台跑着自定义程序的工控机、一个Linux网关甚至是一块树莓派。对方只认最原始的TCP Socket发过来的就是一串裸字节没有任何协议封装。这时候你翻遍FX5UJ的通信手册会发现它原生支持的协议里没有纯TCP客户端这个选项。这就是Socket通信在FX5UJ上要解决的问题——让PLC主动作为TCP客户端去连接一个指定的服务器IP和端口然后收发自定义格式的数据。注意这里的关键词是客户端意味着连接是由PLC主动发起的服务器那边先监听、后接受。这个方向不能搞反搞反了整个程序逻辑就全乱了。我见过不少同行在这件事上绕弯路。有人试图用MC协议去模拟Socket结果对方服务器根本不认有人干脆加一块第三方通信模块成本上去了还多一个故障点。其实FX5UJ本身通过内置的Socket通信功能配合SLMP以外的开放通信指令是完全可以实现TCP客户端行为的只是配置和编程的细节比较绕手册里分散在好几个章节第一次做很容易漏掉关键步骤。这篇内容适合三类人一是第一次在FX5UJ上做Socket通信、被各种参数搞晕的电气工程师二是需要让PLC和自定义上位机对接、正在选通信方案的开发者三是已经跑通了但连接不稳定、想搞清楚底层机制的老手。我会从连接建立、数据收发、异常处理到实测踩坑把整条链路拆开讲清楚尽量让你看完就能上手改自己的项目。2. FX5UJ做TCP客户端的连接建立机制2.1 开放通信里的连接到底指什么在FX5UJ的语境里Socket通信属于开放通信范畴和MC协议那种你问我答的固定格式完全不同。开放通信的核心是PLC把以太网口当成一个可以自由读写的通道数据内容由你自己定义。而TCP客户端模式就是PLC主动向某个IP的某个端口发起连接请求。这里要先理解一个概念连接Connection在PLC里是一个需要被打开和关闭的资源。它不是自动存在的你得用指令去建立它用完还得关掉。FX5UJ支持同时打开多个连接每个连接有独立的编号通常叫连接No.1、No.2……每个连接对应一组参数对方IP、对方端口、本方端口可选、通信协议TCP/UDP。对于TCP客户端来说最关键的一点是PLC不监听端口它只负责发起连接。所以你在配置里填的是对方的IP和端口而不是自己的。这一点和服务器模式正好相反很多人第一次配错就是在这里——把本机端口填成了对方端口或者反过来。2.2 连接参数配置的实操路径在GX Works3里配置路径大致是导航窗口 → 参数 → FX5UJCPU → 模块参数 → 以太网端口 → 基本设置 → 外部设备配置。在这里你可以添加连接选择通信协议为TCP打开方式选择Active主动这就是客户端模式。如果选Unpassive或Passive那就是服务器模式了。具体参数我列个表方便对照参数项客户端模式填法说明通信协议TCP不要选UDP除非对方明确要求打开方式Active主动发起连接即客户端对方IP地址服务器实际IP比如192.168.1.100对方端口号服务器监听端口比如5000本方端口号通常自动分配也可指定但一般不用管连接编号1~8任选后续指令要用这个编号配置完之后这些参数会占用PLC的软元件比如SD寄存器程序里可以通过读取这些寄存器来确认配置是否生效。我习惯在程序开头加一段把连接状态读出来放到HMI上调试的时候一眼就能看到连接有没有建立成功。2.3 用指令打开和关闭连接配置只是告诉PLC有这么个连接存在真正让它动起来还得靠指令。FX5UJ用的是SOPENSocket Open指令来打开连接SCLOSE来关闭。这两个指令的用法在手册里有但有几个细节手册写得比较隐晦。SOPEN指令需要指定连接编号、打开方式主动/被动、对方IP、对方端口、超时时间等。执行后PLC会尝试去连接对方。如果对方在线且端口开放连接就建立成功对应的打开完成标志位会置ON。如果对方不在线指令会等待超时然后报错。这里有个坑SOPEN是异步的。你执行指令后不能马上假设连接已经好了必须等完成标志位。我见过有人执行完SOPEN紧接着就发数据结果数据全丢了因为连接还没真正建立。正确的做法是执行SOPEN→ 等待打开完成标志ON → 再执行发送指令。关闭连接用SCLOSE指定连接编号即可。但要注意如果连接已经因为异常断开了再执行SCLOSE可能会报错所以关闭前最好先判断一下连接状态。3. 数据收发的指令细节与缓冲区管理3.1 发送数据SP_SEND指令的用法连接建立之后发送数据用SP_SEND指令。这个指令需要指定连接编号、发送数据起始软元件、发送字节数、完成标志等。数据可以是字符串也可以是二进制取决于你和对方约定的格式。发送的时候有个关键点发送字节数必须准确。比如你要发HELLO这5个字符字节数就填5。如果你填了10PLC会把后面5个字节的垃圾数据也发出去对方解析就会出错。我一般会在程序里用一个变量记录实际要发的长度而不是写死数字。另外SP_SEND也是异步的。执行后要等发送完成标志ON才能进行下一次发送。如果连续发多条必须等上一条完成。这一点在高速通信场景下要特别注意必要时得用队列来管理待发数据。3.2 接收数据SP_RECV与接收缓冲区接收比发送麻烦一些。FX5UJ的接收机制是数据到达后先进入一个内部的接收缓冲区然后你用SP_RECV指令把数据从缓冲区读到自己的软元件里。这里有几个参数要搞清楚接收缓冲区大小在参数里可以设置默认可能不够用大数据量要改大。接收超时如果对方迟迟不发数据SP_RECV会等待超时超时时间可以设。接收完成标志数据读完后置ON程序据此判断有新数据。我踩过的一个坑是接收缓冲区的数据不会自动清除。如果你读了一次没读完下次读的时候可能读到旧数据。所以每次SP_RECV之后最好确认一下实际接收到的字节数只处理有效部分。还有一个更隐蔽的坑TCP是流式协议没有消息边界。对方发了两条消息可能粘在一起到达一条消息也可能分两次到达。所以你的接收程序必须能处理半包和粘包。常见做法是在数据前面加长度字段或者用固定分隔符比如换行符来切分。这个逻辑得在PLC程序里实现不能指望底层帮你分好。3.3 收发时序的配合发送和接收如果同时进行要注意时序。比如你发了一个请求然后等对方回复。正确的流程是发送 → 等发送完成 → 等接收完成 → 处理数据。如果发送还没完成就去接收可能收到的是上一次的残留数据。我在实际项目里通常用一个状态机来管理空闲 → 发送中 → 等待回复 → 接收中 → 处理 → 回到空闲。每个状态有超时保护超时就报错并重连。这样逻辑清晰也不容易出错。4. 连接异常与断线重连的实战处理4.1 常见的连接失败原因TCP客户端连不上服务器原因就那么几类但排查起来得有顺序现象可能原因排查方法一直连不上超时对方IP错、端口错、对方没监听ping对方IP用telnet测端口连上就断对方主动关闭、协议不匹配看对方日志确认握手数据偶尔断网络抖动、对方重启加心跳做重连完全没反应网线、交换机、IP冲突检查物理链路和IP配置我遇到最多的是对方没监听。很多上位机程序在调试时忘了启动服务器PLC这边就一直超时。所以调试阶段我习惯先用电脑上的网络调试助手模拟服务器确认PLC能连上再去对接真实上位机。4.2 断线检测的几种手段TCP连接断开PLC这边不一定马上知道。如果对方正常关闭PLC会收到FIN连接状态会变。但如果对方是拔网线、断电这种硬断PLC可能得过很久才发现。所以需要主动检测心跳机制定期发一个心跳包对方回复则说明连接正常。多久发一次取决于实时性要求一般1~5秒。发送失败检测如果SP_SEND报错说明连接可能已经断了。接收超时如果长时间收不到对方数据也可以认为连接异常。我一般用心跳发送失败双重检测。心跳包内容很简单比如一个固定字节对方收到后回一个固定字节。如果连续几次心跳没回复就判定断线执行重连。4.3 重连逻辑的设计重连不是简单地再执行一次SOPEN。正确的顺序是先SCLOSE关闭旧连接如果还开着等关闭完成再SOPEN重新打开。如果直接SOPEN可能会因为连接资源没释放而失败。重连要有退避策略。不能一断就疯狂重连那样会给对方服务器造成压力。我的做法是第一次断线后等1秒重连失败等2秒再失败等4秒最多等到30秒。一旦连上退避时间重置。这样既能快速恢复又不会雪崩。还有一个细节重连期间要暂停数据发送。否则数据发不出去还会堆积。我通常用一个连接就绪标志位只有它为ON时才允许发送。5. 实测中那些手册不会告诉你的坑5.1 初始IP和网络配置的坑FX5UJ出厂默认IP通常是192.168.1.1或者通过拨码开关决定具体看型号批次。第一次上电如果你不知道IP可以用GX Works3的搜索功能找。但要注意搜索是基于广播的如果PLC和电脑不在同一网段搜不到。我建议的做法是先用USB或者串口连上PLC在参数里把IP设成你想要的然后再用以太网。不要指望出厂IP能直接用很多项目现场网段是192.168.0.x或者10.0.0.x和默认的不一样。另外子网掩码和网关也要配对。如果PLC和服务器在同一网段网关可以不填如果跨网段网关必须填对否则连不上。这个在调试时经常被忽略。5.2 端口号选择的注意事项对方服务器的端口号尽量选1024以上的避免和系统端口冲突。我见过有人用80端口做自定义通信结果和Web服务打架。另外有些防火墙会拦截特定端口调试时可以先关防火墙确认再按需开放。PLC这边的本方端口一般让系统自动分配就行。但如果对方服务器有只接受特定源端口的限制少见但存在那就得手动指定。指定的时候注意不要和其他连接冲突。5.3 数据字节序和对齐TCP传输的是字节流多字节数据比如16位整数、32位浮点数就有字节序问题。三菱PLC内部是小端序低位在前但很多上位机协议用大端序高位在前。如果直接发一个32位整数对方解析出来可能是错的。解决办法要么在PLC里手动做字节交换要么和对方约定好统一用哪种序。我一般倾向于在PLC侧做转换因为改PLC程序比改上位机方便。三菱有SWAP指令可以做字节交换用起来很简单。5.4 接收缓冲区的溢出如果对方发数据很快而PLC程序处理慢接收缓冲区可能会溢出导致数据丢失。这时候要增大缓冲区或者优化程序让接收处理更快。我遇到过一次对方每秒发几十条消息PLC用默认缓冲区根本扛不住后来把缓冲区调到几KB才稳定。还有一个技巧如果数据量大可以用SP_RECV一次读一大块然后在PLC里慢慢解析而不是频繁调用SP_RECV。这样能减少指令开销。6. 从调试到上线的完整流程建议6.1 分阶段调试法我习惯把调试分成三步单机验证用电脑上的网络调试助手做服务器PLC做客户端确认能连上、能收发。这一步排除PLC配置问题。联调验证对接真实上位机确认协议格式、字节序、心跳都匹配。这一步排除协议问题。压力验证模拟高频收发、断线重连、长时间运行确认稳定性。这一步排除性能问题。每一步都有明确的通过标准不通过不进入下一步。这样出问题的时候能快速定位是哪一层的毛病。6.2 上线前的检查清单上线前我一般会过一遍这个清单IP、端口、子网掩码、网关都确认无误连接参数和实际服务器一致心跳间隔和超时时间合理重连逻辑经过测试接收缓冲区大小足够字节序转换正确异常处理有日志或HMI提示断电重启后能自动恢复这个清单看着简单但每次都能查出点小问题。尤其是断电重启后的恢复很多人忘了测结果现场一停电PLC起来后连不上还得人工干预。6.3 长期运行的维护建议Socket通信跑起来之后不是就没事了。建议定期检查连接状态记录断线次数和时间。如果发现频繁断线要分析是网络问题还是对方服务器问题。另外PLC的程序如果修改了重新下载后连接会断需要重新建立这个要有心理准备。我个人在实际操作中的体会是Socket通信在FX5UJ上完全可行但它的开放意味着很多细节要自己把控。手册给的是指令用法真正的稳定性来自于你对TCP机制的理解和对异常情况的预判。把心跳、重连、缓冲区、字节序这几件事做扎实基本就能应对大部分工业现场的需求了。