汇川EASY系列PLC做Socket主站：从零到稳定运行的完整指南-平芜编程栈

1. 项目概述：为什么我选择让EASY系列PLC当socket主站

先交代一下背景。我手头有一台汇川EASY系列PLC，具体型号是EASY320，平时主要是做现场设备的逻辑控制。这次项目有一个特殊需求：现场有一批第三方设备，它们只开放了基于TCP/IP的socket接口，既不是Modbus TCP，也不是Profinet这类工业总线协议，而是最原始的——上位机或者控制器直接往指定IP和端口发报文，设备按报文格式返回数据。

这种情况下，很多人的第一反应是加一个协议转换网关，或者用上位机做中转。但现场条件不允许加额外硬件，而且上位机中转有个致命问题：一旦上位机死机或者网络抖动，整个链路就断了，设备直接失控。所以我把目光放在了PLC本身——汇川EASY系列是否具备socket通信能力？能不能直接作为TCP客户端（也就是主站）去主动连接远端设备？

答案是肯定的。EASY系列虽然定位是小型PLC，但它的以太网口支持原生socket编程，可以在程序里创建TCP连接，主动向服务器发起请求，收发自定义报文。这个能力比想象中重要得多：它意味着PLC可以绕过协议转换器，直接对接各种只提供socket接口的设备——比如视觉相机、扫码枪、称重仪表、第三方控制器，甚至是一些老旧的工业设备。

这篇文章就把我从零开始，到最终让EASY320作为socket主站跑通全流程的经验完整记录下来。内容包括：开发环境搭建、socket功能块怎么调、报文怎么组、数据怎么解析、踩了哪些坑，以及最后实际运行的稳定性表现。如果你也在用汇川EASY系列想走以太网socket通信，这篇文章可以直接当参考手册用。

2. 环境准备与硬件接线：动手之前必须确认的事

2.1 硬件清单和固件版本

先说硬件。汇川EASY系列目前主流的几款型号，包括EASY320、EASY521等，都自带以太网口。我用的EASY320，网口是标准RJ45，支持10/100M自适应，物理上就是一个普通网口，接线和连电脑网口一模一样。

有一点需要特别提醒：EASY320的以太网口是支持socket通信的，但必须确认PLC固件版本不能太低。我第一次拿到设备时固件版本是V1.0，程序里怎么也找不到socket相关的功能块，后来查资料发现，socket库是在较新的固件版本里才集成的。升级固件到V1.2之后，功能块才出现。所以拿到设备第一件事，先看一下固件版本，最好升级到最新正式版。

2.2 网络拓扑设计

这个项目的拓扑非常简单：

PLC（EASY320）：IP地址设为192.168.1.10
远端设备：IP地址为192.168.1.50，端口号5020（这里是自己定义的例程端口）
交换机：普通工业交换机，也可以用网线直连

如果是现场有多台设备要同时通信，建议把PLC、设备、上位机都放在同一个网段，避免跨网段路由带来的延迟和配置麻烦。我的习惯是：PLC使用固定IP，不要用DHCP，这样重启后地址不变，程序里连接目标IP也不用改。

2.3 开发软件与功能块库

EASY系列使用汇川的InoProShop软件进行编程，软件基于CODESYS平台，如果你用过Codesys，上手基本无缝。打开软件后，新建工程时需要选择对应的PLC型号，然后会加载对应的设备描述文件。

这里重点说socket相关的库。在InoProShop的库管理器里，需要手动添加一个名为"Ethernet Communication"或者类似名称的库（具体名称因版本而异，通常在库列表里可以搜到Socket相关关键字）。添加之后，程序里就能调用TCP连接、发送、接收等功能块了。

库的版本和PLC固件版本要匹配，否则编译会报错或者运行时行为异常。我调试时因为库版本太新、固件版本太老，曾经出现了连接功能块一直返回超时的问题，后来重新下载匹配版本的库才解决。

3. Socket主站功能块详解：每一个接口都必须搞清楚

3.1 核心功能块一览

EASY系列socket库提供了几个核心功能块，我实际用到的有这几个：

功能块名称	功能	关键参数
`Socket_Open`	建立TCP连接	ServerIp（目标IP）、ServerPort（目标端口）、ConnectTime（超时时间）
`Socket_Send`	发送数据	Buff（数据缓冲区）、Len（发送长度）
`Socket_Recv`	接收数据	Buff（接收缓冲区）、Len（接收长度）
`Socket_Close`	关闭连接	无

