简介工业物联网与智能制造背景下CNC设备联网已成为车间数据采集的基础环节。机床数据采集的难点不仅在于读取控制器内部状态更在于如何通过稳定、高效的通信架构实现多设备并发连接与实时监控。基于TCP/IP的远程API技术为这类场景提供了标准化入口配合合理的连接管理与轮询调度上位机可对车间内十余台控制器进行统一汇聚覆盖主轴转速、坐标、报警等关键参数进而支撑OEE分析、远程运维与MES系统建设。新代SyntecRemoteAPI的一对多采集架构正是这一路径的典型实践涵盖连接管理、轮询策略、数据对齐等关键工程问题。 在机加工车间里做数据采集绕不开一个很现实的问题车间里十几台新代SYNTEC控制器有雕铣机、高光机、石墨机品牌统一、型号各异想统一把运行状态、主轴转速、当前坐标、报警信息实时拉上来市面上却找不到一个真正省心的方案。SyntecRemoteAPI_v4_1.0.12就是新代针对这类远程数据交互场景提供的接口配合一对多的采集程序架构一台工控机就能同时顶住十几台设备的实时数据回传。这篇文章不是翻译一遍官方文档而是把我在实际项目里用这套API做车间级采集的完整过程拆开讲透包括连接管理、轮询策略、数据对齐以及那些不踩一次根本不会注意到的坑。如果你正在做类似的项目不管是给客户上设备联网系统还是给自家车间搭OEE看板这篇应该能帮你少走不少弯路。1. 为什么车间数据采集绕不开SyntecRemoteAPI1.1 新代控制器在数据采集场景里的特殊性新代系统在国内的雕铣、精密加工领域占有率相当高特点是开机快、界面直接、宏程序支持好很多中小加工厂的主力设备都是新代系统。这类设备虽然自带网口但原厂并没有像FANUC FOCAS那样把数据接口做成行业标准导致很多做设备联网的工程师第一反应是串口读或者PLC硬线接吃力不讨好。实际上新代控制器内部有一套完整的状态数据体系当前程序名、程序行号、主轴实际转速、三轴坐标、进给倍率、报警码、运行模式甚至宏变量区。这些数据通过网口就能访问SyntecRemoteAPI做的就是这件事——它把控制器的内部数据以远程接口的形式开放出来上位机通过TCP/IP协议直接读写不需要改PLC程序也不需要动电气柜。1.2 采集难点从来不在读而在怎么读单个读数据其实很简单难的是稳定地、持续地、成规模地读。我自己最早做新代采集时也天真地以为用调试工具连上一台设备读几个地址项目就完事了。真正上线才发现车间现场是另一回事设备IP乱、网线松、控制器偶尔死机、车间停电半小时、有人把网线拔了插到自己笔记本上……这些都是常态。所以SyntecRemoteAPI的价值不在于它能读数据而在于它给了我们一个稳定、统一的数据入口。剩下的连接健壮性、采集调度、数据落库全都要靠采集程序自己兜住。这也是为什么我强调一对多架构因为当你面对的不再是一台设备而是十台、二十台设备时连接管理者、轮询调度、异常恢复这些设计就变成了核心问题。下面是四种常见的采集方案对比基本能说明为什么最后大家都会走到API这条路上。采集方案实施成本实时性数据覆盖范围对现场的影响人工抄录低差极少无硬线IO PLC中转高中以开关量为主需要改电气柜串口协议解析中中依赖协议文档占用设备串口SyntecRemoteAPI以太网中高坐标/报警/程序/宏变量全覆盖仅占用网口通道2. 一对多采集的架构设计让一个服务同时守住十几台设备2.1 一对多不是简单循环而是要分清连接层和业务层一对多这三个字听起来简单很多人第一反应就是在程序里写个for循环遍历所有设备的IP逐个连接、逐个读取。这样做技术上能跑但项目规模一大就出问题——某台设备断线了整个循环被阻塞后面的设备全都跟着等某台设备通信慢其他设备的数据采集周期被拖长程序一旦异常退出所有设备同时失联。我的做法是把采集程序拆成三个层次连接层、采集层、存储层。连接层负责管理每台设备的TCP会话包括连接的建立、断开、心跳检测、断线重连。采集层负责定义每个采集周期要读哪些数据、以什么频率读、读到之后怎么组装成一个标准的数据点。存储层只做一件事——把数据点持久化可以是关系型数据库、时序数据库也可以是直接写MQTT转发给上层平台。分层之后每一层的改动不会影响另外两层。比如想从500ms轮询改成1s轮询只动采集层想从SQL Server换成TDengine只动存储层。这个架构看起来朴素但后续维护的幸福感完全不一样。2.2 线程模型与调度策略连接层和采集层最容易犯的错是每台设备一个裸线程线程里while(true)循环读。设备少的时候没问题设备一多线程上下文切换、锁竞争、数据库连接占用都会变成瓶颈。我建议用两种方式混合连接层每个设备一个独立会话但会话本身是异步的。连接、重连都不阻塞主流程。采集层用一个统一调度器按周期触发每个周期枚举所有在线的设备并行发起采集任务。在.NET环境里我会用一个定时器触发采集周期每个周期内用Task.WhenAll并行执行所有设备的采集任务同时给每个采集任务加上超时保护防止某台设备通信卡死拖垮整个周期。下面是采集调度器的核心代码骨架这个结构我在多个项目里复用过稳定性和可维护性都不错。public class CollectorScheduler { private readonly IDeviceManager _deviceManager; private readonly IDataSink _dataSink; private readonly TimeSpan _interval; private CancellationTokenSource _cts; public CollectorScheduler(IDeviceManager deviceManager, IDataSink dataSink, TimeSpan interval) { _deviceManager deviceManager; _dataSink dataSink; _interval interval; } public void Start() { _cts new CancellationTokenSource(); Task.Run(() RunLoopAsync(_cts.Token)); } public void Stop() { _cts?.Cancel(); } private async Task RunLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { var devices _deviceManager.GetAllDevices(); // 每个周期并行采集所有设备 var tasks devices.Select(d CollectOneDeviceAsync(d, token)); await Task.WhenAll(tasks); // 等下一个周期 await Task.Delay(_interval, token); } } private async Task CollectOneDeviceAsync(CncDevice device, CancellationToken token) { // 超时保护防止单台设备卡死整个周期 using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(token); timeoutCts.CancelAfter(TimeSpan.FromSeconds(3)); try { if (!device.EnsureConnected()) return; var data device.Session.ReadAllData(); _dataSink.Write(data); } catch (OperationCanceledException) { // 单台设备超时记录日志后跳过 } catch (Exception ex) { // 通信异常交给连接层处理重连 device.MarkAsBroken(); } } }2.3 容量评估一台工控机到底能扛多少台设备做方案的时候经常被问一台工控机采集30台设备跑得动吗这个问题不能拍脑袋回得看数据量和采集频率。我按500ms采集周期、每台设备每次采集20个字段来算每台设备每秒产生的数据量大概是40个值30台就是1200个值/秒。以普通IPC的CPU算力解析和组装这些数据完全不是瓶颈瓶颈在网络带宽和数据库写入。单个数据点按JSON格式算约200字节30台设备每秒写入240KB这个量级普通千兆局域网毫无压力。真正考验工控机的是连接数。如果每台设备一个TCP连接一个采集服务要维护30个长连接还要考虑控制器侧能接受多少路并发连接。我实测下来普通的4核工控机跑15台设备、500ms周期CPU占用稳定在5%以内内存占用100MB左右。所以只要不搞一些没必要的复杂框架容量是完全够的。我自己的经验判断供参考设备数量推荐轮询周期工控机要求风险点5台以内200~500ms任意工控机基本无15台以内500ms~1s双核4G以上注意设备侧连接数限制30台左右1~2s四核8G以上注意数据库写入压力3. 连接管理与会话层先把不掉线这件事做好3.1 设备注册表与连接管理器连接管理是一对多采集的地基。我一般先定义一个设备注册表把车间里所有设备的基础信息集中管理起来包括设备ID、IP地址、端口、所属产线、采集开关、备注。这个注册表可以做成配置文件也可以做成数据库表甚至可以在界面上动态增删设备。关键是要让采集程序具备热加载能力也就是加一台设备不用重启服务。设备注册表的基本结构public class CncDevice { public string DeviceId { get; set; } public string IpAddress { get; set; } public int Port { get; set; } public string LineName { get; set; } public bool CollectEnabled { get; set; } public string Description { get; set; } // 运行时状态 [JsonIgnore] public RemoteApiSession Session { get; private set; } [JsonIgnore] public bool IsConnected Session?.IsConnected ?? false; [JsonIgnore] public DateTime LastSuccessTime { get; set; } [JsonIgnore] public int ConsecutiveFailCount { get; set; } public void AttachSession(RemoteApiSession session) { Session session; } public void DetachSession() { Session?.Dispose(); Session null; } }连接管理器则负责维护这些设备的会话生命周期。我用一个ConcurrentDictionary保存设备ID到设备对象的映射所有对设备的访问都走管理器避免多个线程同时操作同一台设备的会话。3.2 断线重连与心跳机制车间的网络环境没有办公室那么干净断线是常态。我做过一次统计一个20台设备的车间一个月内设备侧偶然掉线、网线松动、控制器重启加起来的次数超过40次。如果采集程序不具备自动重连能力运维人员就得天天跑车间。断线重连我建议用指数退避策略而不是死循环重连。死循环重连在设备恢复之前会一直空转既占CPU又可能把控制器侧的连接队列塞满。指数退避的节奏第一次重连等3秒第二次等6秒第三次等12秒最长不超过60秒。设备恢复后下一次采集周期自然就能重新连上。下面是重连逻辑的简化版本。public class ReconnectPolicy { private const int MaxRetryDelaySeconds 60; private const int InitialRetryDelayMs 3000; private readonly Dictionarystring, int _failCounts new(); public async Task ReconnectAsync(CncDevice device) { if (!_failCounts.TryGetValue(device.DeviceId, out int failCount)) failCount 0; int delayMs Math.Min(InitialRetryDelayMs * (int)Math.Pow(2, failCount), MaxRetryDelaySeconds * 1000); await Task.Delay(delayMs); } public void OnSuccess(string deviceId) { _failCounts.Remove(deviceId); } public void OnFail(string deviceId) { _failCounts.TryGetValue(deviceId, out int failCount); _failCounts[deviceId] failCount 1; } }心跳机制也很重要。有些设备断线之后TCP连接不会立刻报错要等写入时才暴露。我会每隔几秒发送一次心跳查询读一个非常轻量的地址如果连续多次心跳失败就主动断开重连。这样比被动等报错要灵敏得多。3.3 RemoteApiSession封装把底层通信细节藏起来拿到SyntecRemoteAPI的SDK之后我做的第一件事不是直接写业务代码而是做一层会话封装。因为不同版本的SDK接口命名会有差异直接散落着调用后续升级SDK会很痛苦。封装后的RemoteApiSession对外暴露的接口保持稳定内部再映射到底层SDK。主要提供Connect()/Disconnect()ReadMachineStatus()读取运行/暂停/报警状态ReadSpindleSpeed()读取主轴实际转速ReadFeedRate()读取进给速度ReadCurrentCoordinates()读取机械坐标或相对坐标ReadCurrentProgram()读取当前程序名和行号ReadAlarmInfo()读取报警信息ReadMacroVariable(int varId)读宏变量这里要特别说一下宏变量的读取。新代控制器开放了宏变量区很多现场会约定用几个宏变量作为信号交换区比如#6011表示机床请求上下料#602用于记录当前工单号。采集程序支持读宏变量等于可以顺便把生产执行层面的信息也采上来这对后续做追溯非常有价值。这个封装层同时还要做一件事内部捕捉SDK抛出的异常转换成统一的业务异常类型。这样上层代码不需要关心底层通信失败的具体原因只需要处理连不上超时数据读取失败这几类。4. 轮询采集与数据落库从控制器内存到数据库的完整链路4.1 数据模型设计每个数据点带什么字段采集程序本质上是在做一件事把控制器内存里离散的状态数据变成一条条带时间戳、带设备标识的记录。所以数据模型的设计会直接影响后续做看板和分析的方便程度。我常用的采集数据点模型public class DeviceDataPoint { public string DeviceId { get; set; } public DateTime Timestamp { get; set; } public int MachineStatus { get; set; } // 0-停止 1-运行 2-暂停 3-报警 public double SpindleSpeed { get; set; } // 主轴转速单位rpm public double FeedRate { get; set; } // 进给速度单位mm/min public double X { get; set; } public double Y { get; set; } public double Z { get; set; } public string ProgramName { get; set; } public int ProgramLine { get; set; } public string AlarmCode { get; set; } public string AlarmMessage { get; set; } }4.2 采集频率的选择逻辑采集频率不是越快越好。太快的轮询会加重控制器的通信负担可能影响机床本身的运行太慢又会丢失关键事件。我的经验是分两类数据、两种频率连续变化数据坐标、转速、进给500ms到1s一轮足够。这些数据用来算设备利用率、加工进度秒级精度完全够。事件型数据报警、程序切换、状态切换建议单独做实时检测。比如每200ms检查一次状态字段发现和上一轮不同就立即记录一条事件。用两个频率的原因很简单高频轮询全部数据会浪费带宽低频轮询又可能漏掉短暂的报警。分开处理之后既保证了事件的实时性又控制了对设备的影响。4.3 批量入库与缓冲策略数据库写入是很容易被忽视的瓶颈。如果每500ms写一条记录15台设备就是30条/秒直接每次都开数据库连接的话数据库的压力会很大而且会产生大量碎片日志。我建议在存储层加一个内存缓冲区攒够一批再批量插入。500条一批或者1秒刷一次性能会好很多。代码层面的做法是public class BufferDataSink : IDataSink { private readonly ListDeviceDataPoint _buffer new(); private readonly object _lock new(); private readonly int _batchSize; private readonly IDbBulkWriter _bulkWriter; public BufferDataSink(IDbBulkWriter bulkWriter, int batchSize 500) { _bulkWriter bulkWriter; _batchSize batchSize; } public void Write(DeviceDataPoint point) { lock (_lock) { _buffer.Add(point); if (_buffer.Count _batchSize) { var batch _buffer.ToList(); _buffer.Clear(); Task.Run(() _bulkWriter.BulkInsert(batch)); } } } }数据库选型上如果只是给看板提供数据SQL Server或MySQL都够用如果后续要做长时间的历史趋势分析我更推荐时序数据库比如TDengine或InfluxDB写入和查询性能会好很多。但不管用什么库采集程序里统一走IDataSink接口以后想换数据库只改一行注册代码就行。5. 上线前必须搞清楚的五个坑都是实测出来的经验5.1 控制器侧的服务开关与连接数限制这一点最容易踩。很多人拿到SDK就开始写代码满脑子都是连接采集结果实际部署时发现设备上根本没启用远程API服务。新代控制器的远程API需要在控制器侧先开启服务功能并配置好可用端口不同版本的控制器开启路径可能不一样有的在诊断页面有的在参数配置里一定要先到控制器上确认。还有一个隐蔽的坑部分版本的控制器固件对同时连接的客户端数量有限制。如果车间里另有一套系统比如ERP扫码枪、刀具管理系统也在连控制器可能会占到连接名额。我遇到过一次现场采集程序连上几台设备后其他设备怎么都连不上排查半天才发现是某台设备的远程API连接数被其他软件占满了。5.2 高频轮询引发的通信拥塞新代控制器的通信模块不是为无限高频访问设计的。我早期测试时把采集频率调到200ms连续跑了一个小时控制器那边出现了响应变慢、偶尔丢包的情况机床操作工抱怨按键反应迟钝。后来我做了两个调整一是把常规数据的采集频率降到1s二是把读操作合并避免一个周期内多次往返。能一次读出来的数据就一次读减少通信报文的数量。实测下来同样20台设备每轮的通信耗时从原来的一两秒降到了两三百毫秒。5.3 多字段读取的数据对齐问题这是做数据分析时才会发现的坑。读取坐标和转速可能不是同一个时刻的因为它们是分多条指令读回来的。在500ms的采集周期里这个误差不明显但如果你要拿这些数据做精确的加工过程分析就会出现坐标已经到下一段了转速值还是上一个周期的这种错位。解决思路有两种一种是把所有字段放到一条读取请求里让控制器端返回同一时刻的快照但这取决于SDK是否支持另一种是在数据模型里记录采集的起始时间和结束时间后处理时按时间戳对齐。我用的是第二种虽然麻烦一些但对数据的准确性更有保障。5.4 断线期间的数据空洞设备断线那段时间数据是采不到的。这不是bug但要在上层做好标记。我见过一些看板系统设备明明已经报警停机一天了看板上却显示还在运行就是因为采集程序断线后没有把数据缺失这个状态传上去。我在数据模型里加了IsGap标志位连续采集失败超过一定次数后会主动写一条数据空洞记录并更新设备状态为离线。上层收到这条记录后在看板上把设备置灰同时开始计算停机时长。这个细节对OEE统计特别重要。5.5 时间戳归属设备时间不可依赖最后说一下时间戳。控制器的系统时间不一定准车间设备经常因为断电、电池没电导致时间漂移甚至有些设备的时间格式和上位机不一致。所以我在设计上一律以采集服务器的本地时间为准生成时间戳设备侧的时间只作为参考字段保存不参与时序计算。这样做的另一个好处是所有设备的数据天然对齐到同一个时钟做跨设备分析比如整条产线的同时段产量对比时不会出现各说各话的情况。如果你是做多点位关联分析的这一点非常关键。如果对时间一致性要求更高的场景建议在上位机上配置NTP时间同步确保工控机本身的时间准确再从工控机统一分配时间戳。我自己的说法是采集程序的核心不是把数据拿出来而是把数据稳定、连续、可信地拿出来。一对多架构真正难的地方也在这里——它逼着你去面对连接管理、调度策略、数据质量这些平时单台调试时根本不会遇到的问题。如果你正在规划类似的项目找个机会先拿车间里最老的一台设备跑通全链路把重连、丢线、数据空洞这些异常都模拟一遍再谈铺开到全部设备。这样上线之后你大概率只需要坐在办公室里喝喝茶而不是天天被电话叫到车间去拔网线。本文还有配套的精品资源点击获取
新代控制器数据采集：SyntecRemoteAPI一对多架构实践
简介工业物联网与智能制造背景下CNC设备联网已成为车间数据采集的基础环节。机床数据采集的难点不仅在于读取控制器内部状态更在于如何通过稳定、高效的通信架构实现多设备并发连接与实时监控。基于TCP/IP的远程API技术为这类场景提供了标准化入口配合合理的连接管理与轮询调度上位机可对车间内十余台控制器进行统一汇聚覆盖主轴转速、坐标、报警等关键参数进而支撑OEE分析、远程运维与MES系统建设。新代SyntecRemoteAPI的一对多采集架构正是这一路径的典型实践涵盖连接管理、轮询策略、数据对齐等关键工程问题。 在机加工车间里做数据采集绕不开一个很现实的问题车间里十几台新代SYNTEC控制器有雕铣机、高光机、石墨机品牌统一、型号各异想统一把运行状态、主轴转速、当前坐标、报警信息实时拉上来市面上却找不到一个真正省心的方案。SyntecRemoteAPI_v4_1.0.12就是新代针对这类远程数据交互场景提供的接口配合一对多的采集程序架构一台工控机就能同时顶住十几台设备的实时数据回传。这篇文章不是翻译一遍官方文档而是把我在实际项目里用这套API做车间级采集的完整过程拆开讲透包括连接管理、轮询策略、数据对齐以及那些不踩一次根本不会注意到的坑。如果你正在做类似的项目不管是给客户上设备联网系统还是给自家车间搭OEE看板这篇应该能帮你少走不少弯路。1. 为什么车间数据采集绕不开SyntecRemoteAPI1.1 新代控制器在数据采集场景里的特殊性新代系统在国内的雕铣、精密加工领域占有率相当高特点是开机快、界面直接、宏程序支持好很多中小加工厂的主力设备都是新代系统。这类设备虽然自带网口但原厂并没有像FANUC FOCAS那样把数据接口做成行业标准导致很多做设备联网的工程师第一反应是串口读或者PLC硬线接吃力不讨好。实际上新代控制器内部有一套完整的状态数据体系当前程序名、程序行号、主轴实际转速、三轴坐标、进给倍率、报警码、运行模式甚至宏变量区。这些数据通过网口就能访问SyntecRemoteAPI做的就是这件事——它把控制器的内部数据以远程接口的形式开放出来上位机通过TCP/IP协议直接读写不需要改PLC程序也不需要动电气柜。1.2 采集难点从来不在读而在怎么读单个读数据其实很简单难的是稳定地、持续地、成规模地读。我自己最早做新代采集时也天真地以为用调试工具连上一台设备读几个地址项目就完事了。真正上线才发现车间现场是另一回事设备IP乱、网线松、控制器偶尔死机、车间停电半小时、有人把网线拔了插到自己笔记本上……这些都是常态。所以SyntecRemoteAPI的价值不在于它能读数据而在于它给了我们一个稳定、统一的数据入口。剩下的连接健壮性、采集调度、数据落库全都要靠采集程序自己兜住。这也是为什么我强调一对多架构因为当你面对的不再是一台设备而是十台、二十台设备时连接管理者、轮询调度、异常恢复这些设计就变成了核心问题。下面是四种常见的采集方案对比基本能说明为什么最后大家都会走到API这条路上。采集方案实施成本实时性数据覆盖范围对现场的影响人工抄录低差极少无硬线IO PLC中转高中以开关量为主需要改电气柜串口协议解析中中依赖协议文档占用设备串口SyntecRemoteAPI以太网中高坐标/报警/程序/宏变量全覆盖仅占用网口通道2. 一对多采集的架构设计让一个服务同时守住十几台设备2.1 一对多不是简单循环而是要分清连接层和业务层一对多这三个字听起来简单很多人第一反应就是在程序里写个for循环遍历所有设备的IP逐个连接、逐个读取。这样做技术上能跑但项目规模一大就出问题——某台设备断线了整个循环被阻塞后面的设备全都跟着等某台设备通信慢其他设备的数据采集周期被拖长程序一旦异常退出所有设备同时失联。我的做法是把采集程序拆成三个层次连接层、采集层、存储层。连接层负责管理每台设备的TCP会话包括连接的建立、断开、心跳检测、断线重连。采集层负责定义每个采集周期要读哪些数据、以什么频率读、读到之后怎么组装成一个标准的数据点。存储层只做一件事——把数据点持久化可以是关系型数据库、时序数据库也可以是直接写MQTT转发给上层平台。分层之后每一层的改动不会影响另外两层。比如想从500ms轮询改成1s轮询只动采集层想从SQL Server换成TDengine只动存储层。这个架构看起来朴素但后续维护的幸福感完全不一样。2.2 线程模型与调度策略连接层和采集层最容易犯的错是每台设备一个裸线程线程里while(true)循环读。设备少的时候没问题设备一多线程上下文切换、锁竞争、数据库连接占用都会变成瓶颈。我建议用两种方式混合连接层每个设备一个独立会话但会话本身是异步的。连接、重连都不阻塞主流程。采集层用一个统一调度器按周期触发每个周期枚举所有在线的设备并行发起采集任务。在.NET环境里我会用一个定时器触发采集周期每个周期内用Task.WhenAll并行执行所有设备的采集任务同时给每个采集任务加上超时保护防止某台设备通信卡死拖垮整个周期。下面是采集调度器的核心代码骨架这个结构我在多个项目里复用过稳定性和可维护性都不错。public class CollectorScheduler { private readonly IDeviceManager _deviceManager; private readonly IDataSink _dataSink; private readonly TimeSpan _interval; private CancellationTokenSource _cts; public CollectorScheduler(IDeviceManager deviceManager, IDataSink dataSink, TimeSpan interval) { _deviceManager deviceManager; _dataSink dataSink; _interval interval; } public void Start() { _cts new CancellationTokenSource(); Task.Run(() RunLoopAsync(_cts.Token)); } public void Stop() { _cts?.Cancel(); } private async Task RunLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { var devices _deviceManager.GetAllDevices(); // 每个周期并行采集所有设备 var tasks devices.Select(d CollectOneDeviceAsync(d, token)); await Task.WhenAll(tasks); // 等下一个周期 await Task.Delay(_interval, token); } } private async Task CollectOneDeviceAsync(CncDevice device, CancellationToken token) { // 超时保护防止单台设备卡死整个周期 using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(token); timeoutCts.CancelAfter(TimeSpan.FromSeconds(3)); try { if (!device.EnsureConnected()) return; var data device.Session.ReadAllData(); _dataSink.Write(data); } catch (OperationCanceledException) { // 单台设备超时记录日志后跳过 } catch (Exception ex) { // 通信异常交给连接层处理重连 device.MarkAsBroken(); } } }2.3 容量评估一台工控机到底能扛多少台设备做方案的时候经常被问一台工控机采集30台设备跑得动吗这个问题不能拍脑袋回得看数据量和采集频率。我按500ms采集周期、每台设备每次采集20个字段来算每台设备每秒产生的数据量大概是40个值30台就是1200个值/秒。以普通IPC的CPU算力解析和组装这些数据完全不是瓶颈瓶颈在网络带宽和数据库写入。单个数据点按JSON格式算约200字节30台设备每秒写入240KB这个量级普通千兆局域网毫无压力。真正考验工控机的是连接数。如果每台设备一个TCP连接一个采集服务要维护30个长连接还要考虑控制器侧能接受多少路并发连接。我实测下来普通的4核工控机跑15台设备、500ms周期CPU占用稳定在5%以内内存占用100MB左右。所以只要不搞一些没必要的复杂框架容量是完全够的。我自己的经验判断供参考设备数量推荐轮询周期工控机要求风险点5台以内200~500ms任意工控机基本无15台以内500ms~1s双核4G以上注意设备侧连接数限制30台左右1~2s四核8G以上注意数据库写入压力3. 连接管理与会话层先把不掉线这件事做好3.1 设备注册表与连接管理器连接管理是一对多采集的地基。我一般先定义一个设备注册表把车间里所有设备的基础信息集中管理起来包括设备ID、IP地址、端口、所属产线、采集开关、备注。这个注册表可以做成配置文件也可以做成数据库表甚至可以在界面上动态增删设备。关键是要让采集程序具备热加载能力也就是加一台设备不用重启服务。设备注册表的基本结构public class CncDevice { public string DeviceId { get; set; } public string IpAddress { get; set; } public int Port { get; set; } public string LineName { get; set; } public bool CollectEnabled { get; set; } public string Description { get; set; } // 运行时状态 [JsonIgnore] public RemoteApiSession Session { get; private set; } [JsonIgnore] public bool IsConnected Session?.IsConnected ?? false; [JsonIgnore] public DateTime LastSuccessTime { get; set; } [JsonIgnore] public int ConsecutiveFailCount { get; set; } public void AttachSession(RemoteApiSession session) { Session session; } public void DetachSession() { Session?.Dispose(); Session null; } }连接管理器则负责维护这些设备的会话生命周期。我用一个ConcurrentDictionary保存设备ID到设备对象的映射所有对设备的访问都走管理器避免多个线程同时操作同一台设备的会话。3.2 断线重连与心跳机制车间的网络环境没有办公室那么干净断线是常态。我做过一次统计一个20台设备的车间一个月内设备侧偶然掉线、网线松动、控制器重启加起来的次数超过40次。如果采集程序不具备自动重连能力运维人员就得天天跑车间。断线重连我建议用指数退避策略而不是死循环重连。死循环重连在设备恢复之前会一直空转既占CPU又可能把控制器侧的连接队列塞满。指数退避的节奏第一次重连等3秒第二次等6秒第三次等12秒最长不超过60秒。设备恢复后下一次采集周期自然就能重新连上。下面是重连逻辑的简化版本。public class ReconnectPolicy { private const int MaxRetryDelaySeconds 60; private const int InitialRetryDelayMs 3000; private readonly Dictionarystring, int _failCounts new(); public async Task ReconnectAsync(CncDevice device) { if (!_failCounts.TryGetValue(device.DeviceId, out int failCount)) failCount 0; int delayMs Math.Min(InitialRetryDelayMs * (int)Math.Pow(2, failCount), MaxRetryDelaySeconds * 1000); await Task.Delay(delayMs); } public void OnSuccess(string deviceId) { _failCounts.Remove(deviceId); } public void OnFail(string deviceId) { _failCounts.TryGetValue(deviceId, out int failCount); _failCounts[deviceId] failCount 1; } }心跳机制也很重要。有些设备断线之后TCP连接不会立刻报错要等写入时才暴露。我会每隔几秒发送一次心跳查询读一个非常轻量的地址如果连续多次心跳失败就主动断开重连。这样比被动等报错要灵敏得多。3.3 RemoteApiSession封装把底层通信细节藏起来拿到SyntecRemoteAPI的SDK之后我做的第一件事不是直接写业务代码而是做一层会话封装。因为不同版本的SDK接口命名会有差异直接散落着调用后续升级SDK会很痛苦。封装后的RemoteApiSession对外暴露的接口保持稳定内部再映射到底层SDK。主要提供Connect()/Disconnect()ReadMachineStatus()读取运行/暂停/报警状态ReadSpindleSpeed()读取主轴实际转速ReadFeedRate()读取进给速度ReadCurrentCoordinates()读取机械坐标或相对坐标ReadCurrentProgram()读取当前程序名和行号ReadAlarmInfo()读取报警信息ReadMacroVariable(int varId)读宏变量这里要特别说一下宏变量的读取。新代控制器开放了宏变量区很多现场会约定用几个宏变量作为信号交换区比如#6011表示机床请求上下料#602用于记录当前工单号。采集程序支持读宏变量等于可以顺便把生产执行层面的信息也采上来这对后续做追溯非常有价值。这个封装层同时还要做一件事内部捕捉SDK抛出的异常转换成统一的业务异常类型。这样上层代码不需要关心底层通信失败的具体原因只需要处理连不上超时数据读取失败这几类。4. 轮询采集与数据落库从控制器内存到数据库的完整链路4.1 数据模型设计每个数据点带什么字段采集程序本质上是在做一件事把控制器内存里离散的状态数据变成一条条带时间戳、带设备标识的记录。所以数据模型的设计会直接影响后续做看板和分析的方便程度。我常用的采集数据点模型public class DeviceDataPoint { public string DeviceId { get; set; } public DateTime Timestamp { get; set; } public int MachineStatus { get; set; } // 0-停止 1-运行 2-暂停 3-报警 public double SpindleSpeed { get; set; } // 主轴转速单位rpm public double FeedRate { get; set; } // 进给速度单位mm/min public double X { get; set; } public double Y { get; set; } public double Z { get; set; } public string ProgramName { get; set; } public int ProgramLine { get; set; } public string AlarmCode { get; set; } public string AlarmMessage { get; set; } }4.2 采集频率的选择逻辑采集频率不是越快越好。太快的轮询会加重控制器的通信负担可能影响机床本身的运行太慢又会丢失关键事件。我的经验是分两类数据、两种频率连续变化数据坐标、转速、进给500ms到1s一轮足够。这些数据用来算设备利用率、加工进度秒级精度完全够。事件型数据报警、程序切换、状态切换建议单独做实时检测。比如每200ms检查一次状态字段发现和上一轮不同就立即记录一条事件。用两个频率的原因很简单高频轮询全部数据会浪费带宽低频轮询又可能漏掉短暂的报警。分开处理之后既保证了事件的实时性又控制了对设备的影响。4.3 批量入库与缓冲策略数据库写入是很容易被忽视的瓶颈。如果每500ms写一条记录15台设备就是30条/秒直接每次都开数据库连接的话数据库的压力会很大而且会产生大量碎片日志。我建议在存储层加一个内存缓冲区攒够一批再批量插入。500条一批或者1秒刷一次性能会好很多。代码层面的做法是public class BufferDataSink : IDataSink { private readonly ListDeviceDataPoint _buffer new(); private readonly object _lock new(); private readonly int _batchSize; private readonly IDbBulkWriter _bulkWriter; public BufferDataSink(IDbBulkWriter bulkWriter, int batchSize 500) { _bulkWriter bulkWriter; _batchSize batchSize; } public void Write(DeviceDataPoint point) { lock (_lock) { _buffer.Add(point); if (_buffer.Count _batchSize) { var batch _buffer.ToList(); _buffer.Clear(); Task.Run(() _bulkWriter.BulkInsert(batch)); } } } }数据库选型上如果只是给看板提供数据SQL Server或MySQL都够用如果后续要做长时间的历史趋势分析我更推荐时序数据库比如TDengine或InfluxDB写入和查询性能会好很多。但不管用什么库采集程序里统一走IDataSink接口以后想换数据库只改一行注册代码就行。5. 上线前必须搞清楚的五个坑都是实测出来的经验5.1 控制器侧的服务开关与连接数限制这一点最容易踩。很多人拿到SDK就开始写代码满脑子都是连接采集结果实际部署时发现设备上根本没启用远程API服务。新代控制器的远程API需要在控制器侧先开启服务功能并配置好可用端口不同版本的控制器开启路径可能不一样有的在诊断页面有的在参数配置里一定要先到控制器上确认。还有一个隐蔽的坑部分版本的控制器固件对同时连接的客户端数量有限制。如果车间里另有一套系统比如ERP扫码枪、刀具管理系统也在连控制器可能会占到连接名额。我遇到过一次现场采集程序连上几台设备后其他设备怎么都连不上排查半天才发现是某台设备的远程API连接数被其他软件占满了。5.2 高频轮询引发的通信拥塞新代控制器的通信模块不是为无限高频访问设计的。我早期测试时把采集频率调到200ms连续跑了一个小时控制器那边出现了响应变慢、偶尔丢包的情况机床操作工抱怨按键反应迟钝。后来我做了两个调整一是把常规数据的采集频率降到1s二是把读操作合并避免一个周期内多次往返。能一次读出来的数据就一次读减少通信报文的数量。实测下来同样20台设备每轮的通信耗时从原来的一两秒降到了两三百毫秒。5.3 多字段读取的数据对齐问题这是做数据分析时才会发现的坑。读取坐标和转速可能不是同一个时刻的因为它们是分多条指令读回来的。在500ms的采集周期里这个误差不明显但如果你要拿这些数据做精确的加工过程分析就会出现坐标已经到下一段了转速值还是上一个周期的这种错位。解决思路有两种一种是把所有字段放到一条读取请求里让控制器端返回同一时刻的快照但这取决于SDK是否支持另一种是在数据模型里记录采集的起始时间和结束时间后处理时按时间戳对齐。我用的是第二种虽然麻烦一些但对数据的准确性更有保障。5.4 断线期间的数据空洞设备断线那段时间数据是采不到的。这不是bug但要在上层做好标记。我见过一些看板系统设备明明已经报警停机一天了看板上却显示还在运行就是因为采集程序断线后没有把数据缺失这个状态传上去。我在数据模型里加了IsGap标志位连续采集失败超过一定次数后会主动写一条数据空洞记录并更新设备状态为离线。上层收到这条记录后在看板上把设备置灰同时开始计算停机时长。这个细节对OEE统计特别重要。5.5 时间戳归属设备时间不可依赖最后说一下时间戳。控制器的系统时间不一定准车间设备经常因为断电、电池没电导致时间漂移甚至有些设备的时间格式和上位机不一致。所以我在设计上一律以采集服务器的本地时间为准生成时间戳设备侧的时间只作为参考字段保存不参与时序计算。这样做的另一个好处是所有设备的数据天然对齐到同一个时钟做跨设备分析比如整条产线的同时段产量对比时不会出现各说各话的情况。如果你是做多点位关联分析的这一点非常关键。如果对时间一致性要求更高的场景建议在上位机上配置NTP时间同步确保工控机本身的时间准确再从工控机统一分配时间戳。我自己的说法是采集程序的核心不是把数据拿出来而是把数据稳定、连续、可信地拿出来。一对多架构真正难的地方也在这里——它逼着你去面对连接管理、调度策略、数据质量这些平时单台调试时根本不会遇到的问题。如果你正在规划类似的项目找个机会先拿车间里最老的一台设备跑通全链路把重连、丢线、数据空洞这些异常都模拟一遍再谈铺开到全部设备。这样上线之后你大概率只需要坐在办公室里喝喝茶而不是天天被电话叫到车间去拔网线。本文还有配套的精品资源点击获取
