简介：这是一套面向工业自动化工程师、物联网开发者及高校学生的PLC上位机程序源码，基于工业标准Modbus TCP协议开发，采用C#实现，可支持与多种品牌PLC通信，解决设备数据读写、实时监控与异常报警等上位机通讯需求。资源包共56个文件，约641KB，以cs源码文件为核心，配合json、xml、config等配置与数据文件，以及dll依赖库、resx资源文件和sln、csproj工程文件，整体结构清晰，便于在Visual Studio中直接打开与二次开发。源码附带详细注释及使用文档，涵盖Modbus TCP通讯封装、界面交互与业务逻辑分层，读者可据此快速理解协议实现思路，掌握上位机与PLC通讯的完整流程，并在此基础上扩展报警、监控等功能。目前已有100人学习下载，适合作为工业自动化与物联网方向的实战参考。

1. 从一根网线到稳定采集：Modbus TCP 上位机到底解决什么问题

车间里一台 PLC 跑着产线逻辑，工艺工程师想在中控室电脑上实时看数据、存历史、导出报表，最省事的路径往往不是上 SCADA，而是自己写一个 C# 上位机。标题里的「基于 Modbus TCP 协议的 PLC 上位机程序源码（C# 实现，含详细注释）」，说的就是这件事：用 C# 通过 Modbus TCP 跟 PLC 建立连接，周期性读写寄存器，把设备运行状态落到界面上。它适合两类人——刚接触上位机开发、想找一个能跑通的完整骨架的工程师，以及手里有 FX5U、S7-200 Smart、汇川等支持 Modbus TCP 的设备、需要快速做数据采集原型的从业者。核心难点不在协议本身，而在连接管理、寄存器映射和异常重连这三件事上，源码的价值也正在于此。

2. Modbus TCP 报文结构与 C# 侧的最小实现路径

2.1 为什么选 Modbus TCP 而不是 OPC UA

在动手写代码之前，先把选型理由说清楚，否则后面调参数会没有方向。Modbus TCP 和 OPC UA 都能读 PLC 数据，但两者的落地成本差别很大。OPC UA 有完整的信息模型、订阅机制和安全策略，适合跨厂商、跨层级的大型系统，代价是需要 OPC Server 或设备原生支持，配置项多，调试链路长。Modbus TCP 则是「裸协议」：一条 TCP 连接，一段固定结构的报文，没有会话协商，没有证书，PLC 侧通常只要在组态里勾选「Modbus TCP 从站」并分配寄存器地址就能用。

对于单台或少量 PLC、采集点位在几百个以内的上位机，Modbus TCP 的性价比明显更高。它的报文结构固定，头部 7 字节 MBAP（事务标识 2 字节、协议标识 2 字节、长度 2 字节、单元标识 1 字节），后面跟 PDU（功能码 1 字节 + 数据）。读保持寄存器用功能码 0x03，写单个寄存器用 0x06，写多个用 0x10。理解这 7 字节头部，是后面排查「连上了但读不到数」的关键。

常见做法是用现成的库，比如 NModbus4 或 FluentModbus，它们把报文封装好了。但标题强调「源码 + 详细注释」，我一般会建议至少手写一遍报文拼装和解析，这样出问题时你能看懂抓包结果。下面这段是最小可运行的读保持寄存器实现，不依赖第三方库。

