HslCommunication 11.3.2：一个DLL搞定多品牌PLC通讯

简介HslCommunication 是一款面向工业自动化与上位机开发场景的通信库版本 11.3.2基于 .NET Framework 4.5 构建。它封装了串口、网口以及多种常见工业总线的读写逻辑适合需要快速对接 PLC、仪表和自控设备的上位机工程师与中高级开发者使用。该版本已去除授权码限制无需调用 SetAuthorizationCode 进行激活长期使用也不会过期解决了正式版激活码到期导致的中断问题。资源包共 10 个文件以核心 DLL 程序集为主另有 UI 控件与 JSON 辅助库、演示与升级用的 exe 程序、XML 接口注释文档及说明文本具体包含 5 个 dll、2 个 exe、1 个备份、1 个 xml、1 个 txt压缩包总大小约 5.69MB。目前已有 3829 人学习/下载。解压提取核心 dll 后即可直接引用到 .NET 4.5 项目中无需激活配置配套演示 exe 能快速展示通信效果备份与升级工具方便版本回退与维护xml 文档则便于查看接口说明。整体开箱即用适合需要稳定通信组件且不愿受授权限制的开发者。1. HslCommunication 11.3.2一个 DLL 搞定 PLC 通讯的工业通讯库做上位机开发的人八成都在厂家 SDK 的泥潭里挣扎过西门子一个 DLL三菱一个 DLLModbus 又要自己去拼报文换一个品牌整条通讯链路重写。HslCommunication 这个 NET 4.5 版本的通讯库把西门子、三菱、欧姆龙、Modbus TCP/RTU 这些主流协议全部收进了一个 DLL 里用统一的读写接口对接不同 PLC省掉的远不止是集成时间。这个版本对老项目的价值尤其大——很多产线工控机还跑在 Win7 和 .NET Framework 4.5 上升级 .NET 6/8 根本不现实而 11.3.2 是兼容这套老环境的好选择。下文会用实际代码把这个库的连接、读写、排错全部过一遍让你拿到手能直接照着落地。2. 通讯库选型之前HslCommunication 是怎么把协议装进一个 DLL 的2.1 核心架构从设备对象到统一读写接口HslCommunication 的底层设计并不神秘它把所有 PLC 通讯协议抽象成了「设备对象 统一读写方法」两层结构。设备对象负责协议解析、报文封装、socket 连接和异常重试而上层暴露给调用者的只有 Read、Write、ReadAsync、WriteAsync 这一组通用方法。以西门子 S7 协议为例底层就是标准的 ISO-on-TCPRFC 1006封装库内部处理了 TPKT、COTP、S7 协议头的组包和解包。你不需要知道 S7 报文里那个 ROSCTR 字段怎么填只需要建立一个 SiemensS7Net 对象然后调用 ReadString 或 Write 就行。// 创建西门子 S7-1200 设备对象指定 IP 和 PLC 型号 SiemensS7Net s7 new SiemensS7Net(SiemensPLCS.S1200, 192.168.0.10); s7.ConnectTimeOut 5000; // 5秒连接超时 s7.OperateResult s7.ConnectServer(); // 建立连接逻辑说明SiemensPLCS.S1200是库内置的 PLC 枚举不同型号的建连方式和地址区映射规则不一样枚举会把型号差异消化掉。ConnectServer()返回值是OperateResult类型它同时携带成功标志和错误描述。HslCommunication 里几乎每个 I/O 方法都返回这个结果对象所以在调用后立刻判断IsSuccess是标准姿势。参数说明ConnectTimeOut是连接超时毫秒数默认值对跨网段部署的场景过短建议起步 5000但设置过大会让断线重试变得很慢产线上一般 3000~8000 之间比较合理。2.2 资源里已经内置了什么从 DLL 引用到多语言支持拿到 11.3.2 的压缩包解开后核心就是HslCommunication.dll但里面藏的东西远不止基础通讯。库内置了这些实用模块模块功能适用场景SiemensS7Net / SiemensMPIS7 协议 / MPI 协议S7-200/300/1200/1500 及部分数控系统MelsecMcNet / MelsecA1ENet三菱 MC 协议 / A 系列 1E 帧Q/L/iQ-R 系列 PLCModbusTcpClient / ModbusRtuModbus 主站实现仪表、变频器、IO 模块等从站设备OmronFinsNetFINS/UDP 与 TCP欧姆龙 CJ/CS/NJ/NX 系列HslCommunication 内置日志分级日志与运行记录产线现场的故障定位虚拟 PLC 设备在本机模拟一个 PLC 从站没有实体 PLC 时的联调测试这个虚拟 PLC 功能特别值得重视。很多项目死在「上位机写完了、PLC 还没到场」的等待期。你先在开发机上启动一个虚拟设备把整个流程跑通等真机上电后只需要换 IP 就行。省下的调试时间谁经历过谁知道。2.3 为什么老项目该选 11.3.2 而不是追新这里有个容易被忽略的坑HslCommunication 后来的版本对 .NET Core / .NET 5 做了拆分编译如果直接把新版本 DLL 丢进 .NET Framework 4.5 的老项目引用能成功但运行时可能会崩因为目标框架的 API 兼容性已经不保证了。11.3.2 是还完整支持 .NET 4.5 的版本分支这在工控行业是个很现实的约束——现场工控机系统没法随便升开发环境也被锁死在 VS2019 之前的版本。版本选择上我的建议是如果你的环境锁死 NET 4.5安心用这个版本新项目用 NET 6再去追新版本。别跨大版本硬用。3. 落地实战从空白程序到完成 PLC 读写3.1 工程配置步骤与两个必须注意的设置先把资源里解压出的HslCommunication.dll复制到你的项目libs目录然后在 Visual Studio 里右键项目 → 添加引用 → 浏览选中这个 DLL。这里有个常见错误直接双击 DLL 添加没问题但注意别把整个 release 文件夹都弄进引用路径。第二步是目标框架确认。右键项目 → 属性 → 应用程序 → 目标框架确认是.NET Framework 4.5或以上。如果项目是 .NET Core直接放弃这个版本去 NuGet 搜新版。using HslCommunication; using HslCommunication.Profinet.Siemens; using HslCommunication.Profinet.Melsec; using HslCommunication.ModBus;逻辑说明这三个命名空间就覆盖了 90% 的常见场景。HslCommunication是基础类型OperateResult、日志等Profinet.Siemens是西门子全系实现ModBus是 Modbus 主从站实现。如果你的设备是欧姆龙把Profinet.Omron也加上。参数说明引用添加后在解决方案平台那里确认是 x86 还是 x64。这个和 PLC 通讯本身无关但如果后续你要调用原生 ODBC 或第三方库位数不一致会直接报BadImageFormatException。3.2 西门子 S7-1200 读写一个完整的读写周期下面这段是生产环境里最常见的一套操作读字符串、读浮点数、写整数。S7 协议里字符串在 DB 块中通常以「长度字节 字符数据」的形式存储直接用 ReadString 可以自动跳过长度字节但要注意 ReadString 返回的字符串长度参数是从哪开始的。SiemensS7Net s7 new SiemensS7Net(SiemensPLCS.S1200, 192.168.0.10); s7.ConnectTimeOut 5000; OperateResult connect s7.ConnectServer(); if (!connect.IsSuccess) { Console.WriteLine(连接失败: connect.Message); return; } // 读取 DB1 块第 0 字节开始的字符串最大长度 20 字符 OperateResultstring readStr s7.ReadString(DB1.0, 20); if (readStr.IsSuccess) Console.WriteLine(读取到的字符串: readStr.Content); // 读取 DB2 块第 4 字节开始的浮点数 OperateResultfloat readFloat s7.ReadFloat(DB2.4); if (readFloat.IsSuccess) Console.WriteLine(读取到的浮点数: readFloat.Content); // 向 DB3 块第 2 字节写入整数 100 OperateResult write s7.Write(DB3.2, (short)100); if (write.IsSuccess) Console.WriteLine(写入成功);逻辑说明地址串DB1.0的语义是 DB 块号为 1、起始字节偏移为 0这是 SiemensS7Net 类型的统一寻址格式内部会换算为 S7 协议里 8 字节的地址参数。读字符串时第二个参数20是最大读取长度超过这个长度的字符串会被截断写整数时用的是(short)100这是 16 位有符号整型和 STEP7 里的 INT 对应写 32 位要转成int。参数说明ReadString的第三个参数有一个Encoding重载默认 ASCII 编码。但现场很多触摸屏和扫码枪往 DB 区写入的是 GBK 编码中文读出来是乱码几乎可以确定是编码问题。我一般会显式指定Encoding.DefaultWindows 下即 GB2312去兼容老触摸屏的习惯。整套流程走完后务必调用s7.ConnectClose()来释放连接。有些设备对象还持有后台重连线程不显式关闭会导致进程退不干净。3.3 Modbus TCP 读写与批量操作Modbus TCP 在库里的实现更为直接默认走 502 端口采用 MBAP 报文头加功能码的格式。库里封装的 ModbusTcpClient 可以读线圈、读寄存器、写单个/多个寄存器而且支持以x3;y0的地址格式一次性操作多个位置。ModbusTcpClient modbus new ModbusTcpClient(192.168.0.20, 502); modbus.ConnectTimeOut 3000; OperateResult connect modbus.ConnectServer(); if (!connect.IsSuccess) { Console.WriteLine(Modbus 连接失败: connect.Message); return; } // 读取保持寄存器 0 到 9共 10 个寄存器 OperateResultshort[] readReg modbus.ReadInt16(0, 10); if (readReg.IsSuccess) { foreach (short v in readReg.Content) Console.WriteLine(寄存器值: v); } // 向寄存器 100 写入 16 位数值 200 OperateResult write modbus.Write(100, (short)200); if (write.IsSuccess) Console.WriteLine(Modbus 写入成功);逻辑说明ReadInt16读到的short[]与仪表手册上的寄存器表一一对应。很多仪表习惯把浮点数拆成两个寄存器32 位 float此时可以用库里的ReadFloat按大端序合并两个寄存器——不用自己手动移位拼数。Write传入short时对应功能码为 06 写单个寄存器传入short[]时对应功能码 16 写多个寄存器这个区别在控制变频器启停时要特别小心。参数说明ReadInt16(0, 10)的第一个参数为起始寄存器地址十进制第二个参数是读取数量。Modbus 从站对单次读取长度有上限常见限制是 125 个寄存器即 250 字节超过会触发从站异常响应此时需要分批读取。3.4 异步读写别在 UI 线程卡界面任何同步读写方法在工业现场都有「卡死 UI」的风险——PLC 掉站时socket 超时时长取决于系统 TCP 重传时间可能长达 20 秒。虽然库里有ConnectTimeOut属性但那是建连超时不是读写超时。读写过程的等待时间完全由 TCP 层决定。// 异步读取 PLC 数据不阻塞 UI 线程 private async void btnRead_Click(object sender, EventArgs e) { // 在 UI 线程上通过 async/await 异步等待结果 OperateResultstring readStr await s7.ReadStringAsync(DB1.0, 20); if (readStr.IsSuccess) txtResult.Text readStr.Content; else txtResult.Text 读取失败: readStr.Message; }逻辑说明ReadStringAsync是库内置的 async 版本内部会调用Task.Run完成实际网络 I/O并且延续性回到当前同步上下文。WinForm 里用async void是事件处理器的既成事实虽然 async void 不是好实践但在 UI 事件里它反而是最简洁的写法。读写这种互不依赖的操作也可以用Task.WhenAll并行处理。参数说明注意OperateResult本身没有 async 版本但所有返回OperateResult的方法几乎都有对应的XxxAsync没有的比如自定义拼接报文才需要手写Task.Run包一层。4. 避坑手册六个必须掌握的排查经验4.1 异步方法在 WinForm 里抛异常导致程序崩溃现象点击按钮调用ReadAsync读取数据PLC 掉线时程序直接闪退连错误提示都没看到。原因async void事件处理器内异常无法被常规 try-catch 捕获只会触发全局的Application.ThreadException而库内部把网络异常封装成了OperateResult返回值而不是抛出异常——但如果你在 await 前后用了using或try以外的东西仍然会把异常抛进 UI 线程。解决await 返回后一定要先查IsSuccess再访问Content并且整个方法内用 try-catch 包住所有逻辑。另外把库内的日志接到你自己的日志框架掉线时先看日志再猜原因。private async void btnRead_Click(object sender, EventArgs e) { try { var readStr await s7.ReadStringAsync(DB1.0, 20); if (readStr.IsSuccess) txtResult.Text readStr.Content; else txtResult.Text 读取失败: readStr.Message; } catch (Exception ex) { txtResult.Text 异常: ex.Message; } }4.2 PLC 型号枚举选错导致读写偶发超时现象S7-300 的 PLC程序里用了SiemensPLCS.S1200枚举连接正常但读写特别慢偶发超时。原因S7-300 的通讯机制与 S7-1200 有细微差别PDU 长度协商和连接资源类型库内部对不同枚举走的是不同的协议支付路径。型号选错不会报「型号不匹配」而是表现为底层时序上的不稳定。解决设备选型定下来后先核对枚举列表。S7-200 用S7_200S7-300 用S7_300S7-1500 用S15001200 用S1200。另外注意 S7-200 的地址区没有 DB 块只能读 V 区对应V前缀或直接偏移。4.3 连接不释放导致 PLC 通讯资源耗尽现象程序连续开关连接几十次后PLC 拒绝再建立连接重启程序后恢复。原因早期 S7-300/400 和部分 Modbus 网关的并发连接数有限通常 4~8 个每次ConnectServer没有调用ConnectClose就退出PLC 保持半开连接直到超时。解决确认每次读写的using或者 try-finally 里都释放了连接ConnectClose是幂等操作重复调用不会有副作用。另外也可以考虑用一个常驻连接对象避免频繁建连断连。库内部对掉线有自动重连机制但仅在连接状态检测到失效后触发。4.4 字符串读取乱码与字节序混乱现象PLC DB 区里是中文汉字用ReadString(DB1.0, 20)读出来全是问号和乱码读浮点数时数值是反的。原因编码和字节序双重问题。S7 协议在内存中以大端序存储多字节数据而很多仪表和触摸屏写入时是按 CPU 原生的小端序写的。库内部的ReadString默认按 ASCII单字节处理遇到 UTF-8 或 GBK 中文自然全变?。解决统一编码。读中文时显式传Encoding.GetEncoding(GB2312)写回时保持同一个编码。字节序问题通过Reverse工具方法处理s7.ReadFloatReverse(DB2.0)。这些是库内置的重载代码可读性比手动BitConverter强得多。4.5 虚拟 PLC 与真实 PLC 表现差异现象用虚拟 PLC 联调时一切正常换到真机后数据读写重复失败但 ping 是通的。原因虚拟 PLC 运行在本机走的是127.0.0.1没有跨网段的路由、防火墙和交换机 VLAN 隔离问题真机走工业以太网时PLC 侧可能启用了访问保护S7-1200/1500 默认开启这会让协议层连接受阻。解决先在虚拟 PLC 上验证程序逻辑再在真机上排查三件事——PLC 里「允许来自远程对象的 PUT/GET 通讯访问」是否勾选上位机 IP 是否与 PLC 在同一网段S7 协议没有跨网段路由功能交换机端口是否为 TRUNK 模式导致 VLAN 隔离。这三项是 90% 现场通讯问题的根源。4.6 库内日志与自己的日志混合后的定位困难现象出问题时库里自动打印的报文日志和你自己打印的业务日志混杂在一起分不清先后顺序排查链路断了。原因库的日志走的是自带的文件输出机制默认写到程序目录时间精度只到毫秒自己的日志如果走 NLog 且没有同步同一个时钟基准两边日志对不上。解决设置LogNet的基础路径并打开文件日志LogNet.LogWriteComnob true; HslCommunication.BasicFramework.SoftBasic.SetLogMessageCondition(1);逻辑说明LogNet是 HslCommunication 内置的日志网络对象支持分级过滤和文本输出。打开报文级输出后TCP 层的每个收包、发包包括原始十六进制数据都会记录下来。出问题时把这段报文贴出来比任何描述都更能说明问题——到底谁在发、谁没响应、响应是不是延迟全部一目了然。参数说明SetLogMessageCondition(1)里的 1 表示 Debug 级别会输出全部调试信息。产线稳定运行阶段建议调回 2Info否则日志增长非常快几天就能把磁盘塞满。5. 进阶技巧用虚拟设备把调试周期缩短一半5.1 起一个本机 Modbus TCP 从站空载联调模拟项目 X 里甲方要求上位机在 PLC 到场前先完成全部 UI 和数据绑定开发。做法是在开发机上直接起一个库自带的虚拟从站本机程序连本机先把读取链路、显示逻辑、异常处理全部调通。// 方法一绕开真实 PLC直接在内存里模拟一个从站 ModbusTcpServer server new ModbusTcpServer(); server.ServerStart(502); // 监听本机 502 端口 // 模拟从站数据更新每 100ms 更新一组寄存器值 while (true) { short[] values new short[10]; for (int i 0; i values.Length; i) values[i] (short)(i * 100 DateTime.Now.Second); server.Write(0, values); Thread.Sleep(100); }逻辑说明ModbusTcpServer在库内实现了一个完整的 Modbus 从站协议栈包含监听端口、请求解析和响应生成。你的上位机代码不需要任何修改只需要把ModbusTcpClient的 IP 指向127.0.0.1即可跑通全部逻辑。这种做法最大的好处是UI 开发、数据曲线、报表生成全部提前真实设备到场只是换 IP 的事情。参数说明ServerStart(502)的端口号可以任意指定但注意 Windows 上端口小于 1024 一般不会被占用生产环境如果和现场其他服务冲突改成 1502 之类的高位端口也行。用这个办法某跨平台系统的现场联调从原来的三周压缩到了三天——剩下的时间全花在与真实 PLC 的通讯参数核对和网络配置上。从那以后我每次做这类项目都强制先走一遍虚拟设备联调能提前暴露出来 60% 的通讯层问题。希望帮到你。本文还有配套的精品资源点击获取