简介：面向C#开发者与工控技术人员，工控老马出品的实例源码聚焦于如何通过.NET方式与西门子S7系列PLC进行通信。程序采用WinForm界面，完整演示了从S7.NET连接、读写寄存器到界面刷新的过程，覆盖工业上位机开发中最常用的通信场景，既适合零基础入门，也为有经验的程序员提供了可复用的代码模板。资源包为zip格式，约140KB，共32个文件，其中包含9个C#源文件作为核心逻辑，配合Visual Studio工程文件和配置文件可直接编译运行；同时提供exe与dll程序集，方便先运行查看效果再对照源码学习；资源文件夹和界面预览图则用来支撑WinForm设计，整体结构精简且完整。已有322人学习浏览，说明此实例在同类资源中具备不错的参考价值。通过学习，读者可以掌握S7.NET库的连接用法、数据读写格式转换等关键知识点，并能沿窗体入口理清程序执行顺序；项目保留完整解决方案和程序集依赖，稍作修改即可迁移到实际PLC控制项目中，是工业通信入门和项目借鉴的实用资料。
1. 用 C# 和 .NET 连西门子 S7 PLC，真正的门槛在 PLC 侧参数
“C# 通过 .NET 方式实现与西门子 S7 PLC 通信”这个需求，在上位机开发里几乎每天都会出现：MES 要采集产线数据，配料系统要把参数写进 DB 块，设备状态要实时上抛。很多人以为这事的难点在协议解析，其实今天 .NET 生态里 S7 协议早被封装成现成 NuGet 包，几行代码就能把 S7-1200 的 DB 读回来。真正卡住人的是 PLC 侧参数：DB 是否开了优化块访问、CPU 是否允许 PUT/GET 通信、Rack 与 Slot 是否填对，这三项错任何一个，报错方式都不同，而它们和 C# 代码本身无关。下面从协议栈讲清 S7 通信的边界，给出一份连接 S7-1200/1500 的最小可运行代码，再把批量读取、UI 刷新和排错清单一次说透，新手能照着跑通，老手可以核对参数边界。
2. 从 S7 协议到 .NET 库选型：S7.Net 与 Sharp7 怎么选
2.1 S7 通信的本质：TCP 102 端口上的 TPKT、COTP 与 S7Comm
西门子 S7 以太网通信并不是普通 TCP 上直接跑业务数据，而是三层嵌套：最外层是 TPKT，负责声明后续数据包长度；中间是 COTP，负责建立和维持传输连接；最里层才是 S7Comm，也就是真正承载“读 DB、写 M 区”请求应答的协议。C# 里用 Socket 连上 PLC 的 102 端口只是完成了 TCP 层，后面还有两次握手：COTP 的 Connection Request/Confirm，以及 S7 层的 PDU 长度协商，全部走完，PLC 才开始接受读写请求。
这三层协议每一层都有固定字节结构，比如 TPKT 前四个字节是版本号和保留位，后两个字节是总长度；COTP 的 CR 报文里带有本地和远程 TSAP，TSAP 又和 Rack、Slot 强相关。用代码自己实现不是不行，但要做完 CRC、分包、重传、长数据拆分这些事，工作量足够写一个小型通信组件。这也是为什么主流做法是直接用社区封装好的库，把精力留在业务参数上。
验证网络层是否通，可以先用一段最小 C# 代码探测 102 端口：
using System.Net.Sockets; using var client = new TcpClient(); var connectTask = client.ConnectAsync("192.168.0.10", 102); var done = await Task.WhenAny(connectTask, Task.Delay(2000)); if (done == connectTask && client.Connected) { Console.WriteLine("TCP 102 端口已连通"); } else { Console.WriteLine("TCP 连接超时，先查网络和防火墙"); }这段代码的逻辑是同时等待连接完成和 2 秒超时，谁先完成看谁。注意 PLC 的 102 端口只对“允许 PUT/GET 通信”的 CPU 开放，并且只接受 ISO-on-TCP 握手，普通 TCP 探测工具显示端口开放不代表 S7 能通信，但端口都不通时一定是网络层问题。参数说明里值得留意的是超时时间，PLC 响应通常几十毫秒，2 秒已经足够区分网络不通和协议不匹配。
2.2 NuGet 里的两个主力库：S7.Net 与 Sharp7 的取舍
.NET 生态里用来连西门子 S7 的开源库，最常用的是 S7.Net（NuGet 包名为 S7netplus）和 Sharp7。两者封装的都是同一套 S7 协议，但风格差异很大，选型取决于项目规模和你对数据处理的习惯。
| 对比项 | S7.Net (S7netplus) | Sharp7 |
|---|---|---|
| API 风格 | 强类型，直接按地址读对象 | 字节缓冲，S7Client.ReadArea 返回 byte[] |
| 上手难度 | 低，几行代码读写 DB | 中，需要自己解析字节序 |
| 批量读取 | 提供 ReadMultipleVars | 提供 ReadMultiVars，但也要拼字节 |
| 适合场景 | 点数少、逻辑简单的上位机 | 点数多、追求吞吐的采集程序 |
| Real/Int 转换 | 自动完成 | 手动用 S7.GetRealAt / S7.GetIntAt |
我一般这么选：项目里数据点几十个、以 UI 展示为主，就用 S7.Net，代码量最少；要每秒采上千个点、做高速数据归档，用 Sharp7 或直接基于原生 Socket 重写轮询更合适。S7.Net 的 Read 方法返回 object，每次读取都有装箱拆箱，高频采集时这部分开销会被放大，这会在后续循环采集章节专门处理。
如果项目还要打通三菱、Modbus、西门子多个品牌，可以看跨品牌通信库 HslCommunication，它对西门子各系列的支持粒度更细，包括 S7-200 SMART 这种协议族有差异的机型。S7-200 SMART 的协议实现和 S7-1200 并不完全一致，直接套用常见 CpuType 可能连不上，用之前务必确认库是否明确支持该机型。
2.3 连接前必须确认的 PLC 侧设置：PUT/GET 与优化块访问
C# 代码写得再规范，PLC 侧不开权限也是白搭。S7-1200/1500 默认情况下不允许外部设备通过 S7 协议读写，必须在 TIA Portal 里手动开启：进入 CPU 组态，找到“防护与安全”下的“连接机制”，勾选“允许来自远程对象的 PUT/GET 通信访问”。这一步不做，C# 端 Open 可能成功，但真正 Read 时会被拒绝，而且报错信息不一定直观。
比 PUT/GET 更隐蔽的是 DB 块的“优化的块访问”选项。S7-1200/1500 新建的 DB 默认勾选优化块访问，这种块没有固定偏移地址，S7.Net 用 DB1.DBD0 这类绝对地址去读会失败。解决办法是在 DB 属性里取消“优化的块访问”，重新编译下载后才会生成偏移地址。S7-300/400 的 DB 默认非优化，基本没有这个问题，所以很多老工程师第一次碰 1200 都会在这卡住。S7-1500 对优化块的支持更彻底，如果项目不允许取消优化访问，那 S7 协议这条路就走不通，只能换 OPC UA 或西门子官方 API，这个边界在项目选型时就要确认。
提示：取消优化块访问会改变 DB 内部布局，且无法直接恢复原状，务必在 PLC 程序编译下载前另存一份备份。
3. 最小可运行实例：用 S7.Net 读写 S7-1200 的 DB 与 M 区
3.1 建立连接：CpuType、IP 与 Rack/Slot 的对应关系
S7.Net 建立连接只需一行代码，构造函数里四个参数全是坑。以 S7-1200 为例，标准写法是new Plc(CpuType.S71200, "192.168.0.10", 0, 1)，其中第三、四个参数是 Rack 和 Slot。Rack 是机架号，Slot 是 CPU 所在插槽号，不同系列的默认值不一样，最常搞错的是 S7-300 和 S7-400。
| PLC 系列 | 常用 Rack | 常用 Slot | 备注 |
|---|---|---|---|
| S7-1200 | 0 | 1 | 绝大多数固件适用 |
| S7-1500 | 0 | 1 | 部分早期组态为 0/0 |
| S7-300 | 0 | 2 | 导轨式安装，CPU 常在 2 号槽 |
| S7-400 | 0 | 3 | 机架式，CPU 在 3 号槽居多 |
Rack/Slot 的作用是生成 COTP 握手时的 TSAP 值，填错时 TCP 连接能建立，但 COTP 握手会被 PLC 拒绝，现象表现为 Open 卡住或直接抛异常。S7.Net 里 CpuType 枚举映射了 CPU 型号，S71200、S71500、S7300、S7400 是常用项，选错型号会导致 PDU 协商参数不匹配。连接代码和基本读写可以这样写：
using S7.Net; var plc = new Plc(CpuType.S71200, "192.168.0.10", 0, 1); plc.Open(); float temp = (float)plc.Read("DB1.DBD0"); short speed = (short)plc.Read("DB1.DBW4"); bool start = (bool)plc.Read("DB1.DBX2.0"); plc.Write("M0.0", true); plc.Write("DB1.DBD8", 25.5f); plc.Close();代码的逻辑是先通过 Open 完成 TCP 连接和 S7 握手，之后 Read 和 Write 都基于同一连接进行，最后 Close 释放。地址语法里 DB1.DBD0 表示 DB1 从偏移 0 开始的双字（4 字节），通常对应 PLC 侧 Real 或 DInt 类型；DB1.DBW4 是偏移 4 开始的字（2 字节），对应 Int；DB1.DBX2.0 是 DB1 偏移 2 字节的第 0 位，对应 Bool。M0.0 是位存储区地址，与 DB 无关。需要特别说明，Read 返回的是 object，强转类型必须和 PLC 侧声明一致，Real 读出来强转 float 没问题，但如果 DB 里声明的是 DInt 却按 Real 读，数值会完全错乱，这是地址对齐最常见的坑。
3.2 读写 DB 与 M 区：使用 ReadBytes 做更底层的读取
Read 方法虽然方便，但遇到 PLC 侧是自定义结构体、数组或者字符串时就不够用了。更底层的做法是用 ReadBytes 直接按字节区间读取，然后自己在 C# 侧解析。这样做的好处是读写范围和解析逻辑完全可控，不再依赖库内置的类型映射。
byte[] data = plc.ReadBytes(DataType.DataBlock, 1, 0, 20); float temp = BitConverter.ToSingle(data, 0); short speed = BitConverter.ToInt16(data, 4); uint counter = BitConverter.ToUInt32(data, 6);这段代码从 DB1 的偏移 0 开始读 20 个字节，然后按位置解析出 4 字节的 float、2 字节的 short 和 4 字节的 uint。参数含义很直接：DataType.DataBlock 指定访问数据块，第二个参数 1 是 DB 编号，第三个参数 0 是起始字节偏移，第四个参数 20 是要读取的总字节数。需要强调的是字节序，西门子 PLC 使用大端序，而 BitConverter 在大多数 Windows 机器上按小端序解析，所以解析前要做反转：
sbyte[] reversed = data[..4].Reverse().ToArray(); float temp = BitConverter.ToSingle(reversed, 0);这一条几乎每个从零写采集程序的人都会踩一次。如果你用 S7.Net 的 Read 方法，库内部已经处理了字节序，不会遇到这个问题。但一旦切到 ReadBytes，大端转小端就变成你自己的责任。批量读 DB 时建议统一按字节区间读取，然后集中做一次字节序转换，避免对每个变量都调用一次 Read 导致多次 TCP 往返。
3.3 Open 抛异常时的排查顺序：网络、握手、权限
PLC 通信报错时最忌讳逐个猜。S7.Net 的 Open 会抛出 PlcException，异常里带 ErrorCode，但错误码信息量有限，多数人要查半天。我建议按固定顺序排查：先确认 TCP 通不通，再确认 Rack/Slot 是否正确，然后确认 PUT/GET 权限，最后确认 DB 地址。前两个问题主要在 Open 阶段暴露，后两个问题通常在第一次 Read 或 Write 时暴露。
try { plc.Open(); _ = plc.Read("DB1.DBD0"); } catch (PlcException ex) { Console.WriteLine($"ErrorCode: {ex.ErrorCode}"); Console.WriteLine($"Message: {ex.Message}"); }这个简短逻辑的价值在于把协议层的错误暴露出来。S7 协议的错误码大体分两类：0x81 段多位对象不存在或地址类型不对，0x80 段多位请求不被支持，比如 PUT/GET 未开启。看到 0x81 就先检查 DB 地址和偏移，看到 0x80 就先回 PLC 侧看连接机制。值得说明的是，Open 成功不代表能读写，很多 PUT/GET 问题会延迟到第一次 Read 才暴露，所以测试代码至少要包含一次真实读写，只测 Open 不算验证通过。
4. 循环采集不卡 UI：S7.Net 批量读取与后台轮询写法
4.1 ReadMultipleVars 一次取回多个变量
逐条调用 Read 是最直观的写法，但每条 Read 都是一次完整的 S7 请求应答往返，读 30 个变量就是 30 次网络往返。S7-1200 单条读写响应在毫秒级，30 个变量积攒下来至少几十毫秒，再加上 UI 线程渲染，循环采集和 UI 刷新卡顿是必然结果。S7.Net 提供的 ReadMultipleVars 把多个读取请求合并到一个 PDU 里，一次往返取回全部数据。
var items = new[] { new DataItem(DataType.DataBlock, 1, 0, VarType.Real, 1), new DataItem(DataType.DataBlock, 1, 4, VarType.Int, 1), new DataItem(DataType.Memory, 0, 0, VarType.Bit, 1), new DataItem(DataType.DataBlock, 1, 40, VarType.S7String, 20) }; var results = plc.ReadMultipleVars(items); float temp = (float)results[0]; short speed = (short)results[1]; bool running = (bool)results[2]; string name = (string)results[3];DataItem 构造函数的五个参数分别是数据类型、DB 编号、起始地址、变量类型和个数，结果按传入顺序返回。注意 VarType.S7String 的第 5 个参数 20 表示最大字符长度，PLC 侧字符串要声明成相同长度，否则读回来的字符串可能被截断。ReadMultipleVars 适合固定点位的采集，点位列表通常在程序启动时构建一次，不要每次轮询都 new 一批 DataItem，那样会引入额外的 GC 压力。S7 协议单次 PDU 有长度限制，一次读取的总字节数不要超过 240 字节左右，超过时分组读取，这个限制来自 S7 协议自身的 PDU 协商，不是库的缺陷。
4.2 后台采集与 UI 定时刷新，解决循环数据采集和 UI 刷新卡顿
UI 卡顿的本质是采集和渲染抢占同一个线程。S7.Net 的 Read 是同步阻塞方法，如果直接在按钮事件里 while 循环调用，界面从点击到结束完全无响应，几秒后系统会提示“程序未响应”。常见做法是把采集放到后台线程，用快照对象保存最新数据帧，UI 线程用定时器只负责读快照和刷新界面，两者通过锁或并发集合隔离。
public sealed class PlcPollingService { private readonly Plc _plc; private readonly ConcurrentDictionary<string, object> _snapshot = new(); private CancellationTokenSource? _cts; public PlcPollingService(Plc plc) => _plc = plc; public void Start(int intervalMs = 200) { _cts = new CancellationTokenSource(); Task.Run(() => PollLoop(_cts.Token, intervalMs)); } private async Task PollLoop(CancellationToken token, int intervalMs) { var items = BuildDataItems(); while (!token.IsCancellationRequested) { try { var values = _plc.ReadMultipleVars(items); for (int i = 0; i < items.Length; i++) { _snapshot[items[i].VarName] = values[i]; } } catch (PlcException) { // 断线处理：记录时间，等待下次轮询重连 } await Task.Delay(intervalMs, token); } } public T? Get<T>(string key) => _snapshot.TryGetValue(key, out var v) ? (T)v : default; }这段代码的逻辑核心是：采集循环只负责把最新值写入快照，不接触任何 UI 控件，因此 UI 线程永远不被网络阻塞。UI 侧用 DispatcherTimer 每 100 毫秒读一次快照并刷新 TextBlock，最终呈现的效果是界面不掉帧，PLC 通信也不中断。参数说明里有几个取舍：intervalMs 设为 200 毫秒是最常见的起步值，对应 5Hz 采集频率，能满足大多数设备监控场景；低于 50 毫秒时 S7-1200 的响应能力会逼近极限，而且频繁的 PDU 交互会挤占 PLC 的通信资源。ConcurrentDictionary 在这里比普通 Dictionary 合适，因为它保证后台线程写入和 UI 线程读取之间不会出现“读到半截数据”的竞态。这个方案的局限是轮询本身有延迟，PLC 侧数据变化要在下一个采集周期才能看到，对实时性要求特别高的场景可以缩短间隔，但不要试图在 UI 线程直接做高频轮询。
4.3 字符串与字节解析：从 DB 读一段原始数据
S7 协议里的字符串不是 .NET 那种长度前缀，而是两字节头加内容体的结构：第一个字节是字符串最大长度，第二个字节是当前有效长度，从第三个字节开始才是真正的字符内容。直接用 Read 读字符串有时能成功，但如果 PLC 侧声明长度和 C# 侧不一致，读回来的字符会多出尾部空格或乱码。最可靠的方式是 ReadBytes 后手动按 S7 格式解析。
byte[] raw = plc.ReadBytes(DataType.DataBlock, 1, 40, 22); int maxLen = raw[0]; int curLen = raw[1]; string value = Encoding.ASCII.GetString(raw, 2, curLen);这段代码的逻辑是：先读 DB1 偏移 40 处的 22 个字节，22 对应 2 字节头加 20 字节最大内容，然后从 raw[1] 取当前有效长度，最后从第 2 字节开始截取定长内容。注意 PLC 字符串是 ASCII 编码，如果 PLC 里声明的是 WString（宽字符串），内容是 UTF-16 编码，要改用 Encoding.Unicode 解析，字节数也要相应翻倍。这个解析细节在做配方管理、读取报警文本时基本都会遇到。另一个实用场景是读数组，比如 PLC 侧有 10 个 Real 组成的数组，ReadBytes 按 40 个字节一次读回，再用循环从每个 4 字节切片转 float，比调用 10 次 Read 快得多。
5. S7 通信排错参数清单与一个验证技巧
5.1 连不上 PLC 时的核对参数表
PLC 通信排错不是看代码，而是按参数表逐项核对。下面这张表覆盖了我在现场遇到过的绝大多数场景，每一项都对应一个明确操作。
| 现象 | 常见原因 | 处理动作 |
|---|---|---|
| TCP 102 端口不通 | 网线/交换机/防火墙 | ping 通后用 telnet 验证 102 端口 |
| Open 超时 | Rack/Slot 填错 | 按机型对照 Rack/Slot 表修改 |
| Open 成功但 Read 报 0x81 | 地址不存在或类型不符 | 核对 DB 号和偏移地址，检查 DB 长度 |
| Read 报 0x80 | PUT/GET 未勾选 | 回 TIA Portal 勾选连接机制 |
| 能读保护 DB 但读不到值 | 优化块访问未取消 | 取消优化访问后重新编译下载 |
| 虚拟机里连不上 PLC | NAT 网络导致 PLC 无法回连 | 把虚拟机网络改为桥接模式 |
最后一行值得单独说：很多人习惯在 VMware 里做 C# 开发，虚拟机用 NAT 模式时，虚拟机可以访问外网，但 PLC 回应虚拟机发出的握手包时，会因为 NAT 地址转换找不到目标，表现为 TCP 能连上但 S7 握手一直没有响应。改成桥接模式后，虚拟机直接占用物理网段地址，PLC 回包不再经过宿主机的 NAT 转译，问题立刻消失。
5.2 用 ReadBytes 缩小问题范围
业务代码里叠加了各种类型转换，出问题时很难判断是连接问题还是解析问题。一个实用的定位手段是最小化读取：只读 4 个字节，看能不能拿到原始数据。
byte[] probe = plc.ReadBytes(DataType.DataBlock, 1, 0, 4); Console.WriteLine(BitConverter.ToString(probe));如果 probe 能正常输出 4 字节十六进制，说明连接、协议、DB 访问全通，问题出在后续的类型解析或地址换算；如果 probe 抛异常，问题在连接层或 PLC 侧权限，根本还没走到数据类型那一步。这样一拆，排查范围直接缩小一半。
5.3 用抓包确认握手是否完成
当代码链路看不出问题时，抓包是最客观的验证方式。Wireshark 里设置过滤条件tcp.port == 102，连一次 PLC 再断开，正常情况能依次看到 TCP 三次握手、COTP 的 Connection Request 和 Connection Confirm，以及若干 S7 Read/Write 请求。如果在 TCP 握手后看不到 COTP Confirm，说明 Rack/Slot 或 TSAP 配置有问题，PLC 已经拒绝应用层握手；如果 COTP 正常但看不到 S7 请求，说明 PUT/GET 权限受限。把这组过滤条件保存成 Wireshark 常用过滤配置，之后每次连不上都能直接打开对照，比反复猜测参数高效得多。
本文还有配套的精品资源，点击获取