这几个功能块的调用方式，和普通的功能块类似：每个功能块都有EN（使能）和ENO（输出使能），外加各种输入输出参数。使用前先在程序里实例化，然后按顺序调用。

3.2 建立连接的完整流程

TCP通信的特点是面向连接，所以第一步永远是建立连接。在实际程序中，我用了一个布尔变量b_ConnectReq作为连接请求信号，上升沿触发Socket_Open功能块：

IF b_ConnectReq THEN Socket_Open_Instance( EN := TRUE, ServerIp := '192.168.1.50', ServerPort := 5020, Timeout := 3000 ); END_IF

注意几个细节：ServerIp是字符串类型，必须写完整的IP地址，注意引号；Timeout的单位是毫秒，我习惯设置为3000，也就是3秒。如果3秒内连不上，功能块会把Done或者Error标志位置位，方便程序里判断。

连接是否成功，不能只看功能块有没有被调用，还要看输出参数。Socket_Open输出里通常有Done、Busy、Error这几个标志。Done为TRUE表示连接成功，Error为TRUE表示失败，同时会有一个错误码输出，根据错误码可以定位问题。我把这些状态都存到DB变量里，方便上位机监控。

3.3 数据发送与接收

连接建立之后，就可以收发数据了。发送功能块Socket_Send的核心输入是一个缓冲区，缓冲区本质上是字节数组。在CODESYS体系里，我通常用ARRAY [0..255] OF BYTE来定义缓冲区。

发送逻辑是这样的：

// 先将需要发送的报文按字节填入缓冲区 Send_Buffer[0] := 16#01; // 设备地址 Send_Buffer[1] := 16#03; // 功能码 Send_Buffer[2] := 16#00; // 起始地址高字节 Send_Buffer[3] := 16#00; // 起始地址低字节 // ... 按设备协议填充 // 调用发送功能块 Socket_Send_Instance( EN := TRUE, Buff := ADR(Send_Buffer), Len := 8, Done => Send_Done, Error => Send_Error );

最关键的一点是Len参数，它告诉功能块要发送多少个字节。这个值必须和Buff里实际填充的数据长度一致，多填或者少填都会导致报文解析错误。

接收数据相对简单一些，Socket_Recv同样传入一个缓冲区，功能块接收数据后就往里写。需要特别注意的是，TCP是流式协议，一次Recv收到的数据长度不固定，不能假设一次就能收完整一帧报文。我通常的做法是在接收完成标志位触发后，检查实际接收到的字节数，再根据协议去解析。

3.4 多设备通信时的实例化管理

有些项目里，PLC需要同时和多个socket设备通信。这时候有两种方案：一种是轮询式的，一个时刻只处理一个设备的收发；另一种是并行式的，为每个设备单独实例化一组socket功能块。

我在实际项目中发现，小型PLC的算力有限，并行处理多个socket连接容易造成CPU负荷偏高。我的建议是，如果设备数量不超过3台，可以直接并行实例化；如果超过3台，最好用轮询的方式，在一个状态机里分时处理每个设备的收发，这样可以大幅降低PLC扫描周期的压力。

4. TCP连接状态机设计：从连接到稳定通信的关键

4.1 为什么需要一个状态机

TCP通信不是"调用一次功能块就完事了"那么简单。真实场景里，设备随时可能重启、网线可能断开、PLC可能需要重连。如果只是线性地调用连接->发送->接收，一旦链路中断，程序就卡死了。

我采用的方法是设计一个简单的连接状态机。状态机的核心思路是：把通信过程拆分成几个有限状态，每个状态对应一个明确的动作，状态之间通过条件切换。这样程序的逻辑会非常清晰，也方便排查问题。

4.2 状态机状态定义与切换条件

状态	含义	进入条件	退出条件
IDLE	空闲	初始状态或连接断开后	收到连接请求，进入CONNECTING
CONNECTING	连接中	发送连接请求	连接成功（进入RUNNING）或超时/失败（回到IDLE）
RUNNING	通信中	连接成功	发送/接收出错或链路断开（回到IDLE）

具体实现时，我用一个整数变量state来表示当前状态，用CASE语句来实现状态切换。下面是一个简化的状态机框架：

