工控上位机开发有一个经常被忽视的分水岭界面做得好只能证明你熟练了 WPF能做上位机意味着你要把设备协议、字节解析、线程调度、状态恢复这些事真正跑通。很多初级工程师卡住的地方往往不是按钮不会写而是程序写完以后——PLC 连不上、寄存器读出来是乱数、程序运行一晚上就断线甚至数据错位到完全不可用。这篇文章要讲的就是从零到一打通这条链路使用 C# 与 .NET 6/.NET 7基于 WPF 和 MVVM 模式手写一个最小可运行的 Modbus TCP 上位机数据采集应用。文章不会绕圈子会直接回答几个实质问题Modbus 报文到底长什么样为什么不能把 Socket 读取代码直接塞进窗口类寄存器数值为什么经常“对不上”以及如何用仿真器在不接 PLC 的情况下验证整个项目。说一句更直接的话WPF 本身并不难难的是把 TCP 收到的字节可靠地变成界面上的数值Modbus 协议也不算难难的是把它组织成一个可以长期运行、便于维护的工程结构。这篇文章完整覆盖这一过程你可以把它当作一份“上位机零基础手写实战”的路线图。1. 为什么用 WPF Modbus 做上位机1.1 上位机到底在做什么很多初学者误以为上位机开发就是“一个人机界面”把思维局限在按钮、表格和曲线图上。实际上在工控语境里上位机通常承担三类工作与下位机PLC、传感器、仪表、变频器、嵌入式板卡等通信采集数据。对采集到的数据做显示、存储、报警判断或者业务计算。向设备下发控制指令例如启停、参数设定、点位写入。所以通信层才是一个上位机项目的底盘。如果一个程序只能通过模拟数据把界面搞得很好看一接到真实设备就现出原形那它还不是一个完整的上位机方案。反过来即便界面朴素只要能稳定采集和下发它已经具备实际交付能力。这就是本文把重心放在 Modbus 通信上的原因通信不稳定界面做得再花哨也没有工程价值。1.2 为什么选 WPF 而不是 WinForms 或 Web在 .NET 技术栈里WinForms 依然有大量存量项目但如果是新启动的上位机项目我更推荐优先考虑 WPF理由有几点WPF 的绑定体系比 WinForms 的控件属性赋值方式成熟天然适合 MVVM。界面与逻辑分离后通信层可以被独立测试而不是和窗口生命周期绑死。WPF 模板、样式和分辨率适配能力明显更强。工控现场最常见的需求是“给客户换一套深色主题”“需要在 1366×768 的老工控机上正常显示”WPF 做这类事情成本比 WinForms 低不少。Web 技术栈例如 Blazor Server / Electron / Web 页面也不是不能做但在工业现场很多时候需要程序直接访问本机串口、网卡、USB 加密狗、第三方 SDK并且要保证断网环境下也能运行。桌面客户端的部署方式仍然更直接。所以对于工控上位机WPF 是一个综合成本很低的选择。1.3 为什么是 ModbusModbus 不是性能最强、功能最丰富的工业协议但它是兼容面最广、可调试性最好、最容易上手的工业协议之一。PLC 支持它变频器支持它温控器支持它很多物联网网关也支持它。在一些项目里哪怕总线上走的是 Profinet、EtherCAT 或 CANopen设备侧仍然会预留 Modbus TCP 或 Modbus RTU 接口用于第三方系统对接。更关键的是Modbus 的报文模型足够简单非常适合学习网络通信与数据解析。把 Modbus 吃透之后再去看其他工业协议很多概念都能迁移。2. Modbus 上位机需要理解的协议基础2.1 主站与从站模型Modbus 通信采用典型的主从模型主站Master主动发起请求。上位机通常作为主站。从站Slave被动响应。PLC、传感器等设备通常作为从站。使用 Modbus TCP 时从站一般是 TCP 服务端监听固定端口上位机是 TCP 客户端主动去连接。这与很多人习惯的“服务器 上位机”思维正好相反。实际调试时先用这个模型去理解设备手册会少走很多弯路。2.2 数据模型与功能码Modbus 把数据分成四类区域每一类对应不同类型的功能码数据区域区域类型读写方向常用功能码PLC 地址常见表示线圈Coil可读可写01 读、05 写单线圈、15 写多线圈00001 起离散输入Discrete Input只读02 读10001 起输入寄存器Input Register只读04 读30001 起保持寄存器Holding Register可读可写03 读、06 写单寄存器、16 写多寄存器40001 起现场最常见的两种寄存器是“保持寄存器”和“输入寄存器”。模拟量、温度、压力、状态字、控制字绝大多数都是通过寄存器来传输的。这里必须提醒一个很容易踩坑的细节PLC 上看到的地址可能是 40001 或 400101但 Modbus 报文里的寄存器地址往往是相对地址。40001 通常对应协议地址 040002 对应协议地址 1以此类推。写代码时不能直接把“40001”塞进报文要先把工程上的点位号换算成协议起始地址。2.3 Modbus TCP 报文的组成Modbus TCP 报文由 MBAP 头报文头和 PDU协议数据单元组成。MBAP 头包含事务标识符、协议标识符、长度和单元标识符。一个读取从站 1 的保持寄存器、从地址 0 开始读 10 个寄存器的请求帧如下00 01 00 00 00 06 01 03 00 00 00 0A逐个字段拆开看字节长度含义示例事务标识符2 字节用于匹配请求和响应可自增00 01协议标识符2 字节Modbus TCP 固定为 000 00长度2 字节后面还会跟多少字节00 06单元标识符1 字节从站地址常见为 101功能码1 字节03 表示读保持寄存器03起始地址2 字节从寄存器 0 开始00 00寄存器数量2 字节读 10 个寄存器00 0A请求帧“长度”为什么是 6因为长度字段后面依次是单元标识符 1 字节、功能码 1 字节、起始地址 2 字节、寄存器数量 2 字节合计 6 字节。对应的响应帧大致是00 01 00 00 00 17 01 03 14 00 64 00 65 ...其中00 17是长度十进制 2301是单元标识符03是功能码14是后面数据区的字节数十进制 20正好是 10 个寄存器 × 2 字节再往后是寄存器数据。每个寄存器的 16 位数据在报文里都是高字节在前、低字节在后。2.4 小结论从编码视角看读寄存器操作本质就是一个循环组帧 → 发送 → 等待完整响应 → 解析。真正容易出错的地方有两个一是 TCP 是流式协议响应可能半包、粘包不能简单以为“收到多少就是多少”二是寄存器里的 16 位或 32 位数据必须按正确的字节顺序转换。后面代码部分会重点解决这两件事。3. WPF 上位机环境准备3.1 开发环境本文示例使用的技术栈如下操作系统Windows 10/11 或 Windows ServerWPF 属于 Windows 桌面项目。IDEVisual Studio 2022或使用命令行与 VS Code。运行框架.NET 6 或 .NET 7。具体版本以你本机实际 SDK 为准本文代码里的 API 在这两个版本上均可正常使用。模式WPF MVVM不依赖额外第三方 MVVM 框架方便你看清绑定原理。如果安装了 .NET SDK可以通过命令行直接创建项目dotnet new wpf -n WpfModbusDemo cd WpfModbusDemo dotnet buildWPF 项目只有在 Windows 上才能构建运行。如果你使用的是 Linux 或 macOS 开发机还是需要一台 Windows 机器或者 Windows 虚拟机来运行最终程序。3.2 仿真调试工具在没有真实 PLC 的情况下最好准备一个 Modbus 从站仿真器。常见做法是从站模拟软件模拟一个 TCP 服务端监听 502 或自定义端口。在模拟器里设置一批寄存器和初始值。上位机作为客户端去连接它读取数据。调试工具的获取要注意合规。优先选择厂商官方评估版、开源实现或者现场网关自带的模拟工具。不要使用来路不明的破解版插件。原因不只是版权风险工控联调时一个被篡改的调试工具可能给你错误的报文排查起来非常痛苦。如果操作系统对 502 端口有权限限制建议在模拟器里把监听端口改成1502或1024以外的端口上位机连接时同步修改端口即可。协议本身不强制必须使用 502。3.3 联调前先约定公共参数开始写代码之前建议先列出一张参数表参数示例值说明设备 IP192.168.1.10PLC 或模拟器的 IPTCP 端口502常见 Modbus TCP 端口单元标识符1从站地址功能码03读保持寄存器起始地址0协议地址不是 40001寄存器数量10示例一次读 10 个寄存器轮询周期500ms实际项目按需求调整先把这张表定下来后面代码里的常量才有意义。实际项目中这些参数通常会放到配置文件中而不是写死在代码里。4. 用一个可落地的结构组织 WPF 上位机4.1 最常见的错误做法很多初学者拿到需求后会直接在MainWindow.xaml.cs里写一个按钮事件然后在事件里创建TcpClient、发送字节、解析响应最后用TextBox.Text把结果显示出来。这种写法跑一个最小 Demo 没问题但项目稍微变大就会失控界面刷新和通信线程混杂窗口一关闭后台线程可能还在读写网络。通信逻辑无法复用换个窗口或者改成主动上报模式需要大面积重写。没法做单元测试因为逻辑和视觉控件耦合。4.2 推荐目录结构本文示例采用下面这种简单的分层WpfModbusDemo/ ├─ App.xaml ├─ App.xaml.cs ├─ MainWindow.xaml ├─ MainWindow.xaml.cs ├─ Models/ │ └─ RegisterPoint.cs ├─ Services/ │ └─ ModbusTcpClientService.cs ├─ ViewModels/ │ ├─ ObservableObject.cs │ ├─ RelayCommand.cs │ └─ MainViewModel.cs └─ Views/ └─ MainWindow.xaml这里的原则是Service 层只负责 TCP 连接、组帧、收发、解析绝不出现MessageBox和Dispatcher。ViewModel 层负责状态、命令、轮询调度不关心按钮具体在窗口的什么位置。View 层负责 XAML 布局和数据绑定不在后台代码里写通信逻辑。这样做的好处很明显如果将来要把现场设备从 Modbus TCP 换成其他协议只需要替换 Service 层的实现ViewModel 和 View 基本不用动。5. 手写 Modbus TCP 通信服务核心代码5.1 为什么选择手写而不是直接引库.NET 社区有 NModbus 等成熟的开源 Modbus 库可以直接使用。但本文依然要演示手写的过程原因是在工控项目里你经常会遇到“标准库不好用”的情况例如设备厂商对功能码做了特殊扩展、一次读多个寄存器时的数量限制、某些网关需要固定事务 ID 等。这时候不懂协议底层就只能黑盒试错。自己实现一遍协议帧对得上、响应能解析再由需要决定是否换成开源库这是最稳妥的学习路径。而且 Modbus TCP 的主流程不算长一个服务类完全能承载。5.2 实现 Protocol 服务类首先定义服务类它负责连接、断开、发送请求、读取完整响应以及解析寄存器值。// Services/ModbusTcpClientService.cs using System.Buffers.Binary; using System.Net.Sockets; public sealed class ModbusTcpClientService : IDisposable { private readonly SemaphoreSlim _syncRoot new SemaphoreSlim(1, 1); private TcpClient? _tcp; private NetworkStream? _stream; private ushort _transactionId 0; public bool IsConnected _tcp?.Connected true _stream ! null; public async Task ConnectAsync(string ip, int port, CancellationToken ct default) { if (IsConnected) return; var tcp new TcpClient(); await tcp.ConnectAsync(ip, port, ct); _tcp tcp; _stream tcp.GetStream(); _stream.ReadTimeout 2000; _stream.WriteTimeout 2000; } public void Disconnect() { _stream?.Dispose(); _tcp?.Dispose(); _stream null; _tcp null; } /// summary /// 读取保持寄存器功能码 03 /// /summary public async Taskushort[] ReadHoldingRegistersAsync( byte unitId, ushort startAddress, ushort quantity, CancellationToken ct default) { if (quantity 1 || quantity 125) throw new ArgumentOutOfRangeException(nameof(quantity), 一次最多读取 125 个保持寄存器); byte[] request BuildReadRequest(unitId, 0x03, startAddress, quantity); byte[] data await ExecuteAsync(request, ct); if (data.Length % 2 ! 0) throw new InvalidDataException(寄存器数据长度不是偶数); ushort[] values new ushort[data.Length / 2]; for (int i 0; i values.Length; i) { values[i] BinaryPrimitives.ReadUInt16BigEndian(data.AsSpan(i * 2, 2)); } return values; } /// summary /// 读取输入寄存器功能码 04 /// /summary public async Taskushort[] ReadInputRegistersAsync( byte unitId, ushort startAddress, ushort quantity, CancellationToken ct default) { byte[] request BuildReadRequest(unitId, 0x04, startAddress, quantity); byte[] data await ExecuteAsync(request, ct); // 解析逻辑与 03 一致省略重复代码 // 实际项目中可抽取公共方法 return ParseRegisters(data); } private byte[] BuildReadRequest(byte unitId, byte functionCode, ushort startAddress, ushort quantity) { _transactionId; byte[] frame new byte[12]; frame[0] (byte)(_transactionId 8); frame[1] (byte)(_transactionId 0xFF); frame[2] 0x00; // 协议标识符高字节 frame[3] 0x00; // 协议标识符低字节 frame[4] 0x00; // 长度高字节 frame[5] 0x06; // 长度低字节单元标识 功能码 起始地址2字节 数量2字节 frame[6] unitId; frame[7] functionCode; frame[8] (byte)(startAddress 8); frame[9] (byte)(startAddress 0xFF); frame[10] (byte)(quantity 8); frame[11] (byte)(quantity 0xFF); return frame; } private ushort[] ParseRegisters(byte[] data) { if (data.Length % 2 ! 0) throw new InvalidDataException(寄存器数据长度不是偶数); ushort[] result new ushort[data.Length / 2]; for (int i 0; i result.Length; i) { result[i] BinaryPrimitives.ReadUInt16BigEndian(data.AsSpan(i * 2, 2)); } return result; } private async Taskbyte[] ExecuteAsync(byte[] request, CancellationToken ct) { if (_tcp null || _stream null) throw new InvalidOperationException(尚未连接到 Modbus 服务端); await _syncRoot.WaitAsync(ct); try { if (!_tcp.Connected) throw new IOException(TCP 连接已断开); await _stream.WriteAsync(request.AsMemory(0, request.Length), ct); await _stream.FlushAsync(ct); // 先读取 7 字节 MBAP 头 byte[] head new byte[7]; await ReadExactlyAsync(_stream, head, head.Length, ct); // length 表示 head 之后剩下的字节数包含单元标识和 PDU int length (head[4] 8) | head[5]; if (length 2) throw new InvalidDataException(响应长度字段异常); // 去掉单元标识后的 PDU 长度 byte[] pdu new byte[length - 1]; await ReadExactlyAsync(_stream, pdu, pdu.Length, ct); byte functionCode pdu[0]; if ((functionCode 0x80) ! 0) { byte errorCode pdu[1]; throw new IOException($Modbus 异常响应异常码{errorCode:X2}); } byte byteCount pdu[1]; if (byteCount pdu.Length - 2) throw new InvalidDataException(响应中的字节计数超过实际数据长度); byte[] data new byte[byteCount]; Array.Copy(pdu, 2, data, 0, byteCount); return data; } finally { _syncRoot.Release(); } } private static async Task ReadExactlyAsync( NetworkStream stream, byte[] buffer, int count, CancellationToken ct) { int offset 0; while (offset count) { int read await stream.ReadAsync(buffer.AsMemory(offset, count - offset), ct); if (read 0) throw new IOException(连接已关闭读取不到完整报文); offset read; } } public void Dispose() { Disconnect(); _syncRoot.Dispose(); } }这段代码里面最关键的是ReadExactlyAsync。TCP 本身没有消息边界Modbus 响应可能在一次ReadAsync里只到达一半也可能一次到达多个响应。如果不循环读取就会频繁出现“报错响应长度不对”或者“数据错位”的问题。另外一个关键点是信号量_syncRoot。如果同时有多个界面按钮或轮询任务去执行读写并发发送会导致请求和响应交叉解析必然出错。用信号量把每次请求-响应过程串行化是最简单的保护手段。5.3 响应错误码说明如果服务端返回异常响应功能码最高位会置 1同时附带异常码。常见异常码异常码含义常见原因01非法功能码设备不支持该功能码02非法数据地址起始地址或数据区域不存在03非法数据值寄存器数量超范围或值不合法04从站设备故障设备内部处于错误状态
C# WPF上位机开发实战：手写Modbus TCP数据采集应用
工控上位机开发有一个经常被忽视的分水岭界面做得好只能证明你熟练了 WPF能做上位机意味着你要把设备协议、字节解析、线程调度、状态恢复这些事真正跑通。很多初级工程师卡住的地方往往不是按钮不会写而是程序写完以后——PLC 连不上、寄存器读出来是乱数、程序运行一晚上就断线甚至数据错位到完全不可用。这篇文章要讲的就是从零到一打通这条链路使用 C# 与 .NET 6/.NET 7基于 WPF 和 MVVM 模式手写一个最小可运行的 Modbus TCP 上位机数据采集应用。文章不会绕圈子会直接回答几个实质问题Modbus 报文到底长什么样为什么不能把 Socket 读取代码直接塞进窗口类寄存器数值为什么经常“对不上”以及如何用仿真器在不接 PLC 的情况下验证整个项目。说一句更直接的话WPF 本身并不难难的是把 TCP 收到的字节可靠地变成界面上的数值Modbus 协议也不算难难的是把它组织成一个可以长期运行、便于维护的工程结构。这篇文章完整覆盖这一过程你可以把它当作一份“上位机零基础手写实战”的路线图。1. 为什么用 WPF Modbus 做上位机1.1 上位机到底在做什么很多初学者误以为上位机开发就是“一个人机界面”把思维局限在按钮、表格和曲线图上。实际上在工控语境里上位机通常承担三类工作与下位机PLC、传感器、仪表、变频器、嵌入式板卡等通信采集数据。对采集到的数据做显示、存储、报警判断或者业务计算。向设备下发控制指令例如启停、参数设定、点位写入。所以通信层才是一个上位机项目的底盘。如果一个程序只能通过模拟数据把界面搞得很好看一接到真实设备就现出原形那它还不是一个完整的上位机方案。反过来即便界面朴素只要能稳定采集和下发它已经具备实际交付能力。这就是本文把重心放在 Modbus 通信上的原因通信不稳定界面做得再花哨也没有工程价值。1.2 为什么选 WPF 而不是 WinForms 或 Web在 .NET 技术栈里WinForms 依然有大量存量项目但如果是新启动的上位机项目我更推荐优先考虑 WPF理由有几点WPF 的绑定体系比 WinForms 的控件属性赋值方式成熟天然适合 MVVM。界面与逻辑分离后通信层可以被独立测试而不是和窗口生命周期绑死。WPF 模板、样式和分辨率适配能力明显更强。工控现场最常见的需求是“给客户换一套深色主题”“需要在 1366×768 的老工控机上正常显示”WPF 做这类事情成本比 WinForms 低不少。Web 技术栈例如 Blazor Server / Electron / Web 页面也不是不能做但在工业现场很多时候需要程序直接访问本机串口、网卡、USB 加密狗、第三方 SDK并且要保证断网环境下也能运行。桌面客户端的部署方式仍然更直接。所以对于工控上位机WPF 是一个综合成本很低的选择。1.3 为什么是 ModbusModbus 不是性能最强、功能最丰富的工业协议但它是兼容面最广、可调试性最好、最容易上手的工业协议之一。PLC 支持它变频器支持它温控器支持它很多物联网网关也支持它。在一些项目里哪怕总线上走的是 Profinet、EtherCAT 或 CANopen设备侧仍然会预留 Modbus TCP 或 Modbus RTU 接口用于第三方系统对接。更关键的是Modbus 的报文模型足够简单非常适合学习网络通信与数据解析。把 Modbus 吃透之后再去看其他工业协议很多概念都能迁移。2. Modbus 上位机需要理解的协议基础2.1 主站与从站模型Modbus 通信采用典型的主从模型主站Master主动发起请求。上位机通常作为主站。从站Slave被动响应。PLC、传感器等设备通常作为从站。使用 Modbus TCP 时从站一般是 TCP 服务端监听固定端口上位机是 TCP 客户端主动去连接。这与很多人习惯的“服务器 上位机”思维正好相反。实际调试时先用这个模型去理解设备手册会少走很多弯路。2.2 数据模型与功能码Modbus 把数据分成四类区域每一类对应不同类型的功能码数据区域区域类型读写方向常用功能码PLC 地址常见表示线圈Coil可读可写01 读、05 写单线圈、15 写多线圈00001 起离散输入Discrete Input只读02 读10001 起输入寄存器Input Register只读04 读30001 起保持寄存器Holding Register可读可写03 读、06 写单寄存器、16 写多寄存器40001 起现场最常见的两种寄存器是“保持寄存器”和“输入寄存器”。模拟量、温度、压力、状态字、控制字绝大多数都是通过寄存器来传输的。这里必须提醒一个很容易踩坑的细节PLC 上看到的地址可能是 40001 或 400101但 Modbus 报文里的寄存器地址往往是相对地址。40001 通常对应协议地址 040002 对应协议地址 1以此类推。写代码时不能直接把“40001”塞进报文要先把工程上的点位号换算成协议起始地址。2.3 Modbus TCP 报文的组成Modbus TCP 报文由 MBAP 头报文头和 PDU协议数据单元组成。MBAP 头包含事务标识符、协议标识符、长度和单元标识符。一个读取从站 1 的保持寄存器、从地址 0 开始读 10 个寄存器的请求帧如下00 01 00 00 00 06 01 03 00 00 00 0A逐个字段拆开看字节长度含义示例事务标识符2 字节用于匹配请求和响应可自增00 01协议标识符2 字节Modbus TCP 固定为 000 00长度2 字节后面还会跟多少字节00 06单元标识符1 字节从站地址常见为 101功能码1 字节03 表示读保持寄存器03起始地址2 字节从寄存器 0 开始00 00寄存器数量2 字节读 10 个寄存器00 0A请求帧“长度”为什么是 6因为长度字段后面依次是单元标识符 1 字节、功能码 1 字节、起始地址 2 字节、寄存器数量 2 字节合计 6 字节。对应的响应帧大致是00 01 00 00 00 17 01 03 14 00 64 00 65 ...其中00 17是长度十进制 2301是单元标识符03是功能码14是后面数据区的字节数十进制 20正好是 10 个寄存器 × 2 字节再往后是寄存器数据。每个寄存器的 16 位数据在报文里都是高字节在前、低字节在后。2.4 小结论从编码视角看读寄存器操作本质就是一个循环组帧 → 发送 → 等待完整响应 → 解析。真正容易出错的地方有两个一是 TCP 是流式协议响应可能半包、粘包不能简单以为“收到多少就是多少”二是寄存器里的 16 位或 32 位数据必须按正确的字节顺序转换。后面代码部分会重点解决这两件事。3. WPF 上位机环境准备3.1 开发环境本文示例使用的技术栈如下操作系统Windows 10/11 或 Windows ServerWPF 属于 Windows 桌面项目。IDEVisual Studio 2022或使用命令行与 VS Code。运行框架.NET 6 或 .NET 7。具体版本以你本机实际 SDK 为准本文代码里的 API 在这两个版本上均可正常使用。模式WPF MVVM不依赖额外第三方 MVVM 框架方便你看清绑定原理。如果安装了 .NET SDK可以通过命令行直接创建项目dotnet new wpf -n WpfModbusDemo cd WpfModbusDemo dotnet buildWPF 项目只有在 Windows 上才能构建运行。如果你使用的是 Linux 或 macOS 开发机还是需要一台 Windows 机器或者 Windows 虚拟机来运行最终程序。3.2 仿真调试工具在没有真实 PLC 的情况下最好准备一个 Modbus 从站仿真器。常见做法是从站模拟软件模拟一个 TCP 服务端监听 502 或自定义端口。在模拟器里设置一批寄存器和初始值。上位机作为客户端去连接它读取数据。调试工具的获取要注意合规。优先选择厂商官方评估版、开源实现或者现场网关自带的模拟工具。不要使用来路不明的破解版插件。原因不只是版权风险工控联调时一个被篡改的调试工具可能给你错误的报文排查起来非常痛苦。如果操作系统对 502 端口有权限限制建议在模拟器里把监听端口改成1502或1024以外的端口上位机连接时同步修改端口即可。协议本身不强制必须使用 502。3.3 联调前先约定公共参数开始写代码之前建议先列出一张参数表参数示例值说明设备 IP192.168.1.10PLC 或模拟器的 IPTCP 端口502常见 Modbus TCP 端口单元标识符1从站地址功能码03读保持寄存器起始地址0协议地址不是 40001寄存器数量10示例一次读 10 个寄存器轮询周期500ms实际项目按需求调整先把这张表定下来后面代码里的常量才有意义。实际项目中这些参数通常会放到配置文件中而不是写死在代码里。4. 用一个可落地的结构组织 WPF 上位机4.1 最常见的错误做法很多初学者拿到需求后会直接在MainWindow.xaml.cs里写一个按钮事件然后在事件里创建TcpClient、发送字节、解析响应最后用TextBox.Text把结果显示出来。这种写法跑一个最小 Demo 没问题但项目稍微变大就会失控界面刷新和通信线程混杂窗口一关闭后台线程可能还在读写网络。通信逻辑无法复用换个窗口或者改成主动上报模式需要大面积重写。没法做单元测试因为逻辑和视觉控件耦合。4.2 推荐目录结构本文示例采用下面这种简单的分层WpfModbusDemo/ ├─ App.xaml ├─ App.xaml.cs ├─ MainWindow.xaml ├─ MainWindow.xaml.cs ├─ Models/ │ └─ RegisterPoint.cs ├─ Services/ │ └─ ModbusTcpClientService.cs ├─ ViewModels/ │ ├─ ObservableObject.cs │ ├─ RelayCommand.cs │ └─ MainViewModel.cs └─ Views/ └─ MainWindow.xaml这里的原则是Service 层只负责 TCP 连接、组帧、收发、解析绝不出现MessageBox和Dispatcher。ViewModel 层负责状态、命令、轮询调度不关心按钮具体在窗口的什么位置。View 层负责 XAML 布局和数据绑定不在后台代码里写通信逻辑。这样做的好处很明显如果将来要把现场设备从 Modbus TCP 换成其他协议只需要替换 Service 层的实现ViewModel 和 View 基本不用动。5. 手写 Modbus TCP 通信服务核心代码5.1 为什么选择手写而不是直接引库.NET 社区有 NModbus 等成熟的开源 Modbus 库可以直接使用。但本文依然要演示手写的过程原因是在工控项目里你经常会遇到“标准库不好用”的情况例如设备厂商对功能码做了特殊扩展、一次读多个寄存器时的数量限制、某些网关需要固定事务 ID 等。这时候不懂协议底层就只能黑盒试错。自己实现一遍协议帧对得上、响应能解析再由需要决定是否换成开源库这是最稳妥的学习路径。而且 Modbus TCP 的主流程不算长一个服务类完全能承载。5.2 实现 Protocol 服务类首先定义服务类它负责连接、断开、发送请求、读取完整响应以及解析寄存器值。// Services/ModbusTcpClientService.cs using System.Buffers.Binary; using System.Net.Sockets; public sealed class ModbusTcpClientService : IDisposable { private readonly SemaphoreSlim _syncRoot new SemaphoreSlim(1, 1); private TcpClient? _tcp; private NetworkStream? _stream; private ushort _transactionId 0; public bool IsConnected _tcp?.Connected true _stream ! null; public async Task ConnectAsync(string ip, int port, CancellationToken ct default) { if (IsConnected) return; var tcp new TcpClient(); await tcp.ConnectAsync(ip, port, ct); _tcp tcp; _stream tcp.GetStream(); _stream.ReadTimeout 2000; _stream.WriteTimeout 2000; } public void Disconnect() { _stream?.Dispose(); _tcp?.Dispose(); _stream null; _tcp null; } /// summary /// 读取保持寄存器功能码 03 /// /summary public async Taskushort[] ReadHoldingRegistersAsync( byte unitId, ushort startAddress, ushort quantity, CancellationToken ct default) { if (quantity 1 || quantity 125) throw new ArgumentOutOfRangeException(nameof(quantity), 一次最多读取 125 个保持寄存器); byte[] request BuildReadRequest(unitId, 0x03, startAddress, quantity); byte[] data await ExecuteAsync(request, ct); if (data.Length % 2 ! 0) throw new InvalidDataException(寄存器数据长度不是偶数); ushort[] values new ushort[data.Length / 2]; for (int i 0; i values.Length; i) { values[i] BinaryPrimitives.ReadUInt16BigEndian(data.AsSpan(i * 2, 2)); } return values; } /// summary /// 读取输入寄存器功能码 04 /// /summary public async Taskushort[] ReadInputRegistersAsync( byte unitId, ushort startAddress, ushort quantity, CancellationToken ct default) { byte[] request BuildReadRequest(unitId, 0x04, startAddress, quantity); byte[] data await ExecuteAsync(request, ct); // 解析逻辑与 03 一致省略重复代码 // 实际项目中可抽取公共方法 return ParseRegisters(data); } private byte[] BuildReadRequest(byte unitId, byte functionCode, ushort startAddress, ushort quantity) { _transactionId; byte[] frame new byte[12]; frame[0] (byte)(_transactionId 8); frame[1] (byte)(_transactionId 0xFF); frame[2] 0x00; // 协议标识符高字节 frame[3] 0x00; // 协议标识符低字节 frame[4] 0x00; // 长度高字节 frame[5] 0x06; // 长度低字节单元标识 功能码 起始地址2字节 数量2字节 frame[6] unitId; frame[7] functionCode; frame[8] (byte)(startAddress 8); frame[9] (byte)(startAddress 0xFF); frame[10] (byte)(quantity 8); frame[11] (byte)(quantity 0xFF); return frame; } private ushort[] ParseRegisters(byte[] data) { if (data.Length % 2 ! 0) throw new InvalidDataException(寄存器数据长度不是偶数); ushort[] result new ushort[data.Length / 2]; for (int i 0; i result.Length; i) { result[i] BinaryPrimitives.ReadUInt16BigEndian(data.AsSpan(i * 2, 2)); } return result; } private async Taskbyte[] ExecuteAsync(byte[] request, CancellationToken ct) { if (_tcp null || _stream null) throw new InvalidOperationException(尚未连接到 Modbus 服务端); await _syncRoot.WaitAsync(ct); try { if (!_tcp.Connected) throw new IOException(TCP 连接已断开); await _stream.WriteAsync(request.AsMemory(0, request.Length), ct); await _stream.FlushAsync(ct); // 先读取 7 字节 MBAP 头 byte[] head new byte[7]; await ReadExactlyAsync(_stream, head, head.Length, ct); // length 表示 head 之后剩下的字节数包含单元标识和 PDU int length (head[4] 8) | head[5]; if (length 2) throw new InvalidDataException(响应长度字段异常); // 去掉单元标识后的 PDU 长度 byte[] pdu new byte[length - 1]; await ReadExactlyAsync(_stream, pdu, pdu.Length, ct); byte functionCode pdu[0]; if ((functionCode 0x80) ! 0) { byte errorCode pdu[1]; throw new IOException($Modbus 异常响应异常码{errorCode:X2}); } byte byteCount pdu[1]; if (byteCount pdu.Length - 2) throw new InvalidDataException(响应中的字节计数超过实际数据长度); byte[] data new byte[byteCount]; Array.Copy(pdu, 2, data, 0, byteCount); return data; } finally { _syncRoot.Release(); } } private static async Task ReadExactlyAsync( NetworkStream stream, byte[] buffer, int count, CancellationToken ct) { int offset 0; while (offset count) { int read await stream.ReadAsync(buffer.AsMemory(offset, count - offset), ct); if (read 0) throw new IOException(连接已关闭读取不到完整报文); offset read; } } public void Dispose() { Disconnect(); _syncRoot.Dispose(); } }这段代码里面最关键的是ReadExactlyAsync。TCP 本身没有消息边界Modbus 响应可能在一次ReadAsync里只到达一半也可能一次到达多个响应。如果不循环读取就会频繁出现“报错响应长度不对”或者“数据错位”的问题。另外一个关键点是信号量_syncRoot。如果同时有多个界面按钮或轮询任务去执行读写并发发送会导致请求和响应交叉解析必然出错。用信号量把每次请求-响应过程串行化是最简单的保护手段。5.3 响应错误码说明如果服务端返回异常响应功能码最高位会置 1同时附带异常码。常见异常码异常码含义常见原因01非法功能码设备不支持该功能码02非法数据地址起始地址或数据区域不存在03非法数据值寄存器数量超范围或值不合法04从站设备故障设备内部处于错误状态
