三菱M70做主轴转速毫秒级采集，C#上位机走通的关键就三件事：网口走EZSocket读CNC窗口数据，独立采集线程按20毫秒周期轮询，数据带毫秒级时间戳落本地库再补传。我们在无锡一个二十台M70的车间实测，局域网单次请求响应3到8毫秒，20毫秒周期跑得稳，断刀报警比操作工肉眼快好几秒。这篇把整条链路拆开讲，含可以直接套用的采集循环写法。
M70里的主轴转速数据，到底从哪儿读？
很多人第一反应是去读PLC的D寄存器，其实M70这类数控系统有两条数据通道。一条是CNC窗口数据，实际主轴转速、主轴负载率、进给速度、当前程序号、报警代码都在里面，直接反映加工状态；另一条是内置PLC的软元件区，机床厂把外围信号映射到D区和M区。转速这种工艺量，走EZSocket官方通信库读窗口数据最正，时序、单位、倍率换算系统都给好了，不用自己猜地址。
| 采集项 | 数据来源 | 建议周期 | 拿来干什么 |
|---|---|---|---|
| 主轴实际转速 | CNC窗口（轴数据） | 20ms | 转速曲线、断刀判定特征之一 |
| 主轴负载率 | CNC窗口（轴数据） | 20ms | 断刀/崩刃检测、刀具磨损趋势 |
| 进给速度 / 程序号 / 行号 | CNC窗口（运行信息） | 200ms | 工序段切分、加工追溯 |
| 报警代码 | CNC窗口（报警区） | 500ms | 停机原因归集、稼动分析 |
| 加工完成计数 | 内置PLC软元件 | 1s | 产量报工 |
如果你手头的机床没有选配以太网口，RS232口也能读，但速度只够做秒级状态监控，毫秒级采集别指望串口。这点很关键，选型阶段先确认机床侧的网络配置，别等程序写完才发现硬件缺口。
20毫秒周期是怎么跑稳的？核心是线程模型
说句实话，上位机的"毫秒级"不是指一毫秒采一次，那没有意义也做不到。机加工场景20到50毫秒的粒度足够还原转速曲线。采集必须独立成线程，跟界面彻底分开，写库走队列异步消费。M70同一时刻只接受一个会话请求，多线程抢同一个连接必报错，信号量锁一定要加。核心循环长这样：
▲ 采集线程骨架：批量读、信号量限流、时间戳入队、周期补偿
四个细节决定这套循环能不能长期稳跑：批量请求，一次调用把转速、负载、程序号全读回来，别一项一发；时间戳用Stopwatch校准，系统时钟毫秒级跳动不稳，Stopwatch做相对计时再折算绝对时间；写库异步化，采集线程只往Channel里放，消费线程攒够500条批量写SQLite，网络通了再往服务器补传；周期补偿，请求耗时从20毫秒里扣掉，防止读得慢时周期漂移。
采到转速之后，能挖出什么东西？
最直接的是断刀和崩刃检测：正常切削时主轴负载在一条窄带内波动，刀具断裂瞬间负载跌零、转速因负载骤降而上冲，两个特征同时出现，判定断刀比操作员肉眼快好几秒，能避免空切报废整批工件。再往上是刀具磨损趋势：同一把刀、同一道工序，随着磨损加剧，稳态负载会缓慢爬升，攒够几百件的曲线就能反推换刀点，从"按件数换刀"升级到"按状态换刀"。加工追溯也顺带有了，每件产品对应哪段转速负载曲线，质量科倒查时拿得出证据。
我之前在无锡做过一个汽车零部件CNC车间的联网项目，二十台M70加工中心，一开始用50毫秒周期，工艺说曲线发虚，调到20毫秒后每次入切的负载尖峰都清清楚楚。断刀判定上线后第一个月，空切报废件从每月七八件降到零。
一天八九十万条数据，怎么存才不丢不爆？
20毫秒一条，一台机床一天四万多条，二十台就是八九十万条。原始曲线全量上服务器没意义还费带宽，我们的做法是边缘预处理：本机SQLite按天分库存全量，保留30天滚动；同时只往服务器推特征值——入切负载均值、峰值、异常片段，MES和看板用特征值就够了，真要查原始曲线再从工控机本地按时间段调。断网期间数据全留本地，恢复后按时间戳顺序补传，车间拉闸检修太常见，没有缓存机制的数据链路等于没建。
想给M70机床上这套采集，第一步做什么？
行动建议：先找机床厂确认两件事——系统是否带以太网选配、EZSocket授权是否在手上。然后拿一台机床做20毫秒周期的单台验证，跑半天，把转速负载曲线跟实际加工动作对一遍，看入切尖峰、空载基线段对不对得上。单台通了再批量铺开，数控联网项目里，通信验证永远排在写软件前面。