CASE state OF 0: // IDLE IF b_ConnectReq THEN state := 10; // 进入连接状态 END_IF 10: // CONNECTING // 调用Socket_Open // 如果Done，则state := 20 // 如果Error，则state := 0，并记录错误码 20: // RUNNING // 调用Socket_Send和Socket_Recv // 如果Error，则state := 0，并触发重连 END_CASE

RUNNING状态内部，我还会再细分为"发送等待"和"接收等待"两个子状态，避免发送和接收同时进行导致缓冲区冲突。

4.3 断线重连与异常处理

这部分是现场运行最关键的。TCP连接断开后，如果程序不处理，PLC会一直傻等，导致整个逻辑停滞。我的处理策略是：

在RUNNING状态中，如果检测到发送超时、接收超时或者功能块Error标志，立即关闭连接，将状态切回IDLE。
IDLE状态下，延迟3秒后自动重新发起连接。延迟的目的，是给远端设备留出恢复时间，也避免频繁重连导致网络风暴。
重连次数不做限制，一直重试。但为了防止无限循环刷屏，每次重连间隔至少3秒。

这个策略在我现场运行了三个月，非常稳定。设备重启、网线被误拔，PLC都能在几秒内自动恢复通信，整个过程不需要人工干预。

4.4 状态机与主程序的配合

状态机放在PLC主程序的某个周期任务里执行，任务周期我设置的是10ms。这种周期设置可以保证socket收发的实时性，同时不会因为任务过于频繁而影响其他逻辑。

在实际工程中，状态机的运行状态、当前错误码、收发数据计数，我都映射到了Modbus寄存器中，这样上位机或者HMI可以实时查看通信链路的健康状况。排查问题的时候，直接看状态变量，比翻程序快得多。

5. 报文构造与数据解析：跨过协议这道坎

5.1 报文格式的确定

socket通信最大的坑，就是报文格式完全由设备厂商自定义。拿到第三方设备的协议文档时，首先看清楚几个信息：

字节序：是大端（高字节在前）还是小端（低字节在前）
帧头帧尾：有没有固定的起始符和结束符
长度字段：报文长度是固定值还是包含在报文内
校验方式：CRC、LRC、校验和等

以我这次对接的设备为例，它的协议是这样的：

字段	长度	说明
帧头	2字节	固定为16#AA 16#55
命令字	1字节	01表示读，02表示写
数据长度	1字节	数据区长度
数据区	可变	实际数据
CRC16	2字节	CRC校验，低字节在前

5.2 组帧与循环冗余校验的实现

组帧在PLC程序里本质上就是填充字节数组。需要注意的一点是，在IEC61131-3编程环境里，数组偏移是从0开始的，而协议文档里通常说第1字节、第2字节，心里要有个映射关系，免得对应错。

CRC16在PLC里需要写一个小功能块来实现。因为CRC计算是逐字节的位操作，在PLC中实现时需要注意数据类型的位宽，推荐使用BYTE、WORD类型进行操作，避免用到INT时出现符号位的问题。

我之前在组帧时犯过一个低级错误：CRC功能块算出的校验值，和设备的校验值永远对不上。排查了很久才发现，原来是CRC算法的初始值和结果异或值设错了，设备文档里写的是初始值0xFFFF、结果异或0x0000，我软件里的默认参数却是初始值0x0000。所以组帧之前，一定要先把CRC参数核对清楚。

5.3 接收数据的拆分与转换

接收到的一串字节，需要按协议拆分出各个字段。在CODESYS里，我习惯先把接收到的字节数组拷贝到一个独立的解析数组里，然后用指针或者数组偏移去提取数据。

这里有一个非常常见的问题：多字节数值类型（比如16位整数）的高低位顺序。收到的字节可能是高字节在前，也可能是低字节在前，必须协议文档为准。现场调试时，可以用一个已知数据去验证——比如让设备返回一个已知值，然后看PLC解析出来的数值是否正确。如果发现数值明显不对（比如读数大得离谱），十有八九是字节序处理反了。

另外，浮点数的解析更麻烦。EASY系列的PLC和第三方设备之间，如果涉及到浮点数传输，需要确认双方的浮点字节序是否一致。常见的是IEEE754大端，但有些设备会按小端存储，这样解析出来完全是乱码。我的建议是，如果有条件，最好在设备侧先设置成与PLC一致的字节序；如果设备侧不可配置，PLC里就需要做一个字节交换的处理，把32位浮点的四个字节顺序调整一下再接成REAL。

