用C#从零搭建一个Modbus串口采集程序

做上位机开发，跟PLC通信是绕不开的一关。通信协议虽然多，但Modbus绝对是工控领域用得最多的，没有之一。串口走Modbus RTU，网口走Modbus TCP，基本上覆盖了80%以上的设备通信场景。这篇文章把C#实现Modbus RTU串口通信的完整流程走一遍，从环境搭建到代码实现，照着做就能跑起来。

开发工具用Visual Studio，Community版免费够用。新建一个WinForm项目，目标框架选.NET Framework 4.7.2或者.NET 6都行，看你的项目需求。

Modbus通信不用从零写协议帧，有现成的类库可以用。推荐用NModbus4或者nModbus库，通过NuGet包管理器直接安装。在VS里右键项目，选管理NuGet程序包，搜索NModbus4，点安装就完事了。这个库封装了Modbus RTU和TCP的主站和从站功能，读写线圈、读写寄存器这些常用操作都有现成的方法可以调用。

串口通信的核心是SerialPort类。先实例化一个SerialPort对象，设置好参数：端口号、波特率、数据位、校验位、停止位。这几个参数必须跟从站设备一致，否则通信不上。

常用的串口参数配置：波特率9600，数据位8，校验位None，停止位One。这是最标准的配置，大部分设备出厂默认就是这个。但有些设备会用奇校验或者偶校验，具体看设备手册。

串口打开和关闭的逻辑要写好。打开前判断是否已经打开，关闭前判断是否处于打开状态。窗体关闭事件里一定要把串口关掉，不然程序退出了串口还被占用，下次启动就打不开了。同时把定时器也停掉，避免定时器触发时串口已经关闭导致异常。

基于打开的串口对象创建Modbus主站实例，用ModbusSerialMaster.CreateRtu方法。创建后设置三个超时参数：读取超时1000毫秒，写入超时1000毫秒，重试次数3次。这几个参数根据实际网络环境调整，通信质量差的现场可以适当加大超时和重试次数。

Modbus RTU读写操作的核心参数就三个：从站地址、起始寄存器地址、读取数量。从站地址是设备的站号，一般1到247。起始地址是你要读的寄存器从哪个开始。数量是连续读几个。

读取线圈状态用ReadCoils方法，返回布尔数组。读取保持寄存器用ReadHoldingRegisters方法，返回ushort数组。写入单个线圈用WriteSingleCoil，写入单个寄存器用WriteSingleRegister。这些方法都是同步阻塞的，调用后会等待从站响应或者超时返回。

实际应用中，数据采集一般用定时器轮询。Timer每隔500到1000毫秒触发一次，在Tick事件里调用读取方法。读到数据后更新到界面的TextBox或者Label上。如果数据量不大，这种轮询方式完全够用。

但要注意一点：Timer的Tick事件是在UI线程上执行的，如果读取操作耗时较长，界面会卡顿。解决方法是把读取操作放到后台线程里执行，读完后通过Invoke或者BeginInvoke把结果回调到UI线程更新界面。多设备并发采集的场景，建议每个设备一个独立线程，互不阻塞。

工业现场通信环境复杂，断线是家常便饭。程序必须能处理通信异常，不能一断线就崩掉。读取操作要包在try-catch里，捕获超时异常和串口异常。异常发生后不要立刻重试，先标记通信状态为断开，停掉定时器，然后在后台线程里做重连尝试。

重连逻辑：关闭当前串口，等待1秒，重新打开串口，重新创建Modbus主站。如果打开成功，发一个测试读取请求验证通信是否恢复。恢复成功后重新启动定时器，恢复数据采集。如果重连失败，继续等待下一轮重试。

通信状态要在界面上有明确提示。连接正常显示绿色，断开显示红色，重连中显示黄色。操作人员一眼就能看出通信状态，出了问题也能第一时间发现。

上面说的是最基本的采集程序，能跑起来，但离工业级应用还有距离。工业级上位机需要考虑的东西更多：多设备并发采集、数据本地缓存与断点续传、历史数据存储到数据库、报警阈值判断与通知、操作日志记录、用户权限管理。

架构上建议分层设计。通讯服务层封装Modbus协议核心，提供稳定的数据读写接口。业务逻辑层处理数据解析、报警判断。表现层负责界面展示和用户交互。三层之间通过事件或者回调解耦，这样后期改某一层不影响其他层。

数据存储方面，实时数据可以写SQLite或者内存表，历史数据写MySQL或者InfluxDB。别把所有数据都堆一个表里，按时间分表查询效率会好很多。

C#做上位机开发，上手门槛不算高，但要做出稳定可靠的工业级产品，靠的是对现场工况的理解和对异常场景的处理能力。代码写得好不好，不是在正常跑的时候看出来的，是在设备断线、网络抖动、数据异常的时候才见真章。