企业官网建设流程全解析

简介：面向工业自动化系统集成开发者与C#上位机学习者，聚焦C#通过Modbus协议与汇川PLC建立网络通信的示例工程，可用于理解寄存器读写、设备地址映射及上位机数据交互流程。压缩包共624个文件、约214.54MB，包含cs与vb示例源码、sln和vcxproj工程配置、h/cpp底层接口文件、exe/dll/pdb等编译运行产物，以及docx/pdf说明文档和界面资源，便于直接运行示例并对照源码修改。已有583人学习下载。读者可从中参考Modbus请求与响应报文构造、线圈和保持寄存器读写、通信参数配置、超时与CRC校验异常处理，以及实时性和界面集成等实践思路；较完整的解决方案与工程依赖也有助于排查编译、运行和联调问题。

1. 从一张点位表说起：C# 怎么把汇川 PLC 的 D 寄存器读上来

产线调试的第三天，PLC 那边工程师甩过来一张 Excel：D200 是设定温度，D210 是当前温度，M100 是启动信号，问你上位机能不能把这些读走。这时候大多数人的第一反应是找厂商驱动、装 OPC 服务器、配 DCOM，一套下来半天没了，还不一定通。这份 C# 与汇川 PLC 通信的示例走的是另一条路：一根网线，Modbus TCP，502 端口，两百多行代码就能把 D 寄存器和 M 线圈读上来、写下去。

它适合做上位机、MES 数据采集、设备联调的人，也适合刚接手一个「要连 PLC」的需求、但还没搞清 Modbus 报文长什么样的开发者。整套代码不依赖厂商运行环境，纯 .NET 就能跑，控制台里敲一次就能看到寄存器值刷出来。下面按选型、报文、封包、写值、踩坑、改造的顺序拆开讲，把中间那些手册上不写、但现场一定会遇到的东西说清楚。

2. 选型与骨架：Modbus TCP 打底，把通信层拆成四个文件

汇川的 PLC 在以太网口上基本都支持 Modbus TCP 从站，这一点让整个方案的门槛降到了「会写 Socket 就能连」。但真放进工程里，直接在一个 Form 的按钮事件里写两百行 Socket 收发，后面是没法维护的。这个示例的第一件事就是把通信拆层，让协议、设备语义、业务调用各归各位。

2.1 三条路线的取舍：Modbus TCP、OPC UA 与第三方通信库

连汇川 PLC 上位机常见三条路，选哪条直接决定后面代码的形状。

第一条是 Modbus TCP。PLC 侧在编程软件里把以太网口配好 IP，打开 Modbus TCP 从站功能，C# 侧拿 Socket 直接发协议报文。优点是零依赖、协议全公开、跨平台，Linux 上跑 .NET 也能用；缺点是它能看到的只有「寄存器」这一个视角，PLC 里的变量名、数据类型、结构体统统看不到，全部要靠一张点位表做映射。示例走的就是这条路，因为它最可控，也最能让读者看懂报文。

第二条是 OPC UA。AM 系列或加个网关就能开，优点是带符号名、带类型、支持订阅推送，工程量大时确实省事；缺点是证书、信任列表、端口、会话保活这一套配置下来，示例工程的篇幅会全花在配置上，通信本身的逻辑反而看不见了。做小规模采集、只读几十个点位，用它有点杀鸡用牛刀。

第三条是买第三方通信库。这类库把 Modbus、S7、三菱、欧姆龙全封了一遍，API 确实顺手，但商用授权和后续升级要算进成本，出问题的时候也只能等厂商。示例里的做法是：核心链路手写一遍，看清 MBAP 头怎么拼、长度字段怎么算；需要快速铺开时再接 NModbus 这类开源库，两者不冲突。

选型的结论其实很朴素：只要 PLC 那边能开 Modbus TCP 从站，就先走第一条，把链路跑通、把字序和地址这些坑趟平；等点位涨到几百个、又需要类型信息时，再考虑往上加一层。

2.2 解决方案目录与依赖：一个类库加一个控制台

