1. 通信方案选型没有最好的协议只有最合适的场景1.1 先搞清你面对的西门子PLC型号在动手写C#代码之前我建议你先花五分钟确认自己手里到底是哪一代西门子PLC。这决定了后面所有通信方案的选择选错了方向代码写得再漂亮也白搭。西门子当前市面上的主流PLC大概分成这几类老当益壮的S7-200和S7-200 Smart经典稳重的S7-300/400以及现在项目里最常见的S7-1200/1500。这几类PLC在通信能力上完全不是一个量级S7-200走串口居多S7-300/400多用MPI/DP到了S7-1200/1500开始全面拥抱以太网支持S7协议、Modbus TCP、Profinet、OPC UA。你如果拿S7-200的老思路去连S7-1500大概率会卡在固件版本和协议差异上。还有一个容易忽略的点同一型号不同固件版本支持的通信能力也可能不一样。比如S7-1200早期固件对S7协议访问DB块有限制到V4.0之后才放开了优化DB的访问权限。所以我一般建议先通过博途TIA Portal看一下PLC的实际型号、固件版本再决定方案。1.2 主流通信方式横向对比我整理了一张对照表基本覆盖了C#和西门子PLC通信的所有主流路子。这个表我项目里一直留着选型时直接对照。通信方式适用PLC优点缺点C#常用库S7协议西门子私有S7-1200/1500部分S7-300/400读写速度快直接访问I/O、M、DB区无需额外授权私有协议文档不公开需要依赖成熟库S7.Net PlusSharp7HslCommunicationModbus TCPS7-1200/1500S7-200 Smart需加模块或固件支持工业标准协议跨品牌兼容库多且成熟只能访问保持寄存器/线圈数据结构不够直观EasyModbusNModbusHslCommunicationOPC UAS7-1200/1500固件支持S7-200 Smart不行跨平台、安全、自带信息模型适合MES/SCADA集成配置较复杂实时性不如原生S7协议OPCFoundation.NetStandard.Opc.Ua串口自由口S7-200S7-200 Smart简单直接适合低速点位成本最低速率低需自己拼帧解析仅适合点对点System.IO.Ports从这张表能看出没有哪一种是绝对王者。如果你只是做一块小屏或者本地主机读数据S7协议最方便如果要和对面的第三方设备交互Modbus TCP最稳如果整个车间需要上云、做数据中台OPC UA才是正解。1.3 我为什么优先推荐S7协议除非你用的是老款200我在实际项目里只要是S7-1200/1500第一反应都是走S7协议。原因很直接S7协议是西门子的“母语”对PLC内部存储区的访问最直接读写DB、M、I/Q区都像操作本地数组一样简单。Modbus TCP虽然也能读但要把DB块里的数据一个一个映射到保持寄存器地址上光维护映射表就够头疼的。当然S7协议也有一个门槛它是未公开的私有协议正常情况下需要“逆向”或者用现成库。但好在开源社区已经把这条路趟平了像S7.Net、Sharp7、HslCommunication都是稳定的方案C#里几十行代码就能连上PLC读写数据。所以除非你手里是S7-200这种老古董否则别纠结直接S7协议。不过这里也提醒一句S7协议默认使用102端口如果你的PLC和上位机之间有防火墙记得放行TCP 102否则连IP都ping通了还是报“目标计算机积极拒绝”。2. 上手最快的方案使用S7.NetS7-1200/1500实例2.1 准备工作PLC侧的参数设置先说一个最常见的翻车点代码写完一跑报“无法连接到远程服务器”第一反应往往是查IP但很多时候问题其实出在PLC侧没开访问权限。S7-1200/1500默认情况下只允许HMI和博途本体访问CPU不会把所有“外部PUT/GET通信”都打开。你需要先在博途里给CPU的“防护与安全”设置中勾选“允许来自远程对象的通信”或者更具体地在“连接机制”里勾上“允许来自远程对象的PUT/GET通信访问”。如果你用的是S7-1500还要确认一下固件版本有些旧固件默认禁止PUT/GET需要更新。另外最好在博途中给PLC分配一个固定IP比如192.168.0.10上位机设为192.168.0.20子网掩码255.255.255.0用一根网线直连或者走交换机。曾经我遇到一个间歇性连不上的问题折腾半天发现是上位机开了两个网卡一个连着外网一个连着PLC网段路由表混乱导致数据包出不去。建议调试阶段把不用的网卡先禁用掉。DB块的设置也有讲究。默认情况下S7-1200/1500的DB块是“优化的块访问”这种DB块在S7协议通信里不能直接按偏移量访问需要通过符号名。而S7.Net这类库很多还是基于经典DB的绝对地址方式所以我更习惯在创建DB的时候取消勾选“优化的块访问”这样可以像老PLC一样直接按字节偏移读写省去符号解析的麻烦。当然如果项目要求必须用优化访问那就得用符号寻址的接口HslCommunication对这块支持得更好一些。2.2 创建C#项目并引用S7.Net打开Visual Studio创建一个.NET Framework或者.NET 6/8的Windows窗体应用或控制台程序都可以。我这次以WPF和C#为例因为热词里提到了WPF C#其实WinForm也一样。S7.Net的安装方式很简单在NuGet包里搜索“S7.Net”或“S7netplus”选择作者是“S7netplus”的那个稳定版本安装。这个库是GitHub上开源的作者一直在维护对S7-1200/1500支持得不错对S7-200系列也有一部分兼容性。装好之后引用里多了一个“S7.Net”命名空间就可以开始写连接代码了。2.3 连接PLC并读取写入数据的核心代码直接上干货。下面这段是我在项目中实测过的最小可运行代码连接一台IP为192.168.0.10的S7-1200CPU型号为S7-1200using System; using S7.Net; class Program { static void Main(string[] args) { using (var plc new Plc(CpuType.S71200, 192.168.0.10, 0, 1)) { plc.Open(); if (plc.IsConnected) { Console.WriteLine(连接成功); // 读取I0.0输入点 bool input0 plc.Read(I0.0); Console.WriteLine($I0.0 {input0}); // 读取Q0.0输出点 bool output0 plc.Read(Q0.0); Console.WriteLine($Q0.0 {output0}); // 读取M区某个字节比如MB0 byte mByte plc.Read(MB0); Console.WriteLine($MB0 {mByte}); // 写一个变量到M区比如把1写入MW10 plc.Write(MW10, (short)1); // 读取DB1.DBW0字 short dbw0 plc.Read(DB1.DBW0); Console.WriteLine($DB1.DBW0 {dbw0}); // 读取DB1.DBD4实数 float dbd4 plc.Read(DB1.DBD4); Console.WriteLine($DB1.DBD4 {dbd4}); } else { Console.WriteLine(连接失败); } plc.Close(); } } }这里有几个细节说明一下。new Plc(CpuType.S71200, 192.168.0.10, 0, 1)里的0和1是机架号和插槽号S7-1200默认是0和1S7-300有的需要填0和2S7-1500则通常也是0和1但具体要看硬件组态如果读不对CPU会拒绝连接。plc.Read(DB1.DBW0)这种字符串寻址方式是S7.Net封装好的底层会转换成S7协议需要的Any类型读起来非常方便。写入时最容易反的错误是数据类型不匹配。比如MW10是一个字你如果写plc.Write(MW10, 1)编译器会自动把int转成Int32但MW10在S7里是16位高16位会被截断甚至导致“对象类型不匹配”异常。所以我写MW的时候一定用(short)强转写DBD浮点数就用(float)强转一定要类型精确。2.4 读取不同类型数据的字节序处理西门子PLC的数据存储是“大头在前”的也就是大端模式而你的电脑x86/x64默认是小端模式。好在S7.Net底层已经帮你处理了大部分字节序问题直接用Read读整数、浮点数都没问题。但如果你用ReadBytes去读原始字节然后自己转换就容易踩坑。举个例子你要读DB1.DBD4里的浮点数如果直接用plc.Read(DB1.DBD4)返回的就是float没问题。但如果你用ReadBytes(DataType.DataBlock, 1, 4, 4)拿到的是4个字节需要自己倒序后BitConverter.ToSingle一把。这里放一段我用ReadBytes的常用封装public static float ReadFloatFromBytes(Plc plc, int db, int startByteAdr) { byte[] bytes plc.ReadBytes(DataType.DataBlock, db, startByteAdr, 4); Array.Reverse(bytes); return BitConverter.ToSingle(bytes, 0); }同理读16位整数要倒序两个字节读32位整数要倒序四个字节。而S7.Net的Read已经帮你把倒序做了所以我建议能用Read就别用ReadBytes。还有一个常见需求是读字符串。PLC里用字符串类型在DB块中存放一般包含长度前缀读出来的是字节数组需要根据编码和长度截取。这个在后面的问题排查里我再细讲。3. 老PLC的救星Modbus TCP与串口自由口实战3.1 Modbus TCP与S7-1200/200 Smart的配合如果是S7-200 Smart它官方就支持Modbus TCP只需要在组态里开启服务器模式把需要通信的V区映射到保持寄存器外部就能用标准Modbus协议读取。S7-1200/1500则需要通过博途里添加MB_SERVER指令块来组态Modbus TCP服务器步骤稍微多一点但只要配一次后续上位机用任何语言的Modbus库都能读写完全不挑客户端。Modbus TCP最方便的地方在于任何支持Socket的编程语言都能轻松对接。C#里用NModbus或者EasyModbus都很成熟。我用得比较多的是EasyModbus因为它的API非常简单几行代码就能连上而且封装的寄存器读写方法特别符合直觉。3.2 使用EasyModbus实现通信以S7-1200为例假设我PLC里通过MB_SERVER组态了保持寄存器起始地址为0上位机现在要读取前10个保持寄存器代码可以这么写using EasyModbus; var client new ModbusClient(192.168.0.10, 502); client.Connect(); if (client.Connected) { // 读取保持寄存器从地址0开始读10个 int[] registers client.ReadHoldingRegisters(0, 10); for (int i 0; i registers.Length; i) { Console.WriteLine($寄存器[{i}] {registers[i]}); } // 写单个寄存器把地址5的值设为100 client.WriteSingleRegister(5, 100); // 写多个寄存器 client.WriteMultipleRegisters(0, new int[] { 1, 2, 3 }); } client.Disconnect();这段代码没有任何魔法EasyModbus把Modbus TCP协议的数据帧封装好了你只需要指定IP、端口、功能码和寄存器地址。如果PLC组态里寄存器地址不是从0开始记得统一偏移量否则读出来全是0或者报错。Modbus TCP的坑主要是寄存器数量限制。一个请求最多读125个保持寄存器超过就要分批读。如果数据量很大比如要读200个字节的设备状态建议拆成两个请求或者让PLC侧把数据紧凑排列减少读的次数。实际项目中我常用的是轮询方式用一个定时器每隔100ms读一次关键数据这样界面上的数据就能动态刷新。3.3 西门子200自由口通讯例程热词里有这里专门讲S7-200不是Smart没有以太网口通信最常用的就是串口自由口模式。所谓自由口就是PLC的串口可以按照你自己定义的协议收发字节流非常灵活但也意味着数据帧要自己拼自己解析。典型场景是这样PLC作为一个数据采集终端通过串口向上位机发送一组数据帧比如帧头AA 55命令码长度数据段累加和校验帧尾0D 0A。C#这边用System.IO.Ports.SerialPort来接收解析过程如下using System; using System.IO.Ports; class PlcSerialPort { SerialPort _port; public void Connect(string portName, int baudRate) { _port new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One); _port.DataReceived OnDataReceived; _port.Open(); } void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { byte[] buffer new byte[_port.BytesToRead]; _port.Read(buffer, 0, buffer.Length); ParseFrame(buffer); } void ParseFrame(byte[] data) { // 查找帧头 0xAA 0x55 for (int i 0; i data.Length - 1; i) { if (data[i] 0xAA data[i 1] 0x55) { int len data[i 3]; // 假设第4字节是数据长度 byte[] payload new byte[len]; Array.Copy(data, i 4, payload, 0, len); // 校验和验证略 Console.WriteLine(BitConverter.ToString(payload)); } } } }这里我用的是SerialPort.DataReceived事件注意这个事件是后台线程触发的在事件里不能直接操作UI控件需要用Invoke或Dispatcher.BeginInvoke回到UI线程。很多人一开始不知道这个会莫名其妙报“线程间操作无效”的异常这个印象非常深刻。自由口通信的关键是协议对齐。PLC侧发送帧的波特率、数据位、校验位必须和C#里设置完全一致。曾经我遇到过一个奇怪的问题上位机收的每一帧都少了几个字节后来发现是PLC发送缓冲区没清空上一帧残留的数据跟在下一帧后面发出来了。解决办法是让PLC在发送完毕后加延时或者严格按帧间隔发送比如两帧间隔50ms。3.4 串口通信中的坑超时与粘包串口跟网口不一样没有TCP那种流控制和分包机制数据就是一串字节流。如果PLC连续发了多帧上位机一次可能收到好几帧的数据这叫“粘包”如果一帧很长上位机可能分几次才收全这叫“拆包”。处理思路很简单每次收到数据先放进一个缓冲区然后按帧头和长度把完整的一帧“抠”出来剩余的数据继续留着等待下一次接收。我用的办法是维护一个Listbyte缓冲区每次接收末尾追加然后循环查找帧头并判断长度是否足够够的话就截取一帧处理再把已处理的部分移除。这样不管怎么拆包粘包都能正确还原。具体代码不贴了原理就是“拼积木”。4. 另一种思路OPC UA跨平台与信息模型4.1 OPC UA是什么为何适合复杂系统如果你的项目不是单一上位机和PLC点对点通信而是涉及到MES、SCADA、历史数据库甚至要把数据传到云端那么OPC UA会是一个更优雅的方案。OPC UA不只是通信协议它还定义了数据模型、订阅机制、安全认证和报警事件。比如你读PLC里的一个电机温度在OPC UA里它不再是一个内存地址而是一个带有工程单位的变量节点上层系统看到的是“温度75℃”而不是“DB1.DBD475”。S7-1200/1500从较新的固件开始原生支持OPC UA服务器。你只需要在博途里启用OPC UA功能并配置好服务端证书C#这边就可以通过标准OPC UA客户端库去连接和订阅数据。4.2 使用OPCFoundation.NetStandard.Opc.Ua 客户端库示例NiGet包搜索OPCFoundation.NetStandard.Opc.Ua这是OPC基金会的官方客户端库功能全但API偏底层。下面是一个简化的连接并读取节点值的示例using Opc.Ua; using Opc.Ua.Client; using Opc.Ua.Configuration; // 配置证书 var application new ApplicationInstance { ApplicationName CSharpOpcClient, ApplicationType ApplicationType.Client, // 证书路径等配置省略 }; await application.LoadApplicationConfiguration(Config.xml, silent: false); await application.CheckApplicationInstanceCertificates(false, 0); using (var session await Session.Create( application.ApplicationConfiguration, new ConfiguredEndpoint(null, new Uri(opc.tcp://192.168.0.10:4840)), false, MySession, 60000, null, null)) { var nodeId new NodeId(ns3;s\Motor1\.\Temperature\); var value (float)session.ReadValue(nodeId).Value; Console.WriteLine($Motor1 Temperature: {value}); }这个代码里最麻烦的是证书配置。OPC UA为了安全默认要求服务端和客户端互相信任你需要把客户端的证书安装到PLC的信任列表里或者临时把安全策略改成None仅测试环境。生产环境千万别用None否则数据在网络上裸奔一旦车间网络被入侵PLC控制指令都可能被篡改安全风险非常大。实际上如果只是简单读写我更倾向于先用S7协议快速验证通信链路等项目需要对接第三方软件了再引入OPC UA。因为OPC UA的配置复杂度和调试成本比S7协议高不少不适合拿来当最底层的数据通道。5. 我在实际项目中踩过的坑常见问题与排查记录5.1 连接超时或连接不上的排查步骤每次有同事问“为什么连不上PLC”我脑子里都会自动跑一遍排查脚本按顺序执行基本能解决九成问题。第一步先ping PLC的IPping不通说明网络物理层有问题查网线、交换机、IP段。第二步ping通了但连不上TCP 102端口用telnet测一下IP 102端口通不通不通就去PLC侧检查访问权限和防火墙上位机防火墙常见PLC侧基本没有防火墙。第三步看PLC型号和CPU类型参数是否匹配S7-300和S7-1200的机架号和插槽号不一样。第四步如果前几步都对还报“协议错误”多半是DB块设置了优化访问或者是固件版本太旧不支持PUT/GET。有一次我花了两个小时排查一个与1500的连接问题最后发现是博途里勾选了“仅允许安全通信”导致S7协议裸连接被拒绝。把安全通信关掉或者配置证书后问题立刻解决。这种问题从代码里完全看不出来只能靠PLC侧日志和逐步排除。5.2 DB块读取数据错位优化块访问与绝对地址S7-1200/1500默认创建的DB块是“优化的块访问”数据地址是自动分配的没有固定的偏移量。S7协议通过绝对地址读写时需要“符号寻址”如果用DB1.DBW0去读往往读不到正确值甚至直接报“对象未找到”。解决方法是在DB块属性里取消勾选“优化的块访问”重新编译后DB块就有了明确偏移量才能用DB1.DBX0.0、DB1.DBD4这种方式访问。如果你因为某些原因无法取消优化访问那就用HslCommunication这类支持符号寻址的库。HslCommunication里读取优化DB的代码大致是HslCommunication.Profinet.Siemens.SiemensS7Net plc new HslCommunication.Profinet.Siemens.SiemensS7Net( HslCommunication.Profinet.Siemens.SiemensPLCS.S1500, 192.168.0.10); plc.SetPersist(); var result await plc.ReadAsync(DB1.DBX0.0);这个方法我已经在好几个项目里验证过确实能读优化访问DB里的变量。不过如果PLC侧还有SCL程序在改这些数据要注意变量名和实际物理地址的对应关系别读错对象。5.3 字节顺序与大小端以及浮点数、字符串的处理这个话题我前面简单提过这里再展开。西门子PLC传输数据时默认是大端字节序而C#里BitConverter默认是小端。如果你直接BitConverter.ToInt32(bytes, 0)去解释从PLC拿来的原始字节得到的整数会变成一个巨大的错误值。解决办法是先将字节倒过来再转换或者用库自带的方法。关于浮点数还牵扯到单精度和双精度的区别。PLC里REAL是32位浮点对应C#的floatLREAL是64位对应double。实际项目中我用得最多的是REAL所以读DBD时直接强转float没问题。但如果你用S7协议读了一个包含多个数据项的大缓冲区一定得注意字节偏移和类型长度错一位就是满屏“天文数字”。字符串的读取比数值更麻烦。S7中STRING类型通常有头部2字节最大长度和实际长度或者4字节然后再是字符内容。比如读取DB10.DBX0.0开始的一个STRING你需要先读前两个字节找到实际长度再从第三个字节开始按ASCII或UTF-8编码取值。由于S7中的字符串默认是Latin-1编码中文会乱码所以如果涉及中文建议PLC侧用WSTRING或者直接转成UTF-8字节数组放在DB里上位机再按UTF-8解析。5.4 读写性能优化批量读写与轮询周期在一些快节奏的产线上比如每100ms就要采集一批数据如果用单次Read一个点一个点地读性能会非常差因为每次读写都要走一次协议握手。实测下来S7协议单次读写耗时在毫秒级100个点循环读一遍可能就要几百毫秒根本跟不上。优化办法是使用批量读写。S7.Net里提供了ReadStruct和ReadBytesHslCommunication里也有Read支持地址数组批量读取。最常见的方式是利用S7协议可以连续读取多个连续字节的特点一次性把一段DB块的整体字节数组读回来然后在上位机内存里解析。比如我要读DB1中从DBW0到DBW20的连续10个字可以直接byte[] bytes plc.ReadBytes(DataType.DataBlock, 1, 0, 20); // 然后按偏移解析 short val0 (short)(bytes[0] 8 | bytes[1]); short val1 (short)(bytes[2] 8 | bytes[3]);注意一次读字节数不要太大S7协议单次请求PDU大小有限制S7-1200大概240字节S7-1500最多960字节左右超过要分多次。同时轮询周期也要合理不要小于PLC扫描周期否则读出来的数据根本不是同一时刻的快照逻辑判断会出错。5.5 界面卡死与异步处理很多刚接触C#上位机的朋友一跑代码点“连接”按钮后窗体就白屏了鼠标转圈几秒后弹出异常。这是因为连接、读写PLC是耗时操作你直接放在了UI线程里执行。PLC响应慢甚至超时界面自然卡死。解决方法是使用异步编程或者后台线程。最简单的是用async/await配合Task.Run把PLC操作放到线程池里。比如private async void BtnConnect_Click(object sender, RoutedEventArgs e) { btnConnect.IsEnabled false; try { await Task.Run(() plc.Open()); TxtStatus.Text $连接成功; } catch (Exception ex) { TxtStatus.Text $连接失败: {ex.Message}; } finally { btnConnect.IsEnabled true; } }同时数据刷新用System.Timers.Timer或者DispatcherTimer在定时器回调里读取数据后再通过Dispatcher.Invoke更新UI。这个套路在WPF和WinForm里都一样核心原则就是UI线程只做界面操作任何可能阻塞的操作都扔到后台。实际上我在设计一个监控界面时还会把“读取数据”和“写入命令”分开。读取用一个定时器循环写入只在用户点击按钮时触发。这样即使某次写入超时也只是那一次操作卡一下不会影响整个界面的数据刷新。如果你用同一个串口或同一个PLC对象同时读写还要加锁防止多线程同时向PLC发请求导致通信错乱这个坑可能比较隐蔽但一旦发生了会出现莫名其妙的“超时”和“数据错乱”。写在最后的一点体会做C#和西门子PLC通信这么多年最大的感受就是技术方案永远不是越高级越好而是越稳定越好。S7协议、Modbus TCP、OPC UA这些都是工具核心是摸清你的PLC型号、项目场景、数据量和实时性要求。如果只是一个小设备联机用S7.Net几十行代码就够了如果要做车间级数据采集可能OPC UA更方便。另外就是调试心态。通信问题有时候跟代码根本没关系网线松了、IP配错了、PLC安全设置没开这些都能让你查上一天。所以别急着写代码先把整个链路理一遍物理连接、网络配置、PLC组态、C#库调用每一个环节都确认无误后再开始写业务逻辑。有个小技巧我一直保留着写任何通信程序先把读取的数据打到控制台或者日志里看原始值确认数据帧正确后再做界面绑定。很多初学者上来就做图表、做动画结果数据源就是错的后面全白搭。希望这篇文章能帮你少走弯路。如果你正在连某个具体型号遇到问题不妨把PLC型号、固件版本、通信方式、报错信息都列出来按这个思路排查一遍大概率能解决。
