简介：三菱Q系列PLC之间SOCKET通讯详解是一份面向工业自动化工程师与PLC开发者的技术文档，围绕Q03UDE型号PLC间的以太网通信展开，系统梳理从SOCKET概念到实际落地的完整流程。文档先说明SOCKET作为TCP/IP封装接口的作用，再给出所需硬件与GX-WORKS2软件配置方法，并以1#、2#两台PLC为例拆解实验步骤，同时重点解析SP.SOCOPEN、SP.SOCSND、SP.SOCRCV三个应用指令的用法，可作为现场联调的操作性参考。资源为单个docx格式文档，压缩包大小824KB，内容精炼、步骤清晰；正文还提及《QPLC内置以太网手册》作为深化查阅的补充资料。目前已有1644人学习下载，适合需要快速掌握三菱Q系列PLC间SOCKET通信配置、并希望减少前期摸索时间的自动化从业者。 直接开工。这标题一看就是工控老炮儿的需求——两台三菱Q系列PLC要对传数据，不走CC-Link，不走MODBUS，偏偏选了Socket。说实话这方案不算烂，真正干过项目的人都懂，有时候现场就是没有专用总线条件，或者跨设备跨网段，Socket是最通用的路子。这篇我把完整配置、指令、踩坑、断线重连都给你捋清楚，照着抄就能跑。
1. 方案选型：为什么是SOCKET，而不是CC-Link或MC协议
1.1 三菱Q系列常用通讯方式横向对比
Q系列PLC的通讯路子看着多，实际干项目的时候选择反而纠结。我先把常见的几种方式拉个对照表，大家心里有个底。
| 通讯方式 | 硬件要求 | 传输距离 | 适用场景 | 开发难度 |
|---|---|---|---|---|
| CC-Link | 主站模块+远程站模块 | 100m左右（取决于速率） | 同产线高实时控制、I/O共享 | 中低（GX Works2组态即可） |
| MODBUS TCP | 以太网模块或内置网口 | 跨交换机无限制 | 与第三方设备（仪表、变频器、上位机）通讯 | 低（协议简单） |
| MC协议（三菱专用） | 以太网模块 | 无限制 | 上位机、SCADA读写PLC数据 | 中（需了解指令格式） |
| Socket通讯 | 以太网模块（QJ71E71或内置网口） | 无限制 | PLC与PLC直连、PLC与自定义设备、跨平台传输 | 中高（需要自己规划链路和数据帧） |
这里要重点说一句，很多做项目的人一听Socket就头大，觉得要写协议要处理粘包拆包太麻烦。但实际上在PLC里做Socket并不像PC端编程那样要自己写三次握手、滑动窗口这些东西，三菱把底层的TCP/IP协议栈已经封装好了，PLC侧只需要调用OPEN、SEND、RECV、CLOSE这几个指令就能完成整个通讯过程。真正要自己设计的东西，说白了就是两句话：连上谁，发什么。这就是Socket通讯在PLC场景里的真实定位——它不负责业务逻辑，只负责把字节流可靠地从A点送到B点。
1.2 Socket通讯的底层原理与使用前提
我习惯用打电话来类比Socket通讯的过程。OPEN指令就是拨号建立连接，SEND指令就是说话，RECV指令就是听对方讲话，CLOSE就是挂断电话。TCP协议保证了你说的每一句话对方都能按顺序听到，如果没听到还会自动重传，这就是TCP和UDP最大的差异。对于PLC这种实时控制设备来说，数据绝对不能丢，所以Socket通讯几乎全部走TCP。
有一点必须提前确认：你要做Socket通讯，PLC必须配置以太网模块，或者使用内置以太网口的CPU型号，比如Q03UDECPU、Q03UDVCPU这一类的。如果是老旧机型没有网口，就得加装QJ71E71-100之类的以太网模块。硬件条件不满足，后面全部免谈。另外，通讯的稳定性还依赖于网络环境的确定性，工业环境里我不建议把PLC的Socket通讯放在办公网络里跑，因为广播风暴、ARP欺骗、流量拥塞都会导致通讯中断，而且断得毫无预兆，排查起来特别虐心。最好是用独立的管理型工业交换机把PLC网络隔离出来，这是我在多个现场总结出来的硬经验。
2. GX Works2中的工程配置与参数规划
2.1 IP地址与端口号的规划方案
我在实际项目中调试两台Q系列PLC的Socket通讯时，第一步不是着急写程序，而是先做一张网络参数规划表。很多新手上来就写梯形图，结果模块参数没设置，OPEN指令一直报错，回头查半天才发现IP冲突或端口号不一致，纯浪费时间。建议把下面这个表格先填好再动手。
| 设备角色 | 设备名称 | IP地址 | 子网掩码 | 本地端口号 | 远端端口号 |
|---|---|---|---|---|---|
| 主站（客户端） | Q03UDECPU（内置网口） | 192.168.1.10 | 255.255.255.0 | 4000 | 5000 |
| 从站（服务端） | Q03UDECPU（内置网口） | 192.168.1.20 | 255.255.255.0 | 5000 | 4000 |
端口号的分配要特别注意，PLC侧不存在端口占用的问题，但要注意和上位机软件的端口号避开，另外建议把端口号固定下来写成设备参数表交给电气和上位机开发各留一份，不然项目后期扯皮特别常见。IP地址则尽量不要用192.168.0.x和192.168.1.x这两个默认网段，因为很多工厂里路由器、办公设备、相机、打印机都默认使用这两个网段，非常容易冲突。我个人的习惯是用172.20.x.x或者10.10.x.x这类不常用的私网段，从根上减少冲突概率。
2.2 GX Works2中以太网模块参数设置实操
参数规划好了，下面就是动手配置。这里以三菱常用的GX Works2软件为例，整个设置过程其实也就是几分钟的事情，但是我见过不少人卡在开机时选择CPU型号这一步，或者模块配置时找不到网口。这里有一个关键点：如果你用的是内置网口的CPU型号，不需要在工程里添加额外模块，直接在导航窗口双击“PLC参数”，在弹出的对话框中选择“内置以太网端口设置”选项卡就可以进行配置。
配置的核心操作分三步。第一步，设置IP地址、子网掩码等基本参数。第二步，在“通信协议设置”里选择“TCP”，因为Socket通讯在绝大多数工业场景下用的都是TCP，保证数据不丢失。第三步，设置端口号。这里有一个非常容易搞错的点：主站和从站的端口号不是随便填的，OPEN指令中要指定“自端口号”和“对方端口号”，两者必须和对方的实际监听配置一一对应。说白了就是你要发的数据包，目标端口必须和对方监听的端口完全一致，否则TCP连接建立不了。
还有一处隐秘的设置容易被忽略——在“内置以太网端口设置”里，有一个“打开方式”的选项，需要设置为“MC协议”或“Socket”等不同的通信协议方式。做Socket通讯时，必须选择“Socket”对应的打开方式，否则你后面写SEND指令、RECV指令都不会按Socket的规则工作。不同的Q系列固件版本，这个界面的具体措辞有细微差异，但逻辑是相通的。配置完成后要把程序写入PLC并复位重启，参数才会真正生效。我见过有人设置完直接编译下载，不重启PLC就测试通讯，结果发现参数还是旧的，折腾半天才反应过来。
3. Socket通讯指令详解与梯形图完整实现
3.1 Socket指令族：OPEN、SEND、RECV、CLOSE
三菱Q系列Socket通讯的核心指令就是四个：OPEN，建立TCP连接；SEND，发送数据；RECV，接收数据；CLOSE，断开连接。这些指令在GX Works2的指令列表里都能找到，用法需要配合特定的控制数据寄存器。下面我直接给出常用的指令格式和各个区的含义。
OPEN指令负责建立连接。执行时，需要指定一个数据寄存器（比如D0）作为控制数据的起始地址，控制数据的内部设置包含了连接编号、自端口号、对方IP地址、对方端口号等。SEND和RECV指令同样需要指定控制数据寄存器，数据结构里包含了连接编号、发送/接收数据长度以及数据存储区间。CLOSE指令用于关闭指定连接的通道。
我先给一个参照用的控制数据布局表，这是我在项目中常用的一种布局方式，你可以根据实际需要调整，但总体结构是一致的。
| 控制数据通道 | 内容示例 | 说明 |
|---|---|---|
| 连接编号（设为固定值1） | 1 | 对应以太网模块中定义的连接号 |
| 自端口号 | 4000 | 仅OPEN时有效 |
| 对方IP地址 | 192.168.1.20 | 仅OPEN时有效 |
| 对方端口号 | 5000 | 仅OPEN时有效 |
| 发送/接收数据长度 | 字节数 | SEND/RECV时使用 |
| 数据存储起始地址 | D100 | 存放实际发送/接收的数据 |
3.2 主站（客户端）完整梯形图实现
场景定为一个很常见的需求：主站Q03UDECPU把D100到D107这8个字的数据发送给从站，从站把设备状态字回传并存储到主站的D200开始的位置。主站的程序我拆成四段来说明。
第一段，初始化与OPEN请求。用首次扫描脉冲M8002去触发OPEN指令。OPEN指令的写法如下（用结构化文本描述便于理解，梯形图实际操作时拖动指令块填入参数即可）：
OPEN "D0" "M100" "D0"其中D0到D5存放OPEN的控制数据，M100是开始执行标志。注意OPEN指令和SEND、RECV指令的执行标志位一定不能复用同一个M点，否则会出现上一次操作还没结束下一次就被触发的乱序问题，这是我调试时踩过的坑。OPEN成功后，M100会复位，同时一个完成标志位（比如M110）会置位，表示链路已建立，可以开始发送数据了。
第二段，SEND发送指令。当M110为ON时，把D100到D107共8个字的数据发送出去。SEND指令格式中需要指定控制数据寄存器和发送数据的存储区地址：
SEND "D10" "M200" "D100" "8"这里的D10到D15是SEND的控制数据，M200是执行标志，D100是数据源起始地址，8是发送的数据长度（单位为字）。SEND完成之后，你可以用一个计数器累计发送次数，这个习惯在排查数据是否丢帧的时候特别有用。
第三段，RECV接收指令。从站回传的数据会主动通过TCP发过来，主站需要用RECV去接收。RECV的控制数据结构里同样要指定连接编号和接收数据长度。重点说一下这个“接收数据长度”——它必须设置成你预期收到数据的最大长度，如果对方发过来的数据超过了这个长度，RECV指令只会接收你设置的长度，多余的部分会被丢掉，而且不会报错。所以这里长度一定要设置得足够大或者和对方发送长度严格匹配。RECV指令写法如下：
RECV "D20" "M300" "D200" "8"D20到D25是RECV控制数据，M300是执行标志，D200是存放接收数据的起始地址，8是接收长度。接收完成标志位置位后，可以对数据做个简单的校验，比如检查数据帧头和设备状态字，这个在后面的故障排查部分会细讲。
第四段，CLOSE连接关闭。当通讯任务结束或发生异常需要重置链路时，执行CLOSE指令断开连接。CLOSE指令相对简单，只需要指定连接编号。我一般会在一个故障复位按钮上串联CLOSE，这样手动断开连接后，重新触发OPEN就能重连。
3.3 从站（服务端）的程序逻辑与差异
从站的程序逻辑和主站有一个本质区别：从站只做监听和响应，不主动发起连接。因此在从站侧，OPEN指令的打开方式与主站不同，它不需要指定对方的IP地址和端口号，而是固定监听本地端口，等待主站来连接。从站侧同样要有SEND和RECV指令，只是逻辑顺序上通常是先RECV等主站发数据，处理完成后再SEND回传。
从站程序我是这样写得：初始化时直接执行OPEN指令，模式设为服务器监听状态。当检测到有客户端连接成功时，从站程序的接收完成标志位置位，代表RECV成功读取到主站发来的数据。随后把读取到的数据搬到发送缓冲区去，然后触发SEND指令把处理结果回传。
这里有个很多初学者容易困惑的点：TCP连接建立之后，数据通道是双向的。也就是说不存在“Client只能发，Server只能收”的说法，两边都可以主动SEND和RECV，只是连接的建立是由Client发起的而已。理解了这一点，从站程序就只是把收发指令的执行顺序调过来，本质上和主站的程序没有太大差异。整个链路中相当于一个电话通话建立后，两边谁都可以先说先听。
4. 通讯调试中的常见问题与排查技巧
4.1 OPEN指令不成功，连接状态监控判断
做完程序、写好参数，下载到PLC后，最常见的问题就是OPEN一直不成功。这时候如果只盯着梯形图看，是看不出什么花来的。三菱PLC里有关键的通讯监控手段——系统监控缓冲区。用GX Works2的“监视”功能，查看系统监视器里的以太网信息，能看到每个连接号对应的状态是“正在连接”、“等待打开”还是“连接完成”。
OPEN不成功的原因大概就三类。第一类是参数设置不对，比如对方IP地址错了、端口号没对应上。第二类是网络不通，用一台PC去ping一下对端PLC的IP地址，能通就说明物理链路没问题，不能通就要检查网线、交换机、防火墙。第三类是对方PLC还没有开始监听，也就是从站的OPEN程序还没执行到，同时从站回包时主站还没准备好，导致握手失败。用PC上的网络抓包工具看一眼TCP握手包，如果只看到SYN没有SYN-ACK，就能断定是对方没有监听。
4.2 数据收发异常：乱码、粘包、长度不匹配
连接通了，数据也发过去了，但是接收方拿到的是乱码，或者数据都挤在了同一个缓冲区里。这个问题的根源在数据帧设计。TCP是流式协议，它能保证字节顺序和完整性，但不保证每条SEND的数据能作为独立的包被对方一次RECV出来。所以实际项目中，我强烈建议在数据帧里加上帧头、功能码、长度、数据和校验码这几个部分。帧头用固定的两个字节，比如0xA5 0x5A，接收方一看到这个帧头就开始解析，帧头后面的两个字节存放数据长度；接收方拿到指定长度的数据后，再做CRC校验。如果校验不过，就主动扔掉这一帧，申请重发，这就保证了数据传输的可靠性。
这里贴一个简单实用的数据帧结构表，是我经常用的，大家可以直接拿去做参考。
| 字节偏移 | 内容 | 长度 | 说明 |
|---|---|---|---|
| 0-1 | 帧头 | 2字节 | 固定为0xA5 0x5A |
| 2-3 | 数据长度 | 2字节 | 数据区的实际长度 |
| 4-5 | 功能码 | 2字节 | 01读，02写，03状态等 |
| 6-15 | 数据区 | N字节 | 具体业务数据 |
| 末尾2字节 | CRC16 | 2字节 | 前面所有字节的CRC校验 |
4.3 通讯中断与自动重连机制
Socket通讯最让人头疼的不是第一次连接不上，而是跑着跑着自己断了。常见的断线原因包括交换机重启、网线松动、对方PLC复位、上位机软件占用了端口等。TCP连接一旦断开，PLC侧不会自动恢复，必须重新执行OPEN指令才能重新建立链路。这就要求程序里必须写自动重连逻辑。
我的做法是，在程序中加一个链路监视定时器。用PLC的定时器指令，每隔500毫秒检查一次TCP连接状态。检查的方式是去读取系统缓冲区里对应连接号的连接状态字，如果状态字显示断开，就延时5秒后自动重新触发OPEN指令。这个5秒延时的作用是避免频繁重连加重网络负担，尤其是在多台PLC批量重启的现场，如果没有延时，所有PLC同时疯狂重连，瞬间把交换机打满，后果就是雪崩式掉线。另外建议在重连逻辑里加一个重试次数上限，比如连续重连10次都失败，就置一个报警位，把故障状态通知到上位机或触摸屏，让维护人员介入处理，而不是让PLC在那里无限循环地重连。
4.4 调试辅助工具与监控技巧汇总
最后分享几个我多年调试Socket通讯时积累的效率工具和手段。GX Works2自带的系统监视器是最基础的一个，能看每个连接的打开状态、发送接收字节数等实时数据。如果这个层面还不够，那我就会用Wireshark抓包分析TCP交互过程。抓包的时候过滤规则设置为tcp.port == 5000，这样只看到和对应端口相关的流量，不会被别的网络数据干扰。
除此之外，还有一个PC端的调试利器——网络调试助手工具。它可以直接以TCP客户端或TCP服务器的身份接入PLC的Socket通讯中，这样在没有第二台PLC的情况下也能完整测试收发逻辑。我平时在项目现场调试时，PC就扮演第二台PLC，先用网络调试助手确认底层通讯正常，再把网络调试助手关掉，换上真实的PLC程序跑联调，这样可以大幅缩短排错时间，每一个人参与过现场调试的工程师都应该备一个这个工具。另外，在实际运行期间，我还习惯把发送次数、接收次数、重连次数、错误码都累计到PLC的断电保持寄存器里，这样不管现场出了什么问题，我都能通过GX Works2看到历史累计值，判断是数据瞬断、偶发干扰还是长期累积才导致的问题，排查效率高很多。
在做完上面这一整套配置和程序后，我实测下来两台Q03UDECPU之间的Socket通讯非常稳定。尤其是使用了固定网段和独立交换机后，连续运行一周都没有出现断开或丢帧的情况。和CC-Link相比，Socket确实需要自己多写一点控制逻辑，但胜在不受距离限制、不依赖专用总线，扩展性强，而且跨设备、跨品牌通讯也是它的强项。根据自己的应用场景选好方案，Socket通讯在Q系列PLC上的使用体验还是很让放心的。
本文还有配套的精品资源，点击获取