示例的工程结构不复杂，但分层是清楚的，四块职责互不越界：

PlcDemo/ ├── PlcDemo.Protocol/ # 协议层：只管字节，不懂业务 │ ├── ModbusTcpMaster.cs # 连接、收发、组包拆包 │ ├── ModbusException.cs # 异常码封装 │ └── FrameBuilder.cs # MBAP + PDU 拼装（可选，便于单测） ├── PlcDemo.Device/ # 设备层：懂地址、懂类型 │ ├── PlcDevice.cs # ReadFloat / WriteInt 这类语义方法 │ ├── PointTable.cs # 点位表：名称 → 地址 → 类型 │ └── WordOrder.cs # 大小端、字序转换 ├── PlcDemo.Demo/ # 控制台：验证用，读一轮打一行日志 │ └── Program.cs └── PlcDemo.Tests/ # 单测：拿假报文喂给拆包函数

依赖方面，目标框架用 .NET 6 或 .NET 8 的控制台项目即可，串口相关的包完全用不上，因为走的是网口。如果选 NModbus 那条路，加一个NModbus的 NuGet 引用就行。真正需要自己写的是协议层那两个文件，加起来 200 行左右。

这么拆的好处很直接：协议层可以单独做单元测试，扔一段手工构造的响应报文进去，看它拆出来的寄存器数组对不对，不需要现场有 PLC；设备层改点位、改类型不影响收发逻辑；控制台随时能换成一个 Windows 服务或者 ASP.NET Core 的后台任务。

2.3 地址映射约定：软元件怎么换算成 Modbus 寄存器号

这一步是整个项目里最容易翻车、又最容易被跳过的地方。PLC 里叫 D200、M100，Modbus 报文里只有「功能码 + 起始地址 + 数量」，中间得有一张换算表。

示例里约定的映射关系大致如下，具体偏移要以对应机型的通信手册为准：

这里有个必须记住的差别：手册上写「40001 表示第一个保持寄存器」，这是给人看的 1 基址编号；报文里实际填的是 0。所有地址在进FrameBuilder之前，都要先减掉基址。示例里干脆把这件事收口在一个方法里：

// 把手册上的 4xxxx 编号转成报文里用的 0 基址偏移 public static ushort ToPduAddress(ushort manualAddress, FuncKind kind) { return kind switch { // 保持寄存器：4xxxx，报文从 0 开始 FuncKind.HoldingRegister => (ushort)(manualAddress >= 40001 ? manualAddress - 40001 : manualAddress), // 线圈：0xxxx，同样减基址 FuncKind.Coil => (ushort)(manualAddress >= 1 ? manualAddress - 1 : manualAddress), _ => manualAddress }; }

FuncKind是自定义枚举，标识这次访问的是线圈还是保持寄存器；manualAddress传手册上的编号。这个方法看着不起眼，但它把「编号体系」和「报文地址」这两种东西彻底分开了，后面点位表里存的是手册编号，出报文时才转换，减少手滑。

提示：D 寄存器在很多机型上从 0 开始一一对应，但不是所有型号、所有固件都一样。最稳的验证方式是在 PLC 编程软件里在线监控 D0，同时用调试工具往地址 0 发一次 FC03，看两个数对不对得上。

3. 报文拆解：一次 FC03 读请求从 Socket 到寄存器的全过程

把链路跑通靠的是理解这一条请求长什么样。Modbus TCP 的帧结构其实就两块：7 字节的 MBAP 头，加上 PDU（功能码 + 数据）。看懂这 12 个字节，后面所有读写都是同一套模板换个功能码。

3.1 MBAP 七字节头与 PDU 的组包规则

MBAP 头七个字节，字段含义固定：

读保持寄存器时，PDU 是 5 字节：功能码 0x03、起始地址 2 字节、寄存器数量 2 字节。所以长度字段填 6，整帧 12 字节。响应回来时长度字段会变，要看响应里的值重新算。

