上位机与安川PLC通讯：MEMOBUS协议解析及C#调用VB.net控件实战

简介这套上位机与安川PLC通讯控件及C#使用实例源码由工控老马出品并亲测校正主要面向工业自动化领域需要借助C#或VB.NET实现上位机与安川PLC通讯的开发者既能帮助新手快速上手控件调用也能为有经验的工程师提供可复用的通讯封装与调试思路。压缩包内共33个文件核心为6个VB源码文件与3个DLL控件库另含可直接运行的EXE测试程序、PDB调试符号、XML配置及Resx资源文件等整体仅157KB结构紧凑便于对照学习与二次开发。目前已有720人学习下载。借助这份源码读者既能查看控件在VB.NET中的底层实现也能在C#测试程序中理解具体调用流程配合工程文件、解决方案与界面截图可大幅节省从零搭建上位机通讯环境的时间是掌握安川PLC通讯机制的高性价比参考资料。1. 从一次现场通讯失败说起为什么我放弃了裸写串口做上位机开发的同行应该都有过这种经历设备联调现场PLC那边程序下好了触摸屏监控数值一切正常可你的C#程序通过串口发指令PLC就是没反应。用串口助手抓包看报文格式明明是对的CRC校验也算完了问题到底出在哪这个场景几乎每个工控上位机开发者都踩过。安川PLC的MEMOBUS协议从报文结构到寄存器映射和标准的Modbus协议有不少细节差异你在网上搜到的Modbus例程直接搬过来用十有八九在功能码和地址换算上出偏差。这也是为什么我拿到这套上位机与安川PLC通讯控件及C#使用实例源码时会专门花时间去拆它——它把安川PLC的MB协议封装成了通用控件测试程序是C#写的控件本身用VB.net实现正好覆盖了工控上位机开发中最常见的技术组合。这套资源适合正在做上位机与安川PLC通讯开发的工程师也适合刚入门想搞懂通讯控件封装思路的新人。它不只是一份能跑的代码更是一个可以直接拿来做二次开发的通讯底座。下文我会从MEMOBUS协议原理、控件封装结构、C#调用细节到通讯排错技巧一层层拆开讲。2. MEMOBUS协议与安川PLC通讯的地址映射机制2.1 MEMOBUS和Modbus到底差在哪安川PLC的串口通讯基于MEMOBUS协议底层是Modbus协议的一个工业变种。很多初学者直接用Modbus例程去连安川PLC指令发出去能收到响应但读写的数据就是不对根源往往在于地址区映射方式不同。在Modbus协议中寄存器地址是线性的比如40001到49999是保持寄存器区。但MEMOBUS把安川PLC的存储区分成了多个独立区域每个区有独立的地址编号规则。举一个实际例子写入PLC的保持寄存器Modbus里面你直接操作40001地址即可但在安川PLC的MEMOBUS协议下你需要先把目标地址换算成协议报文内部使用的16进制地址。安川PLC存储区主要分为以下几种存储区类型对应PLC区域通讯报文中的地址范围读写支持CIO区外部输出/输入继电器0000~07FF读/写WR区工作继电器0000~01FF读/写HR区保持继电器0000~01FF读/写DM区数据内存0000~01FF读/写AR区辅助继电器0000~00FF读/写地址映射的差异是通讯失败的高发区。你通过串口助手发一条读保持寄存器的指令报文中地址字段用的是协议内部的十六进制编号不是你在PLC编程软件里看到的那个地址。这个换算关系如果不搞清楚程序写再多也白搭。2.2 报文结构与CRC校验的实现细节MEMOBUS的报文帧格式和标准Modbus RTU基本一致从站地址、功能码、起始地址、数据、CRC16校验。串口参数是9600波特率、8数据位、1停止位、无校验这个配置在安川PLC的默认通讯设定下是标准参数。// CRC16校验计算Modbus RTU标准多项式0xA001 public static ushort CRC16(byte[] data, int len) { ushort crc 0xFFFF; for (int i 0; i len; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) { crc 1; crc ^ 0xA001; } else { crc 1; } } } return crc; }这里用的是查表法之外最直白的位运算法每字节要循环8次。通讯频率不高时完全够用但如果是高频读写场景建议改成查表法速度能提升一个数量级。CRC计算完成后低字节在前、高字节在后填入报文的最后两位这个字节顺序是初学最容易搞反的地方。提示MEMOBUS协议中从站地址默认是0即使用00作为站号时PLC不做地址校验直接响应。多台PLC组网通讯时才需要设置不同站号。上位机开发时单机调试直接用站号0可以省掉不少排查时间。2.3 功能码选择与典型通讯指令实例安川PLC的MEMOBUS协议支持的功能码不多常用的是以下几个01H读取线圈状态位读取03H读取保持寄存器内容05H写入单个线圈10H写入多个寄存器其中03H和10H是使用频率最高的两个功能码。读取DM区数据和写入DM区数据是上位机最常见的操作因为PLC的运算结果和生产参数大多存放在DM区中。// 读取DM区数据的报文构造站号0 功能码0x03 起始地址DM100 读取长度2个寄存器 byte[] readCommand new byte[] { 0x00, // 从站地址 0x03, // 功能码 读保持寄存器 0x00, 0x64, // 起始地址 0x0064 100 0x00, 0x02, // 读取寄存器数量 0x00, 0x00 // CRC占位 }; ushort crc CRC16(readCommand, 6); readCommand[6] (byte)(crc 0xFF); // CRC低字节 readCommand[7] (byte)((crc 8) 0xFF); // CRC高字节注意这里的地址映射规则PLC编程软件里看到的是DM100但在通讯报文中地址字段填的是0x0064也就是100的十六进制。这是MEMOBUS协议中DM区起始地址和实际编号一致的特例。换到CIO区就不是这个逻辑了CIO区在协议中从0000开始映射。网上很多例程直接复制修改起始地址不做区域换算这也是半天调不通的原因之一。3. 通讯控件的源码结构拆解与VB.net实现分析3.1 控件工程的整体架构打开这套资源里的MEMOBUS_COM工程解决方案里包含两个项目一个是VB.net编写的通讯控件另一个是C#编写的WinForm测试程序。控件项目本身用的是VB.net测试程序用C#这种跨语言组合在实际工业项目里很常见——老牌工控企业用VB.net沉淀了不少组件库而新写上位机界面的人大多用C#。控件项目的类结构按职责拆成了三个层面串口通讯层封装SerialPort的打开、关闭、收发数据协议层负责报文构造、响应解析、CRC校验业务接口层向上位机暴露读写PLC数据的公共方法串联口收发是很多初学写上位机通讯最容易出问题的地方。如果收数据用DataReceived事件去拼接缓存很容易出现半包、粘包的情况。这套控件里的做法是收到响应后按帧长度截取实际开发中这个逻辑需要根据PLC的响应超时时间做调整。3.2 报文收发与超时处理的实现控件在实现上有几个细节值得单独拿出来说。先看C#测试程序里调用控件读PLC数据的代码// 创建通讯控件实例 MEMOBUS_COM.MemobusControl mb new MEMOBUS_COM.MemobusControl(); // 设置串口参数并打开连接 mb.PortName COM3; mb.BaudRate 9600; mb.DataBits 8; mb.StopBits 1; mb.Parity None; mb.Open(); // 从DM100开始读取2个字的数据 short[] data mb.ReadDM(100, 2);串口参数设置部分暴露的是字符串类型的停止位和校验位参数这是VB.net控件的典型风格。调用方传进来的参数在控件内部会转换成SerialPort所需的枚举类型屏蔽了部分细节。实际项目里如果把波特率写死成9600会有局限性自动化设备中PLC通讯为了追求速度很多现场改用19200甚至38400波特率所以我在二次开发时会把这个参数做成可配置项。超时处理是另一个值得关注的设计点。串口通讯不是HTTP请求没有天然的对方必须响应的保证。PLC在总线繁忙或程序跑飞时可能完全不回应你。控件内部对每条指令都设了超时时间超时后会触发Timeout事件上位机可以在这个事件里做重试或告警处理。 VB.net控件内部读取DM区的实现 Public Function ReadDM(ByVal startAddr As Integer, ByVal count As Integer) As Short() 构造读取报文 Dim cmd(7) As Byte cmd(0) 0 站号 cmd(1) H3 功能码 03H cmd(2) CByte((startAddr 8) And HFF) cmd(3) CByte(startAddr And HFF) cmd(4) CByte((count 8) And HFF) cmd(5) CByte(count And HFF) 计算CRC并填充 Dim crcValue As UShort Crc16(cmd, 6) cmd(6) CByte(crcValue And HFF) cmd(7) CByte((crcValue 8) And HFF) 发送并等待响应 SendData(cmd) Dim response As Byte() WaitResponse(128) 解析响应数据 End Function地址参数的处理上做了一次位运算拆分高字节放前、低字节放后这是Modbus RTU协议固定的大端序。收到响应后需要校验从站地址、功能码、数据长度三个字段再取出有效数据做类型转换。这套代码的逻辑很完整适合直接拿去做二次开发的模板。3.3 位地址读写与字地址读写的差异处理安川PLC的数据类型分成位和字两种。线圈类数据如CIO区的单个输出点按位操作而DM区的数值数据按字操作。控件中对这两种操作分别提供了接口。// 读取单个位地址 bool coilStatus mb.ReadCoil(0, 100); // 写入单个位地址 mb.WriteCoil(0, 100, true); // 读取字地址数据 short[] values mb.ReadDM(100, 10); // 写入多个字地址数据 short[] writeData new short[] { 100, 200, 300 }; mb.WriteDM(100, writeData);位操作和字操作在报文构造上差别很大的地方在于功能码和地址表示方式。写入单个线圈用05H功能码写入多个寄存器用10H功能码而读取操作中读取线圈用01H读取寄存器用03H。实际项目中常见一个坑是你需要写多个连续的线圈状态比如控制流水线上8个气缸的动作顺序如果用05H逐条写一次要发8条指令通讯效率很低。标准Modbus协议支持用0FH功能码批量写线圈但安川PLC的MEMOBUS协议支持范围有限所以控件里没提供这个接口上位机侧需要自行把这8次写操作合并成一次10H功能码的寄存器写入在字节位与寄存器字之间做转换。4. C#调用VB.net通讯控件的实战与跨语言互操作细节4.1 在Visual Studio中引用VB.net控件工程C#项目调用VB.net控件本质上是程序集级别的引用。在解决方案中直接添加项目引用是首选方式这样调试时可以直接跟进VB.net代码内部看报文收发细节。具体操作是在C#工程中右键引用选择项目选项卡勾选MEMOBUS_COM项目。这里有一个容易踩的坑如果VB.net控件的目标框架版本和C#工程不一致引用会报黄色警告图标运行时会抛FileLoadException异常。一般需要把两个工程的目标框架统一到.NET Framework 4.6.2或4.7.2。提示如果控制器的目标框架设置不一样务必统一。实际开发中遇到的大多数DLL引用失败根源都是目标框架不兼容。测试程序里控件的实例化方式和C#自建类库没什么区别直接用类型名声明即可using MEMOBUS_COM; public partial class MainForm : Form { private MemobusControl _plcControl; public MainForm() { InitializeComponent(); _plcControl new MemobusControl(); } }命名空间和类名保持一致VB.net控件在使用上完全无缝。要注意的是VB.net中的模块级变量默认为静态在控件设计时如果用了Module而不是Class来做内部共享状态多线程访问时会有关键区问题。4.2 从控件接口设计看C#调用VB.net的语法差异VB.net控件对外暴露的方法名、参数顺序和C#代码直接对应但在类型转换上有一个值得注意的地方。VB.net中Integer类型是32位有符号整型Short类型是16位有符号整型正好对应C#的int和short。看下面这个C#调用语句// 注意返回类型是short数组不是int数组 short[] dmValues mb.ReadDM(100, 2); // 如果PLC中存储的是无符号数值需要做转换 ushort value (ushort)dmValues[0];上述代码中从PLC读回来的的short类型在C#中如果不注意符号位读到的值一旦超过32767就会显示成负数。PLC的DM数据区中存放FIFO读写指针计数这类不断累加的数据时数值很容易突破32767。这个坑在调试时很隐蔽因为小数值调试时永远正常数值一大就出现负数第一反应往往是查PLC程序而不是查类型转换。再看写入场景的对比// 写法一直接传short数组 mb.WriteDM(100, new short[] { 1, 2, 3 }); // 写法二int数组需要逐个强转 int[] sourceData new int[] { 1000, 2000, 3000 }; short[] shortData Array.ConvertAll(sourceData, x (short)x); mb.WriteDM(100, shortData);控件内部如果没做溢出保护传入超过short范围的数据会被截断静默丢失高位。我在调试这套控件时PLC侧写的是温度采集值现场能到200°C乘以10倍精度后是2000在short范围内没事。但如果你做的是计数累加类应用或者直接把传感器的32位原始值往DM区塞就一定会出问题。4.3 跨线程访问UI与通讯控件的协作上位机通讯控件和界面的交互是另一个高频出错点。C#的WinForm中串口的数据接收线程不是UI线程直接在DataReceived回调里修改界面控件会抛InvalidOperationException异常。测试程序里用了Invoke机制做线程切换private void plcControl_DataReceived(object sender, EventArgs e) { if (this.InvokeRequired) { this.BeginInvoke(new Action(() { // 在UI线程中更新显示 textBoxValue.Text _currentValue.ToString(); })); } }这是工业上位机中典型的回调线程回UI线程模式。逻辑上分批处理收到完整响应后内核触发事件UI线程在事件处理器中安全更新。如果你在主线程中写一个while循环去调用ReadDM读取并且间隔很短会直接卡死界面——串口操作的阻塞时间虽然短但累加起来足以让窗口失去响应。更稳妥的做法是开一个后台通讯线程做轮询把读到的数据放进队列或共享变量UI线程通过Timer定时刷新显示。这套资源里的测试程序用的是后一种方式定时器每200ms触发一次读取刷新。5. 通讯调试的三个关键技巧抓包验证、参数调优与互操作避坑拿到这套源码后建议不要直接接PLC联调先把串口通讯的验证链路搭起来。用虚拟串口工具如Virtual Serial Port Driver创建一对互联的COM口再用Modbus Slave模拟软件挂在其中一个串口上你的C#程序连另一个串口先跑通读写再上真机。第一件事是验证CRC校验的实现是否正确。在网上找一个CRC16-Modbus在线计算器用手工构造的报文对拍。如果一个报文算出结果一致再换带不同长度数据字段的报文测试。CRC一旦错了PLC侧直接静默丢弃不会返回任何错误码这是最折磨人的故障类型。第二个技巧是分析功能码和地址映射的换算逻辑。对着安川PLC手册逐个区域排查你要读写的是CIO区、WR区、HR区还是DM区报文地址填对没有。CIO区的0000地址对应PLC的CIO 0通道。如果使用了CX-Programmer软件打开内存视图对照着看一条条核对比对着手册猜要高效得多。调试中如果发现PLC能收到指令但执行结果不对多在报文起始地址上找问题。比如你要读DM区的数据PLC软件设置里起始地址是D100但通讯协议报文里填的是100的十六进制0x0064。高位字节必须放在前一个字节这一条错了PLC会回复错误码02H非法地址。第三个关键点在VB.net与C#互操作的边界上。这套资源中控件是VB.net、测试程序是C#这就涉及COM互操作的注册问题。如果你是直接引用工程或DLL文件这种方式不需要额外注册但如果通过COM组件方式引用VB.net控件就需要在目标机器上执行RegAsm注册命令。部署到没有安装.NET框架环境的工控机上时还有依赖项缺失的问题需要一并处理。# 使用.NET Framework自带的RegAsm工具注册VB.net控件为COM组件 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe MEMOBUS_COM.dll /codebase /tlb:MEMOBUS_COM.tlb5.1 通讯参数的选型参考参数项推荐值备注波特率9600 或 19200通讯距离超过15米建议降速数据位8固定停止位1固定校验位NonePLC默认配置超时时间500~1000ms依据PLC扫描周期调整重试次数2~3次超过3次建议直接报错超时时间与PLC的扫描周期相关。如果PLC的扫描周期较长比如梯形图很复杂从收到指令到返回响应的间隔就会变大。设的500ms超时实际调试时发现偶发超时改成1000ms后情况明显改善。这个参数的设定原则是能短则短不能短就加长太短误报故障太长会让操作工感觉界面卡顿。最后再提一个这套源码里隐藏的小技巧控件中预留了通讯日志功能可以在调试阶段把收发报文全部记录到文本文件里。日志文件里的报文内容比串口助手抓包多了时间戳和CRC校验结果排错效率会高很多。联调完成后建议关闭日志功能因为工控机长期运行会产生大量日志文件把C盘塞满以后PLC通讯会异常中断。安川PLC的通讯调试不是高深技术关键在于把协议细节吃透、把地址映射搞对、把异常处理想全。这套源码把最底层的报文封装和解析都做完了剩下就是根据你现场设备的实际情况做参数适配。拿到代码后第一件事不是改功能而是把上面说的三个验证步骤跑一遍确认通讯链路是通的再去做数据交互。本文还有配套的精品资源点击获取