// 手写 Modbus TCP 读保持寄存器（功能码 0x03） // 参数：ip PLC地址，port 502，slaveId 单元标识，startAddr 起始寄存器，count 寄存器数量 public static ushort[] ReadHoldingRegisters(string ip, int port, byte slaveId, ushort startAddr, ushort count) { using (var client = new TcpClient()) { // 连接超时单独控制，避免默认 20 秒卡死界面 var ar = client.BeginConnect(ip, port, null, null); if (!ar.AsyncWaitHandle.WaitOne(TimeSpan.FromSeconds(3))) throw new TimeoutException($"连接 {ip}:{port} 超时"); client.EndConnect(ar); var stream = client.GetStream(); stream.ReadTimeout = 2000; stream.WriteTimeout = 2000; // 组装 MBAP 头 + PDU var frame = new byte[12]; frame[0] = 0x00; frame[1] = 0x01; // 事务标识，可自增 frame[2] = 0x00; frame[3] = 0x00; // 协议标识，Modbus 固定 0 frame[4] = 0x00; frame[5] = 0x06; // 后续字节数 = 6 frame[6] = slaveId; // 单元标识 frame[7] = 0x03; // 功能码 frame[8] = (byte)(startAddr >> 8); // 起始地址高字节 frame[9] = (byte)(startAddr & 0xFF);// 起始地址低字节 frame[10] = (byte)(count >> 8); // 数量高字节 frame[11] = (byte)(count & 0xFF); // 数量低字节 stream.Write(frame, 0, frame.Length); // 响应：MBAP 7 字节 + 功能码 1 + 字节数 1 + 数据 var header = new byte[9]; int read = 0; while (read < 9) read += stream.Read(header, read, 9 - read); if (header[7] != 0x03) throw new Exception($"异常响应，功能码=0x{header[7]:X2}，异常码=0x{header[8]:X2}"); int dataLen = header[8]; var data = new byte[dataLen]; read = 0; while (read < dataLen) read += stream.Read(data, read, dataLen - read); var result = new ushort[count]; for (int i = 0; i < count; i++) result[i] = (ushort)((data[i * 2] << 8) | data[i * 2 + 1]); return result; } }

这段代码的逻辑分四步：建连接、拼请求、读响应头、解析数据。参数上要特别注意三点。第一，slaveId在 Modbus TCP 里通常填 1，但部分网关设备要求填 0xFF 或实际站号，填错会返回异常码 0x0B（网关目标设备无响应）。第二，startAddr是协议地址，不是 PLC 组态里的软元件编号，比如三菱 FX5U 的 D100 在 Modbus 映射表里往往对应 4100 之类的偏移，必须查设备手册的映射表。第三，count单次不要超过 125，超过会返回异常码 0x03（数据值非法），需要分批读。

2.2 寄存器地址映射：从 PLC 软元件到协议地址

地址映射是新手翻车最多的地方。PLC 厂商的软元件命名（D、M、X、Y、DB 块）和 Modbus 的四种寄存器（线圈、离散输入、输入寄存器、保持寄存器）不是一一对应的，中间隔着一张映射表。以常见设备为例，映射关系大致如下。

注意表里的 40001 是「文档地址」，实际报文里要减 1 变成 0。很多库的 API 直接收 0 基地址，也有库收 1 基地址，混用就会出现「读到的值整体偏移一个寄存器」的玄学现象。我的习惯是：在配置文件里统一存 0 基地址，界面上显示时再加 1，避免来回换算。

对于西门子 S7-200 Smart 这类设备，要特别注意它并不原生支持 Modbus TCP，需要通过指令库做 Modbus TCP 服务器映射，或者加网关模块。热词里提到的「西门子 PLC200 不能实现 Modbus TCP 通讯」就是这个原因——S7-200 只有 PPI 和自由口，S7-200 Smart 才带以太网口并支持 Modbus TCP 服务器指令。选型阶段就要确认清楚，否则代码写得再好也连不上。

2.3 用 NModbus4 快速搭出可维护的采集层

手写报文适合理解原理，但生产代码我一般用 NModbus4，省去连接管理和字节序处理的重复劳动。下面是一个带重连的采集封装，重点看连接复用和异常处理。

// 基于 NModbus4 的采集封装，连接复用 + 断线重连 public class PlcClient { private TcpClient _tcp; private IModbusMaster _master; private readonly string _ip; private readonly int _port; private readonly object _lock = new object(); public PlcClient(string ip, int port = 502) { _ip = ip; _port = port; } private void EnsureConnected() { if (_tcp != null && _tcp.Connected) return; lock (_lock) { if (_tcp != null && _tcp.Connected) return; _tcp?.Close(); _tcp = new TcpClient(); _tcp.Connect(_ip, _port); // 生产环境建议用带超时的异步连接 _master = ModbusIpMaster.CreateIp(_tcp); _master.Transport.ReadTimeout = 2000; _master.Transport.WriteTimeout = 2000; _master.Transport.Retries = 2; // 重试 2 次，避免偶发丢包直接报错 } } public ushort[] ReadRegisters(byte slaveId, ushort start, ushort count) { EnsureConnected(); try { return _master.ReadHoldingRegisters(slaveId, start, count); } catch (Exception) { _tcp?.Close(); // 标记连接失效，下次调用自动重连 throw; } } }

