简介：面向C#上位机开发者与工业自动化入门者的TCP通信学习笔记，聚焦基于Socket类库实现与PLC服务器之间的通信连接，适用于需要掌握上位机与设备数据交互的初学者。文中以Visual Studio 2019为开发环境，配合TIA Portal与S7-PLCSIM Advanced的仿真场景，逐步讲解登录窗体设计、连接按钮事件编写、IP与端口参数配置，并给出可参考的Socket连接代码。针对接收缓冲区中的不同类型数据，重点展示了利用BitConverter与Encoding完成整数、浮点数、字符串解析的思路，也说明通信协议中大小端序、字段起始位置等关键细节。此外还提及实际工程中的异常处理、心跳检测、断线重连等稳定性问题。资源为单个Word文档，压缩包约365KB，已有966人在线学习，适合正在学习C#上位机通信并需要参考连接与数据解析写法的开发者，可作为从基础学习到实际项目排错的过渡资料使用。
1. 为什么“基于SOCKET实现与PLC服务器的TCP通信”值得写第二部分：连上只是开始
C#上位机基础学习-基于SOCKET实现与PLC服务器的TCP通信（二）这个标题，第一眼像是在讲“怎么连上PLC”，但真正做过上位机开发的人都知道，连上只是开始。当你把Socket第一次握手打通之后，会发现PLC服务器并不是一个主动把数据推给你的服务端，它更像一台“你发一条合法请求、它才回一条响应”的工控机器人。第二部分要解决的是连接建立之后的事：请求报文怎么拼、响应怎么拆、粘包半包怎么处理、PLC重启或网线抖动后客户端怎么恢复。这条路走通了，你的上位机项目才能从演示变成能长期开机运行。适合正在做C#上位机项目、需要对接西门子、三菱或台达PLC，被TCP通信“时灵时不灵”困住的工程师。
2. 先立住理论：SOCKET、TCP与PLC服务器的通信边界
2.1 谁监听谁连接：PLC服务器与C#客户端的角色边界
在以太网PLC场景里，PLC一般作为TCP Server，C#上位机作为TCP Client。这是我接触过的绝大多数项目里的角色分配：PLC固件里烧了TCP监听逻辑，并在固定端口上等待客户端；C#上位机在启动时发起连接。常见端口不一定通用：ModbusTCP默认是502，西门子S7协议家族是102，三菱MC协议是6000。这些端口在工厂里常常会因为网段规划或防火墙被改掉，所以不要把端口号写死在代码里，放到AppSettings或配置文件里，一份配置对应一条产线。
为什么不把角色反过来？因为PLC的TCP栈不是通用操作系统，它通常只支持少量并发连接，常见只支持几个客户端。如果让C#去做服务器、PLC做客户端，那PLC必须先来连上位机，一旦上位机先启动、PLC还没准备好，就会出现启动顺序强耦合。保持PLC服务器、C#客户端的角色，上位机随时可以断开重连，不影响PLC程序循环。
所以C#上位机里不要每读一次数据就新建一个TcpClient再Close，最好是一台设备一条长连接。长连接除了减少握手开销，更重要的是很多PLC的TCP栈在反复“连接-断开”时会进入TIME_WAIT，连接数被占用后新的连接会被拒绝。这个坑后面细说。
2.2 字节流不是报文：为什么必须自己解决粘包和半包
TCP保证的是字节顺序和可靠性，不保证“一次发送对应一次接收”。协议栈可能把一次Send拆成多个TCP段，也可能把多个请求合并后交给应用层。这就是socket网络编程里几乎人人都会遇到的粘包/半包。PLC上位机通信里，如果没做拆包，直接读固定字节数，结果通常时好时坏。
工业PLC协议普遍采用长度字段来界定报文。以ModbusTCP为例，报文结构是：事务ID（2字节） + 协议ID（2字节） + 长度（2字节） + 单元号（1字节） + 功能码（1字节） + 数据（N字节）。其中“长度”字段表示从单元号开始到报文末尾的字节数，而不是整个报文长度。响应报文的长度字段同样这样算，所以C#端可以从接收缓存中先读够6个字节的头部，再取长度值，然后决定是否继续读余下部分。
拆包的基本流程是：接收循环把新流入的原始字节追加到缓冲区内，每次只判断缓冲区内是否已经包含6字节的头部；头部够了就解析长度，再看缓冲区剩余是否达到整个帧的长度；不够就继续等，够了就切出一帧返回给上层。这一层不要和业务解析混在一起，我习惯独立成“拆包器”，这样后面切换到西门子S7或三菱MC协议时，只需要换报文字段位置，拆包骨架不变。
在启动代码前，先用一个PowerShell命令确认PLC端口真的通，避免白白调试：
# 在局域网内检测PLC的TCP端口是否可通，IP和端口按现场改 Test-NetConnection 192.168.1.10 -Port 502这条命令会返回TcpTestSucceeded字段。如果它显示False，后面C#代码怎么写都会卡在Connect或超时上，先检查网线、网卡IP和PLC侧允许访问的开关。如果用默认端口不通，换个端口再试，很多PLC支持自定义端口号，但需要在PLC程序里开放对应端口。
2.3 同步阻塞与上位机的UI线程冲突
C#上位机开发里最常见的翻车现场是：在按钮点击事件里直接调用socket.Receive(buffer)，然后整个窗体卡死。原因是UI线程被阻塞后无法继续处理消息循环，界面没反应。PLC响应慢一点，卡顿就特别明显；网络完全断开时，Receive阻塞到超时甚至更久，用户只能强杀进程。
解决方向有三个：一是把所有网络操作放后台线程或Task；二是使用async/await异步读写并保持UI线程空闲；三是用CancellationToken让窗体关闭时能中断等待。三件事要一起做，不是只有async就够。
还要明确一点：不要把“能在按钮里读到一次数据”当成合格。一个能上线的上位机通信模块必须至少有连接状态管理，状态大致包括Disconnected、Connecting、Connected、WaitingResponse、Reconnecting。为什么需要状态机？因为PLC重启、网线插拔、上位机休眠恢复，都会让连接变成一种“看着没断、实际已死”的状态。只有状态机知道当前该重连还是继续等，才能避免无意义的读写异常。
3. 用C#把PLC读通：建立连接、发送请求、接收响应的最小代码
3.1 连接参数和TcpClient初始化：端口不要写死
先写一个最小客户端类，它的职责只到“连接”为止：
using System.Net; using System.Net.Sockets; public class PlcTcpClient { private readonly TcpClient _tcp; private readonly string _host; private readonly int _port; public PlcTcpClient(string host, int port) { _host = host; _port = port; _tcp = new TcpClient(); _tcp.NoDelay = true; // 关闭Nagle算法，小报文不等待合并 _tcp.ReceiveTimeout = 1000; // 同步读超时，单位毫秒 _tcp.SendTimeout = 1000; // 同步写超时 } public async Task<bool> ConnectAsync() { if (_tcp.Connected) return true; try { // TcpClient的ConnectAsync没有超时参数，用WhenAny做3秒兜底 Task connectTask = _tcp.ConnectAsync(IPAddress.Parse(_host), _port); Task completed = await Task.WhenAny(connectTask, Task.Delay(3000)); if (completed != connectTask) { throw new TimeoutException("PLC连接超时"); } await connectTask; // 连接失败时这里抛SocketException return _tcp.Connected; } catch { _tcp.Close(); throw; } } }几个参数是按工控现场调的。NoDelay设为true，是因为PLC请求报文体量很小，打开Nagle后TCP内核会为小包等待更多数据再发送，可能额外延迟几十毫秒，对需要频繁轮询的上位机来说不值得。ReceiveTimeout和SendTimeout是同步Read/Write的超时，设为1000毫秒；如果你用异步ReadAsync，这个超时不一定生效，所以异步场景里我会用CancellationToken做超时控制。
if (_tcp.Connected) return true不能当作“连接肯定可用”，它只表示上一次TCP操作时连接状态还活着。后面要做心跳。还有，Task.WhenAny只是取消等待，不会取消底层连接，如果超时了仍然要执行_tcp.Close()释放句柄，不然下一次Connect会拿到一个半开连接。
3.2 拼一个读寄存器请求：从Hex字符串到byte[]
ModbusTCP报文可以用十六进制字符串直观表达。下面是读从地址0x0000开始的两个保持寄存器的请求帧：
public static byte[] HexToBytes(string hex) { hex = hex.Replace(" ", "").Replace("-", ""); if (hex.Length % 2 != 0) throw new ArgumentException("十六进制长度必须是偶数"); var result = new byte[hex.Length / 2]; for (int i = 0; i < result.Length; i++) { result[i] = Convert.ToByte(hex.Substring(i * 2, 2), 16); } return result; } // 读保持寄存器请求，默认读02个寄存器 byte[] request = HexToBytes("0001 0000 0006 01 03 0000 0002");报文拆开看：0001是事务ID，每次请求要递增；0000是协议ID，ModbusTCP固定为0；0006是长度，表示后面还有6个字节；01是单元号，也就是PLC站号；03是功能码，读保持寄存器；0000和0002是起始地址和寄存器数量。这些都是大端字节序，一个16位数如0x0002，在报文里高字节在前、低字节在后，和C#里BitConverter默认的小端正好相反，后面解析响应时一定要记得Reverse。
长度字段是整个握手最容易错的地方。很多人在调试时把长度写成了整个报文的字节数，这里应该是“后续字节数”，不是总长度，不要额外加6。如果PLC一直不回，先打印这帧的hex，对照手册逐字节看。
3.3 发送请求并读回完整响应：ReadExactly是基本功
发送和接收不能只做一次NetworkStream.Read，TCP流式传输决定了很可能一次Read只拿到部分响应，必须循环读到完整长度：
private static async Task ReadExactlyAsync(NetworkStream stream, byte[] buffer, int count) { int offset = 0; while (offset < count) { int read = await stream.ReadAsync(buffer, offset, count - offset); if (read == 0) { // 对端关闭连接，继续读只会得到0 throw new IOException("PLC连接已关闭，读到0字节"); } offset += read; } } // 拼ModbusTCP请求，事务ID由调用方传入 private static byte[] BuildModbusRequest(ushort txId, byte unitId, byte function, ushort start, ushort count) { using var ms = new MemoryStream(); ms.WriteByte((byte)(txId >> 8)); ms.WriteByte((byte)txId); ms.WriteByte(0x00); ms.WriteByte(0x00); // 协议ID ms.WriteByte(0x00); ms.WriteByte(0x06); // 长度：unitId+function+start+count ms.WriteByte(unitId); ms.WriteByte(function); ms.WriteByte((byte)(start >> 8)); ms.WriteByte((byte)start); ms.WriteByte((byte)(count >> 8)); ms.WriteByte((byte)count); return ms.ToArray(); } public async Task<byte[]> ReadHoldingRegistersAsync(ushort start, ushort count, byte unitId) { byte[] request = BuildModbusRequest(0x0001, unitId, 0x03, start, count); NetworkStream stream = _tcp.GetStream(); await stream.WriteAsync(request, 0, request.Length); // 先读6字节头部：事务ID2 + 协议ID2 + 长度2 byte[] head = new byte[6]; await ReadExactlyAsync(stream, head, 6); // 长度字段表示“后续字节数”，body里包含单元号、功能码和数据 int bodyLength = (head[4] << 8) | head[5]; byte[] body = new byte[bodyLength]; await ReadExactlyAsync(stream, body, bodyLength); return head.Concat(body).ToArray(); }这里的事务ID写死为0x0001，实际应用要递增。可以维护一个ushort字段，每次收发加1，溢出回到0。PLC端会按事务ID把响应和请求对上，如果一直用同一个ID，某些PLC会丢弃它认为重复的请求。
ReadExactly这个名字来自网络编程惯例，意思是“读够指定字节数为止”。注意ReadAsync的返回值是本次实际读到的字节数，可能是1，也可能是几百，这取决于TCP栈缓存。使用这个函数后，上层不再担心半包，但应用层报文边界的粘包问题，还要配合下面的队列机制。
拿到完整响应帧后，解析保持寄存器的值，同样是大端字节序：
public static ushort[] ParseHoldingRegisters(byte[] frame) { // frame至少包含6字节头部 + 单元号 + 功能码 + 字节数 if (frame.Length < 9) throw new ArgumentException("响应帧太短"); if ((frame[7] & 0x80) != 0) { int func = frame[7] ^ 0x80; int err = frame[8]; throw new Exception($"Modbus异常响应，功能码0x{func:X2}，异常码{err}"); } int byteCount = frame[8]; var values = new ushort[byteCount / 2]; for (int i = 0; i < values.Length; i++) { values[i] = (ushort)((frame[9 + i * 2] << 8) | frame[10 + i * 2]); } return values; }注意异常响应时，功能码的最高位会被置1，例如读保持寄存器功能码0x03收到异常时变成0x83。如果没做这个判断，直接解析数据，会把异常码当成寄存器值，界面上会出现看似合法但完全错误的数据。
4. 把通信做好：拆包、心跳、超时与断线重连
4.1 用SemaphoreSlim保证同一时刻只有一个请求在途
上面的ReadHoldingRegistersAsync在只有一个调用方时没问题，但一加上心跳轮询或多个线程同时读，就会出现两个请求同时写同一个NetworkStream。TCP层会把两个请求的字节交叉发送，PLC收到一个混乱的帧，响应也就对不上。解决方法是给整个“发送请求-接收响应”过程加互斥：
private readonly SemaphoreSlim _gate = new SemaphoreSlim(1, 1); private ushort _txId = 1; public async Task<byte[]> ReadHoldingRegistersAsync(ushort start, ushort count, byte unitId) { await _gate.WaitAsync(); try { // 事务ID只在锁内递增，避免并发线程取到同一个ID ushort txId = _txId++; byte[] request = BuildModbusRequest(txId, unitId, 0x03, start, count); NetworkStream stream = _tcp.GetStream(); await stream.WriteAsync(request, 0, request.Length); byte[] head = new byte[6]; await ReadExactlyAsync(stream, head, 6); int bodyLength = (head[4] << 8) | head[5]; byte[] body = new byte[bodyLength]; await ReadExactlyAsync(stream, body, bodyLength); return head.Concat(body).ToArray(); } finally { _gate.Release(); } }SemaphoreSlim的初始值为1，表示同一时刻只允许一个任务进入。后面的UI读取、心跳、报警刷新都调用同一个方法，自然就会排队，不会交叉。finally里的Release保证即使读超时抛出异常，信号量也会释放，否则下一次读会一直卡在WaitAsync上。
这个方案下，ReadExactly已经能把“半包”补齐，因为一个请求只对应一个响应。如果你打算把多个请求同时丢到同一个Socket上，再靠事务ID匹配响应，那就要用真正的拆包器。但PLC场景里，我一般不建议那么做，一个请求在途反而更好排查。
4.2 什么时候需要FrameBuffer拆包器
有一种场景躲不开拆包器：上层同时发两个请求，等待响应时已经无法保证“一次Read读一帧”。或者PLC侧有主动通知报文，间隔时间不确定。这时不能直接用ReadExactly读固定长度，因为数据流里可能混着上一帧的残余。
public class ModbusTcpFrameBuffer { private readonly List<byte> _buffer = new List<byte>(); public IEnumerable<byte[]> Push(byte[] data) { _buffer.AddRange(data); while (_buffer.Count >= 6) // 至少能读出长度字段 { int bodyLength = (_buffer[4] << 8) | _buffer[5]; int frameLength = 6 + bodyLength; // 6字节头部 + 后续字节 if (_buffer.Count < frameLength) { // 半包，等下一次Push再继续 break; } byte[] frame = _buffer.GetRange(0, frameLength).ToArray(); _buffer.RemoveRange(0, frameLength); yield return frame; } } }Push每次收到网络层原始字节时调用，它返回零个或多个完整帧。非常重要的是，半包出现时不要把_buffer.Clear()掉，否则那些字节就丢了，要等下一次数据来拼。使用这个拆包器后，上层逻辑从“读一帧”变成“收一帧”，可以把完整帧按事务ID路由到对应的等待任务。对于绝大多数单请求在途的PLC通信，用锁队列就够，拆包器反而增加复杂度。
4.3 心跳参数与断线重连策略
很多PLC的TCP栈会在连续一段空闲后关闭连接，常见空闲断开值在30秒到60秒之间。如果上位机只在用户点击时才读数据，连接很容易被静默断开。心跳的作用是让连接在空闲时也有小流量通过，同时验证连接真的能用。
private CancellationTokenSource _heartbeatCts = new CancellationTokenSource(); public async Task StartHeartbeatAsync() { while (!_heartbeatCts.IsCancellationRequested) { try { // 每5秒读一个不参与工艺逻辑的寄存器，确保连接可用 await ReadHoldingRegistersAsync(0x1000, 1, 1); } catch { // 心跳失败说明连接已不可用，触发重连 break; } await Task.Delay(5000, _heartbeatCts.Token); } }心跳间隔取5秒是经验值：太短会增加PLC通信负载，太长则可能在PLC空闲断开之前来不及保活。如果现场要求更稳的机制，可以把心跳间隔缩短到3秒，但不要小于1秒，否则PLC的通信日志会被心跳刷屏。
重连不能无限快循环，必须带退避：
public async Task ReconnectWithRetryAsync() { TimeSpan[] retryDelays = { TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2), TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(30), }; foreach (var delay in retryDelays) { try { await ConnectAsync(); _txId = 1; // 重连后重置事务ID _heartbeatCts = new CancellationTokenSource(); return; } catch { await Task.Delay(delay); } } // 连续失败，通知UI报警，不要再后台瞎重试 }重连成功后重置事务ID很重要，因为PLC重启后，旧连接状态里的事务ID可能和当前不匹配，继续从旧值递增可能导致响应被当成异常。退避时间从1秒逐渐加到30秒，是为了避免PLC的TCP栈还没恢复时，上位机一直用并发连接去敲门，把连接队列打满。
5. 排查与避坑：PLC通信卡死、乱码、无响应的5个常见现场
5.1 连接时报“目标计算机积极拒绝”，但PLC程序明明在跑
现象：C#代码执行到ConnectAsync时直接抛SocketException，提示目标计算机积极拒绝；用浏览器访问设备监控页却能打开。原因：PLC作为TCP Server只监听特定端口，可能端口没打开、网段隔离或防火墙拦截，也可能是PLC型号里“允许远程访问”的开关没勾选。解决：先按顺序排查，不要急着改代码。第一步在PLC同一网段的PC上ping设备IP；第二步用Test-NetConnection检测端口；第三步检查PLC程序里CPU的通信允许设置；第四步检查Windows防火墙是否拦截C#程序的出入站连接；第五步确认上位机网卡只有目标地址一个IP，避免路由走错网卡。如果端口探测False，代码怎么调都没用。
5.2 读上来的数据第一次正常，第二次开始错乱
现象：读10个寄存器，第一次解析数值正常，第二次后某些寄存器值没法看，抓包看响应报文齐全，但解析偏移对不上。原因：没有做完整帧读取，用NetworkStream.Read读一次就解析，实际上一个响应可能被拆成两次TCP段到达，第二次Read拿到的是上一帧尾部。还有一种相关原因：两个线程同时读写同一个NetworkStream，请求交叉，PLC把混合后的字节回传。解决：使用ReadExactly保证读满一帧；所有请求走同一个SemaphoreSlim。注意不要在解析前做stream.Read后马上解析，先确认长度字段和数据总量。
5.3 UI线程卡死，窗体白屏只能强杀
现象：点击“启动”按钮后窗体无响应，鼠标转圈，关窗体也没反应。原因：在按钮事件里同步执行Receive，且ReceiveTimeout被设成0或很大，线程一直阻塞。如果收包逻辑还有死循环，界面彻底失去消息泵。解决：事件处理器里用async/await，把网络调用换成异步版本；窗体FormClosing时调用CancellationTokenSource.Cancel，不要让线程等待Socket超时。注意async void只能用在事件处理器上，网络库内部不要用async void，否则异常会直接抛到同步上下文。
5.4 PLC重启后，客户端不再报错也不再更新
现象：PLC断电重启，上位机界面数值停在上一个值，没有异常弹窗；点“手动断开再连接”又能正常。原因：TCP连接断开时，如果应用层没有正在执行的读操作，C#端不会立刻感知。TcpClient.Connected属性还留在true，因为它只是上一次IO操作的状态缓存。没有心跳和重连机制的客户端会一直以为连接可用。解决：增加心跳，连续两次心跳失败就触发重连；不要依赖Connected属性做判断。心跳读操作抛异常后，先Close旧连接，再按退避策略重连，并重置事务ID和拆包缓冲区。
5.5 请求和手册完全一致，PLC就是无应答
现象：把请求帧打印出来，和手册模板逐字节比对没有差异，但PLC一直超时。原因：长度字段算错或事务ID没有递增。ModbusTCP的长度字段是后续字节数，不是整个帧长。请求里如果写成了整个报文的字节数，PLC认为帧没完整到达，不会处理。事务ID重复也会被某些PLC丢弃。解决：打印请求帧的hex，按“单元号+功能码+数据”数出长度；事务ID用一个ushort字段每次加1，不要用随机数。另一个高频坑是大端小端，0x0002在报文里必须是00 02，如果用BitConverter.GetBytes直接拼，得到02 00，PLC会当成地址0x0200，可能回异常码2或干脆不回应。
6. 验证与进阶：并发读压力下的通信框架要关注什么
我不会建议你直接去产线验证，先用并发读把问题逼出来。写一个临时压测方法，同时发起100个读请求，每个请求都记录响应帧，最后统计成功率和耗时：
var tasks = Enumerable.Range(0, 100).Select(async i => { var sw = Stopwatch.StartNew(); byte[] frame = await client.ReadHoldingRegistersAsync(0x0000, 10, 1); sw.Stop(); return new { Index = i, Elapsed = sw.ElapsedMilliseconds, Frame = frame }; }); var results = await Task.WhenAll(tasks); int failCount = results.Count(r => r.Frame.Length < 10); int timeoutCount = results.Count(r => r.Elapsed > 1000);100个任务会并发创建，但SemaphoreSlim会把真正的Socket收发串行化。如果failCount和timeoutCount都为零，说明拆包、锁和超时处理基本可靠。如果出现大量超时，先看ReceiveTimeout和心跳间隔是否太短；如果出现错帧，回头检查事务ID是否在锁外递增。
我还会做连续8小时的跑批验证，期间每小时重启一次PLC，观察客户端是否在15秒内自动恢复。日志里必须记录每次心跳、重连、异常的时间戳、事务ID和耗时。上线后遇到“偶发无响应”，不要靠猜，直接把日志拉出来，看是哪一秒、哪一帧、抛了什么异常。我习惯把拆包、心跳、重连做成三个独立的小类，每次换PLC协议只改编码解码层，框架本身不做大变动。这样对接多品牌PLC时少走弯路。希望帮到你。
本文还有配套的精品资源，点击获取
