简介面向三菱数控系统开发与运维人员这份示例程序以C#源码形式演示数据采集实现方案解决机床状态实时监控、加工参数读取与故障日志获取等场景需求。压缩包大小约3.52MB内含FCSB1224W000参考手册PDF与SimCNC模拟环境相关文件前者帮助理解通讯协议和数据格式涵盖该型号机型的操作指南与技术规格后者可在无实体机床条件下模拟指令运行便于快速验证采集逻辑。已有620人学习。通过源码可掌握C#与三菱CNC建立连接、调用A2.exe通讯接口交换数据的完整思路包括通讯配置步骤和数据结构解析配合参考手册与仿真环境还能深入理解机台通信机制便于后续扩展至多型号数采或集成到现有系统。对自动化工程师、上位机开发者及CNC爱好者而言这是一份兼顾原理与实操的入门参考也可作为实际项目移植测试的基础模板。1. 三菱CNC数据采集Demo附带C#源码到底值不值得花时间研究如果你手里正在做机加工车间的设备联网、产量统计、主轴负载监控或者被老板要求“把几台三菱系统机床的数据弄到看板上”那这份带C#源码的三菱CNC数据采集Demo十有八九能省掉你两周以上的弯路。它解决的问题很具体机床控制系统不是数据库数据不会自己送出来得靠工程师选对协议、写好报文、处理字节序再把它变成一行行能看的数字。我在一个设备联网项目里第一次接触三菱CNC采集当时最懵的就是“到底走哪个口、发什么命令、读回来的十六进制怎么变成十进制”。后来发现一套完整可跑的C# Demo价值不在于它的界面多好看而在于它把三菱数控系统的采集链路打通了连接、读字软元件、解析响应、断线重连这些全是每个车间项目都得重复写的底层活。这篇文章我会按“先选型、再拆源码、后落地、最后避坑”的顺序把它讲透让你能基于它改出一套自己能维护的采集程序。2. 三菱CNC数据采集的两种可行路线自己组MC协议帧还是用官方通信库2.1 先分清采集出口内置以太网口、PMC寄存器和OPC UA三菱CNC的数据出口并不只有一个。常见的机床型号里能采的数据大概分三类NC内部变量主轴转速、进给倍率、当前坐标、PMC信号IO信号、刀具状态、以及工艺参数当前程序号、报警信息。其中最容易上手的是内置以太网口它支持MC协议也叫SLMP协议通过TCP或UDP直接读写软元件地址这也是大多数C# Demo默认走的路线。还有一类机型支持OPC UA这在较新的控制系统里越来越常见OPC UA的好处是免去了组帧的麻烦但需要额外配置安全证书而且免费实现里对报警和历史数据支持参差不齐。我一般建议先看机床的网络参数页面如果能找到IP地址和端口设置说明以太网口已经存在再查对应的接口说明里是否标明支持MC协议如果有就走Socket方案因为它在C#里最可控也不依赖官方组件在目标机器上能否安装。PMC寄存器路线往往是老工程师的首选因为PMC的D寄存器直接对应机床逻辑信号比如自动运行中、主轴运行中这些开关量读起来非常稳定。缺点是PMC地址表和数控系统内部变量地址表是两套东西不同机床系列映射规则不一样需要照着对应机型的软元件地址手册去查。对于Demo来说先用MC协议把D寄存器读通是最容易建立信心的路径。2.2 用Socket直接发MC协议帧报文结构与关键字节C#里自己发MC协议帧本质上是往TCP连接写一段字节序列再等数控系统回一段字节序列。常见的请求帧是3E帧二进制格式结构如下表所示字段顺序不能变长度也不能算错。字段长度字节说明副头部2二进制模式固定为0x50 0x00ASCII模式则不同序列号2每次请求自增用于和响应匹配请求数据长度2从网络号到请求数据区末尾的字节数网络号1通常为0x00PC号1通常为0xFFIO编号2通常为0x03 0xFF站号1通常为0x00监视定时器2单位250ms例如0x00 0x0A表示2.5秒命令2读取字软元件用0x04 0x01子命令20x00 0x00表示按字单位读取首地址4低字节在前含软元件代码软元件点数2建议单帧不超过960字举个例子读取D100开始的2个字请求体大致是网络号00、PC号FF、IO编号03 FF、站号00、监视定时器00 0A、命令04 01、子命令00 00、地址四字节64 00 00 A8这里A8是我常用的D寄存器二进制代码具体以你手里协议手册为准最后是点数00 02。这串字节拼好发给机床返回帧里就能拿到数据区。需要注意请求数据长度很容易算错。它是从网络号那个字节开始数的不含副头部和序列号。很多人把它算成了整个包的长度结果机床返回结束代码错误卡在这一步半天。我在写Demo时习惯先把报文拼成一个byte数组再用数组长度回填这个字段而不是手算能少踩一个坑。2.3 官方通信库与自写协议的取舍先看你的设备支持哪个口官方通信库常见的有面向CNC的EZSocket组件最大的优点是封装了底层的握手、超时、字节序你只需要调用一个“读”函数就能拿到十进制数值调试速度非常快。但它有两个现实问题一是组件依赖注册和运行环境换到没有预装的工控机上容易翻车二是出问题的时候是个黑匣子你很难知道它在哪一步失败纸面文档也不总是和你手里那台机床的系统版本完全对得上。自写协议则相反所有字节都看得见抓包、打日志都方便而且可以很方便地改成一个后台采集服务不依赖任何界面组件。缺点是前期要啃协议文档还要处理二进制帧、ASCII帧的差异。通常我的选型标准是这样的如果只是做一台机床的临时数据演示、三五天就要出效果优先用官方通信库如果要做一个长期运行的采集系统、要部署到多台机床或者将来可能对接不同品牌的设备那必须用自写Socket方案因为它不绑架你的运行环境。还有一点值得注意有些老型号机床的以太网口可能只支持指定端口的固定参数自写Socket时应该把IP、端口、协议类型做成配置文件而不是写死在代码里否则换到下一台机床时改一处漏一处的麻烦会成倍放大。这也是我下面拆解源码时反复强调的一个点。3. C#源码怎么组织采集线程、帧解析与掉线重连的骨架3.1 先定采集器接口再分两种实现一个能落地的C# Demo不应该把Socket逻辑和界面逻辑揉在一起。我最常用的是先定义一个采集器接口把“连接”“读取”“断开”三个动作抽象出来这样无论是用官方通信库还是自写协议都能在同一个界面上切换。public interface ICncCollector : IDisposable { bool Connect(string ip, int port, int timeoutMs); void Disconnect(); // 按软元件代码、起始地址和点数读取一批字数据 int[] ReadWords(byte deviceCode, ushort startAddr, ushort point); bool IsConnected { get; } }逻辑说明接口里的ReadWords返回的是int数组在自写协议实现里负责把MC协议响应帧拼成数值在官方通信库实现里则直接调用库函数转换。这样做的好处是上层采集服务完全不关心底层协议细节将来要加OPC UA实现也只是再写一个类的问题。参数说明timeoutMs是TCP连接的超时时间我一般设3000到5000毫秒太短容易在机床忙时误报太长会让断线重连失去意义。3.2 读取命令帧的构造三菱MC协议3E帧二进制模式下面这段代码是自写实现里最核心的帧构造方法它按3E帧二进制模式拼出一个读取请求。注意地址四字节的拼接顺序以及请求数据长度是从网络号开始算的。private static readonly byte[] Header { 0x50, 0x00 }; // 二进制模式副头部 private ushort seqId 0; private byte[] BuildReadFrame(byte deviceCode, ushort startAddr, ushort point) { var body new Listbyte(); body.Add(0x00); // 网络号 body.Add(0xFF); // PC号 body.Add(0x03); body.Add(0xFF);// IO编号三菱常用默认值 body.Add(0x00); // 站号 body.Add(0x00); body.Add(0x0A);// 监视定时器 2.5秒 body.Add(0x04); body.Add(0x01);// 0401 读取字软元件 body.Add(0x00); body.Add(0x00);// 子命令 按字单位 // 首地址低字节在前最后一个字节是软元件代码 uint addr startAddr; body.Add((byte)(addr 0xFF)); body.Add((byte)((addr 8) 0xFF)); body.Add((byte)((addr 16) 0xFF)); body.Add(deviceCode); // 点数 body.Add((byte)(point 0xFF)); body.Add((byte)(point 8)); var frame new Listbyte(); frame.AddRange(Header); frame.Add((byte)(seqId 0xFF)); frame.Add((byte)(seqId 8)); seqId; // 请求数据长度从网络号字节算到请求体末尾 frame.Add((byte)(body.Count 0xFF)); frame.Add((byte)(body.Count 8)); frame.AddRange(body); return frame.ToArray(); }逻辑说明frame的前6个字节固定是副头部、序列号和请求数据长度真正发给机床的字节流就是这段内容。请求数据长度在这里直接取body.Count避开了手工计算带来的“缺9个字节”的常见错误。参数说明deviceCode对于D寄存器我常用0xA8但不同手册和不同机型可能有差异所以这个值别写死在函数内部而是从上层传入。startAddr对于D寄存器直接写编号即可比如要读D100就传100。3.3 响应解析和字节序读回来的数为什么对不上发送帧只是第一步解析响应才是新手最容易卡住的地方。响应帧开头也是副头部、序列号、长度紧接着是结束代码和时间戳结束代码为0表示正常之后才是数据区。private int[] ParseWordResponse(byte[] resp, ushort point) { // 结束代码在第6和第7个字节小端 ushort endCode BitConverter.ToUInt16(resp, 6); if (endCode ! 0) throw new InvalidOperationException($读取失败结束代码 0x{endCode:X4}); // 数据从第8个字节开始每个字高字节在前 var result new int[point]; for (int i 0; i point; i) { int high resp[8 i * 2]; int low resp[9 i * 2]; result[i] (short)((high 8) | low); } return result; }逻辑说明这里把每个字按高字节在前拼成short这是我在三菱设备上采样的常见字节序如果你的机床返回的数值和面板显示不一致优先怀疑这一处高低字节对调就能验证。参数说明point必须和请求帧里的点数一致否则解析会错位。数据的符号位也容易踩坑转速、位置这些可能有正负的值建议用short类型接收后再转int而不是直接用ushort。3.4 采集线程与UI刷新别把Socket塞进UI线程Demo最常见的翻车方式是在按钮点击事件里直接同步读机床数据一慢界面就假死。正确做法是让采集跑在后台线程里把结果丢进一个队列界面用定时器去取。我经常用BlockingCollection来做线程间数据传递。private CancellationTokenSource cts new CancellationTokenSource(); private BlockingCollectionint[] dataQueue new BlockingCollectionint[](new ConcurrentQueueint[]()); private async Task PollLoop(ICncCollector collector, byte deviceCode, ushort startAddr, ushort point, int intervalMs) { while (!cts.IsCancellationRequested) { if (!collector.IsConnected) { await Task.Delay(intervalMs, cts.Token); continue; } try { var data collector.ReadWords(deviceCode, startAddr, point); dataQueue.Add(data, cts.Token); } catch (Exception ex) { // 记录日志不要在这里强行重连见下方说明 } await Task.Delay(intervalMs, cts.Token); } }逻辑说明采集循环只负责读和丢队列断线重连交给独立的重连逻辑去处理避免在一次调用里反复尝试连接把系统拖垮。界面端只需要按固定频率从dataQueue里取最新一份数据刷新显示这样即便机床偶尔慢一点界面也不会卡死。参数说明intervalMs是轮询周期我一般设500到1000毫秒看板和监控用500毫秒足够统计报表用1到2秒也不会丢数据没必要追求太快的刷新反而会增加机床通信模块的负担。4. 把Demo跑起来并接到产线数据流上4.1 最小验证步骤先连通、再读值、后写值拿到Demo源码后别急着接真实业务数据先按下面的顺序跑通链路每一步都验证通过再进下一步。先确认机床侧的IP地址和端口号通常在系统面板的网络设定页面里能看到把电脑的IP改成和机床同一网段用ping命令确认二层通了。然后在Demo里填上IP和端口连接再读一个你确定有值的地址比如机床里某个已被触发的PMC信号地址。我习惯先读一个固定写入的数值来验证比如在机床侧先给D100写一个已知整数再用Demo去读看返回是否一致。这步通过说明通信链路和帧解析都没问题。之后再读主轴转速、当前坐标这类会变化的量验证字节序和符号位。最后才是写操作写之前务必确认地址不会影响机床运行最好是用一个空的PMC寄存器做测试写坏一个地址让机床报警的事不是没发生过。这个流程不仅是Demo的验收步骤也是一套通用的现场排错方法。凡是链路问题都能在“先连通、再读值、后写值”里定位到阶段不用蒙着头抓包。4.2 从Demo到落地CSV、数据库还是直接推给上层系统Demo一般只是把数据读出来显示但生产环境往往需要把这些数据存下来或推给MES。常见做法有三档最简单的按分钟追加写CSV文件成本低、好排查适合单机演示再进一步写进SQLite或SQL Server配合查询界面做历史趋势如果要对接MES一般是在采集服务里把数据整理成JSON通过HTTP接口推给上层系统而不是让MES直接连机床。我推荐先做一个独立的采集服务进程把协议采集、数据落库、上报任务分开。采集服务维持和机床的长连接轮询数据落库模块负责写数据库上报模块只管HTTP推送。这样即使上报接口挂了采集和落库不受影响数据不会丢。Demo源码里如果只有界面部分扩展成服务也不难关键是当初有没有把采集逻辑和界面分开所以前面提到的接口设计很重要。4.3 一组可抄的初始化参数超时、重试、轮询周期怎么设参数推荐值说明TCP连接超时3000~5000ms太短容易误判太长影响重连速度读取超时3000ms机床忙时可能延迟抓包确认后再调断线重试间隔10~30秒避免频繁重连导致机床通信模块过载轮询周期500~1000ms看板500ms统计报表1~2秒即可单帧读取点数不超过960字超出一帧容易触发协议限制拆帧读日志保留天数30天排查历史问题用按天滚动删除这些参数不是写死就完事每台机床的通信负载不一样。我见过一台老机床轮询周期压到200ms结果机床显示屏都卡了把周期调到1秒后一切正常。参数设计上一定留出配置文件或数据库配置项不要埋在代码里。另外采集服务要记录每次断线的时间点和原因这个日志才是你后期调参的真正依据比猜靠谱得多。5. 三菱CNC数据采集常见问题与排查现场最容易翻车的五个点5.1 能Ping通却连不上端口号和CNC侧协议开关现象电脑能ping通机床的IP但程序连接超时抓包发现TCP握手都完成了就是没有协议响应。原因最常见的是端口号不对或者数控系统参数里MC协议服务没有启用二者缺一不可。解决在机床面板的网络设定里找到通信协议开关确认为启用接口程序里把端口号和机床设置里显示的端口保持一致。另外有些机型会对访问来源做限制确认电脑IP是否在白名单范围内。5.2 返回结束代码不为0多半是帧长度或地址越界现象连接正常发送帧后很快收到响应但结束代码不是0x0000界面报“读取失败”。原因请求数据长度算错、软元件点数超出允许范围、地址越界都可能导致协议拒绝。解决把发送的报文按字节打出来和协议示例逐字节比对重点看长度字段点数改成比如1个字再试确认不是点数问题。请求数据长度从网络号开始算起这一条至少能解决一半的此类问题。5.3 读数忽大忽小字节序、符号位和32位数据拼接现象读取主轴转速数值和面板显示不一致有的位翻转有的负值显示成很大的正数。原因响应数据区每个字的高低字节顺序处理反了或者没有按有符号数解析又或者目标数据本身是32位浮点数你只读了16位。解决先读一个已知数值确认单字解析的正确性再针对32位数据连续读两个字按IEEE754浮点拼接。我在Demo里留下了一个只读单字的版本目的就是让验证过程足够简单避免一次牵扯太多变量。5.4 采集服务跑几天就卡死线程与超时没弄干净现象程序刚启动一切正常跑几个小时后界面没反应或Socket异常重启后又能撑一段时间。原因同步读取阻塞了界面线程或者Socket在异常后没有正确关闭资源最终耗尽。解决把采集放到后台线程读取时设置socket.ReceiveTimeout重连前先关闭旧连接。我从自己的项目里总结出来的习惯是每次异常都打印完整堆栈和当前线程ID这类卡死问题只要能看到日志定位一般不超过十分钟。5.5 换机型就全线崩溃别照抄地址映射表现象同一套程序在A机床上采得好好的连到B机床后读数全乱甚至读回0。原因不同系列数控系统的软元件地址映射不一样D寄存器编号规则、PMC映射区域都可能有差异网上抄来的地址表不一定适用新机型。解决每台机床接入前先拿该机型的地址手册核对一遍关键地址验证顺序还是先读已知值再读业务变量。这个坑不靠写代码能绕过去只能靠规范的接入流程来兜底。6. 一个能保命的排查技巧拿已知值反推协议细节最后一个技巧是我每次对接陌生三菱机床时都会用的先读已知值再用它反推字节序、地址偏移和32位拼接规则。具体做法是在机床可用寄存器里挑一个当前值明确的点比如把某个空D寄存器手动写入十进制1234然后用程序读回来看原始字节是什么顺序。如果抓到的响应数据是04 D2说明高字节在前如果是D2 04那你就要把解析逻辑里的高低字节对调改成低字节在前拼字。这个方法之所以高效是因为它把未知问题缩小成一个坐标系地址对不对、长度对不对、字节序对不对用一次已知值的读取就能同时验证三件事。我现场排查时还会顺手把windows上抓到的原始包转发一份到调试日志字段挨个核对five minutes基本就能判断问题是出在连接、报文还是解析层。对于32位浮点数就写入一个已知的浮点值比如1.5然后连读两个字按大端和小端各拼一次看哪次还原出1.5规则自然就清楚了。调试时养成的另一个习惯是打开数据变化曲线再对照机床面板数字看几秒钟。如果曲线方向和面板一致但数值有固定比例差去查倍率参数如果曲线抖动但面板稳定多半是读取了正在变化的缓冲区换个地址就好。这套“先已知值再动态值”的流程我用了很久至今没遇到哪台三菱机床是靠它搞不定的整理到你的Demo维护手册里希望帮到你。本文还有配套的精品资源点击获取
简介面向三菱数控系统开发与运维人员这份示例程序以C#源码形式演示数据采集实现方案解决机床状态实时监控、加工参数读取与故障日志获取等场景需求。压缩包大小约3.52MB内含FCSB1224W000参考手册PDF与SimCNC模拟环境相关文件前者帮助理解通讯协议和数据格式涵盖该型号机型的操作指南与技术规格后者可在无实体机床条件下模拟指令运行便于快速验证采集逻辑。已有620人学习。通过源码可掌握C#与三菱CNC建立连接、调用A2.exe通讯接口交换数据的完整思路包括通讯配置步骤和数据结构解析配合参考手册与仿真环境还能深入理解机台通信机制便于后续扩展至多型号数采或集成到现有系统。对自动化工程师、上位机开发者及CNC爱好者而言这是一份兼顾原理与实操的入门参考也可作为实际项目移植测试的基础模板。1. 三菱CNC数据采集Demo附带C#源码到底值不值得花时间研究如果你手里正在做机加工车间的设备联网、产量统计、主轴负载监控或者被老板要求“把几台三菱系统机床的数据弄到看板上”那这份带C#源码的三菱CNC数据采集Demo十有八九能省掉你两周以上的弯路。它解决的问题很具体机床控制系统不是数据库数据不会自己送出来得靠工程师选对协议、写好报文、处理字节序再把它变成一行行能看的数字。我在一个设备联网项目里第一次接触三菱CNC采集当时最懵的就是“到底走哪个口、发什么命令、读回来的十六进制怎么变成十进制”。后来发现一套完整可跑的C# Demo价值不在于它的界面多好看而在于它把三菱数控系统的采集链路打通了连接、读字软元件、解析响应、断线重连这些全是每个车间项目都得重复写的底层活。这篇文章我会按“先选型、再拆源码、后落地、最后避坑”的顺序把它讲透让你能基于它改出一套自己能维护的采集程序。2. 三菱CNC数据采集的两种可行路线自己组MC协议帧还是用官方通信库2.1 先分清采集出口内置以太网口、PMC寄存器和OPC UA三菱CNC的数据出口并不只有一个。常见的机床型号里能采的数据大概分三类NC内部变量主轴转速、进给倍率、当前坐标、PMC信号IO信号、刀具状态、以及工艺参数当前程序号、报警信息。其中最容易上手的是内置以太网口它支持MC协议也叫SLMP协议通过TCP或UDP直接读写软元件地址这也是大多数C# Demo默认走的路线。还有一类机型支持OPC UA这在较新的控制系统里越来越常见OPC UA的好处是免去了组帧的麻烦但需要额外配置安全证书而且免费实现里对报警和历史数据支持参差不齐。我一般建议先看机床的网络参数页面如果能找到IP地址和端口设置说明以太网口已经存在再查对应的接口说明里是否标明支持MC协议如果有就走Socket方案因为它在C#里最可控也不依赖官方组件在目标机器上能否安装。PMC寄存器路线往往是老工程师的首选因为PMC的D寄存器直接对应机床逻辑信号比如自动运行中、主轴运行中这些开关量读起来非常稳定。缺点是PMC地址表和数控系统内部变量地址表是两套东西不同机床系列映射规则不一样需要照着对应机型的软元件地址手册去查。对于Demo来说先用MC协议把D寄存器读通是最容易建立信心的路径。2.2 用Socket直接发MC协议帧报文结构与关键字节C#里自己发MC协议帧本质上是往TCP连接写一段字节序列再等数控系统回一段字节序列。常见的请求帧是3E帧二进制格式结构如下表所示字段顺序不能变长度也不能算错。字段长度字节说明副头部2二进制模式固定为0x50 0x00ASCII模式则不同序列号2每次请求自增用于和响应匹配请求数据长度2从网络号到请求数据区末尾的字节数网络号1通常为0x00PC号1通常为0xFFIO编号2通常为0x03 0xFF站号1通常为0x00监视定时器2单位250ms例如0x00 0x0A表示2.5秒命令2读取字软元件用0x04 0x01子命令20x00 0x00表示按字单位读取首地址4低字节在前含软元件代码软元件点数2建议单帧不超过960字举个例子读取D100开始的2个字请求体大致是网络号00、PC号FF、IO编号03 FF、站号00、监视定时器00 0A、命令04 01、子命令00 00、地址四字节64 00 00 A8这里A8是我常用的D寄存器二进制代码具体以你手里协议手册为准最后是点数00 02。这串字节拼好发给机床返回帧里就能拿到数据区。需要注意请求数据长度很容易算错。它是从网络号那个字节开始数的不含副头部和序列号。很多人把它算成了整个包的长度结果机床返回结束代码错误卡在这一步半天。我在写Demo时习惯先把报文拼成一个byte数组再用数组长度回填这个字段而不是手算能少踩一个坑。2.3 官方通信库与自写协议的取舍先看你的设备支持哪个口官方通信库常见的有面向CNC的EZSocket组件最大的优点是封装了底层的握手、超时、字节序你只需要调用一个“读”函数就能拿到十进制数值调试速度非常快。但它有两个现实问题一是组件依赖注册和运行环境换到没有预装的工控机上容易翻车二是出问题的时候是个黑匣子你很难知道它在哪一步失败纸面文档也不总是和你手里那台机床的系统版本完全对得上。自写协议则相反所有字节都看得见抓包、打日志都方便而且可以很方便地改成一个后台采集服务不依赖任何界面组件。缺点是前期要啃协议文档还要处理二进制帧、ASCII帧的差异。通常我的选型标准是这样的如果只是做一台机床的临时数据演示、三五天就要出效果优先用官方通信库如果要做一个长期运行的采集系统、要部署到多台机床或者将来可能对接不同品牌的设备那必须用自写Socket方案因为它不绑架你的运行环境。还有一点值得注意有些老型号机床的以太网口可能只支持指定端口的固定参数自写Socket时应该把IP、端口、协议类型做成配置文件而不是写死在代码里否则换到下一台机床时改一处漏一处的麻烦会成倍放大。这也是我下面拆解源码时反复强调的一个点。3. C#源码怎么组织采集线程、帧解析与掉线重连的骨架3.1 先定采集器接口再分两种实现一个能落地的C# Demo不应该把Socket逻辑和界面逻辑揉在一起。我最常用的是先定义一个采集器接口把“连接”“读取”“断开”三个动作抽象出来这样无论是用官方通信库还是自写协议都能在同一个界面上切换。public interface ICncCollector : IDisposable { bool Connect(string ip, int port, int timeoutMs); void Disconnect(); // 按软元件代码、起始地址和点数读取一批字数据 int[] ReadWords(byte deviceCode, ushort startAddr, ushort point); bool IsConnected { get; } }逻辑说明接口里的ReadWords返回的是int数组在自写协议实现里负责把MC协议响应帧拼成数值在官方通信库实现里则直接调用库函数转换。这样做的好处是上层采集服务完全不关心底层协议细节将来要加OPC UA实现也只是再写一个类的问题。参数说明timeoutMs是TCP连接的超时时间我一般设3000到5000毫秒太短容易在机床忙时误报太长会让断线重连失去意义。3.2 读取命令帧的构造三菱MC协议3E帧二进制模式下面这段代码是自写实现里最核心的帧构造方法它按3E帧二进制模式拼出一个读取请求。注意地址四字节的拼接顺序以及请求数据长度是从网络号开始算的。private static readonly byte[] Header { 0x50, 0x00 }; // 二进制模式副头部 private ushort seqId 0; private byte[] BuildReadFrame(byte deviceCode, ushort startAddr, ushort point) { var body new Listbyte(); body.Add(0x00); // 网络号 body.Add(0xFF); // PC号 body.Add(0x03); body.Add(0xFF);// IO编号三菱常用默认值 body.Add(0x00); // 站号 body.Add(0x00); body.Add(0x0A);// 监视定时器 2.5秒 body.Add(0x04); body.Add(0x01);// 0401 读取字软元件 body.Add(0x00); body.Add(0x00);// 子命令 按字单位 // 首地址低字节在前最后一个字节是软元件代码 uint addr startAddr; body.Add((byte)(addr 0xFF)); body.Add((byte)((addr 8) 0xFF)); body.Add((byte)((addr 16) 0xFF)); body.Add(deviceCode); // 点数 body.Add((byte)(point 0xFF)); body.Add((byte)(point 8)); var frame new Listbyte(); frame.AddRange(Header); frame.Add((byte)(seqId 0xFF)); frame.Add((byte)(seqId 8)); seqId; // 请求数据长度从网络号字节算到请求体末尾 frame.Add((byte)(body.Count 0xFF)); frame.Add((byte)(body.Count 8)); frame.AddRange(body); return frame.ToArray(); }逻辑说明frame的前6个字节固定是副头部、序列号和请求数据长度真正发给机床的字节流就是这段内容。请求数据长度在这里直接取body.Count避开了手工计算带来的“缺9个字节”的常见错误。参数说明deviceCode对于D寄存器我常用0xA8但不同手册和不同机型可能有差异所以这个值别写死在函数内部而是从上层传入。startAddr对于D寄存器直接写编号即可比如要读D100就传100。3.3 响应解析和字节序读回来的数为什么对不上发送帧只是第一步解析响应才是新手最容易卡住的地方。响应帧开头也是副头部、序列号、长度紧接着是结束代码和时间戳结束代码为0表示正常之后才是数据区。private int[] ParseWordResponse(byte[] resp, ushort point) { // 结束代码在第6和第7个字节小端 ushort endCode BitConverter.ToUInt16(resp, 6); if (endCode ! 0) throw new InvalidOperationException($读取失败结束代码 0x{endCode:X4}); // 数据从第8个字节开始每个字高字节在前 var result new int[point]; for (int i 0; i point; i) { int high resp[8 i * 2]; int low resp[9 i * 2]; result[i] (short)((high 8) | low); } return result; }逻辑说明这里把每个字按高字节在前拼成short这是我在三菱设备上采样的常见字节序如果你的机床返回的数值和面板显示不一致优先怀疑这一处高低字节对调就能验证。参数说明point必须和请求帧里的点数一致否则解析会错位。数据的符号位也容易踩坑转速、位置这些可能有正负的值建议用short类型接收后再转int而不是直接用ushort。3.4 采集线程与UI刷新别把Socket塞进UI线程Demo最常见的翻车方式是在按钮点击事件里直接同步读机床数据一慢界面就假死。正确做法是让采集跑在后台线程里把结果丢进一个队列界面用定时器去取。我经常用BlockingCollection来做线程间数据传递。private CancellationTokenSource cts new CancellationTokenSource(); private BlockingCollectionint[] dataQueue new BlockingCollectionint[](new ConcurrentQueueint[]()); private async Task PollLoop(ICncCollector collector, byte deviceCode, ushort startAddr, ushort point, int intervalMs) { while (!cts.IsCancellationRequested) { if (!collector.IsConnected) { await Task.Delay(intervalMs, cts.Token); continue; } try { var data collector.ReadWords(deviceCode, startAddr, point); dataQueue.Add(data, cts.Token); } catch (Exception ex) { // 记录日志不要在这里强行重连见下方说明 } await Task.Delay(intervalMs, cts.Token); } }逻辑说明采集循环只负责读和丢队列断线重连交给独立的重连逻辑去处理避免在一次调用里反复尝试连接把系统拖垮。界面端只需要按固定频率从dataQueue里取最新一份数据刷新显示这样即便机床偶尔慢一点界面也不会卡死。参数说明intervalMs是轮询周期我一般设500到1000毫秒看板和监控用500毫秒足够统计报表用1到2秒也不会丢数据没必要追求太快的刷新反而会增加机床通信模块的负担。4. 把Demo跑起来并接到产线数据流上4.1 最小验证步骤先连通、再读值、后写值拿到Demo源码后别急着接真实业务数据先按下面的顺序跑通链路每一步都验证通过再进下一步。先确认机床侧的IP地址和端口号通常在系统面板的网络设定页面里能看到把电脑的IP改成和机床同一网段用ping命令确认二层通了。然后在Demo里填上IP和端口连接再读一个你确定有值的地址比如机床里某个已被触发的PMC信号地址。我习惯先读一个固定写入的数值来验证比如在机床侧先给D100写一个已知整数再用Demo去读看返回是否一致。这步通过说明通信链路和帧解析都没问题。之后再读主轴转速、当前坐标这类会变化的量验证字节序和符号位。最后才是写操作写之前务必确认地址不会影响机床运行最好是用一个空的PMC寄存器做测试写坏一个地址让机床报警的事不是没发生过。这个流程不仅是Demo的验收步骤也是一套通用的现场排错方法。凡是链路问题都能在“先连通、再读值、后写值”里定位到阶段不用蒙着头抓包。4.2 从Demo到落地CSV、数据库还是直接推给上层系统Demo一般只是把数据读出来显示但生产环境往往需要把这些数据存下来或推给MES。常见做法有三档最简单的按分钟追加写CSV文件成本低、好排查适合单机演示再进一步写进SQLite或SQL Server配合查询界面做历史趋势如果要对接MES一般是在采集服务里把数据整理成JSON通过HTTP接口推给上层系统而不是让MES直接连机床。我推荐先做一个独立的采集服务进程把协议采集、数据落库、上报任务分开。采集服务维持和机床的长连接轮询数据落库模块负责写数据库上报模块只管HTTP推送。这样即使上报接口挂了采集和落库不受影响数据不会丢。Demo源码里如果只有界面部分扩展成服务也不难关键是当初有没有把采集逻辑和界面分开所以前面提到的接口设计很重要。4.3 一组可抄的初始化参数超时、重试、轮询周期怎么设参数推荐值说明TCP连接超时3000~5000ms太短容易误判太长影响重连速度读取超时3000ms机床忙时可能延迟抓包确认后再调断线重试间隔10~30秒避免频繁重连导致机床通信模块过载轮询周期500~1000ms看板500ms统计报表1~2秒即可单帧读取点数不超过960字超出一帧容易触发协议限制拆帧读日志保留天数30天排查历史问题用按天滚动删除这些参数不是写死就完事每台机床的通信负载不一样。我见过一台老机床轮询周期压到200ms结果机床显示屏都卡了把周期调到1秒后一切正常。参数设计上一定留出配置文件或数据库配置项不要埋在代码里。另外采集服务要记录每次断线的时间点和原因这个日志才是你后期调参的真正依据比猜靠谱得多。5. 三菱CNC数据采集常见问题与排查现场最容易翻车的五个点5.1 能Ping通却连不上端口号和CNC侧协议开关现象电脑能ping通机床的IP但程序连接超时抓包发现TCP握手都完成了就是没有协议响应。原因最常见的是端口号不对或者数控系统参数里MC协议服务没有启用二者缺一不可。解决在机床面板的网络设定里找到通信协议开关确认为启用接口程序里把端口号和机床设置里显示的端口保持一致。另外有些机型会对访问来源做限制确认电脑IP是否在白名单范围内。5.2 返回结束代码不为0多半是帧长度或地址越界现象连接正常发送帧后很快收到响应但结束代码不是0x0000界面报“读取失败”。原因请求数据长度算错、软元件点数超出允许范围、地址越界都可能导致协议拒绝。解决把发送的报文按字节打出来和协议示例逐字节比对重点看长度字段点数改成比如1个字再试确认不是点数问题。请求数据长度从网络号开始算起这一条至少能解决一半的此类问题。5.3 读数忽大忽小字节序、符号位和32位数据拼接现象读取主轴转速数值和面板显示不一致有的位翻转有的负值显示成很大的正数。原因响应数据区每个字的高低字节顺序处理反了或者没有按有符号数解析又或者目标数据本身是32位浮点数你只读了16位。解决先读一个已知数值确认单字解析的正确性再针对32位数据连续读两个字按IEEE754浮点拼接。我在Demo里留下了一个只读单字的版本目的就是让验证过程足够简单避免一次牵扯太多变量。5.4 采集服务跑几天就卡死线程与超时没弄干净现象程序刚启动一切正常跑几个小时后界面没反应或Socket异常重启后又能撑一段时间。原因同步读取阻塞了界面线程或者Socket在异常后没有正确关闭资源最终耗尽。解决把采集放到后台线程读取时设置socket.ReceiveTimeout重连前先关闭旧连接。我从自己的项目里总结出来的习惯是每次异常都打印完整堆栈和当前线程ID这类卡死问题只要能看到日志定位一般不超过十分钟。5.5 换机型就全线崩溃别照抄地址映射表现象同一套程序在A机床上采得好好的连到B机床后读数全乱甚至读回0。原因不同系列数控系统的软元件地址映射不一样D寄存器编号规则、PMC映射区域都可能有差异网上抄来的地址表不一定适用新机型。解决每台机床接入前先拿该机型的地址手册核对一遍关键地址验证顺序还是先读已知值再读业务变量。这个坑不靠写代码能绕过去只能靠规范的接入流程来兜底。6. 一个能保命的排查技巧拿已知值反推协议细节最后一个技巧是我每次对接陌生三菱机床时都会用的先读已知值再用它反推字节序、地址偏移和32位拼接规则。具体做法是在机床可用寄存器里挑一个当前值明确的点比如把某个空D寄存器手动写入十进制1234然后用程序读回来看原始字节是什么顺序。如果抓到的响应数据是04 D2说明高字节在前如果是D2 04那你就要把解析逻辑里的高低字节对调改成低字节在前拼字。这个方法之所以高效是因为它把未知问题缩小成一个坐标系地址对不对、长度对不对、字节序对不对用一次已知值的读取就能同时验证三件事。我现场排查时还会顺手把windows上抓到的原始包转发一份到调试日志字段挨个核对five minutes基本就能判断问题是出在连接、报文还是解析层。对于32位浮点数就写入一个已知的浮点值比如1.5然后连读两个字按大端和小端各拼一次看哪次还原出1.5规则自然就清楚了。调试时养成的另一个习惯是打开数据变化曲线再对照机床面板数字看几秒钟。如果曲线方向和面板一致但数值有固定比例差去查倍率参数如果曲线抖动但面板稳定多半是读取了正在变化的缓冲区换个地址就好。这套“先已知值再动态值”的流程我用了很久至今没遇到哪台三菱机床是靠它搞不定的整理到你的Demo维护手册里希望帮到你。本文还有配套的精品资源点击获取