6. 实操过程：从新建工程到第一个Socket报文跑通

6.1 新建工程与初始设置

打开InoProShop，新建工程，选择PLC型号。我选的是EASY320，软件会自动加载对应的设备信息和基础库。在工程树里，双击"Program"，进入主程序编辑区。

在写socket程序之前，先做几个基础设置：

PLC的IP地址：在设备配置页里把PLC的IP设置为固定地址，我这里设为192.168.1.10，子网掩码255.255.255.0。
通信周期设置：默认情况下，CODESYS的Task周期是10ms，这个周期对socket通信来说足够了，不需要改。
库引用：在"Library Manager"里添加socket通信所需的库。

把库添加好之后，在线编译，确认没有错误，再下载到PLC。这个过程是纯环境准备阶段，但要仔细检查编译输出，如果库版本不匹配，编译会提示缺少某个功能块，这时候就要换库版本了。

6.2 写一个最简单的连接程序

在验证socket之前，我建议先写一个最简程序，只做一件事：连接服务器，连接成功后把状态写到某个变量里。这个程序足够简单，方便隔离问题。

下面是我当时的测试代码片段：

VAR fbOpen : Socket_Open; bConnectReq : BOOL; bConnected : BOOL; sTargetIP : STRING := '192.168.1.50'; nTargetPort : WORD := 5020; END_VAR // 主程序 bConnectReq := TRUE; // 上电自动连接 IF bConnectReq THEN fbOpen( ServerIp := sTargetIP, ServerPort := nTargetPort, Timeout := 3000, Done => bConnected ); END_IF

把这个程序下载到PLC，运行后观察bConnected变量。如果变成TRUE，说明连接建立成功。如果一直是FALSE，先检查IP配置是否正确，再检查目标设备是否在监听、防火墙是否封了端口。

6.3 测试Socket服务器的选择

在没有真实设备时可以先用PC上的网络调试工具模拟一个TCP服务器，方便调试PLC的连接和数据收发。我当时用的是SocketTool和网络调试助手这类软件，在电脑上创建了一个TCP Server，监听5020端口，然后让PLC去连接。这样就能在电脑上直观看到PLC发过来的报文内容，也可以手动下发数据模拟设备返回。

这个方法强烈推荐大家先做一遍。它有几个好处：一是可以确认PLC的socket功能是否正常；二是可以仔细检查自己组装的报文是否符合协议；三是在真实设备因为各种原因连不上的时候，可以单独验证PLC侧的程序逻辑，缩小问题范围。

6.4 把发送和接收加进来

连接跑通之后，再把发送和接收逻辑加进去。发送的数据不能死填，要按设备的协议周期性地发送请求。接收的数据要实时检查并解析。

下面是我当时调试时用的发送+接收逻辑的简化版：

// 每500ms发送一次读命令 IF b_Connected AND (b_TimeUp) THEN // 组帧 Send_Buffer[0] := 16#AA; Send_Buffer[1] := 16#55; Send_Buffer[2] := 16#01; // 读命令 Send_Buffer[3] := 16#02; // 数据长度 Send_Buffer[4] := 16#00; // 地址高 Send_Buffer[5] := 16#01; // 地址低 // 计算CRC CRC16(Buff := ADR(Send_Buffer), Len := 6, CRC := CRC_Value); Send_Buffer[6] := CRC_Value MOD 256; // CRC低字节 Send_Buffer[7] := CRC_Value / 256; // CRC高字节 // 发送 Socket_Send_Instance(Buff := ADR(Send_Buffer), Len := 8); END_IF

注意这里我用了一个时间标志b_TimeUp，它的作用是控制发送频率。TCP通信一定要控制报文发送频率，不能每个扫描周期都发，否则远端设备会被淹没。我一般用TON定时器，每500ms产生一个脉冲，用来触发一次发送。

6.5 接收数据的处理流程

接收数据时，我的处理流程是：

判断Socket_Recv的Done标志是否有新数据到达。
读取实际接收的字节数，存入n_RecvLen。
把接收缓冲区的内容复制到一个独立的解析数组中。
校验帧头和CRC，CRC不对直接丢弃，等待下一帧。
CRC校验通过后，按照协议字段依次解析出各个数据。

之所以要把接收缓冲区的内容复制出来，是因为socket功能块的接收缓冲区在下一次Recv调用时会被覆盖，如果不及时复制，数据就会丢失。在实际项目中，这段复制逻辑可以用MEMCPY或者循环赋值实现。