这里的关键设计是「连接失效即关闭，下次调用自动重建」，而不是在 catch 里立刻重连。原因是 PLC 断线往往伴随网络抖动，立刻重连容易陷入重连风暴，把 PLC 的连接资源占满。参数上，Retries设 2 比较稳妥，设太大在真断线时会拖长单次采集耗时；ReadTimeout设 2000ms 是经验值，车间网络差可以放宽到 3000ms，但不要超过采集周期，否则会堆积。

3. 上位机界面与采集线程的协作方式

3.1 采集线程与 UI 线程的解耦

上位机最容易出的问题不是协议，而是界面卡死。如果把 Modbus 读写直接放在按钮事件里，一次超时就是 2 秒白屏，操作工以为程序崩了。正确做法是采集跑在后台线程或定时器里，通过队列把数据交给 UI。

// 采集线程：固定周期读取，数据入队 private BlockingCollection<PlcData> _queue = new BlockingCollection<PlcData>(100); private void PollLoop(CancellationToken token) { while (!token.IsCancellationRequested) { var sw = Stopwatch.StartNew(); try { var values = _plc.ReadRegisters(1, 0, 20); _queue.Add(new PlcData { Time = DateTime.Now, Values = values }); } catch (Exception ex) { _queue.Add(new PlcData { Time = DateTime.Now, Error = ex.Message }); } // 固定周期 200ms，扣除本次耗时，避免周期漂移 int wait = 200 - (int)sw.ElapsedMilliseconds; if (wait > 0) Thread.Sleep(wait); } }

队列容量设 100 是防止 UI 卡顿时内存无限增长，满了就丢弃最旧数据。UI 侧用定时器每 100ms 从队列取一批刷新，而不是每来一条刷一次，这样即使采集周期是 200ms，界面也不会频繁重绘。参数上，采集周期要根据 PLC 扫描周期和点位数量定：点位少可以 100ms，点位上百建议 500ms 以上，否则 PLC 的通信负载会明显上升。

3.2 数据落库与历史查询的轻量方案

采集到的数据要存下来才有价值。小规模场景用 SQLite 或 Access 就够，不必上时序数据库。建表时把时间戳和点位值分开存，避免宽表字段爆炸。

-- 历史数据表：按点位存，便于扩展 CREATE TABLE HistoryData ( Id INTEGER PRIMARY KEY AUTOINCREMENT, PointName TEXT NOT NULL, Value REAL, CollectTime DATETIME NOT NULL ); CREATE INDEX idx_point_time ON HistoryData(PointName, CollectTime);

写入时用事务批量提交，每 100 条或每秒提交一次，比逐条插入快一个数量级。查询时按点位和时间范围走索引，界面上的趋势图只查最近一段，不要一次拉全表。这里有个血泪经验：早期我把所有点位塞进一张宽表，后来加一个点位就要改表结构，迁移一次数据花了大半天，改成纵表后再没遇到过这个问题。

4. 避坑与排查：连不上、读不到、值不对怎么办

4.1 连接被拒绝或超时

现象是TcpClient.Connect抛异常或等待超时。原因通常有三个：PLC 的 Modbus TCP 服务器没使能、端口不是 502、防火墙拦了。解决顺序是先 ping 通 PLC 的 IP，再用 telnet 或端口扫描工具确认 502 端口开放，最后检查 PLC 组态里 Modbus 服务器是否勾选、单元标识是否匹配。注意有些设备默认端口是 500 或 8502，不要想当然填 502。

4.2 返回异常码 0x02 或 0x03

现象是响应功能码变成0x83，异常码 0x02 表示地址非法，0x03 表示数据值非法。原因基本是地址映射错了或数量超限。解决方法是查设备手册的 Modbus 地址表，确认起始地址和数量；单次读取数量控制在 125 以内，写多个寄存器控制在 123 以内。如果读的是输入寄存器却用了 0x03 功能码，也会报 0x02。

