简介该资源是一套面向C#开发人员与工业自动化工程师的ModbusTcp通信实战工程以西门子1200 PLC为对象演示了从Socket底层通信到NModbus库调用的完整路径。压缩包共46个文件13个cs源码文件与sln/csproj工程文件构成主体配合exe可执行程序、pdb调试符号及xml配置便于直接编译运行与二次修改另有3个zip压缩包存放辅助测试内容整体13.02MB结构清晰。目前已有4313人学习下载。通过这份资料读者可以掌握ModbusTcp八种常用功能码的实际用法理清PLC的I/Q/寄存器地址映射关系并了解超时、断线重连等网络异常处理思路适合需要快速落地工业以太网通信项目或准备相关自动化开发工作的技术人员。1. 用 C# 走 ModbusTcp 读西门子 S7-1200PLC一份能直接改的上位机通讯方案做产线数据采集的人大概率遇到这种场景上位机要实时读 S7-1200 PLC 里的电机电流、温控仪回传温度、当班产量数据量不大但要求刷新快、部署简单。对面设备不支持 OPC UA走 S7 协议又要引入底层驱动这时候 ModbusTcp 就成了性价比最高的方案——协议公开、实现简单、PLC 侧只需调用两个指令块。这份 C# 工程提供的就是一个基于 ModbusTcp 协议的客户端封装覆盖读保持寄存器、写线圈、写多个寄存器这类常用操作专为西门子 S7-1200 PLC 场景设计。适合两类人刚接手上位机开发、需要把 PLC 数据接进 WinForm 或 Web 的新手以及已经在用第三方商业控件、想换成开源方案省掉授权费的熟手。2. 整体方案从 MBAP 报文到工程分层先把通讯链路看清2.1 技术选型为什么选 ModbusTcp 而不是 OPC UA 或 S7 协议做 PLC 通讯选型时OPC UA、S7 协议、ModbusTcp 这三条路我都走过简单对比如下方案优势劣势适用场景OPC UA跨平台、安全模型完善、信息建模能力强配置复杂客户端 SDK 体积大服务端和客户端版本匹配常出问题大型自动化系统、跨厂区数据整合S7 协议原生西门子协议能访问全部数据区效率高协议不公开通常依赖第三方驱动许可证是不小的开销西门子生态内深度集成ModbusTcp协议完全公开任意语言几十行就能实现无授权数据类型简单复杂结构需要自己拼装解析轻量采集、MES 对接、快速交付我在这份工程里选 ModbusTcp核心理由是它把复杂度控制在了能看懂、能改、能排错的范围内。PLC 侧只需要调用 TIA Portal 指令库里的 MB_SERVER 块把数据区映射出来上位机这边不管是 C#、Python 还是 Node.js套同一个报文格式就能通讯。相比 OPC UA 那套 UA 模型和证书体系ModbusTcp 的排障链路短得多——出了问题抓包一看就知道是哪一端的毛病。至于实现方式我见过两种主流做法一种是直接用社区维护的开源库 NModbus4把 TCP 连接和功能码封装都省掉另一种是自己用 TcpClient 拼报文。这份工程走的是后者因为自己拼报文能把协议细节完全握在自己手里PLC 型号换了、字节序改了改的都是看得见的代码而不是去翻库的源码。后面章节的报文拆解和核心代码都是基于裸报文实现理解了这套用 NModbus4 也只是换个 API 壳的事。2.2 ModbusTcp 报文MBAP 头加 PDU一条请求就 12 个字节ModbusTcp 请求帧由 MBAP 头7 字节和 PDU功能码加数据组成。MBAP 头固定四段字段长度说明事务元标识符2 字节客户端自增编号用于匹配请求和响应协议标识符2 字节固定 0x0000表示 Modbus 协议长度2 字节后面所有字节数即单元标识符加 PDU 的长度单元标识符1 字节相当于从站地址多设备组网时区分目标默认 1PDU 里最关键的是功能码。读写 S7-1200 最常用的几个03 读保持寄存器、06 写单个寄存器、16 写多个寄存器、05 写单个线圈。拿从地址 0 开始读 2 个保持寄存器举例完整请求是00 01 00 00 00 06 01 03 00 00 00 02逐个字段拆00 01是事务标识符00 00是协议标识符00 06表示后面还有 6 个字节01是单元标识符03是功能码00 00是起始地址00 02是寄存器数量。对端正常响应会原样带回事务标识符数据区跟在功能码后面。这个 12 字节的请求格式几乎包含了后续所有代码的拼装逻辑理解它再看核心模块会快很多。2.3 工程目录与分层协议、转换、点位三层各管各的ModbusTcpDemo/ ├─ Program.cs // 控制台入口演示读写流程 ├─ ModbusTcpClient.cs // TCP 连接建立、报文收发、读写封装 ├─ ModbusDataConverter.cs // 字节序转换、寄存器到浮点/整型的解析 ├─ PlcPoint.cs // 点位模型名称、地址、数据类型、缩放系数 └─ appsettings.json // PLC 的 IP、端口、从站号、超时时间这个分层是我反复改过之后的稳定结构。ModbusTcpClient 只管协议层拼请求、收响应、处理事务 ID。ModbusDataConverter 单独拎出来是因为字节序是个大坑——S7-1200 的数据在 Modbus 报文里是 Big-Endian而 .NET 的 BitConverter 默认按小端解析这两个必须在一个独立类里做统一转换。PlcPoint 是点位抽象把地址 4 是温度这类业务从协议代码里剥离出来后面改点位表不用动通讯代码。跑的时候从 appsettings.json 读配置换 PLC 改配置文件就行不用重新编译。这套结构的好处是边界清楚协议出问题查 ModbusTcpClient数值不对查 ModbusDataConverter点位对不上查配置文件。我做排障的时候基本都是按这个顺序查比堆在一个类里快得多。3. 核心模块拆解一次读请求从发出到拿到真实工程量3.1 连接管理与超时不能让 UI 卡在等待上PLC 不在线是常态连接这一步必须做超时控制。常见做法是直接用 TcpClient.Connect但那会阻塞当前线程严重时界面无响应。我一般用 BeginConnect 加 WaitOne 的组合public class ModbusTcpClient : IDisposable { private TcpClient _tcpClient; private readonly string _ip; private readonly int _port; private readonly int _timeoutMs; public ModbusTcpClient(string ip, int port, int timeoutMs 2000) { _ip ip; _port port; _timeoutMs timeoutMs; } public bool Connect() { _tcpClient new TcpClient(); var asyncResult _tcpClient.BeginConnect(_ip, _port, null, null); if (!asyncResult.AsyncWaitHandle.WaitOne(_timeoutMs)) { _tcpClient.Close(); throw new TimeoutException($连接 {_ip}:{_port} 超时); } _tcpClient.EndConnect(asyncResult); return _tcpClient.Connected; } public bool IsConnected _tcpClient?.Connected ?? false; public void Dispose() { _tcpClient?.Close(); _tcpClient?.Dispose(); } }BeginConnect 发起异步连接后WaitOne 最多等 _timeoutMs 毫秒超时直接抛异常并关闭资源。这里的思路是上层调用方只关心连上了或者超时了两个结果不需要知道底层是同步还是异步。timeoutMs 默认 2 秒现场如果 PLC 响应慢我一般调到 5 秒太短会误判太长又影响轮询节奏。3.2 读保持寄存器手动拼 12 字节请求再手动拆响应读操作是上位机和 PLC 打交道最频繁的动作。功能码 03 读保持寄存器对应 S7-1200 里 MB_SERVER 组态的保持区通常指向一个 DB 块。下面这段是手拼报文的完整实现public ushort[] ReadHoldingRegisters(byte slaveId, ushort startAddress, ushort count) { var request new byte[12]; request[0] 0x00; // 事务标识符高字节 request[1] 0x01; // 事务标识符低字节简单场景固定 1 request[2] 0x00; // 协议标识符 request[3] 0x00; request[4] 0x00; // 长度高字节 request[5] 0x06; // 长度 单元标识符1 功能码1 起始地址2 数量2 request[6] slaveId; request[7] 0x03; // 功能码 03 读保持寄存器 request[8] (byte)(startAddress 8); request[9] (byte)(startAddress 0xFF); request[10] (byte)(count 8); request[11] (byte)(count 0xFF); Send(request); var response Receive(); // 响应结构MBAP 7字节 功能码1 字节数1 数据N if (response[7] ! 0x03) throw new InvalidOperationException($功能码异常: 0x{response[7]:X2}); var byteCount response[8]; var data new ushort[count]; for (int i 0; i count; i) { // 大端拼装每个寄存器两个字节高字节在前 data[i] (ushort)((response[9 i * 2] 8) | response[10 i * 2]); } return data; }事务标识符在单线程请求里可以固定但多线程轮询时必须每次自增否则响应匹配不上。起始地址和数量都是大端序用移位和按位与来拼装比 BitConverter 更直观。count 有协议上限一次最多读 125 个寄存器超过了 PLC 会回异常码这也是后面避坑章节要讲的重点之一。响应数组里第 7 个字节是功能码第 8 个是数据字节数真正的数据从第 9 字节开始按每两个字节一个寄存器解析。3.3 类型转换两个寄存器拼一个浮点字节序在这里翻车率最高Modbus 寄存器是 16 位无符号整型工厂里的温度、压力、流量基本都是 32 位浮点一个浮点要占两个寄存器。S7-1200 在 Modbus 映射里遵循 Big-Endian即高字在前。这个转换函数是踩坑后的标准写法public static float ReadFloat(ushort[] registers, int offset) { // 西门子 Big-Endian 顺序registers[offset] 是高字 byte[] bytes new byte[4]; bytes[0] (byte)(registers[offset] 8); bytes[1] (byte)(registers[offset] 0xFF); bytes[2] (byte)(registers[offset 1] 8); bytes[3] (byte)(registers[offset 1] 0xFF); // .NET 运行在小端机器上手动整体反转 if (BitConverter.IsLittleEndian) Array.Reverse(bytes); return BitConverter.ToSingle(bytes, 0); }先按大端把两个寄存器铺成四个字节再检测当前机器字节序小端就整体反转最后交给 BitConverter。这个先拼大端再反转的写法比逐字节交换清晰得多。如果读出来的浮点值是 3.7e-38 这种天文数字十有八九是字节序没处理把反转去掉试试就能验证。同理还有 ReadInt32、ReadInt16思路一致只是字节宽度不同。3.4 写操作写线圈和写多个寄存器的报文细节写操作比读操作更容易在细节上翻车。写单个线圈时协议规定 ON 必须是 0xFF00OFF 是 0x0000写成 0x01 会被 PLC 拒绝。写多个寄存器时长度字段要自己算这是新手最容易算错的地方public void WriteSingleCoil(byte slaveId, ushort address, bool value) { var request new byte[12]; request[0] 0x00; request[1] 0x02; request[2] 0x00; request[3] 0x00; request[4] 0x00; request[5] 0x06; request[6] slaveId; request[7] 0x05; // 功能码 05 request[8] (byte)(address 8); request[9] (byte)(address 0xFF); request[10] value ? (byte)0xFF : (byte)0x00; // 必须用 FF00/0000 request[11] 0x00; Send(request); var response Receive(); } public void WriteMultipleRegisters(byte slaveId, ushort startAddress, ushort[] values) { int byteCount values.Length * 2; var request new byte[9 byteCount]; request[0] 0x00; request[1] 0x03; request[2] 0x00; request[3] 0x00; request[4] (byte)((5 byteCount) 8); // 长度 单元1 功能码1 地址2 数量2 字节数1 数据 request[5] (byte)((5 byteCount) 0xFF); // 即 5 byteCount request[6] slaveId; request[7] 0x10; // 功能码 16 request[8] (byte)(startAddress 8); request[9] (byte)(startAddress 0xFF); request[10] (byte)(values.Length 8); request[11] (byte)(values.Length 0xFF); request[12] (byte)byteCount; for (int i 0; i values.Length; i) { request[13 i * 2] (byte)(values[i] 8); request[14 i * 2] (byte)(values[i] 0xFF); } Send(request); var response Receive(); }写多个寄存器时报文长度是 9 加数据字节数其中5是单元标识符、功能码、起始地址、数量、字节数这 5 个固定字节。数据区里每个寄存器同样是高字节在前。写完最好读回校验尤其写的是设备参数而不是临时控制位时写错会直接影响现场设备动作。4. 跑起来从 NuGet 还原到 PLC 侧组态的一次完整联调4.1 工程环境与依赖引入这份工程是 .NET 控制台项目用命令行就能跑dotnet new console -n ModbusTcpDemo cd ModbusTcpDemo dotnet add package NModbus4 dotnet restore我自己调试时首选控制台而不是 WinForm原因是控制台启动快、日志输出直接适合先验证连通性和数据正确性。通讯逻辑在控制台里跑通后再把它搬进 WinForm 或 Web API 也不迟。如果你跟着这份工程的裸报文实现来连 NModbus4 都不需要引一个 TcpClient 加一个 Socket 收发就够了NuGet 依赖反而更少。4.2 PLC 侧需要完成的两处配置C# 代码再正确PLC 侧没放行也是白搭。S7-1200 对接 ModbusTcp 有两个必做配置第一在 CPU 属性的保护设置里勾选允许来自远程对象的 PUT/GET 通信访问。不勾这个上位机的 TCP 连接能建立但读写请求会被 CPU 静默丢弃表现就是超时无响应。第二在 OB1 里调用 TIA Portal 指令库的 MB_SERVER 指令块。关键参数如下参数配置值说明DISCONNECT常亮 FALSE使能服务器监听IP_PORT502ModbusTcp 标准端口MB_HOLD_REG指向 DB 块保持寄存器映射的数据区推荐单独建一个 DBMB_HOLD_REG_SYM对应 DB 符号名勾选符号访问后自动绑定MB_SERVER 块会把 PLC 里的 DB 数据映射成 Modbus 保持寄存器地址地址偏移从 0 开始。比如把 DB10 映射到 MB_HOLD_REG上位机读保持寄存器起始地址 0读到的就是 DB10 的第一个字。这个映射关系是联调时最容易对不上的点最好在 PLC 程序里加个注释写明地址 0 对应 DB10.DBW0。4.3 最小可运行示例读一个浮点数到控制台配置完成后一段最小代码就能验证整条链路var client new ModbusTcpClient(192.168.0.1, 502, 3000); client.Connect(); // 从保持寄存器地址 0 开始读 2 个寄存器拼成一个浮点 ushort[] regs client.ReadHoldingRegisters(1, 0, 2); float temperature ModbusDataConverter.ReadFloat(regs, 0); Console.WriteLine($温度 {temperature:F2} ℃); client.Dispose();slaveId 传 1对应 MB_SERVER 默认的单元标识符如果 PLC 侧组态里改过这里必须同步。startAddress 传 0对应映射 DB 的起始偏移。读 2 个寄存器是因为浮点占 32 位。执行后如果控制台能打印出和 PLC 监控表里一致的温度值说明连接、报文、字节序三关都过了打印出天文数字直接去检查字节序超时先去查 PLC 的 PUT/GET 和 MB_SERVER 配置。5. 避坑指南字节序、单元标识符、连接复用一次讲完5.1 浮点数读出来是天文数字现象读回来的浮点值是 3.7e-38 或 1.2e-41 这种明显不合理的数而 PLC 监控表里显示的是正常的 25.3。原因字节序反了。S7-1200 的浮点在 Modbus 报文里是高字在前而 .NET 的 BitConverter 默认按小端解析。如果转换函数没有做字节反转两个寄存器的字节顺序就是反的解析出的浮点自然离谱。解决转换函数里先按大端把寄存器拼成字节数组再检测BitConverter.IsLittleEndian为 true 就执行Array.Reverse。改完之后用 PLC 监控表里的已知值验证确认没问题再往下写业务逻辑。5.2 请求发出后一直超时无响应现象TCP 连接建立成功但 Send 后 Receive 一直卡到超时。原因最常见的是 PLC 侧没勾选允许来自远程对象的 PUT/GET 通信访问CPU 直接丢弃了请求其次是单元标识符不匹配MB_SERVER 里组态的从站号和上位机请求里的 slaveId 不一致。解决先在电脑上 ping PLC 的 IP 确认网络通再确认 CPU 属性里 PUT/GET 已勾选最后用 Modbus 调试工具比如 Modbus Poll读同样的地址如果工具能读而上位机不能对比工具发报文的单元标识符和功能码大概率能定位差异。5.3 读多几次后 PLC 拒绝连接现象程序前三轮读写正常第四轮开始 Connect 超时或直接报异常重启程序后又正常。原因TcpClient 没有释放Socket 资源被耗尽S7-1200 的 Modbus 服务器连接数有上限连接不关闭就占着名额。解决用完调用Dispose()关闭底层 Socket。更稳的做法是设计成长连接整个程序生命周期只建一次连接配合心跳检测断开才重连而不是每次读写都新建和销毁连接。5.4 地址对不上人机界面显示 40001代码里却是 0现象PLC 监控表或触摸屏显示保持寄存器地址 40001代码里填的也是 40001但读回来的数据是错的。原因Modbus 协议地址从 0 开始编号而工业 HMI 习惯从 1 显示40001 在协议里实际是地址 0。二者差了一个偏移量。解决代码里统一使用协议地址也就是界面显示值减 1。在点位配置文件里注释清楚界面 40001 协议 0避免后续维护的人被这个偏移量搞晕。5.5 一次读超过 125 个寄存器被 PLC 拒绝现象功能码 03 的请求返回异常码 02Illegal Data Address单个请求读 200 个寄存器时必现。原因Modbus 协议规定读保持寄存器单次最多 125 个读线圈单次最多 2000 个。超出上限PLC 直接拒绝。解决把大块读取拆成多个小请求循环读取再拼接。读取前先算好总寄存器数按 125 一个批次分片。这个逻辑建议封装成ReadHoldingRegistersAll方法内部循环调ReadHoldingRegisters调用方不需要关心分片细节。提示以上五条是我在真实联调里踩过的坑前三条几乎每个做 ModbusTcp 对接的人都躲不掉。调试阶段建议用抓包工具看一眼实际收发的报文比盯着代码猜快得多。6. 二次开发把通讯代码重构成带点位表的数据采集服务6.1 点位表驱动不硬编码地址配置说话原始代码里读温度是ReadHoldingRegisters(1, 0, 2)读压力又是ReadHoldingRegisters(1, 4, 2)地址散落在各处。我一般会引入点位表模型public class PlcPoint { public string Name { get; set; } // 点位名如 一号炉温 public int Address { get; set; } // 协议地址从 0 开始 public string DataType { get; set; } // Float / Int16 / UInt16 / Bool public double Scale { get; set; } 1.0; // 工程量缩放系数 } // 从 JSON 读取点位表 var points JsonSerializer.DeserializeListPlcPoint(File.ReadAllText(points.json)); foreach (var point in points) { ushort[] regs client.ReadHoldingRegisters(1, (ushort)point.Address, 2); float raw ModbusDataConverter.ReadFloat(regs, 0); double value raw * point.Scale; Console.WriteLine(${point.Name} {value}); }点位表的收益是新增点位只改 JSON不动代码。设备参数、量程、报警阈值都可以塞进 PlcPoint 里扩展。我接 MES 的时候就是这么干的MES 要什么点位配置里加一行就行。6.2 异步轮询与断线重连采集服务不能跑一次就退出需要一个循环。我常用的模式是异步轮询加异常重连private async Task PollLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { try { if (!client.IsConnected) client.Connect(); ReadAllPoints(); // 按点位表循环读取 } catch (Exception ex) { Log.Error(ex, 轮询异常5 秒后重连); client.Dispose(); await Task.Delay(5000, token); } await Task.Delay(1000, token); // 1 秒轮询间隔 } }Try 住整个读取循环异常说明连接断了直接 Dispose 旧连接等 5 秒重新 Connect。轮询间隔按现场要求调一般设备参数 1 秒足够温度这类慢变量 2 到 3 秒也行。6.3 值变化通知让 UI 和 MES 订阅轮询拿到的值每次都抛给上层会显得太吵常见做法是缓存上次值变化了才触发public event EventHandlerPlcPointValue ValueChanged; private Dictionarystring, double _lastValues new(); public void ReadAllPoints() { foreach (var point in _points) { double value ReadPoint(point); if (Math.Abs(value - _lastValues.GetValueOrDefault(point.Name)) 0.001) { _lastValues[point.Name] value; ValueChanged?.Invoke(this, new PlcPointValue(point.Name, value)); } } }UI 层只订阅ValueChanged事件每收到一次就刷新对应文本框MES 集成时把事件转成消息推送架构也不用变。这套从裸报文到事件驱动的完整重构让通讯代码从能跑的 Demo变成了能用进产线的采集服务。做这个项目最大的教训是协议层的代码看着简单但字节序、地址偏移、单元标识符这些细节每一个都能让人排查半天。从那以后我每次联调 PLC 都会先抓包确认报文格式再逐条对照协议文档验证最后才写业务逻辑这个习惯帮我避开了不少暗坑。希望帮到你。本文还有配套的精品资源点击获取