7. 常见问题与排查技巧实录：我踩过的坑都在这里了

7.1 问题速查表

我在整个调试过程中遇到过不少问题，我把它们整理成一个速查表，方便后来者快速定位：

现象	可能原因	解决办法
连接功能块一直返回超时	IP地址配置错误	检查PLC IP、目标IP、子网掩码
连接功能块一直返回超时	目标设备未启动监听	确认设备端服务器已运行，端口已开放
连接立即建立，但发送后无响应	发送频率过高	增加发送间隔，建议500ms以上
接收缓冲区一直无数据	目标设备未主动返回数据	检查报文格式、命令字是否正确
接收数据乱码	字节序不对	确认大小端模式，调整数据解析顺序
CRC校验一直失败	CRC参数错误	核对初始值、异或值、多项式
运行一段时间后连接断开	设备侧主动断开	增加自动重连逻辑，缩短重连间隔
功能块编译不通过	库版本不匹配	下载与固件匹配的socket库版本

7.2 "bind: only one usage of each socket address"这个报错的启发

看标题里大家搜过这个错误：bind: only one usage of each socket address (protocol/network address/port)，这个报错大类是在电脑端做socket编程时出现的，意思是某个IP和端口组合已经被另一个socket占用了。虽然这不是PLC侧的直接报错，但调试时要特别注意端口冲突问题——比如PLC作为客户端连接设备时，本地端口是系统自动分配的，一般不会冲突；但如果你同时开了多个网络调试工具，占用了同一个本地端口，就很容易遇到"起不来"的情况。在用电脑模拟服务器时，如果你已经在一个软件里监听了5020端口，再开另一个软件监听同一端口，就会报这个错误。所以调试时要确保：一个端口只能被一个程序监听。

7.3 汇川EASY系列的独特注意点

这套EASY系列PLC的socket功能，我在实际使用中总结了几个专属注意点：

注意一：socket功能块不能和普通时序逻辑混在一个程序段里不加区分地调用。因为socket功能块的执行等外部事件，扫描周期内可能没有立即完成，如果没有对Busy标志做处理，程序逻辑会被拖慢。我的做法是，把socket相关的调用放到独立的任务中，这个任务的周期适当放宽（比如20ms或50ms），以保证功能块有充足的时间完成内部的状态处理。

注意二：多个设备通信时，接收数据要加队列或者缓冲区管理。如果PLC同时连接多个设备，设备返回数据的时间点不一致，可能出现数据交叉覆盖。我为每台设备分配了独立的接收缓冲区，并且保证在一次任务周期内，只处理一个设备的接收数据，其他设备的数据先存入缓冲区，下一周期再处理。

注意三：不要使用全局变量来传递socket数据。这个是我踩过的最惨的坑。因为socket数据量大、刷新频率高，如果用全局变量传递，容易导致数据在不同任务之间被覆盖。正确的方式是每个功能块实例都定义自己的输入输出变量，通过接口参数传递，数据流清晰可控。

7.4 现场排查的几个经验

现场问题往往比实验环境复杂。我总结了几个排查经验的优先级顺序：

第一，先看物理链路。网线有没有插紧、交换机端口指示灯是否正常、设备有没有上电，这些问题虽然基础，但现场一半的"通信故障"其实是物理链路问题。

第二，再用PC模拟设备验证PLC程序。拔掉设备的网线，把电脑连到PLC的网口上，用网络调试助手模拟设备，看PLC程序是否能正常收发。这样可以确认PLC侧的程序是否正常，把问题缩小到设备侧。

第三，抓包。如果PC和设备同时出现在网络里，可以用Wireshark抓包，查看PLC发出的报文和设备返回的报文内容。一旦看到报文的具体字节内容，很多问题就一目了然了。比如CRC不对、字节序反了、报文长度不对，这些都可以从抓包里直接看出来。

8. 文中用到的关键代码汇总

为了方便直接抄作业，我把几个关键的功能块定义代码汇总在这里。

功能块实例化：

