简介这套C#上位机通讯程序源码涵盖了通过IP和COM口连接多种PLC进行数据交换的完整实现适用于工业自动化场景下的设备监控、数据采集与远程控制。源码采用标准的TCP/IP和串口通信架构兼顾Modbus TCP与Modbus RTU协议既适合新手学习PLC通讯的基本流程也为有经验的开发者提供了可复用的通讯模块。包内共110个文件以.cs源文件为主体配合config、xml等项目配置、dll运行库以及可直接执行的exe还包含pdb调试符号便于跟踪排错整体大小仅1.09MB。通过学习可掌握Socket通讯、串口参数配置、Modbus报文封装、异常处理等关键编码技巧并能依据自身PLC型号快速改造移植。目前已有129人浏览学习程序老媛出品且亲测校正质量有保障。1. 从一套能跑的源码说起接手过不少工控项目的上位机你会发现一个尴尬的现实很多号称“PLC通讯组件”的东西拆开看核心就是 Modbus 协议的封装。真正有用的不是那一堆封装好的类库而是它怎么处理报文、怎么处理超时、怎么在 TCP 和串口之间切换。这套源码给了两个工程文件——ModbusTcp 和 ModbusRtu正好覆盖了工业现场最常见的两种物理链路网线和串口线。IPC 通过 IP 访问 PLC 用的是 Modbus TCP走 COM 口的就是 Modbus RTU协议栈不同、报文格式不同、调试手段也不同但上层业务代码可以共用一套寄存器读写接口。对于 C# 上位机开发者来说这套代码的价值在于它的可移植性能读懂它你就能在前任留下的项目里快速定位通讯故障也能在自己搭框架时少踩几个坑。2. Modbus 通讯的底层逻辑与工程代码结构2.1 先搞清楚三种模式的区别Modbus 协议族里有三种常见的传输模式Modbus RTU、Modbus ASCII 和 Modbus TCP。RTU 和 ASCII 都跑在串口COM 口上RTU 用二进制编码数据密度高同样的波特率下吞吐量比 ASCII 大一倍左右ASCII 用十六进制字符传输肉眼能读但效率低现在新项目几乎不用了。Modbus TCP 跑在以太网上本质上是把 RTU 报文去掉 CRC 校验后套上一个 MBAP 头端口号固定用 502。这套源码把 ModbusTcp 和 ModbusRtu 分成两个独立的工程这个设计我很赞同。因为两者虽然应用层协议一致但下层差异太大TCP 有系统级的连接状态管理而串口需要自己处理帧间隔、超时和半双工切换。如果强行合并成一个类再到处加 if 分支后面维护起来会很痛苦。2.2 报文格式对照与功能码映射关系主站上位机和从站PLC之间的通信本质是“请求-响应”模式。读寄存器时主站发出读请求帧PLC 处理后返回数据帧写寄存器时主站发出写请求帧PLC 返回一个确认帧。下面这组表格是核心报文结构的对照项目Modbus TCP字节数Modbus RTU字节数事务标识符2无靠应答顺序对应协议标识符2无长度字段2无单元标识符11从站地址功能码11数据区NNCRC16 校验无2从这张表能看出来TCP 模式下不需要地址和 CRC因为以太网链路层已经解决了寻址和校验问题。而串口是共享总线必须靠从站地址区分设备靠 CRC 保证链路可靠性。功能码方面做上位机通讯最常用的就这几个功能码含义对应 PLC 数据区0x01读线圈Q 输出点0x02读离散输入I 输入点0x03读保持寄存器VW / MW / D 区0x04读输入寄存器AIW / IW模拟量0x05写单线圈单个 Q 点0x06写单寄存器单个 VW / MW / D 字0x0F写多线圈一组 Q 区0x10写多寄存器一组数据块2.3 源码工程的内部依赖与调用关系这套源码里的两个 csproj 工程典型的依赖关系是这样的上位机窗体界面通常是 WinForm 或 WPF引用通讯层类库通讯层内部封装了ModbusTcpClient和ModbusRtuClient两个核心类。这两个类向上暴露统一的方法比如ReadHoldingRegisters(int startAddress, ushort length)、WriteSingleRegister(int address, short value)、WriteMultiRegisters(int startAddress, short[] values)。通常我会把串口参数COM 口号、波特率、数据位、停止位、校验位和网络参数IP、端口、超时时间分别做成配置类。这样切设备的时候只需要改配置不用动业务代码。实际开发中很多项目同时挂了多个 PLC有的走网线有的走串口这套结构就非常合适——上层逻辑只认“读写寄存器”这个抽象动作底层是走 TCP 还是走 RTU 由配置决定。3. C# 实现 Modbus TCP 通讯的细节拆解3.1 连接建立与保活策略做 Modbus TCP 上位机第一步是建立 TCP 连接。有一点需要注意Modbus TCP 的默认端口是 502但很多 PLC 支持修改端口比如西门子 S7-1200 的 Modbus TCP 服务器可以配到其他端口。连接代码常见做法如下using System.Net.Sockets; public class ModbusTcpClient : IDisposable { private TcpClient _tcpClient; private NetworkStream _stream; private readonly string _ip; private readonly int _port; private readonly int _timeout; // 单位毫秒 public ModbusTcpClient(string ip, int port 502, int timeout 3000) { _ip ip; _port port; _timeout timeout; } public bool Connect() { try { _tcpClient new TcpClient(); var asyncResult _tcpClient.BeginConnect(_ip, _port, null, null); if (!asyncResult.AsyncWaitHandle.WaitOne(_timeout)) { throw new TimeoutException($连接PLC超时(IP: {_ip}:{_port})); } _tcpClient.EndConnect(asyncResult); _stream _tcpClient.GetStream(); _stream.ReadTimeout _timeout; _stream.WriteTimeout _timeout; return true; } catch { Dispose(); throw; // 让上层感知失败统一弹提示或记录日志 } } }BeginConnect配合WaitOne是实现“连接超时控制”的经典做法因为TcpClient.Connect在目标 IP 不可达时可能卡几十秒才报错这在工业现场是无法接受的。连接建立后ReadTimeout和WriteTimeout必须显式设置否则一旦 PLC 掉线Read操作会无限期阻塞。3.2 构建 MBAP 头与数据帧Modbus TCP 报文由两部分组成MBAP 头7 字节和 PDU功能码 数据。MBAP 头的四个字段里事务标识符用来自我确认——同一个连接上快速收发多条请求时靠事务 ID 把响应和请求对上。我用递增计数器生成事务 ID详见代码private ushort _transactionId 0; private byte[] BuildRequestFrame(byte unitId, byte functionCode, byte[] data) { _transactionId; byte[] frame new byte[8 data.Length]; // 7字节MBAP 1字节功能码 数据 frame[0] (byte)(_transactionId 8); // 事务标识符高字节 frame[1] (byte)(_transactionId 0xFF); // 事务标识符低字节 frame[2] 0; // 协议标识符高字节固定0 frame[3] 0; // 协议标识符低字节固定0 frame[4] (byte)((data.Length 2) 8); // 后续字节长度高字节 frame[5] (byte)((data.Length 2) 0xFF); // 单元ID 功能码 数据 frame[6] unitId; // 单元标识符一般填1 frame[7] functionCode; Array.Copy(data, 0, frame, 8, data.Length); return frame; }事务 ID 用 8和 0xFF拆成高低两个字节这是大端序Big-Endian的标准做法。Modbus 协议规定多字节数据一律高字节在前这一点在做 C# 开发时特别容易踩坑——BitConverter默认用本机字节序x86/x64 下是小端必须手动处理字节顺序。3.3 读保持寄存器功能码 0x03完整实现读保持寄存器是最常用的操作用于读取 PLC 的 VW 区、MW 区或数据块。起始地址和读取长度都是 16 位合起来组成数据区注意起始地址是零基的比如要读 PLC 侧地址 40001 对应的数据协议地址填 0。public short[] ReadHoldingRegisters(byte unitId, ushort startAddress, ushort count) { byte[] data new byte[4]; data[0] (byte)(startAddress 8); data[1] (byte)(startAddress 0xFF); data[2] (byte)(count 8); data[3] (byte)(count 0xFF); byte[] request BuildRequestFrame(unitId, 0x03, data); byte[] response SendAndReceive(request); // 检查异常响应PLC返回的功能码最高位置1表示请求出错 if ((response[7] 0x80) ! 0) { int errorCode response[8]; throw new ModbusException($PLC返回错误码: 0x{errorCode:X2}); } int byteCount response[8]; // 返回数据的字节数等于 count * 2 short[] result new short[count]; for (int i 0; i count; i) { // 高字节在前组合成有符号短整型 result[i] (short)((response[9 i * 2] 8) | response[10 i * 2]); } return result; } private byte[] SendAndReceive(byte[] request) { _stream.Write(request, 0, request.Length); byte[] header new byte[7]; // 先读满7字节MBAP头 ReadFull(header, 7); int length ((header[4] 8) | header[5]) - 1; // 减去单元ID后是剩余字节数 byte[] body new byte[length]; ReadFull(body, length); return header.Concat(body).ToArray(); } private void ReadFull(byte[] buffer, int length) { int offset 0; while (offset length) { int bytesRead _stream.Read(buffer, offset, length - offset); if (bytesRead 0) { // 对端关闭连接说明 PLC 可能重启或网线断开 throw new IOException(PLC连接被关闭); } offset bytesRead; } }这段代码有几个关键点值得细说。第一响应校验不要只读一次——TCP 是字节流协议一次Read调用返回的数据量不保证等于请求的数据量必须用ReadFull循环读满。第二解析响应时先读 MBAP 头通过 Length 字段知道后续还要读多少字节。第三PLC 返回的寄存器数据是有符号短整型的如果 PLC 侧存的是无符号数比如 0~65535 的范围需要把解析结果强转成ushort。3.4 写多寄存器功能码 0x10的字节序坑写多寄存器比读稍微复杂一点因为请求帧里要包含写入的字节数和数据本身public void WriteMultiRegisters(byte unitId, ushort startAddress, short[] values) { int dataLen 5 values.Length * 2; byte[] data new byte[dataLen]; data[0] (byte)(startAddress 8); data[1] (byte)(startAddress 0xFF); data[2] (byte)((values.Length 8) 0xFF); data[3] (byte)(values.Length 0xFF); data[4] (byte)(values.Length * 2); // 字节数 for (int i 0; i values.Length; i) { data[5 i * 2] (byte)(values[i] 8); data[6 i * 2] (byte)(values[i] 0xFF); } // 组装请求并发送... }这里最容易出的问题就是字节序。values[i] 8是取高字节这是在 Modbus 协议的大端序要求下做的如果你像写普通二进制文件一样直接BitConverter.GetBytes得到的是低字节在前PLC 解析出来的数据就是错乱的。建议把这个字节序转换抽成独立方法哪怕多写几行也值得——我见过有同事在每个写方法里都做一遍转换结果有的地方转反了排查了一个下午。4. C# 实现 Modbus RTUCOM 口通讯的关键机制4.1 SerialPort 参数配置与串口打开COM 口通讯比 TCP 麻烦在物理层。波特率、数据位、停止位、校验位任何一项和 PLC 侧不一致通讯就建立不起来。常见的 PLC 串口参数组合是 9600-8-N-19600 波特率、8 数据位、无校验、1 停止位但不同品牌可能不一样比如有的老设备用偶校验。using System.IO.Ports; public class ModbusRtuClient : IDisposable { private SerialPort _serialPort; public bool Open(string portName, int baudRate 9600, Parity parity Parity.None, int dataBits 8, StopBits stopBits StopBits.One) { _serialPort new SerialPort(portName) { BaudRate baudRate, Parity parity, DataBits dataBits, StopBits stopBits, ReadTimeout 1000, // 毫秒 WriteTimeout 1000 }; try { _serialPort.Open(); return _serialPort.IsOpen; } catch (UnauthorizedAccessException) { // COM口被其他程序占用比如PLC编程软件在线监控未关闭 throw new Exception($COM口 {portName} 被占用请关闭占用程序后重试); } catch (IOException ex) { // 可能是USB转串口驱动没装好 throw new Exception($COM口 {portName} 打开失败请检查驱动: {ex.Message}); } } }UnauthorizedAccessException是 COM 口开发里最常见的异常——调试的时候开了西门子博途或者三菱 GX Works 的在线监控COM 口就被占用了。另外用 USB 转串口线时设备管理器中看到的 COM 口号可能每次不一样高版本的 Windows 里可以在设备管理器里把 USB 转串口设备的 COM 口号固定下来省得每次插拔后重配置。4.2 CRC16 校验的查表法与逐位计算法对比RTU 模式没有以太网层的兜底差错控制全靠帧尾的 CRC16 校验。CRC 算法从起始地址到数据区结束逐字节计算多项式是0xA001。实现有两种逐位计算和查表法。逐位计算代码直观适用于理解算法查表法效率高适用于频繁通讯的场景。public static ushort CalcCRC16(byte[] data, int start, int length) { ushort crc 0xFFFF; for (int i start; i start length; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) { crc (ushort)((crc 1) ^ 0xA001); } else { crc 1; } } } // CRC低字节在前 return crc; }注意最后一行注释Modbus RTU 报文里的 CRC 是低字节在前发送的和协议里其他字段的大端序不同。也就是说先放入 CRC 的低 8 位再放高 8 位。这个细节用串口抓包工具一对比就能看出来写代码时容易出错。4.3 帧间隔与粘包处理——串口通讯的灵魂串口是字节流没有 TCP 那样的消息边界所以必须自己规定“一帧结束”的标准。Modbus RTU 协议规定帧内字节间隔不能超过 3.5 个字符时间超过就认为一帧结束了。这个时间在 9600 波特率下大约是 4 毫秒在 115200 波特率下不到 1 毫秒。Windows 不是实时操作系统用精确定时器去卡这个时间不现实实际开发中主流做法有两种一种是把SerialPort.DataReceived事件配合BytesToRead判断等串口缓冲区的字节数稳定后再读取另一种是启动一个计时器每次收到字节就重置计时器计时器到期表示一帧收完了。第二种更稳我一般用System.Threading.Timer做private Timer _frameTimer; private readonly object _lockObj new object(); private Listbyte _receiveBuffer new Listbyte(); private void InitFrameTimer() { // 收到字节后重置计时器间隔按波特率自适应 int timeout CalculateTimeout(); // 比如9600波特率时给20ms _frameTimer new Timer(_ OnFrameTimeout(), null, Timeout.Infinite, Timeout.Infinite); _serialPort.DataReceived OnDataReceived; } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { lock (_lockObj) { int count _serialPort.BytesToRead; byte[] buffer new byte[count]; _serialPort.Read(buffer, 0, count); _receiveBuffer.AddRange(buffer); _frameTimer.Change(timeout, Timeout.Infinite); // 重置计时器 } } private void OnFrameTimeout() { byte[] frame; lock (_lockObj) { frame _receiveBuffer.ToArray(); _receiveBuffer.Clear(); } ProcessFrame(frame); // 解析帧、校验CRC、匹配事务 }Timer.Change(timeout, Timeout.Infinite)的作用是每次触发后自动停止计时收到新数据再重新启动。这样即使 PLC 分多次返回数据也能完整拼装成一帧再处理。CalculateTimeout的计算方式是3.5 个字符时间 * 11 位起始位 8 数据位 可能 1 校验位 停止位/ 波特率然后乘一个安全系数。比如 9600 波特率算出来大约 4ms我一般取 20ms 作为兜底因为 Windows 的线程调度抖动可能超过几个毫秒。4.4 发送接收的超时与异常分支处理串口通讯比 TCP 更容易出问题的地方是发出请求后可能没有响应。PLC 没收到消息、PLC 正忙、CRC 校验失败、要读的寄存器越界任何一个环节出错结果都是“没响应”。所以发送时序通常这样安排public byte[] SendAndReceive(byte[] request) { lock (_lockObj) { // 清空缓存避免读到上一次残留数据 _receiveBuffer.Clear(); _serialPort.Write(request, 0, request.Length); // 计时器在OnFrameTimeout里触发响应处理 // 用ManualResetEventSlim等待响应或超时 if (!_responseReceived.WaitOne(responseTimeout)) { throw new TimeoutException(PLC响应超时); } return _lastResponse; } }注意lock是必要的——串口通讯是半双工同一时刻只能有一个请求在等响应。如果不加锁多个线程同时调用读写方法响应会串帧这是串口调试中最让人头疼的问题。WaitOne的超时时间一般给 300~1000msPLC 的程序扫描周期通常小于 20ms300ms 足够从容如果现场通讯负载很高可以放宽到 1000ms但超过这个值还没响应基本可以判定链路或 PLC 出了问题。5. 通讯不上时的排查顺序与一个调试技巧5.1 三层定位物理层、协议层、数据层通讯不上时先不要急着改代码。我自己的排查顺序是固定的三层第一层看物理链路。TCP 模式测试从站电脑上ping PLC的IP能通说明网络通注意 Windows 防火墙可能拦截 502 端口需要放行。串口模式看设备管理器里 COM 口号是否正常、用串口调试工具加回显测试确保线路没断路。第二层看参数匹配。TCP 模式确认端口号很多 PLC 的 Modbus TCP 端口被改过串口模式逐项确认波特率、数据位、停止位、校验位和 PLC 侧完全一致。第三层看数据内容。用 Modbus Poll 这类工具或者自己写个简单的调试帧把请求报文打出来先单帧发送看 PLC 有没有响应。有一个判断技巧很实用如果 CRC 算错PLC 会直接丢弃报文不回任何响应。所以“完全没响应”和“回错误码”是两类问题——前者大概率是物理层、参数、CRC 的问题后者说明链路通了是协议或地址的问题。5.2 串口通讯的震动探针技巧用返回值反推数据调试串口通讯时我最常用的技巧是在DataReceived事件里打印一条日志记录每次收到的字节数和原始十六进制数据private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { int count _serialPort.BytesToRead; byte[] buffer new byte[count]; _serialPort.Read(buffer, 0, count); _receiveBuffer.AddRange(buffer); _frameTimer.Change(GetTimeout(), Timeout.Infinite); // 调试日志打印每次原始数据 Debug.WriteLine($[RX] 本次 {count} 字节: {BitConverter.ToString(buffer)}); }用BitConverter.ToString(buffer)打印十六进制字符串配合发送方打印[TX]日志就能在输出窗口看到一帧完整的请求和响应。如果响应帧的数据长度和你预期的不一致检查byteCount字段对应的值如果长度对但数值不对优先怀疑字节序再做一次高字节和低字节互换测试就能验证。这个方法在处理那些“数据时好时坏”的问题时尤其有效。串口通讯的间歇性故障很难抓现场日志会告诉你到底哪次请求没有响应、哪次响应被拆成了两段、哪次 CRC 对不上——定位到具体环节你就知道下一步该检查的是线路稳定性、波特率误码还是程序里的帧拼装逻辑了。本文还有配套的精品资源点击获取