Gonleon 工业

数控采集项目交付清单：网络、账号权限、关键变量、验收用例四类目录 一级分类 章节 核心问题 交付框架 一、为什么要标准化清单 降低交接风险 交付框架 二、网络与安全清单 IP、端口、VLAN、白名单 交付框架 三、权限与变量清单 账号、点位、读写边界 交付框架 四、验收用例清单 连通、稳定、业务闭环 交付框架 五、小结 交付即运维起点 一、为什么要标准化清单没有清单的项目，人员一换就容易断层。标准化交付能把个人经验变成团队资产。 清单的价值还在于审计与复盘：半年后问当时为什么这样配，有文档可查，而不是靠回忆。 二、网络与安全清单 设备/网关/边缘 IP 与网关。 端口策略与防火墙白名单。 VLAN 与交换机端口配置。 证书与账号保管方式。 同时建议记录：谁有权限改网络、变更窗口、回滚方案。生产网变更往往比软件变更更敏感。 三、权限与变量清单关注点： 点位要有来源与权限边界。 记录每个关键变量的来源（NC/PLC）、类型、单位、读写属性、刷新周期。对写点单独列出审批记录与安全评估。 账号方面写明：用途、权限范...

Edge 侧 Sinumerik 驱动日志开到调试级：常见报错信息怎么交给技术支持目录 一级分类 章节 核心问题 日志认知 一、何时需要开调试级 常规日志不足以定位 日志认知 二、常见错误信息分类 连接、变量、超时 支持协作 三、提交支持前打包哪些材料 日志+配置+时间点 支持协作 四、如何避免泄露与噪声 脱敏与时间窗口 收束与实践 五、小结 好日志就是高效支持 一、何时需要开调试级当问题可复现但普通日志不足以说明原因时，可临时提高日志级别到调试。 注意调试级日志体积大、信息密，不建议长期常开。应在复现阶段开启，复现完成后及时调回，避免磁盘占满与信息泄露风险。 二、常见错误信息分类 连接失败： IP/端口/路由/防火墙相关；先 ping、再 telnet/端口探测（在工厂规程允许范围内）。 变量读取失败： 地址、类型、权限、变量是否存在；对照变量手册与组态界面逐项核对。 超时与重连： 链路抖动、负载过高、设备忙；结合网络监控与健康标签一起看。 分类的意义在于：先判断是链路问题还是数据模型问题，避免两个...

MPI 变量与 $ 变量在读旋转状态时取值不一致：文档里为什么要写两段目录 一级分类 章节 核心问题 语义认知 一、同名语义为何取值不同 来源通道差异 语义认知 二、MPI 与 $ 变量的常见差异 编码范围不一致 实践建议 三、项目里如何统一解释 映射字典与转换层 实践建议 四、联调怎么避免误判 明确来源与样例 收束与实践 五、小结 先统一语义再分析 一、同名语义为何取值不同同样是旋转状态，不同变量来源可能采用不同编码标准，因此会出现数值不一致但语义相同。 这不是采集错误，而是数据字典未对齐的典型表现。 二、MPI 与 $ 变量的常见差异常见情况是：一侧用 0/1/2，另一侧用 3/4/5 表示正反停。若未做映射，报表会出现同机不同值的假异常。 手册里分列说明时，应逐字抄入项目数据字典，禁止凭印象翻译。 三、项目里如何统一解释关注点： 建立转换字典。 在边缘或上位增加一层标准化映射，把不同来源统一成业务可读枚举。映射表要版本化，随软件升级复核。 四、联调怎么避免误判文档中标注变量来源+取值范围+业务映射，并给出...