VAR // Socket功能块实例 fb_Open : Socket_Open; fb_Send : Socket_Send; fb_Recv : Socket_Recv; fb_Close : Socket_Close; // 连接参数 s_ServerIP : STRING := '192.168.1.50'; n_ServerPort : WORD := 5020; // 数据缓冲区 arr_SendBuf : ARRAY [0..255] OF BYTE; arr_RecvBuf : ARRAY [0..255] OF BYTE; n_SendLen : INT; n_RecvLen : INT; // 状态标志 b_IsConnected : BOOL; b_SendDone : BOOL; b_RecvDone : BOOL; b_Error : BOOL; n_ErrorCode : WORD; END_VAR

状态机主逻辑：

CASE n_CommState OF 0: // IDLE - 等待连接 IF b_ConnectReq THEN n_CommState := 10; END_IF 10: // CONNECTING fb_Open( ServerIp := s_ServerIP, ServerPort := n_ServerPort, Timeout := 3000, Done => b_IsConnected, Error => b_Error, ErrorCode => n_ErrorCode ); IF b_IsConnected THEN n_CommState := 20; ELSIF b_Error THEN n_CommState := 0; // 延时3秒后重试 END_IF 20: // RUNNING // 发送周期请求 // 接收数据解析 // 如果错误，关闭连接，回到IDLE END_CASE

CRC16计算功能块（部分）：

FUNCTION_BLOCK FB_CRC16 VAR_INPUT pData : POINTER TO BYTE; nLen : INT; END_VAR VAR_OUTPUT nCRC : WORD; END_VAR // 内部变量省略 // 实现标准Modbus CRC16算法，注意初始值和结果异或值

整个代码的核心思路就是：实例化socket功能块，用状态机控制连接状态，通过独立的发送/接收缓冲区完成数据交互。这个框架可以套用到任何基于socket的第三方设备通信中，只需要修改报文格式和解析逻辑即可。

9. 稳定性优化与运行效果：现场跑了三个月我才敢写这篇文章

9.1 通信周期的选择

socket通信的实时性，取决于PLC的任务周期和网络延迟。EASY320的默认任务周期是10ms，对于大部分socket通信场景，这个周期已经足够快。但如果你需要更高实时性，建议把socket通信放在单独的高优先级任务中，并把任务周期设定在5ms。

需要注意的是，任务周期越短，CPU占用率越高。我实际测试过：当任务周期为10ms时，CPU占用率大概在30%左右；当任务周期缩短到5ms时，CPU占用率上升到50%以上。所以除非迫不得已，不建议把socket通信周期设置得太激进。

9.2 数据安全的处理

socket通信是明文传输的，如果现场有网络安全要求，建议在应用层做简单的加密或者至少加鉴权机制。比如在报文中加入设备ID和密码字段，设备端校验通过后才响应。

另外，串口转以太网或者无线桥接的场景，网络质量不稳定，更容易出现数据丢包和乱序。这种情况下，建议在报文协议中增加序号字段，PLC侧检测到序号不连续时，主动丢弃当前帧，请求设备重发。

9.3 运行效果

这个项目上线后，PLC和设备之间的socket通信已经连续运行了三个月，没有出现过一次通信中断。设备的每次请求响应时间都在100ms以内，完全满足现场工艺要求。PLC在设备重启、断网重连等异常场景下，都能自动恢复通信，稳定性达到预期。

要说不足，就是EASY320的内存空间有限，如果接收缓冲区定义得太大，会影响PLC的程序容量。我的建议是接收缓冲区按需定义，在满足最大报文长度的前提下尽可能小，一般256字节足够。

10. 一些想提醒后来者的经验

这篇文章写到这里，核心内容基本都覆盖了。从环境搭建、功能块使用、状态机设计、报文解析，到稳定性优化、常见问题排查，可以说是一套完整的EASY系列socket主站通信方案。

最后分享几个个人体会：

第一，socket通信本身并不难，难的是报文的适配和异常的鲁棒性处理。协议文档一定要反复读，字节序、CRC、帧格式这些细节，一个字母都不能错。

第二，调试阶段，PC模拟工具是最好用的伙伴。PLC端的程序先用网络调试助手模拟验证，不要一上来就接真实设备，那样问题太多，很难定位。

第三，PLC的socket通信虽然灵活，但也带来了程序复杂度上升和CPU占用率增加的问题。在有标准工业总线协议可用的场景下，优先选标准协议；只有设备确实只开放socket接口时，才走这条路线。

希望这篇文章能帮你少走弯路，也欢迎大家在实际项目中遇到问题随时交流。我的经验是，只要把状态机和报文解析这两块理清楚，EASY系列做socket主站这条路，走起来会很顺。