这里有两个细节值得单独拎出来。第一，事务标识必须自增并记住，因为 TCP 是流式的，如果将来做并发，靠它才能把响应和请求对上。第二，长度字段是判断「这一帧到哪结束」的唯一依据，不能靠一次Receive返回多少算多少。

3.2 手写 Socket 版 FC03：收发、长度校验与粘包处理

下面这段是示例协议层的核心，读保持寄存器的完整实现：

public ushort[] ReadHoldingRegisters(ushort start, ushort count) { // ---- 1. 组请求帧：MBAP 7 字节 + PDU 5 字节 ---- var tid = ++_transactionId; // 事务标识自增，用于匹配响应 var frame = new byte[12]; frame[0] = (byte)(tid >> 8); // 事务标识高字节 frame[1] = (byte)(tid & 0xFF); // 事务标识低字节 frame[2] = 0x00; frame[3] = 0x00; // 协议标识，固定 0 frame[4] = 0x00; frame[5] = 0x06; // 后续长度 = 单元标识1 + PDU5 frame[6] = _unitId; // 从站地址 frame[7] = 0x03; // 功能码：读保持寄存器 frame[8] = (byte)(start >> 8); frame[9] = (byte)(start & 0xFF); frame[10] = (byte)(count >> 8); frame[11] = (byte)(count & 0xFF); _socket!.Send(frame); // ---- 2. 先收 7 字节头，再按长度字段收剩余 ---- var header = ReceiveExact(7); var respTid = (header[0] << 8) | header[1]; if (respTid != tid) throw new ModbusException($"事务标识不匹配，期望 {tid}，收到 {respTid}"); var length = (header[4] << 8) | header[5]; // 剩余字节数（含单元标识） var body = ReceiveExact(length - 1); // 头里已经取走了单元标识 // ---- 3. 判断是不是异常响应，功能码最高位置 1 即为异常 ---- if ((body[0] & 0x80) != 0) throw new ModbusException($"PLC 返回异常码 0x{body[1]:X2}", body[1]); var byteCount = body[1]; if (byteCount != count * 2) throw new ModbusException($"字节数不符，期望 {count * 2}，实际 {byteCount}"); // ---- 4. 大端拼回 ushort 数组 ---- var result = new ushort[count]; for (var i = 0; i < count; i++) result[i] = (ushort)((body[2 + i * 2] << 8) | body[3 + i * 2]); return result; }

_transactionId是ushort字段，自增到 65535 自然回绕，不影响使用。_unitId就是站号，单台 PLC 直连填 1，多台走网关时按现场分配。start是已经转过基址的 PDU 地址，count是寄存器个数，不是字节数——这一点在算长度字段时特别容易搞混，长度字段里的 6 是固定值，跟count无关。

响应判断的部分值得多说一句：功能码最高位为 1 表示异常响应，比如 0x03 变成 0x83，第二个字节就是异常码。很多示例代码不判这个，结果 PLC 报错时它去解析数据区，读出来一串垃圾值还以为是字序问题，白查半天。

ReceiveExact是 TCP 流式收发的必需品，因为一次Receive不保证收满：

private byte[] ReceiveExact(int length) { var buffer = new byte[length]; var read = 0; while (read < length) { // 只向内核要还缺的字节数，避免一次多读把下一帧吃掉 var n = _socket!.Receive(buffer, read, length - read, SocketFlags.None); if (n <= 0) throw new IOException("连接被对端关闭"); read += n; } return buffer; }

粘包问题的解法就藏在这里：每一次都严格按「已知长度」去要字节，绝不多读。收到的数据既不会少，也不会把下一帧的头吞掉。如果将来做并发请求队列，还要再加一个按事务标识分发的字典，但单线程轮询采集用现在的写法已经够了。

3.3 换成 NModbus：少写两百行，但要接住它的异常

手写一遍是为了看懂报文，实际项目里如果点位多、节奏快，用 NModbus 能省不少事：

// 建立主站，TcpClient 负责底层连接 var factory = new ModbusFactory(); using var tcp = new System.Net.Sockets.TcpClient(); tcp.Connect("192.168.1.10", 502); using var master = factory.CreateMaster(tcp); master.Transport.ReadTimeout = 2000; // 读超时，单位毫秒 master.Transport.WriteTimeout = 2000; master.Transport.Retries = 1; // 失败重试次数，别设太大 // 站号 1，起始地址 0，读 10 个保持寄存器 ushort[] regs = master.ReadHoldingRegisters(1, 0, 10);

三个参数要注意：第一个1是站号，不是地址；第二个0才是起始地址，同样是 0 基址；第三个10是寄存器个数。类型转换它不管，ushort[]出来之后还得自己合并成 float 或 int。

它抛的异常类型是SlaveException，里面带SlaveExceptionCode，跟你手写版解析出的异常码是一回事。如果控制台里直接try-catch一个空的catch {}，现场出问题时只能看到「读失败」四个字，什么线索都没有。示例里的做法是统一包一层，把手写版和库版的异常都转成自定义的ModbusException，上层只认一种类型。

3.4 32 位数据合并：字序反了比读不到更难查

16 位寄存器读上来只是半成品。温度、流量、累计值这类 32 位浮点，在 PLC 里占两个连续寄存器，谁放高 16 位、谁放低 16 位，各家不一样。汇川这边常见的是低字在前：D200 存低 16 位，D201 存高 16 位。

// 把两个连续寄存器还原成 float，lowWordFirst 控制字序 public static float ToSingle(ushort[] regs, int offset, bool lowWordFirst = true) { var lo = lowWordFirst ? regs[offset] : regs[offset + 1]; var hi = lowWordFirst ? regs[offset + 1] : regs[offset]; // 先拼成 32 位无符号整数：高位在左，低位在右 var raw = ((uint)hi << 16) | lo; // .NET Framework 没有 Int32BitsToSingle，用 BitConverter 兜底 return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); }

lowWordFirst这个开关一定要暴露出来。我见过不止一次，同一台设备上有的变量是低字在前，有的是高字在前，跟 PLC 里变量的声明方式有关。硬编码一种字序，换台机器就得改代码重新发版。

判断字序对不对有个笨办法但很有效：让 PLC 那边把变量写成一个已知的数，比如 25.5，你读出来如果是 1.6e-38 量级或者 1.1e+10 量级，基本可以断定高低字反了，把lowWordFirst翻一下再试。

4. 写值与长连接：把网络抖动当成常态

读通只是开始。产线上真正要求稳的是写：改配方、下发设定值、点启动按钮。写操作一旦丢包或者半截，PLC 侧的工艺状态可能就停在中间态，所以这部分的重试策略和读完全不是一回事。

4.1 FC06 与 FC16：写单个和批量写多个寄存器

写单个保持寄存器用 FC06，报文结构和读差不多，只是 PDU 里第二个字段变成了要写的值：

public void WriteSingleRegister(ushort address, ushort value) { var tid = ++_transactionId; var frame = new byte[12]; frame[0] = (byte)(tid >> 8); frame[1] = (byte)(tid & 0xFF); frame[4] = 0x00; frame[5] = 0x06; // 长度仍然 6 frame[6] = _unitId; frame[7] = 0x06; // 功能码：写单个寄存器 frame[8] = (byte)(address >> 8); frame[9] = (byte)(address & 0xFF); frame[10] = (byte)(value >> 8); frame[11] = (byte)(value & 0xFF); _socket!.Send(frame); // 正常响应是请求的原样回显，回显不一致就说明中间串了 var echo = ReceiveExact(12); if (echo[7] != 0x06) throw new ModbusException($"写寄存器响应功能码异常 0x{echo[7]:X2}", echo[8]); var echoAddr = (ushort)((echo[8] << 8) | echo[9]); if (echoAddr != address) throw new ModbusException($"写寄存器地址回显不一致：{echoAddr} != {address}"); }

回显校验这一步别省。Modbus TCP 在单连接上虽然是有序的，但如果代码里有并发写、或者有别的线程在同一条连接上发请求，回显就能第一时间暴露「响应串了」这件事。

批量写用 FC16（0x10），PDU 变成：功能码 + 起始地址 2 + 数量 2 + 字节数 1 + 数据 N。长度字段随之变化，frame[5]要按实际算，不能写死。示例里把它抽成了一个BuildWriteMultipleFrame方法，参数是起始地址和ushort[]，长度 = 7 + 数据字节数，数据区每个寄存器仍然是大端两个字节。

一个实操建议：配方这类成组的参数，一定要用 FC16 一次写。拆成多次 FC06，中间任何一次失败都会留下半套配方，PLC 拿着新旧混合的参数跑，比直接报错更危险。

4.2 超时、重连与心跳寄存器的设计

网络层的超时在Socket上设，但真正难的是判断「这条连接还活着吗」。

public void Connect(int timeoutMs = 3000) { _socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp) { NoDelay = true, // 关掉 Nagle，短周期采集能省几毫秒 SendTimeout = timeoutMs, ReceiveTimeout = timeoutMs }; var ar = _socket.BeginConnect(_ip, _port, null, null); if (!ar.AsyncWaitHandle.WaitOne(timeoutMs)) throw new TimeoutException($"连接 {_ip}:{_port} 超时"); _socket.EndConnect(ar); }

BeginConnect加WaitOne这种写法看起来老派，但比Connect好在能自己控制连接超时——直接调Connect，在网线没插、对端不回 RST 的情况下会卡很久，界面直接假死。

心跳不要用Socket.Connected判断，这个属性反映的是「上次 IO 时的状态」，网线拔了它可能还返回true。真正可靠的做法是周期性读一个已知寄存器，读成功就算活，超时次数到阈值就主动Dispose掉旧 Socket 重连：

private int _failCount; public bool EnsureAlive() { try { ReadHoldingRegisters(_heartbeatAddress, 1); // 心跳地址，随便挑一个只读的 _failCount = 0; return true; } catch { if (++_failCount < 3) return false; // 偶发丢一两次不重连 Reconnect(); // 连续失败才断线重连 _failCount = 0; return false; } }

重连要做退避，别在循环里死磕。我一般用 1 秒、2 秒、4 秒、最多 10 秒的间隔，既能快速恢复，又不会把 PLC 的连接资源打满。

4.3 异常码与日志：让故障现场能复盘

Modbus 的异常码就那么几个，但对应的现场原因差别很大：

日志里必须带上这四样：事务标识、功能码、地址和数量、耗时。少了任何一样，事后复盘都得靠猜。示例里用一个简单的文件日志，每次请求前后各记一条，出错时把异常码一起打。

注意：日志不要在每个采集周期都全量落盘，I/O 会把采集线程拖慢。我一般只在状态变化时写（成功转失败、失败转成功、异常码变化），正常运行每分钟一条摘要就够了。

5. 避坑排查：现场最容易翻车的五个地方

下面这五条，每一条我都在现场遇到过，也都花了不短的时间才定位。写在这里，是希望有人能少走一遍。

5.1 能 ping 通却连不上 502

现象：ping 192.168.1.10正常，代码里Connect一直超时，或者立刻抛连接被拒绝。

原因有两个方向。一是 PLC 侧根本没启用 Modbus TCP 从站，编程软件里那个选项默认是关的，只是网口通了而已。二是中间的交换机或防火墙挡了 502 端口，尤其是跨网段访问的时候。

解决：先在 PLC 编程软件里确认 Modbus TCP 从站已启用，并核对站号和端口；再用telnet 192.168.1.10 502或者Test-NetConnection -ComputerName 192.168.1.10 -Port 502从目标机测一次端口。端口不通就别在代码里找原因了，问题在网络上。

5.2 数据错位：0 基址与 1 基址的暗坑

现象：读 D200，返回值跟 PLC 在线监控里 D200 的数对不上，而且差得很有规律，比如读到的总是下一个寄存器的值。

原因：手册上的 4xxxx 编号是 1 基址，报文里是 0 基址，代码里少减了 1。也有反过来的情况，某些第三方库的 API 已经帮你减过了，你又减了一次。

解决：拿一个已知值做锚点。在 PLC 里把 D200 写成 1234，然后用调试工具分别往地址 199、200、201 发 FC03，看哪个返回 1234。定位到之后，把这个偏移固化到ToPduAddress里，全局只留一个地方做转换。

5.3 浮点数读出来是天文数字

现象：整数寄存器读得都对，唯独 float 类型的值读出来是1.6E-38或者-3.4E+38这种明显不合理的数。

原因：字序反了。PLC 里低字在前，代码按高字在前合并，或者反过来。整数只看一个寄存器，所以不受影响，浮点跨两个寄存器立刻就露馅。

解决：给类型转换函数加lowWordFirst开关，两种都试一次，哪个数值落在合理区间用哪个。更稳的做法是让 PLC 侧先写一个固定值 25.5，代码里两种字序都打出来对比，一次就能确定。

5.4 跑几个小时连接假死

现象：刚部署时一切正常，跑三五个小时之后读数停止刷新，日志也不报错，界面看着还连着。

原因：Socket.Connected返回的是上次 IO 的状态，网络中间设备把空闲连接悄悄断了，它还是true。之后每次Send可能成功（进了内核缓冲区），Receive一直等不到数据，直到超时才抛，但超时设得长的话，表现出来就是「卡住」。

解决：加心跳，别信Connected。另外把ReceiveTimeout设成 2 到 3 秒，宁可快速失败也别长时间挂着。重连时旧 Socket 一定要Dispose，不然句柄会一直涨。

5.5 一次读太多寄存器被打回异常码 02

现象：读 10 个寄存器正常，读 200 个就报异常码 0x02。

原因：PLC 对单次请求的寄存器数量有上限（常见是 120 个左右，跟机型有关），超了就当非法地址处理。另外起始地址加数量也可能越过该区域的边界。

解决：分批读，每批 50 到 100 个，批与批之间留几十毫秒间隔。分批的时候注意别把一个 32 位变量拆到两批里，按点位表切分，保证每个变量完整落在同一批内。

6. 从示例到产线采集服务：三个改造点

示例跑通之后，离能用还有一段距离。我一般按这三步改。

第一步是把点位表从代码里搬出去。定义成 JSON，每个点位有名称、地址、功能码、数据类型、字序、缩放系数、读写权限，启动时读进来。这样 PLC 那边加一个点，改配置重启就行，不用重新编译发布。点位表本身要做校验：地址不能重叠、32 位变量必须占两个连续寄存器、只读点不许出现在写接口里。

public record PlcPoint( string Name, // 点位名，如 "Temp_Set" ushort Address, // 手册上的原始地址，转换在协议层做 string Func, // "Holding" / "Coil" string DataType, // "Int16" / "Int32" / "Float" / "Bool" bool LowWordFirst, // 32 位数据的字序 double Scale); // 工程值缩放，比如 0.1 表示寄存器值除以 10

第二步是把采集和业务解耦。采集跑在独立的后台任务里，按固定周期把整张表读一遍，读到的结果通过Channel<PlcSnapshot>往外发，上层是谁消费、消费多快，采集这边都不关心。这样界面卡顿、数据库慢、HTTP 回调超时，都不会把采集周期拖乱。写操作反过来走一个命令队列，保证同一条连接上不会出现读写交叉。

第三步是上线前对拍。拿 Modbus Poll 之类的调试工具和你的代码同时读同一批寄存器，连续观察半小时，数值必须完全一致；再故意拔一次网线、重启一次 PLC，看采集服务能不能在 10 秒内自动恢复，恢复后数据有没有跳变。这套动作我每次都要走一遍，尤其是拔网线这步，能暴露 90% 的保活问题。

从那以后我每次接新的 PLC，都先用调试工具和代码同时读同一个寄存器，两个数对上才往下写业务逻辑。差的这几个数，往往就是后面几个小时的排查成本。希望帮到你。

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