主轴转速、倍率、运行方式：和工艺分析相关的读数注意点目录 一级分类 章节 核心问题 工艺认知 一、主轴变量为何对工艺关键 直接影响加工质量 工艺认知 二、转速、倍率、模式怎么联看 单点不够解释过程 工艺实践 三、常见误读有哪些 单位、取值范围、状态位 工艺实践 四、分析时的建议维度 程序段、刀具、批次 收束与实践 五、小结 数据要回到工艺场景 一、主轴变量为何对工艺关键主轴相关变量是连接设备状态与加工结果的核心桥梁，常用于异常波动追溯。 质量异常复盘时，主轴转速与倍率往往与刀具磨损、颤振等问题强相关。 二、转速、倍率、模式怎么联看仅看实际转速不够，应同时看倍率与运行模式，判断是否人为降速或系统限速。 例如 G96 恒线速生效时，转速变化可能完全正常，单看转速曲线会误判。 三、常见误读有哪些关注点： 变量含义与取值范围必须先确认。 同一字段在不同读取方式下可能取值定义不同，分析前要先做数据字典对齐。单位（rpm、%、模式码）必须写清。 四、分析时的建议维度按程序段、刀具编号、批次分层分析，避免把不同工况的数据混在一起比较。 报表层建议保留最小粒度到件号...

负载、电流、功率、温度相关：设备健康与过载预警可以怎么选点目录 一级分类 章节 核心问题 健康认知 一、为什么要多维健康点 单指标误判风险 健康认知 二、四类常见指标作用 负载、电流、功率、温度 预警实践 三、阈值怎么设更稳妥 静态阈值+动态基线 预警实践 四、如何减少误报漏报 工况分段与持续判定 收束与实践 五、小结 预警是系统工程 一、为什么要多维健康点单独看一个指标容易误判。多维组合才能更准确反映设备健康状态。 例如负载高但电流不高，可能是机械阻力；电流高但负载不高，可能是电气或参数问题。 二、四类常见指标作用 负载： 反映工况压力。 电流： 反映驱动负担。 功率： 反映能量消耗。 温度： 反映散热与异常趋势。 不同机床可选项不同，以手册为准。选点原则是：能解释异常、能指导维护动作。 三、阈值怎么设更稳妥关注点： 不同工况下阈值不应完全相同。 建议先跑一段基线，再按工况分段设阈值，并保留报警持续时间条件。避免启动瞬态触发大量误报。 四、如何减少误报漏报结合状态信号（加工中/待机）做判定，避免待机温升或启动瞬态触发误报。 ...

轴状态与进给、转速设定/实际：OEE 或稼动分析常取哪些量目录 一级分类 章节 核心问题 指标认知 一、OEE 不只看开关机 过程变量很关键 指标认知 二、建议采的轴与主轴量 状态、进给、转速 指标实践 三、设定值与实际值怎么用 偏差诊断 指标实践 四、看板怎么呈现更有用 趋势+阈值 收束与实践 五、小结 从有数到有洞察 一、OEE 不只看开关机仅靠开停机信号很难解释效率损失。轴和主轴过程量能补足为何慢、为何停的证据。 例如计划运行但进给长期为 0与未计划停机在 OEE 归因上完全不同。 二、建议采的轴与主轴量 轴状态与进给倍率。 主轴设定转速与实际转速。 负载与运行模式。 具体点位以机型手册为准，关键是成组采集，避免只有一个孤立量无法解释工况。 三、设定值与实际值怎么用关注点： 设定-实际偏差是关键诊断线索。 持续偏差可能对应机械问题、参数限制或工艺约束，不应只看单点值。可把偏差超过阈值作为亚健康预警输入维护系统。 四、看板怎么呈现更有用建议实时值 + 趋势 + 告警阈值组合展示，避免仅显示瞬时数字。 趋势窗口长度要与工艺节拍匹...

报警类变量 SALA / SALAP / SALAL：按时间、按优先级读分别适合什么展示目录 一级分类 章节 核心问题 变量认知 一、三类报警视图有什么区别 时间与优先级维度 变量认知 二、何时看时间排序 追溯事件链 变量认知 三、何时看优先级排序 快速处置当前风险 展示实践 四、看板与报表如何分工 运维屏与分析表 收束与实践 五、小结 两种视角都需要 一、三类报警视图有什么区别报警变量按时间、优先级等不同逻辑组织，服务不同场景。选型前要问清：班组要看什么、分析员要看什么，而不是只采一种视图。 若只采单一列表，可能在处置效率或追溯完整性上顾此失彼。 二、何时看时间排序做事故复盘、过程追踪时，应按时间查看，便于还原先发生了什么。 时间排序更适合报表与审计，也便于与 MES 工单、录像时间轴对齐。 三、何时看优先级排序关注点： 实时处置时优先级更关键。 当报警很多时，优先级排序能帮助班组先处理高风险项。看板应限制条数并支持确认/销项流程，避免信息淹没。 四、看板与报表如何分工实时看板显示高优先级当前报警；报表系统保留时间序列...