4.3 读到的值明显不对

现象是数值翻倍、缩小或完全对不上。原因多是字节序和数据类型问题。Modbus 寄存器是 16 位，32 位浮点要占两个寄存器，高低字顺序因设备而异。有的设备高字在前，有的低字在前，还有的字节内部也要交换。解决办法是先用已知值（比如写入 1.0）读回来，看四个字节的排列，再决定是否交换。下面这个转换函数覆盖了常见情况。

// 两个寄存器合成 32 位浮点，swapWords 控制高低字顺序 public static float ToFloat(ushort high, ushort low, bool swapWords) { byte[] bytes = new byte[4]; if (swapWords) { bytes[0] = (byte)(low >> 8); bytes[1] = (byte)(low & 0xFF); bytes[2] = (byte)(high >> 8); bytes[3] = (byte)(high & 0xFF); } else { bytes[0] = (byte)(high >> 8); bytes[1] = (byte)(high & 0xFF); bytes[2] = (byte)(low >> 8); bytes[3] = (byte)(low & 0xFF); } if (BitConverter.IsLittleEndian) Array.Reverse(bytes); return BitConverter.ToSingle(bytes, 0); }

4.4 运行一段时间后连接断开

现象是程序跑几小时后采集全部失败，重启又正常。原因是 PLC 对空闲连接或连接数有限制，长时间不通信会被服务端主动断开，而客户端没感知。解决办法是加心跳，即使没有采集需求也定期读一个寄存器；同时在每次读写失败时关闭连接并重建，不要复用已失效的 socket。另外注意不要频繁创建新连接，每次采集都 new 一个 TcpClient 会快速耗尽 PLC 的连接资源。

4.5 多线程同时读写导致数据错乱

现象是偶发读到别人的响应或异常码。原因是 Modbus 是请求-响应模型，一条连接上同时发多个请求会串包。解决办法是给通信加锁，保证同一连接上同一时刻只有一个请求在途；或者每个线程用独立连接。我一般用一把锁把读写串起来，采集周期 200ms 的情况下完全够用。

5. 把源码改造成能长期运行的生产级采集器

前面几章的代码能跑通，但离「长期无人值守」还差几步。这一章讲三个具体技巧，都是我在现场反复验证过的。

第一个是配置外置。把 IP、端口、单元标识、点位表、采集周期全部写进 JSON 配置文件，程序启动时加载。这样换设备、加点位不用重新编译。点位表建议用数组，每项包含名称、功能码、地址、数据类型、字节序，采集层按配置动态读取。

{ "plc": { "ip": "192.168.1.10", "port": 502, "slaveId": 1, "intervalMs": 200 }, "points": [ { "name": "温度", "func": 3, "addr": 0, "type": "float", "swap": true }, { "name": "运行状态", "func": 1, "addr": 0, "type": "bool" } ] }

第二个是日志分级。通信异常记 Warning，解析异常记 Error，正常采集记 Debug 并限制文件大小。现场排查时，日志里能看到「几点几分哪个点位读失败、异常码多少」，比任何猜测都快。日志按天滚动，保留 7 天即可，避免占满磁盘。

第三个是看门狗。用一个独立线程监控采集线程的最后心跳时间，超过 3 个采集周期没更新就记录并尝试重启采集线程。这个机制能兜住那些「线程卡在某个 socket 读上」的极端情况，是无人值守的最后一道保险。

验证方法上，我习惯用 Modbus Poll 或 Modbus Slave 模拟器先对测，确认地址和数据类型无误，再连真实 PLC。模拟器能构造异常响应，方便测试异常分支。上线前至少跑 24 小时，观察内存和连接数是否稳定。

最后说个习惯：每次现场调试，我都会把抓包结果和配置文件一起存档。下次遇到「同样的代码换个车间就不行」，翻出当时的抓包对比，往往几分钟就能定位是地址映射还是字节序的差异。这套源码骨架不大，但把连接管理、地址映射、异常重连这三块吃透，换成 OPC UA 或别的协议也是同样的思路。希望帮到你。

本文还有配套的精品资源，点击获取