简介：本资源是一套面向工业自动化开发者的西门子S7系列PLC与C#上位机通信实战源码，专为掌握PLC数据采集、远程监控与人机交互开发的工程师及高校自动化/电气专业学习者设计，有效解决上位机与S7-1200/S7-1500等主流型号PLC基于TCP/IP协议的稳定读写难题。压缩包共435个文件，含128个核心C#源码（.cs）、148个运行依赖DLL（含S7.Net等工业通信库）、12个配置文件（.config/.json）、17个XML文档（含API说明与配置模板）及9个可执行程序（.exe），完整覆盖连接管理、DB块读写、多PLC并发通讯、异常重连与UI线程安全处理等关键模块，包体仅5.86MB，轻量易部署。已有2100人学习下载，源码结构清晰，含多个工程（如WinForms71200multiple、S7.Net.UnitTest），便于分层理解协议封装、单元测试验证与实际项目集成，是快速打通工业通讯底层逻辑与C#工程实践的重要参考。 直接说结论：用C#对接西门子S7系列PLC做上位机通讯，最稳的落地路径就是S7协议 + Snap7开源库。这个组合我从S7-200 SMART一路用到S7-1500，跨了将近五个项目，至今没出过原则性的大坑。下面把整套思路、踩过的坑和可直接抄的源码结构完整写出来，希望对正准备搭上位机通讯的朋友有帮助。
这篇内容对应的项目是一个完整的PLC数据采集与监控上位机示例，源码覆盖了连接管理、读写数据块、异步处理、断线重连、日志记录这几个核心模块。适合三类人看：刚接触上位机开发、需要给现有产线设备配监控界面的工程师，以及想搞懂S7通讯底层机制的C#开发者。我会尽量把每一步为什么这么做讲清楚，而不是只扔给你一段能跑的代码。
1. 项目整体设计与技术选型
1.1 核心需求解析
做上位机通讯，大部分人第一反应是“写个socket连上PLC就行”。但真正落地过的人都知道，这里面藏着一堆问题：PLC的型号不同，底层协议就不同；数据区的地址和类型对不上，读出来的就是乱码；通讯卡顿、断线重连、多PLC并发采集，每一个都能让产线停摆。
这个项目的核心目标可以拆成四点：
- 支持S7系列主流型号（200 SMART、300、400、1200、1500）的以太网通讯。
- 提供稳定的数据读写能力，覆盖I区、Q区、M区、DB块。
- 解决长期运行的稳定性问题，比如断线自动重连、通讯超时处理。
- 预留数据落盘和接口扩展能力，方便对接MES、数据库、Web看板。
围绕这四点，技术选型就清晰了：通讯层用S7协议，数据访问层用Snap7，上层用C#的异步机制和线程安全队列。
1.2 为什么选Snap7而不是OPC UA或Modbus TCP
这是我在项目评审时被问得最多的问题。先把三种方案做个对比：
| 方案 | 协议复杂度 | 开发效率 | 实时性 | 跨平台 | 授权成本 |
|---|---|---|---|---|---|
| Snap7（S7协议） | 中等 | 高 | 高（毫秒级） | 支持 | MIT开源 |
| OPC UA | 高 | 低（需建信息模型） | 中 | 支持 | 部分免费 |
| Modbus TCP | 低 | 中 | 中 | 支持 | 免费 |
选Snap7的核心原因有三个：
第一，S7协议是西门子PLC的“母语”，通讯效率最高。Modbus TCP虽然简单，但很多西门子PLC的DB块访问需要额外映射，数据量一大性能就下降。
第二，Snap7是纯开源库，不涉及商业授权问题，而且支持Linux和Windows。这意味着你写的通讯逻辑以后可以无缝迁移到边缘计算网关或者树莓派上，不用改代码。
第三，Snap7内部实现了S7协议的握手、PDU协商、分包传输等底层逻辑。S7协议的PDU大小默认是240字节，超过这个大小需要分包发送，手动实现这些很繁琐，Snap7帮你封装好了。
注意：如果你的现场设备种类很杂，既有西门子又有三菱、欧姆龙，那OPC UA可能是更好的统一方案。但如果现场以西门子为主，或者你只是想快速搭一套可用的监控系统，Snap7性价比完胜。
1.3 源码结构规划
这个项目的源码我按分层来组织：
S7Demo/ ├── S7.Core/ # 通讯核心库 │ ├── S7ClientWrapper.cs # Snap7客户端封装 │ ├── S7DataBlock.cs # 数据块模型 │ └── S7Config.cs # 连接配置 ├── S7.Service/ # 业务服务层 │ ├── PlcMonitorService.cs # 采集调度服务 │ ├── DataPersistence.cs # 数据落盘 │ └── AlarmService.cs # 报警处理 └── S7.WinApp/ # 上位机UI ├── MainForm.cs └── TagMonitorControl.cs这样分层的目的很明确：通讯核心库不依赖UI，可以单独做单元测试；业务服务层负责调度和数据处理；UI层只做展示和人机交互。如果你后面要改成Web版，只需要替换UI层，核心逻辑全部复用。
2. 环境准备与S7通讯基础
2.1 开发环境与工具链
我用的开发环境是Windows 10 + Visual Studio 2022 + .NET 6（其实.NET Framework 4.7.2也能跑，但新项目建议直接.NET 6以上）。Snap7直接用NuGet安装：
Install-Package S7netplus这里要特别说明一下，NuGet上常见的Snap7库有两个：S7netplus和Snap7。我推荐用S7netplus，它在原版Snap7基础上做了很多C#友好的封装，比如直接用Plc.Read("DB1.DBX0.0")这种类LS5风格的字符串地址，对新手非常友好。
另外还有一个重要工具：如果你不开Visual Studio，只用VSCode开发，记得装好.NET SDK和C# Dev Kit插件。VSCode配置C#环境这件事本身就有不少坑，网上教程很多，这里不展开，但建议新手直接用Visual Studio，省心。
2.2 S7协议通讯模型
想用好Snap7，得先理解S7协议的通讯模型。S7协议是ISO-on-TCP（RFC 1006）的变体，默认端口是102。它比普通的TCP多了一层TPKT和COTP头，所以不能直接拿Socket发原始字节——握手阶段非常讲究时序和PDU协商。
通讯链路建立过程大致是：
- TCP三次握手。
- 发送COTP Connection Request报文。
- 等待COTP Connection Confirm。
- 发送S7协议握手请求，协商PDU长度。
- 建立成功，之后就是正常读写。
Snap7把上述过程全部封装在Connect()方法里。但理解这个模型很重要，因为后面排查连接问题时，你得能判断是TCP层问题还是S7层问题。
S7协议的数据访问模型核心是三张表：
- 过程映像输入区（I区）：对应PLC的输入端子状态。
- 过程映像输出区（Q区）：对应PLC的输出端子状态。
- 位存储区（M区）：PLC内部标志位。
- 数据块（DB块）：最大的数据存储区，也是上位机读写最频繁的区域。
每个区域访问时都有严格吗的编码规则：S7协议在报文的RDREC/WRREC参数中通过区标识符（Area Code）和DB编号来定位数据。Snap7进一步把规则简化成S7AreaDB、S7AreaMK等枚举常量，配合DB编号和字节偏移量就能访问任意位置。
2.3 数据地址与字节对齐规则
这个坑我见过太多人踩：C#里读到的数据长度明明对，但值就是不对。原因几乎都是地址偏移算错了。
S7协议的地址偏移是按字节算的，但PLC的内部地址（比如M区和I/Q区）通常用“位/字节地址”来表示，比如M10.0表示M区的第10字节的第0位。当你想用字节方式去读M区时，偏移地址要写计算后的字节偏移量。
举几个例子：
| PLC地址 | Snap7中对应的Area和Offset | 说明 |
|---|---|---|
| I0.0 | S7AreaPE, 0 | I区第0字节开始 |
| Q0.0 | S7AreaPA, 0 | Q区第0字节开始 |
| M10.0 | S7AreaMK, 10 | M区第10字节开始 |
| DB1.DBX0.0 | S7AreaDB, DB编号=1, 偏移0 | DB1第0字节开始 |
对于Byte、Word、DWord类型，偏移量直接对应字节数。但对于Bool型，你得自行计算位偏移。Snap7支持按位读，但大多数情况下，一次读一个字节然后按位解析效率更高。一个字节8个Bool，一次到位，比读8次强得多。
DB块的偏移设计还要注意对齐。比如你PLC里DB1的结构是：
变量名 类型 偏移 A Bool 0.0 B Byte 1 C Int 2 D Real 4C#中要想一次读出来，结构体必须按同样的对齐规则定义。这里有个很容易被忽略的坑：C#的struct默认会做内存对齐，比如bool占了1字节后，后面跟byte会自动对齐到2字节边界，导致偏移错位。所以用StructLayout特性显式控制布局：
[StructLayout(LayoutKind.Sequential, Pack = 1)] public struct PlcDataBlock { public bool A; public byte B; public short C; public float D; }Pack = 1告诉编译器按1字节对齐，这样才能和PLC侧的内存布局完全对应。实测中如果漏了这个属性，结构体整体大小会偏大几个字节，ReadStruct读取时数据错位。
3. 核心功能实现
3.1 连接管理与生命周期
S7通讯的第一步是建立连接。我习惯把连接生命周期封装成一个ClientWrapper类，避免业务代码里到处newPlc对象。
public class S7ClientWrapper : IDisposable { private Plc _plc; private readonly S7Config _config; private readonly object _lockObj = new object(); private bool _isConnected; public S7ClientWrapper(S7Config config) { _config = config; } public bool Connect() { lock (_lockObj) { try { if (_plc != null && _plc.IsConnected) return true; _plc?.Dispose(); _plc = new Plc(CpuType.S71500, _config.IpAddress, _config.Rack, _config.Slot); _plc.Timeout = _config.TimeoutMs; _plc.Connect(); _isConnected = _plc.IsConnected; return _isConnected; } catch (Exception ex) { Logger.Error($"PLC连接失败: {ex.Message}"); _isConnected = false; return false; } } } public void Disconnect() { lock (_lockObj) { _plc?.Dispose(); _plc = null; _isConnected = false; } } public void Dispose() => Disconnect(); }这个封装有几个关键点：
第一，所有操作都加了lock。S7协议客户端不是线程安全的，如果多个线程同时在同一个连接上调用读写方法，会导致PDU协商混乱，严重的直接卡死。用锁串行化访问是最简单的做法，实测性能损失可以忽略。
第二，CpuType参数要选对。S7-1200和S7-1500选S71500，S7-300选S7300，S7-400选S7400。选错了会导致连接成功后握手异常，典型表现是Connect不报错，但第一次Read就超时。S7-200 SMART比较特殊，它走的是PPI协议封装在TCP里，Snap7新版有S7200Smart类型，早期版本没有的话要用S7200+ 特殊参数。
第三，Rack和Slot参数。S7-300/400通常分别是0和2，S7-1200/1500是0和0。这个参数必须和PLC硬件组态一致，不一致时握手会失败。
3.2 数据读取：从基础到高效
最基础的读取方式是按字节读：
public byte[] ReadBytes(DataType dataType, int dbNumber, int startByteAdr, int count) { lock (_lockObj) { if (!EnsureConnected()) return null; try { return _plc.ReadBytes(dataType, dbNumber, startByteAdr, count); } catch (PlcException ex) { Logger.Error($"读取失败: {ex.ErrorCode} - {ex.Message}"); _isConnected = false; return null; } } }在实际项目里，更推荐用泛型方法加结构体映射：
public T? ReadStruct<T>(int dbNumber, int startByteAdr = 0) where T : struct { lock (_lockObj) { if (!EnsureConnected()) return null; try { return _plc.ReadStruct<T>(DataType.DataBlock, dbNumber, startByteAdr); } catch (Exception ex) { Logger.Error($"结构体读取失败: {ex.Message}"); return null; } } }用结构体读取一个完整的DB块，一次网络交互就能拿到一屏数据。这个优化非常显著：如果逐字段读10个变量，需要10次网络往返；用结构体读，1次搞定。在1200/1500这种高性能PLC上差异还没那么大，但在老掉牙的S7-300上，1个DB的读取时长能从近百毫秒降到十几毫秒。
注意：轮询频率超过每秒50次，且数据量大时，建议在PLC侧把需要上位机读取的数据先统一汇总到一块“通讯映像DB”。这是西门子官方推荐的做法，可以有效降低PLC通讯负载，避免扫描周期被拉高。
3.3 数据写入：可靠性和安全
写入的API和读取对称，但写操作要加更多保护。在实际生产中，写错一个位可能直接导致设备动作，所以我的原则是：写操作必须显式指定类型和值，禁止泛型Object。
public bool WriteBit(DataType dataType, int dbNumber, int startByteAdr, bool bitValue) { lock (_lockObj) { if (!EnsureConnected()) return false; try { _plc.WriteBit(dataType, dbNumber, startByteAdr, 0, bitValue); return true; } catch (Exception ex) { Logger.Error($"写入失败: {ex.Message}"); _isConnected = false; return false; } } }写DB块的时候，我习惯先读出来，修改后再整体写回，而不是直接按地址写。原因是生产环境中多个变量可能在同一个DB块里，如果只写其中一个字段，PLC侧块一致性会受影响。当然，前提是你对这个DB块有完全的写权限。读改写模式虽然多了一次网络往返，但安全性高得多。
3.4 异步化与多PLC并发
工业通讯里，如果只用同步阻塞方式，UI线程会卡死，而且多PLC采集时一台设备慢会拖垮整个循环。所以我用async/await把所有通讯操作包装成异步任务。
public async Task<bool> ConnectAsync() { return await Task.Run(() => Connect()); } public async Task<T?> ReadStructAsync<T>(int dbNumber, int startByteAdr = 0) where T : struct { return await Task.Run(() => ReadStruct<T>(dbNumber, startByteAdr)); }多PLC并发采集用SemaphoreSlim控制并发数，避免线程爆炸：
private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(initialCount: 8); public async Task CollectAllAsync() { var tasks = new List<Task>(); foreach (var plcClient in _plcClients) { await _semaphore.WaitAsync(); tasks.Add(Task.Run(async () => { try { await plcClient.CollectAsync(); } finally { _semaphore.Release(); } })); } await Task.WhenAll(tasks); }实测一个现场有6台PLC，每台PLC有10个DB块需要读取，用并发采集后一轮完整采集时间从原来的8秒降到了1.2秒，效果非常明显。当然，最终瓶颈往往在PLC的通讯处理能力，所以并发数要克制，不是越大越好。
4. 进阶功能与项目扩展
4.1 心跳检测与自动重连
上位机长期运行，PLC重启、网络瞬断、交换机过热都会导致连接断开。为了恢复，必须先有自动重连机制。
我的实现思路简单粗暴：每2秒检查一次连接状态，如果断开，就进入重连循环。重连循环里前3次间隔5秒，之后间隔30秒，避免PLC正在恢复时频繁打请求。
public void StartHeartbeatCheck() { _heartbeatCts = new CancellationTokenSource(); _ = Task.Run(async () => { while (!_heartbeatCts.Token.IsCancellationRequested) { await Task.Delay(2000); if (!_plc.IsConnected) { for (int i = 0; i < 3; i++) { if (Connect()) break; await Task.Delay(5000); } if (!_plc.IsConnected) await Task.Delay(30000); } } }); }心跳检测的判断依据不是IsConnected属性，而是每次都尝试发送一个轻量级的读请求。因为TCP连接可能处于“半开”状态——操作系统层面连接还挂着，但PLC已经重启了，这时候IsConnected还是true，只有实际读写才会报错。所以更稳妥的方式是心跳读一个固定地址，读失败了就置为断开状态。这里用Snap7的ReadBytes读一个字节的DB数据即可，负载很小，实测不会对PLC扫描周期产生明显影响。
4.2 与数据库和MES联动
数据采到之后，不能光在界面上显示。大多数项目需要把关键产量、报警、设备状态记录到数据库，或上抛到MES系统。
数据库这块我用Dapper + SQL Server。Dapper的好处是轻量，执行简单SQL很方便，比Entity Framework在物联网采集场景下性能好得多。典型的数据落库逻辑：
public async Task SaveDataAsync(PlcDataSnapshot snapshot) { const string sql = @" INSERT INTO [dbo].[PlcData] ([DeviceId], [TagName], [Value], [QualityCode], [CollectTime]) VALUES (@DeviceId, @TagName, @Value, @QualityCode, @CollectTime)"; using var conn = new SqlConnection(_connectionString); await conn.ExecuteAsync(sql, snapshot); }落库时有个要点：数据吞吐量大的时候建议批量插入，而不是一条条插。用SqlBulkCopy或者Dapper的Execute一次插多条非常快。实测批量100条/次比单条循环快30倍以上。
对接MES系统我一般用HTTP API或者消息队列。HTTP API简单直接，HttpClient设置超时时间，失败后重试3次。如果甲方要求高可靠性，就用RabbitMQ或者Kafka，通过消息队列把数据异步上抛，避免MES系统慢时反向拖垮采集服务。注意HttpClient最好全局单例，不要每次new，否则会耗尽socket端口。
4.3 摄像头视觉联动与上位机界面
补充聊聊热词里提到的C# AForge摄像头控制。这类需求在自动化产线很常见：当PLC检测到产品到位，上位机需要触发相机拍照，然后调用视觉算法进行判定。
用AForge控制摄像头的核心步骤是：
- 用
FilterInfoCollection枚举本机视频输入设备。 - 用
VideoCaptureDevice打开指定设备。 - 设置视频属性（帧率、分辨率）。
- 通过
NewFrame事件接收图像帧。
private VideoCaptureDevice _videoDevice; public void StartCamera(string monikerString) { _videoDevice = new VideoCaptureDevice(monikerString); _videoDevice.NewFrame += OnNewFrame; _videoDevice.Start(); } private void OnNewFrame(object sender, NewFrameEventArgs eventArgs) { var bitmap = (Bitmap)eventArgs.Frame.Clone(); pictureBox.Image?.Dispose(); pictureBox.Image = bitmap; }关于摄像头参数设置，AForge也支持控制一些属性和控制逻辑。比如VideoCapabilities可以设置分辨率，VideoDevice的某些属性可通过CameraControl操作亮度、曝光、对焦等。这里有一个容易踩的坑：不是所有摄像头都支持所有控制属性，调用前先枚举CameraControlProperties的可用标志，否则会抛异常。
如果是高帧率产线项目，建议用专业的机器视觉相机SDK（如海康、Basler），AForge更适合实验室和低帧率监控场景。真正常规项目中，视觉和PLC的同步是通过硬件IO触发器实现的，上位机只需要接收视觉结果，再写入PLC，这个数据链路需要按项目需求设计。
4.4 与汇川等第三方PLC的兼容思考
做上位机这行，你很难保证只碰到西门子。很多项目里，产线混搭了汇川、台达甚至基恩士的PLC。这里简单说下思路：
- 汇川H系列很多型号底层协议和S7兼容，用法和Snap7类似，仅IP或模块参数不同。
- 汇川早期型号走Modbus TCP，用
System.Net.Sockets写个Modbus客户端，协议栈不算复杂，01/02/03/04/05/06/0F/10功能码覆盖90%的采集需求。 - 基恩士多用UDP私有协议，一般得按手册自己拼报文，或用官方DLL。
代码层面可以做一个统一的通讯接口，用工厂模式按PLC类型发射不同驱动：
public interface IPlcDriver { bool Connect(); Task<byte[]> ReadAsync(int area, int address, int length); bool Write(int area, int address, byte[] data); } public class PlcDriverFactory { public static IPlcDriver Create(PlcConfig config) { return config.PlcType switch { PlcType.SiemensS7 => new S7Driver(config), PlcType.InovanceModbus => new ModbusTcpDriver(config), _ => throw new NotSupportedException() }; } }这样一个上位机项目可以同时挂多个品牌的PLC，互不干扰。这个抽象思想源自实际项目：当时客户要求一个线体同时对接西门子和汇川两台设备，我用这个工厂模式一天就搞定接入。
5. 常见问题与排查技巧实录
5.1 连接类问题
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| Connect超时 | IP不通、PLC防火墙 | 先ping，再Telnet测102端口 |
| 连接成功但Read超时 | Rack/Slot参数错误 | 核对硬件组态，S7-1200/1500用0/0 |
| 连接频繁断开 | PLC通讯负载过高 | 增大轮询间隔，PLC侧优化通讯负载 |
| S7-200 SMART连不上 | CPU类型选错 | 用S7200Smart，不能用S7200 |
有一回客户现场S7-1200老连不上，我在远程排查了很久。最后发现是PLC的PROFINET口接的交换机做VLAN隔离，上位机虽然在同一个网段但跨了VLAN。ping是通的，但102端口被交换机策略过滤了。用工具测一下端口通不通，能解决一半的“假连接”问题。
5.2 数据类问题
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 读出的Int和PLC里不一致 | 大小端差异 | Snap7默认返回大端，需SetWordOrder或手动反转 |
| Bool读数错位 | 位偏移算错 | 确认是按位偏移还是按字节偏移 |
| Real除以100才能对上 | PLC侧值类型是DInt | 检查变量类型定义 |
| 读出来的字符串乱码 | 编码不对 | 常见的是ASCII和UTF-8的差异 |
大小端这个问题是重灾区。S7协议是big-endian，而Intel架构的C#默认是little-endian。如果你用ReadBytes读一个Int，然后直接BitConverter.ToInt32，大概率得到错误的值。正确做法是：
byte[] raw = plc.ReadBytes(DataType.DataBlock, 1, 0, 2); short value = (short)((raw[0] << 8) | raw[1]);如果你用的是S7netplus的强类型方法（比如ReadInt），它内部已经处理了字节顺序，就不会遇到这个问题。所以我的建议是：优先用强类型API，少碰裸字节。
5.3 程序稳定性问题
长期跑的上位机，最怕内存泄漏和句柄泄漏。我用S7netplus时遇到过一个坑：如果断开连接后不调用Dispose()，PLC对象会持有底层Socket和COTP连接的句柄，反复重连几次之后内存占用飙升。
排查内存泄漏用dotnet-counters和PerfView，在.NET 6环境里非常方便：
dotnet-counters monitor --process-id <pid> --counters System.Runtime另外，如果你的UI层用了定时器反复刷新表格，记得用BeginUpdate/EndUpdate包裹大数据量刷新，否则UI线程会被拖死。再有，把耗时的通讯操作放到后台线程跑，用Invoke回到UI线程更新界面，这是基本素养。
5.4 环境与依赖问题
开发中常见的“无法加载一个或多个请求的类型”异常，几乎都出自两个原因：一是DLL版本冲突，二是引用了不兼容的target framework。比如你在.NET Framework 4.7.2项目里引用了某个只支持.NET Core的库，运行时就会报这个错。
解决方法是统一各项目的目标框架。现在新项目我一般直接统一到.NET 6，NuGet引用时留意看依赖图的兼容性符号。如果你的项目必须停留在.NET Framework，那就尽量少用新特性库，保持整个依赖树的框架版本一致。
6. 实操中的几个独家技巧
技巧一，调试S7通讯前，先在PLC侧用博途的“监控表”功能确认地址和数据。很多“通讯问题”其实是PLC里根本没这个数据，地址格式又写错了，浪费两个小时才发现是DB编号写错。
技巧二，用系统时间戳标记每条采集数据，而不是用PLC时间。因为很多老型号PLC的时钟不准确，或者根本没有电池维持时钟。上位机本地时间戳还能配合数据分析做时间对齐，这个习惯帮我省了很多麻烦。
技巧三，给通讯层加一个“裸报文日志”开关。在开发阶段打开，把bytesToDuplicate存下来，有问题时直接看报文交互。Snap7有事件钩子可以做包抓取，开启后保存最近的500条通信记录。这个功能上线后一定要关掉，不然日志文件几天就能涨到几个G。
技巧四，上位机界面上的数据刷新频率和数据采集频率要分开。采集频率可以高，比如500ms一圈，但界面上1秒刷新一次就够了。否则UI重绘开销会影响采集线程稳定性。
技巧五，信号字（Word）和浮点（Real）的系数处理。很多设备数据实际值需要在原始值基础上乘以系数或加上偏移才能得到真实的工程量。建议在做数据访问层时就把系数换算集成进去，不要在UI层做。这样数据库存的就是标幺后的真实值，避免报表分析时还得还原。
7. 写在最后的经验之谈
做上位机通讯这行，能稳定跑上几个月的系统，靠的不是某一个高深算法，而是把每一层的基础打扎实。硬件物理链路可靠，网络通畅，PLC通讯负载合理，代码层处理好异常、重连、超时，这套体系自然稳定。反而是一上来就追求复杂架构的，往往在调试阶段就倒在最不起眼的字节序上。
这个项目我最满意的地方不是用了多新的技术，而是它足够“朴素”：没有任何一个环节依赖特定硬件型号或特定的商业组件，所有核心通讯逻辑都摆在一份开源的Snap7之上。无论未来PLC换型，还是上位机要从Windows迁到Linux工控机，改动量都能控制在两天以内。
如果你正准备做类似的项目，我的建议是先别急着写界面，把通讯核心层写好、测好，再往上面堆业务。通讯不稳，界面再炫酷也是空中楼阁。等通讯层稳定了，你会发现剩下的功能开发都变得特别顺手。
本文还有配套的精品资源，点击获取