系统与版本类变量：NCK 类型、版本在现场资产管理里怎么用目录 一级分类 章节 核心问题 资产认知 一、为什么先采版本信息 资产分层治理 资产认知 二、NCK 类型字段怎么用 机型识别与策略分组 资产应用 三、版本字段怎么用 兼容性与升级评估 资产应用 四、如何落地到台账 自动同步与告警 收束与实践 五、小结 先识别再优化 一、为什么先采版本信息没有版本与型号基线，后续变量兼容、故障统计、升级计划都很难做准确。 资产系统里若只有机床出厂铭牌而没有控制系统版本，采集策略与备件策略都容易一刀切出错。 二、NCK 类型字段怎么用可用于快速识别控制器类型，作为采集模板、阈值策略的分组条件。 例如不同 NCK 类型对应不同默认可用变量包，模板里可预置不同标签集，减少重复配置。 三、版本字段怎么用关注点： 版本信息直接关系可读变量范围与驱动策略。 当某机型读点异常时，先看版本差异，往往比盲目改参数更有效。升级后应触发回归采集清单，复核关键点位是否仍可读。 四、如何落地到台账把 NCK 类型、版本号自动写入资产台账，设置变更告警，避免现场静默升级导致兼容性问题。 ...

# 产线多品牌数控并存时，统一上报接口（HTTP）的利与弊 目录 一级分类 章节 核心问题 统一价值 一、为什么想统一 HTTP 接口 降低上位复杂度 统一价值 二、统一后的收益 开发与运维效率 统一代价 三、统一后的代价 语义抽象损失 统一实践 四、如何兼顾统一与差异 通用层+扩展层 收束与实践 五、小结 统一要分层 一、为什么想统一 HTTP 接口多品牌并存时，若上位逐一适配协议，成本会迅速上升。统一 HTTP 接口可让 MES 只面对一种契约。 二、统一后的收益 对接周期更短。 监控与日志更统一。 新增设备可复用已有流程。 三、统一后的代价关注点： 统一会丢失部分品牌特有语义。 过度抽象可能导致高级状态被压成简单枚举，影响分析深度。 四、如何兼顾统一与差异建议分两层：通用字段层（状态、报警、节拍）+ 扩展字段层（品牌特有参数），既保证统一又保留深度。 五、小结统一接口是治理手段，不是目的。分层设计可以让系统既统一又不失真。 关于作者联系方式： cheng.z ...

返回值 200 / 201 与业务语义：接口文档和现场排错时怎么对齐目录 一级分类 章节 核心问题 语义认知 一、为什么状态码常被误用 技术成功≠业务成功 语义认知 二、200 与 201 分别表示什么 约定要落文档 协作实践 三、如何做统一返回体 code+msg+detail 协作实践 四、排错时先看什么 状态码后看业务码 收束与实践 五、小结 文档先于联调 一、为什么状态码常被误用很多现场把HTTP 200当作业务成功，但有些接口会在 200 内返回业务失败信息，导致误判。 自动化监控如果只判断状态码，会漏掉大量业务失败。 二、200 与 201 分别表示什么通常 200 表示请求处理成功，201 常用于创建成功。实际项目应以双方接口文档为准，并明确异常语义。 若同一系统混用 200/201，要在文档里写清各自触发条件，避免集成商猜测。 三、如何做统一返回体关注点： 仅靠状态码不够。 建议返回：status/code、msg、detail、request_id，便于追踪与重放。 request_id 对跨团队排障极有价值，应...