马扎克Smart/Smooth CNC数据采集免授权实战

车间里有台用了快六年的马扎克加工中心屏幕亮着活儿干得挺好可你要问它现在主轴负载多少、今天换了几次刀、昨天夜里三点停过多久操作工只能摊手设备台账上永远是手写的正常/异常两栏。想让机床自己说话厂商给的方案通常是一套采集软件加一个授权价格按点位或者按台数算几台机器下来就是一笔不小的预算。实际上 Smart 和 Smooth 这两代控制器本身就留了不少口子——MTConnect 服务、Windows 共享目录、日志文件、宏程序输出这些通道出厂就带着只是没人主动告诉你。这篇就聊马扎克 Smart、Smooth 系列 CNC 数据采集怎么在尽量不增加授权成本的前提下跑起来从需求拆解、通道选型、实机配置到脚本落地和踩坑记录全部按现场可复现的方式写适合设备管理、自动化集成、产线数字化的朋友参考也适合手上有几台老机床想先把数据跑通再谈平台的团队。1. 先把需求拆开一台机床到底要采什么数据1.1 三类数据的分层思路很多人上来就问能不能把所有数据都采上来这个问题本身就是个坑。加工中心能吐出来的变量成百上千但你真正常用的其实就三类分层想清楚了后面的通道选型和采样频率才有依据。第一层是状态类回答机床现在在干嘛运行、待机、报警、停机、换刀、预热。这类数据的特点是变化频率低但意义大直接决定设备稼动率的统计口径。第二层是计数类回答干了多少活加工件数、循环次数、报警次数、刀具使用次数。这类数据是累加量最怕的是丢点一次断电或者一次采集程序崩溃累计值就断了。第三层是工艺类回答干得怎么样主轴转速、进给倍率、主轴负载、轴坐标、当前程序号、当前行号、报警内容。分层之后你会发现第一层和第二层才是 OEE 和看板的核心第三层更多是给工艺和设备维护用的。这三层的采样要求完全不同状态类 1 秒一次足够计数类必须在事件发生时抓到工艺类才是那些需要 100 毫秒级采样的场景。我见过不少项目一上来就按 50 毫秒全量采集结果控制器 CPU 占用上去了采集端也扛不住最后看板上全是噪点。提示先把你要做的报表或看板画出来反推需要哪些字段再去机床侧找对应的数据项。反过来做往往是采了一堆用不上的数据真正的关键字段反而漏了。1.2 Smart 与 Smooth 两代控制器的差异马扎克的控制器代际差异挺大采集方式不能用同一套逻辑套。Smart 系列属于比较早的一代智能控制器系统底层更接近传统的嵌入式结构对外接口主要靠以太网、串口和存储介质。Smooth 系列则是基于 Windows 平台的控制器型号上有 SmoothC、SmoothG、SmoothX 等不同规格硬件平台更新网络能力和文件系统能力都强很多。这个差异直接决定了你的策略。Smooth 系列因为跑在 Windows 上天然具备文件系统、网络共享、甚至能在上面装轻量服务的条件所以文件型采集和网络型采集都好做。Smart 系列更依赖标准的工业接口比如通过以太网走 MTConnect、通过串口走数据输出、通过存储卡定期导出。我这边的实际经验是Smooth 机床上先把 MTConnect 通道验证通通不了再退到文件通道Smart 机床上先确认有没有内置的 MTConnect 适配器不同年份、不同选型差异很大没有的话直接走文件导出或者 I/O 硬接线别在协议上死磕。注意同一系列不同年份、不同选配的控制器开放能力可能完全不同。别人机床上能访问的端口你这台不一定有。所有方案落地前必须在自己的实机上验证不要照着别人的经验直接批量部署。1.3 为什么先定采样频率再定协议这个顺序很多人搞反了。正确做法是先明确我最快需要多快的数据再倒推协议和部署方式因为采样频率直接决定了三件事控制器侧的资源消耗、网络带宽、以及采集端的存储和计算压力。举个具体的账。假设一台机床每个采样点返回的报文按 3 KB 算1 秒一次一天开机 20 小时单台日流量大约 216 MB十台机床就是 2 GB 出头这个量级在车间内网完全无压力。但如果改成 100 毫秒一次量级直接放大十倍就是 20 GB 一天而且控制器侧的 HTTP 服务每秒要处理 10 次请求长期跑对老控制器不算友好。我的建议是分档状态和报警用 500 毫秒到 1 秒轮询工艺参数用 200 到 500 毫秒计数类不靠轮询靠事件。计数类的正确做法是用 MTConnect 的序列接口拉取变化记录而不是靠/current反复读同一个值去比对后者在两次轮询之间发生的短暂跳变会直接丢掉。另外还要考虑一件事采集不能影响加工。这个话题在车间里非常敏感设备科的人一听说你要在机床上加东西第一反应就是会不会影响精度和稳定性。所以采集方案的资源占用必须可控任何会导致控制器卡顿的操作都要在设计阶段就排除掉。2. 免授权路径的选型四条能走通的路子2.1 MTConnect 通道控制器自带的 HTTP 服务MTConnect 是机床行业里比较通用的开放协议用 HTTP 加 XML 的方式把设备数据暴露出来。马扎克在 Smooth 系列上对 MTConnect 的支持相对完整部分机型出厂就带着适配器控制器内部会跑一个轻量的 HTTP 服务默认端口一般是 5000。这个通道的价值在于它是机床自己提供的数据出口不需要额外装第三方采集软件也不需要买一套按点位计费的采集授权。你只需要一台能连到机床网络的普通工控机或者树莓派之类的设备用浏览器或者脚本去请求就行。验证方法非常简单把笔记本和机床接到同一个交换机配一个同网段的地址然后在浏览器里输入http://机床IP:5000/probe正常的话会返回一段 XML里面描述了这台设备有哪些数据项DataItem、每个数据项的 id 和类型。这个/probe返回的文档其实就是你的数据字典所有能采的字段都在里面。如果这个地址打不开先别急着下结论说没有检查三件事端口是不是 5000、控制器侧的服务有没有开、网络通不通。拿到/probe之后日常采集主要用两个接口接口用途适用场景/current返回当前所有数据项的最新值低频轮询状态、看板刷新/sample?fromxxxcountn返回指定序号区间内的变化序列抓取状态跳变、报警、计数事件/probe返回设备能力描述一次性获取数据字典/current简单好用但有个硬伤它只告诉你现在是什么不告诉你中间发生过什么。比如机床在两次轮询之间报警了 200 毫秒又恢复了/current完全看不到但/sample能把这个跳变序列完整拉回来。所以做报警统计必须用/sample不能用/current做差。2.2 共享目录与日志文件通道Smooth 系列跑在 Windows 上这就意味着它在文件层面是可访问的。控制器会生成一些运行日志、报警历史、维护记录类的文件格式通常是 CSV 或者文本。如果控制器侧开放了共享或者你能通过项目备份、U 盘导出的方式拿到这些文件就等于拿到了一个事后可查的数据源。这条路的好处是完全不影响实时运行读写压力小而且历史数据完整。缺点是时效性差一般是分钟级甚至小时级而且文件格式会随版本变化解析脚本要跟着维护。实际操作上我一般会配一个只读共享账号把采集端挂载上去定时扫描目录里的新增文件。判断新增靠文件名的时间戳或者文件的最后修改时间不要靠比对内容后者在文件大的时候很慢。注意给采集端用的共享账号一定要设成只读权限并且限制访问来源 IP。控制器上的系统往往比较老不适合暴露在办公网里更不要直接挂到公网上。2.3 宏程序主动写文件兜底最稳前两条路都不通的时候宏程序是最后的兜底手段。思路是在加工程序里插入一段自定义宏指令让它定期把关键变量比如当前程序号、加工件数、刀具号写到一个文本文件或者通过串口输出。这招的好处是完全由程序控制不依赖控制器的对外接口机床怎么干活就怎么写数据。缺点是侵入性比较强需要在程序里加代码而且要评估对加工节拍的影响。我的做法是只在程序的头尾和换刀点插入不在加工路径中间插这样对节拍的干扰最小。具体写法要看控制器版本和当前模式。马扎克的对话式编程和 EIA 模式下的宏指令支持不完全一样部分版本支持文件打开、写入、关闭这类指令具体指令名和参数必须查对应版本的编程手册确认不要照搬别的系统。我踩过一次坑按另一套系统的写法直接套程序跑起来不报错但文件是空的查了半天才发现参数顺序不一样。2.4 I/O 硬接线没有网络时的物理方案如果机床年代实在太老或者网络通道被完全封死那就退到最原始的办法从电气柜引出几个信号点。最典型的是三色灯的驱动信号、循环启动信号、报警输出继电器。这套方案的优点是绝对可靠、延迟极低一个 PLC 输入模块就能搞定几十毫秒内就能抓到信号变化。缺点也很明显信息量极少你只能知道在加工/不在加工/报警不知道加工程序号不知道主轴负载更不知道报警内容是什么。我一般把它定位成主通道的补充而不是替代。比如 MTConnect 通道采工艺数据I/O 通道采设备状态两条数据流在采集端做时间对齐这样即使网络断了状态类的数据也不会断档。下面这张表是我自己总结的选型对照实际项目里基本按这个顺序试通道数据丰富度时效性侵入性适用控制器MTConnect高秒级/亚秒级低Smooth 居多Smart 视选配共享目录/日志中分钟级极低Smooth宏程序写文件中事件触发中Smart 与 Smooth 均可I/O 硬接线低毫秒级中全部3. 实机落地从网络配置到第一条数据3.1 网络与端口准备先说网络。机床的网络接口我是强烈建议单独拉一个 VLAN 的不要和办公网混在一起。原因有两个一是机床控制器的网络栈通常比较老办公网里的广播包、组播包、扫描流量对它来说都是无谓负担二是安全边界控制器不应该被办公网里任何一台机器随便访问到。地址规划上我给机床段留一个独立的网段比如192.168.10.0/24机床从.20开始往下排采集服务器固定在.10。这样做的目的是让地址有规律运维的时候一眼能看出这台设备是机床还是服务器。端口方面MTConnect 默认 5000有些版本会用到 5001 作为 SHDR 的流式端口。共享文件走的是 Windows 的 445。这些端口在采集服务器和机床之间要放通但机床侧不要往办公网开放。机床控制器 192.168.10.21 TCP 5000MTConnect HTTP 采集服务器 192.168.10.10 只作为客户端主动连接机床 交换机 独立 VLAN无跨网段路由配置完成之后先做最基本的连通性测试用ping确认链路再用telnet或者nc确认端口开没开ping -c 4 192.168.10.21 nc -zv 192.168.10.21 5000nc返回succeeded就说明端口开着可以进入下一步。这一步看似废话但我见过的采集不通问题里至少三成是网络层没通包括网线插错口、IP 冲突、交换机端口被划到别的 VLAN。3.2 用浏览器验证服务是否在网络通了之后直接用浏览器访问/probe。这一步的意义不只是验证服务在不在更重要的是拿到这台机床的数据字典。返回的 XML 里每个 DataItem 都有一个id、一个type、一个categorySAMPLE 还是 EVENT这些信息是你后面写解析逻辑的全部依据。我通常会把这个 XML 存一份下来按机床型号归档。因为同一系列不同版本的固件数据项会有细微差别比如有的版本有part_count有的版本叫别的名字不实际看一遍根本不知道。几个常见的关键数据项在不同版本里名字可能不完全一样但语义基本一致语义常见数据项 id 片段类型运行状态executionEVENT可用状态availEVENT操作模式modeEVENT当前程序programEVENT主轴转速spindle_speedSAMPLE主轴负载spindle_loadSAMPLE进给倍率path_feedrate或feedrate_overrideSAMPLE加工计数part_countEVENT报警message或alarmEVENT急停emergency_stopEVENT拿到这份表之后你的采集端就不用硬编码字段名了可以在启动时先请求/probe动态建立 id 到业务字段的映射这样换一台机床只要改配置不用改代码。3.3 Python 采集器骨架采集端的实现我一般用 Python理由很简单开发快、库全、部署轻扔在一台低功耗的小主机上就能跑。下面这个骨架是我实际项目里用的简化版核心是三件事——定时请求、解析 XML、落到时序库或者 CSV。先看解析部分关键是不要用带命名空间的路径去取节点因为不同版本的 MTConnect 命名空间版本号不一样写死会挂。正确做法是按标签名匹配import time import requests from xml.etree import ElementTree as ET AGENT http://192.168.10.21:5000 TIMEOUT 3 def local_name(el): return el.tag.split(})[-1] def fetch_current(agentAGENT): resp requests.get(f{agent}/current, timeoutTIMEOUT) resp.raise_for_status() root ET.fromstring(resp.text) snapshot {_ts: None, _seq: None} for el in root.iter(): name local_name(el) if name Header: snapshot[_ts] el.attrib.get(creationTime) snapshot[_seq] el.attrib.get(nextSequence) item_id el.attrib.get(dataItemId) if item_id: val (el.text or ).strip() if name in (Condition,): snapshot[item_id] el.attrib.get(type) or CONDITION else: snapshot[item_id] val return snapshot if __name__ __main__: while True: try: data fetch_current() print(data) except Exception as exc: print(poll failed:, exc) time.sleep(1)这段代码有几个细节值得说。Header里的creationTime是 UTC 时间带Z后缀落地的时候一定要转成本地时区再入库。nextSequence是下一次/sample的起始序号把它存下来下次拉序列的时候传from参数就能做到不丢不重。再说/sample的用法。假设你上一次拿到的nextSequence是 1024现在想追平到最新就这么请求def fetch_sample(start, agentAGENT, count1000): url f{agent}/sample?from{start}count{count} resp requests.get(url, timeoutTIMEOUT) resp.raise_for_status() root ET.fromstring(resp.text) rows [] for el in root.iter(): if local_name(el) Header: next_seq int(el.attrib.get(nextSequence, start)) if dataItemId in el.attrib and el.text is not None: rows.append({ seq: el.attrib.get(sequence), ts: el.attrib.get(timestamp), item: el.attrib.get(dataItemId), value: el.text.strip(), }) return rows, next_seq/sample的返回是一个变化序列每条记录都带序号和时间戳。这个接口的价值在于能补数据——采集端重启、网络闪断的时候只要你还记得上次的序号就能把中间的变化全部追回来。这是/current做不到的。采集主循环我一般这么组织一个线程跑/sample追变化落库另一个线程低频跑/current做兜底快照再加一个看门狗线程检测某个线程卡住超过 30 秒就整体重启。这样即使某个接口偶发超时也不会把整个采集链路拖死。提示/sample的count参数不要设太大。我试过设到 5000控制器返回明显变慢个别老版本还会直接超时。建议不超过 1000追不平就分多次追。3.4 共享目录方案的具体配置对走文件通道的机床配置步骤大概是这样的。先在控制器侧确认有可访问的共享路径或者可导出的数据目录然后在采集服务器上用只读方式挂载。Linux 采集端挂载 Windows 共享一般用cifssudo mkdir -p /mnt/cnc sudo mount -t cifs //192.168.10.22/CncLog /mnt/cnc \ -o usernamereader,password******,ro,vers2.0,iocharsetutf8这里的vers2.0是踩过坑的。老控制器上的 SMB 版本比较低新版内核默认用 SMB3 协商会失败显式指定vers2.0或者1.0才能连上。iocharsetutf8是为了防止日志里的中文或者日文报警文本读出来是乱码。挂载之后用一个定时任务扫描新增文件。判断依据用文件的修改时间比当前时间晚一个扫描周期内的文件算新增。解析的时候注意编码问题这类日志文件很多时候不是 UTF-8可能是 Shift-JIS 或者 GBK读之前先试一遍读失败了再换编码。3.5 时间戳与时区对齐这一节单独拿出来讲因为它是数据质量里最容易被忽视、后果又最严重的一环。MTConnect 的时间戳统一用 UTC带Z后缀。而车间里的排班、班次统计、报警追查全是本地时间。如果入库的时候没做转换你在看板上看到的凌晨三点报警实际可能是上午十一点这种错一旦发生排查起来非常痛苦。我的做法是入库统一存 UTC展示层按配置的时区转换绝不混着存。同时机床控制器本身的系统时钟未必准有的机床装好之后就没校过时偏差几十分钟都可能。所以采集端要做一个漂移检测定期比对机床返回的时间戳和采集服务器的本地时间偏差超过阈值就告警提示现场校时。4. 数据模型与字段映射4.1 从数据项到业务字段的映射拿到/probe之后直接上生产之前一定要做一层映射把机床侧的技术字段翻译成业务语义。这层映射不要写死在代码里做成配置文件因为不同型号、不同固件的机床字段名不一样。一个典型的映射配置长这样machine: cnc-01 agent: http://192.168.10.21:5000 poll_interval_ms: 500 fields: execution: item: execution type: event map: ACTIVE: 运行 READY: 待机 STOPPED: 停止 INTERRUPTED: 中断 program: item: program type: event part_count: item: part_count type: counter spindle_load: item: spindle_load type: sample unit: percent这层配置的好处是扩展性好。新加一台机床拷贝一份配置改改 IP 和字段名就行采集程序一行不用动。字段名对不上怎么办先跑一次/probe把返回的 XML 里所有dataItemId列出来对照着填。4.2 报警码到故障类型的映射维护报警这块是最麻烦的。机床返回的报警通常是英文或日文的短文本加上一个报警号。你把原始文本直接扔到看板上操作工看了也不一定知道该怎么处理。所以需要维护一张映射表把报警号映射到中文描述、故障分类、建议处理动作。这张表的维护原则是增量补齐不要一开始就想着把所有报警都翻译完先跑起来采到一条新的就补一条两个月下来常用的那几十条就齐了。报警号前缀故障分类处理方向伺服类伺服系统检查负载、编码器、驱动器报警主轴类主轴系统检查刀具、夹紧、冷却程序类程序与指令检查程序语法、刀补、坐标系液压润滑类辅助系统检查油位、压力、滤芯操作类人为操作检查门开关、急停、模式切换报警文本还有一个坑部分报警是短暂跳变型的比如门开关瞬间触发又恢复用/current轮询根本抓不到。这类必须靠/sample拉序列同时要在采集端做去抖同一个报警号在 3 秒内连续出现只记一次避免统计失真。4.3 加工节拍与稼动率的计算口径数据采上来只是第一步怎么算才是关键。同一个稼动率用不同口径算出来能差十几个百分点。我的建议是先把三个时间定义清楚计划开机时间排班决定的可用时间、实际运行时间execution为 ACTIVE 的累计时长、有效加工时间主轴负载超过阈值的累计时长。稼动率一般用实际运行时间除以计划开机时间。这里有个细节execution显示 ACTIVE 不代表真的在切屑。机床在空跑程序、快速定位、换刀的时候状态也是 ACTIVE但主轴负载很低。所以判断真在加工要叠加一个条件比如主轴负载大于 5% 且进给倍率大于 0。这个阈值因机床和工件而异需要在现场标定。节拍统计同理用相邻两次加工计数递增的时间差算单件节拍比用程序开始结束时间算更准因为后者会把换刀和等待时间算进去。算出来的节拍数据要按工件号分组不同工件没法放一起比。5. 常见问题与排查速查表5.1 连不上控制器这是最高频的问题排查顺序建议固定下来别东一榔头西一棒子。第一步永远是ping。不通就先查物理层网线、交换机端口、指示灯。第二步是nc测端口端口不通就查控制器侧的服务有没有开、有没有被防火墙拦。第三步是浏览器访问/probe能访问但返回异常那就是应用层的问题了。现象可能原因处理方式ping 不通网线/网段/VLAN 配置错检查物理链路和地址规划ping 通但端口不通控制器服务未启动或防火墙拦截确认服务状态检查控制器侧防火墙端口通但/probe无响应服务假死重启控制器侧适配器服务或断电重启/probe返回空适配器未配置数据项检查控制器侧的采集配置注意控制器侧的适配器服务在断电重启后不一定会自启这是很多人遇到的昨天还好好的今天早上全断了的原因。如果条件允许配置开机自启或者在采集端加一个服务探活发现连续 N 次失败就发告警。5.2 能连上但数据不动数据不动分两种情况得先分清是机床真的没变化还是采集没拿到。判断方法很简单让操作工在机床上手动改一下进给倍率或者切一下模式然后看采集端有没有收到变化。如果手动改了但采集端没反应那问题在采集链路如果采集端有反应但数值一直不变那可能是你盯的那个字段本来就不常变。还有个容易被忽略的原因字段 id 对错了。/probe里可能有多个相似的 id比如既有主轴负载又有轴负载名字很像取错了就一直是 0。这种情况在第一次接入新机型时特别常见唯一的办法是把所有可疑 id 都打印出来人工比对一遍。5.3 数据断点与时间漂移断点的来源主要有三个网络闪断、采集进程崩溃、控制器服务重启。前两个好解决加断线重连和进程守护第三个只能靠采集端的序号续传机制来补数据。具体做法是每个采集周期都把nextSequence持久化下来写本地文件或者写库进程重启后从这个序号开始拉/sample中间的变化就都补回来了。这个机制非常重要我见过有项目没做这个每次重启采集程序就丢一段数据月底对账的时候对不上查了两天才发现问题出在这儿。时间漂移前面提过处理方式是定期校时。机床侧如果能配置 NTP 最好配不了就在采集端做偏差检测超过 60 秒就告警人工校时。5.4 采集对加工的影响评估这是设备科最关心的问题也是项目能不能推下去的关键。我的经验是只要控制住三件事基本不会影响加工。第一采样频率不要过高。状态类 1 秒一次工艺类 500 毫秒一次这个量级对现代控制器来说完全无感。第二不要在采集端做重计算。采集端只管取数和转发解析、聚合、计算全部放到后端的数据库或者计算服务里别让采集程序占满 CPU 导致请求堆积。第三控制/sample的返回量。count控制在 1000 以内追不平就分多次。上线前建议做一次对比测试采集程序全速运行的状态下让机床跑一段标准试切件测一下加工时间和表面粗糙度和不开采集的时候比。数据摆出来设备科的人才会放心。6. 实操心得几条踩过坑的经验第一条先把一台机床跑通再谈批量。我见过太多项目一上来就十台二十台同时部署结果一个字段映射错了二十台全错返工成本极高。正确节奏是先拿一台最有代表性的机床做样板把数据字典、映射配置、报警表都摸清楚形成标准模板之后再复制。第二条别迷信协议现场验证永远是第一位。同一批次的两台机床一台/probe能返回完整数据另一台因为固件版本差一点少了好几个关键字段。这种事你查文档查不出来只能一台一台试。第三条采集程序要能自己活下来。车间网络不稳定、控制器偶发假死这些都是常态。采集程序必须做到断线自动重连、进程崩溃自动拉起、序号持久化续传、连续失败主动告警。这四点做到了运维成本能降一个数量级。第四条数据落地的格式一开始就要定好。我一开始图省事直接存原始报文后面做报表的时候才发现要反复解析性能很差。后来改成入库时就拆成结构化字段原始报文单独归档查询效率好了很多。最后分享一个我觉得挺实用的小技巧给每台机床的采集配置加一个version字段每次改配置就加一同时记录变更时间和变更内容。等到某天数据出现异常先看配置有没有改过能省掉大量排查时间。这个习惯是从一次事故里学来的——某次改了个轮询间隔忘了记录后来数据出现周期性缺口查了整整一天才想起来是自己改的。