简介面向注塑机设备制造与使用企业的工业物联网方案文档聚焦传统注塑机状态监控、故障报警依赖人工记录、多协议设备难以统一联网等痛点给出从网关数据采集到云端分析的完整改造思路适合设备管理、生产运维及智能制造方案设计人员参考。 全包仅含 1 个 docx 文件约 169KB篇幅精炼、结构完整围绕项目需求、总体方案、网关接入与平台功能等章节展开。 文档具体梳理了注射压力、油温、模具温度、注射速度等参数的实时采集与上传路径说明如何通过支持 5G、4G、WiFi 的智能网关连接注塑机控制器并接入模温机、下料机等周边设备形成生产数据链路后台部分涵盖运行状态可视化、停机与故障数据综合分析、远程故障预警定位与程序升级、历史数据查询与趋势分析可作为方案汇报或实施落地的参考底稿。目前已有 228 人学习下载。1. 注塑机联网不是装个网关就完事这份方案文档到底能落地什么一台用了七八年的液压注塑机操作工每两小时拿纸笔抄一次油温和产量夜班漏抄、白班补记月底设备科拿着那张皱巴巴的记录表倒推停机时间——注塑机设备物联网要解决的就是这类现场。这份《注塑机设备工业物联网智能解决方案.docx》把工业物联网在注塑车间的落地路径拆成三段网关侧采什么、传什么平台侧存什么、算什么管理侧看什么、管什么。它本身不是代码包更像一份带功能清单的方案底稿适合设备主管做立项参考、自动化集成工程师做接口对照、刚接工业物联网项目的上位机或后端开发摸清业务边界。下面按现场实操顺序把这份方案拆成能照着搭的链路。2. 从注塑机控制器到云平台四层数据链路怎么搭方案文档把系统画成“网关—网络—平台”三段真到现场落地我一般拆成现场层、采集层、传输层、平台层四段来对。多拆一层的原因是现场层决定能不能接得上采集层决定数据准不准传输层决定稳不稳平台层决定后面能不能算账。四层里任何一层偷懒后面看板做得再漂亮也是空中楼阁。2.1 现场层先把注塑机控制器的通讯口摸清注塑机不是一块铁板控制器品牌、年代、接口差别极大。落地第一步是做点位普查不是先选网关型号。常见情况有三类近十年的机器多半带以太网口支持 Modbus TCP 或 OPC UA注塑机行业还有基于 OPC UA 的信息模型接口约定能直接读到注射压力、螺杆位置、熔胶时间这类工艺量稍老一些的机器只有 RS485 或 RS232跑 Modbus RTU 或控制器厂商私有协议再老的就只剩继电器输出和指示灯没有通讯口。周边设备同样要一并摸模温机通常有 Modbus RTU 口下料机很多只有开关量冷水机和机械手看品牌部分支持以太网。方案文档特意提到“除注塑机联网外还可支持接入模温机、下料机等周边设备”这句话落到现场就是一张点位表把每台设备、每个参数的地址、类型、单位、量程先登记清楚。参数典型来源数据类型量程示例采集价值注射压力控制器寄存器32 位浮点0200 MPa判断注射是否到位、是否憋压油温控制器或温控表16 位整数×0.10120 ℃液压系统健康度模具温度模温机或控制器16 位整数×0.10300 ℃影响良品率注射速度控制器寄存器32 位浮点0300 mm/s工艺节拍分析螺杆位置控制器寄存器32 位浮点0500 mm判断储料与注射阶段合模/开模信号IO 或状态字布尔0/1状态机核心输入产量计数控制器计数或接近开关32 位整数累加OEE 与订单进度报警码控制器报警区16 位整数厂商定义故障归因这张表不是抄一遍就完普查时要拿控制器手册逐条对地址尤其注意寄存器是 0 基还是 1 基、32 位浮点占两个寄存器时高低字顺序。很多项目后期数据跳变根子都在普查阶段少问了一句“这个地址是十进制还是十六进制”。提示没有通讯口的老机器不要硬拆控制柜取信号。涉及强电和联锁的改动交给现场电气负责人确认采集侧优先用电流互感器、接近开关、三色灯状态这类非侵入方式。2.2 采集层网关做协议转换也做第一道清洗工业物联网网关在这套方案里干三件事把不同协议翻成统一协议、按周期轮询点位、断网时本地缓存。很多方案文档只写“实时采集”实际落地必须回答“多快算实时”。我的做法是按变量变化速度分组轮询而不是把所有点位塞进一个 100 ms 周期。快变量组放注射压力、注射速度、螺杆位置周期 1 s 左右慢变量组放油温、模温1030 s 足够报警和状态字用事件触发或 500 ms 轮询保证停机瞬间能抓到。下面这段 Python 用 Modbus TCP 读四个模拟量逻辑可以直接搬到边缘网关的脚本引擎里。import struct import time from pymodbus.client import ModbusTcpClient HOST 192.168.10.21 # 注塑机控制器 IP按现场改 PORT 502 # Modbus TCP 默认端口 UNIT 1 # 从站地址串口转以太网时常见为 1 # 点位表地址按控制器手册填写这里用 0 基地址示例 POINTS { inj_pressure: {addr: 0, scale: 0.1, unit: MPa}, oil_temp: {addr: 2, scale: 0.1, unit: C}, mold_temp: {addr: 4, scale: 0.1, unit: C}, inj_speed: {addr: 6, scale: 0.01, unit: mm/s}, } def read_f32(client, addr, unit): # 32 位浮点占两个寄存器先按大端拼字节再解包 rr client.read_holding_registers(addr, count2, slaveunit) if rr.isError(): raise IOError(fread failed at {addr}) hi, lo rr.registers[0], rr.registers[1] return struct.unpack(f, struct.pack(HH, hi, lo))[0] def main(): client ModbusTcpClient(HOST, portPORT, timeout1) if not client.connect(): raise SystemExit(controller unreachable) try: while True: row {ts: int(time.time() * 1000)} for name, p in POINTS.items(): raw read_f32(client, p[addr], UNIT) row[name] round(raw * p[scale], 3) print(row) # 实际项目里这里换成 MQTT 发布或写本地缓存 time.sleep(1) finally: client.close() if __name__ __main__: main()这段代码的关键参数不多但每个都能让人翻车。addr是协议地址不是手册上写的 40001 这种展示地址两者差 1 是常态count2对应 32 位浮点struct.unpack(f, ...)里的表示大端如果现场读出来是乱码级的大数或极小数先把换成再试高低字交换四种组合试完基本能对上。timeout1是单次读取超时车间网络抖动时不要设太小否则重试会把轮询周期拖垮。slave参数在部分 pymodbus 版本里叫unit升级库之后报参数错误先看版本文档再改。网关选型时方案文档列了 5G、WiFi、4G 多模通信实际选哪档看车间条件有稳定 WiFi 覆盖且机台不跨 AP 漫游WiFi 成本最低车间没有网络又不想布线4G 最省事高节拍产线或多路数据并发再考虑 5G。通信方式不是越高越好4G 在注塑车间的电磁环境里跑一年稳定性往往比想象中好前提是天线别塞在电柜里。2.3 传输层MQTT 主题设计与断网续传采集层把数据翻成统一格式后往上走最常见的是 MQTT。主题设计要在项目第一天定死后面改一次就要动平台订阅、规则引擎和看板查询三处。我一般按“工厂/车间/机台/数据类型”分层plant/p1/workshop/A/machine/IMM-01/telemetry # 周期遥测 plant/p1/workshop/A/machine/IMM-01/event # 报警与状态跳变 plant/p1/workshop/A/machine/IMM-01/status # 在线状态保留消息机台号用资产编号而不是 IPIP 会变资产编号不会。QoS 用 1保证至少到一次平台侧按ts machine_no做幂等去重。在线状态用保留消息平台一订阅就能拿到每台机当前在不在线不用等下一轮心跳。import json import time import paho.mqtt.client as mqtt client mqtt.Client(client_idgw-A-01) client.username_pw_set(gateway, change-me) client.will_set(plant/p1/workshop/A/machine/IMM-01/status, json.dumps({online: False}), qos1, retainTrue) client.connect(mqtt.example.internal, 1883, keepalive60) client.loop_start() def publish_telemetry(machine_no, row): topic fplant/p1/workshop/A/machine/{machine_no}/telemetry payload json.dumps(row, ensure_asciiFalse) # QoS1发布失败时 paho 会重试生产环境还要落本地队列 client.publish(topic, payload, qos1, retainFalse) while True: row {ts: int(time.time() * 1000), inj_pressure: 82.4, oil_temp: 45.1, mold_temp: 63.7, inj_speed: 41.2} publish_telemetry(IMM-01, row) time.sleep(5)遗嘱消息是这套链路里的“后悔药”网关掉电或网络断开broker 会替它发一条online: false平台不用等超时轮询就能标红。keepalive60表示 60 秒没有心跳就判定断线车间 4G 信号偶尔抖一下这个值别设太小30 秒以下容易误报。断网续传要看缓存容量。按一台机每秒一条、单条 300 字节算一天约 26 MB网关本地留 7 天缓存就要按 200 MB 起步规划。恢复后补传要带原始时间戳平台按时间戳入库不能拿补传时刻当采集时刻否则 OEE 的时间轴会整体错位。方案文档里写“历史数据查询、统计任意时段设备参数”前提就是每条数据的时间戳可信。2.4 平台层时序表怎么建看板才不白做数据落到平台第一件事是选存储。注塑机数据是典型时序数据写多读少、按时间范围查、按机台聚合。用关系库硬扛三个月后查询就会变慢。常见做法是上时序数据库TDengine、InfluxDB 都行表结构按“一个超级表 机台作为标签”设计。CREATE STABLE IF NOT EXISTS imm_telemetry ( ts TIMESTAMP, inj_pressure FLOAT, oil_temp FLOAT, mold_temp FLOAT, inj_speed FLOAT, cycle_time INT, shot_count BIGINT, state TINYINT ) TAGS ( plant BINARY(32), workshop BINARY(32), machine_no BINARY(24), model BINARY(32) );标签放不随时间变化的维度遥测放随时间变化的量。state用枚举整数存0 停机、1 待机、2 合模、3 注射、4 保压、5 储料、6 顶针、9 报警比存字符串省空间也方便聚合。原始数据按 1 s 或 5 s 存再建 1 分钟和 1 小时降采样任务看板默认查聚合表查明细时才回原始表。看板不要一上来铺满屏。先做三块实时状态墙每台机当前状态、当前循环时间、当班产量、报警中心按机台和时间倒序带确认状态、OEE 趋势按班次、按机台。方案文档里提到的“动态形式显示合模、注射、储料、顶针、座台”落到界面上就是状态墙里一个色块加一行文字颜色规则要在需求阶段和车间对齐否则上线后每个人理解的红色都不一样。3. 关键参数怎么设采样周期、状态机与告警阈值同样一套网关和平台参数设得粗数据就只能看个热闹设得细才能拿去算 OEE、做故障归因。这一章把三个最容易被敷衍过去的配置讲透采样与上报周期、注塑循环状态机、告警阈值防抖。3.1 采样周期和上报周期分开设很多人把“采集周期”和“上报周期”混成一个参数结果要么流量爆掉要么曲线锯齿严重。正确做法是分开采集周期决定数据精度上报周期决定网络和存储成本中间还可以加一层死区过滤数值变化不超过阈值就不上报。参数采集周期上报周期死区说明注射压力200 ms1 s1 s0.3 MPa峰值要抓得住死区避免稳态刷屏注射速度1 s1 s0.5 mm/s与压力同组轮询油温10 s30 s0.2 ℃慢变量死区可以小模温10 s30 s0.2 ℃多路模温按通道拆点循环时间事件触发每模一次无开模信号上升沿触发产量计数事件触发每模一次无用边沿不用电平报警码500 ms变化即报无从 0 变非 0 立即上报死区不是拍脑袋定的。压力死区设太小稳态时每秒钟都在上报设太大真实的压力爬升会被吃掉。我的经验是先按量程的 0.5%1% 起步跑一周看曲线再调。油温和模温这类慢变量死区可以压到 0.2 ℃因为上报频率本来就低。注意上报周期不要小于采集周期否则同一份数据会被重复打包。规则引擎里看到“一秒内三条相同时间戳”的记录先查这个参数。3.2 状态机映射别拿一个运行信号判断整台机方案文档要求实时显示“合模、注射、储料、顶针、座台”这些状态现场最容易犯的错是只取一个“运行中”信号然后所有非运行都算停机。这样算出来的 OEE 会把调模、待料、预热全算成故障停机车间一看数据就说不准项目信任度直接塌。状态机要拿多个信号组合判断合模信号、螺杆位置、注射压力、顶针信号、报警码。下面这段逻辑是简化版实际项目按控制器状态字调整。def detect_state(s): # s 是采集层组装好的字典布尔量和模拟量混在一起 if s.get(alarm_code, 0) ! 0: return ALARM if s.get(manual_mode): return MANUAL # 调模、试模单独归类不算故障 if not s.get(mold_closed): if s.get(ejector_fwd): return EJECT if s.get(cycle_active): return IDLE return STOP if s.get(inj_pressure, 0) 0.5 and s.get(screw_pos, 0) s.get(screw_end, 0): return INJECT if s.get(holding): return HOLD if s.get(charging): return CHARGE return CLAMPmanual_mode这个点值得单独争取。很多控制器有手动/自动状态位能读到就一定要读读不到就用“合模信号长时间不动 有操作面板输入”去推断。调模时间单独归类之后停机分析里就不会混进大量“假故障”。状态切换要记事件不要只存当前状态否则事后没法还原“这台机上午十点到十点二十到底在干什么”。状态编码定好之后平台侧的状态墙、OEE 可用率、停机原因分布都从这张事件表出口径统一后面加报表不用重复对数。3.3 告警阈值与防抖连续越限才报恢复要滞回注塑机报警分两类控制器自带的故障码和采集侧算出来的工艺越限。前者直接透传后者要自己配阈值。油温过高、模温偏差过大、注射压力峰值超限、循环时间异常这四类是最常配的。阈值不能只看绝对值要看工况。油温 55 ℃ 在夏天正常、在冬天可能偏高模温偏差要跟设定值比不是跟固定值比。我的做法是每条规则带三个参数阈值、持续次数、恢复滞回。连续 3 次越限才告警恢复时要比阈值低 2 ℃ 才消警避免在临界点反复横跳。class DebounceAlarm: def __init__(self, high, low, n3): self.high, self.low, self.n high, low, n self.hits 0 self.active False def feed(self, value): if not self.active: self.hits self.hits 1 if value self.high else 0 if self.hits self.n: self.active True self.hits 0 return RAISE else: if value self.low: self.active False return CLEAR return Nonehigh是触发阈值low是恢复阈值两者之间就是滞回带。n3对应“连续三次”采样周期 1 s 时相当于 3 秒确认能滤掉大部分毛刺。报警产生后要落库带机台号、规则名、触发值、时间戳方案文档里“记录设备故障发生的时刻”靠的就是这张表。报警确认动作也要记谁在什么时候确认的后面做 MTTR 分析用得上。告警分级建议只分三级提示、警告、停机。级别太多车间不会看。提示类进日报警告类进当班看板停机类才推送到设备管理员的手机端。4. 多协议老设备统一接入点表、转换方式与无口设备方案文档点出的行业痛点很实在“不同注塑机设备企业不同工序设备中工控协议、通信协议众多造成不同协议注塑机设备无法进行统一的物联网智能化解决。”这句话翻译成工程问题就是点表怎么统一、协议在哪转、没口的设备怎么办。4.1 点表设计先定命名再谈采集多协议接入的第一件事不是写驱动是定一套统一命名。没有命名规范今天叫oil_temp、明天叫oilTemperature、后天叫T_OIL三个月后自己都认不全。我一般用三段式区域.设备.点位全小写加下划线。a1.imm01.inj_pressure a1.imm01.oil_temp a1.imm01.mold_temp_ch1 a1.imm01.cycle_time a1.imm01.shot_count a1.imm01.alarm_code a1.temp_ctrl01.set_temp a1.loader01.run_state点表至少包含这些字段统一点位名、源设备、源协议、源地址、数据类型、寄存器数量、缩放系数、单位、读写权限、采集组、死区。缩放系数要写清楚是乘还是除比如控制器读出来 451 表示 45.1 ℃系数就是 0.1如果读出来是 4510 表示 45.10 ℃系数就是 0.01。这两者搞混看板上的温度会差十倍属于上线第一天就会被车间发现的低级错误。字段示例作用taga1.imm01.oil_temp平台侧统一查询名protocolmodbus_tcp决定用哪个驱动address2源地址按协议手册data_typef32决定解析方式scale0.1原始值到工程值unitC展示与告警单位groupslow决定轮询周期deadband0.2上报过滤点表用 Excel 维护也可以但上线前要导成平台能吃的 JSON 或 CSV手工在网关界面一个个敲五十台机就是灾难。4.2 协议转换的三种落地方式多协议统一接入常见三条路各有适用边界。第一条是网关内置驱动。工业物联网网关厂商通常已经把 Modbus RTU/TCP、OPC UA、部分欧系和日系控制器协议做成内置驱动现场选驱动、填地址就能跑。这条路上手最快适合标准化程度高的项目缺点是遇到冷门私有协议只能等厂商排期。第二条是边缘程序自己写。网关支持容器或脚本引擎时用 Python 或 C 写采集程序pymodbus 读 Modbus、opcua 库读 OPC UA、paho-mqtt 往上发协议转换逻辑完全自己控制。适合协议杂、点位映射规则复杂的项目代价是要自己维护重连、缓存、线程调度。前面 2.2 的代码就是这条路的最小骨架。第三条是串口服务器加上位机轮询。老设备只有 RS485先用串口服务器转成以太网再由一台边缘计算机统一轮询。这是过渡方案优点是串口服务器便宜、不用换网关缺点是轮询压力和单点故障都集中在那台计算机上机台超过二三十台就要考虑拆进程或换方案。方式上手速度协议覆盖维护成本适用场景网关内置驱动快看厂商低主流控制器、标准化产线边缘程序自写中取决于库中协议杂、映射规则多串口服务器上位机快串口协议高老设备改造、小批量试点选型时不要只看“能不能通”要看“断线之后多久能自己恢复”。内置驱动一般带看门狗自写程序要自己加指数退避重连否则网络抖一下采集进程就挂在那里等重启。4.3 无通讯口的老设备非侵入式采集也能出数据老注塑机没有通讯口不代表没有数据。常见做法是加装三类传感器电流互感器夹在主电机回路上用电流阈值判断开停机接近开关或光电开关装在开模位置数开模次数算产量三色灯状态用光敏或电压检测取运行、待机、报警。电表加在总进线还能把单台机能耗算出来。这类采集的精度不如控制器读数但足够回答“这台机今天开了多久、做了多少模、有没有长时间停”。方案文档里“设备运行、产量、停机、各种故障数据自动进行综合分析”在老设备场景下靠的就是这些替代信号。要注意的是加装传感器涉及停电、接线、动电柜必须由现场电气负责人确认采集侧只负责取干接点和通讯数据不碰强电改造。非侵入式采集的点位也要进同一张点表命名上加ext_前缀区分来源比如a1.imm07.ext_current、a1.imm07.ext_shot_count。平台侧做 OEE 时来自控制器的循环时间和来自接近开关的模数要能对得上对不上就说明其中一路有问题这本身就是数据校验的入口。5. 避坑排查上线前最容易翻车的五件事这套链路我见过太多项目在演示环境跑得通、到车间就出问题。下面五条按“现象—原因—解决”写都是上线前该主动验一遍的点。5.1 数据类数值跳变、产量多计现象看板上油温一会儿 45 ℃、一会儿 4500 ℃或者压力曲线出现整段直线后突然一个尖峰。原因九成是解析问题。32 位浮点的高低字顺序搞反、缩放系数用错、寄存器地址差 1、把有符号数当无符号读。剩下的一成是轮询冲突两个采集任务同时读同一段寄存器控制器返回错位数据。解决拿控制器面板显示值和网关原始值逐点对照先确认地址和数据类型再试四种字节序组合。轮询任务按设备分组串行不要多线程并发读同一台机。上线前跑一轮 24 小时原始数据留存出问题能回放。5.2 数据类产量计数多计或漏计现象一个班次实际做了 800 模平台显示 1200 模或者少一百多。原因用了电平信号而不是边沿信号开模信号持续 2 秒1 秒轮询就计了两次或者信号抖动机械开关在临界位置反复通断。解决计数逻辑改成上升沿触发并在边缘侧做 200500 ms 的软件消抖。能读到控制器内部计数器就直接读计数器差值比外部开关可靠。上线前拿一个班次手工点数对照误差超过 1% 就要查。5.3 传输类网关在线平台没数据现象网关管理页面显示在线MQTT 也连上了但平台查不到某台机的数据。原因主题拼错、平台侧订阅权限没开、机台号里有大小写或空格、时间戳用了网关本地时间而网关没对时。还有一种隐蔽情况是 NAT 或防火墙只放行了上行 broker 的回执下不来QoS 1 的重传把队列堵死。解决在 broker 侧用命令行订阅通配主题看原始报文能不能到对比网关本地日志和平台入库时间戳差超过 5 秒就查 NTP主题命名统一小写机台号在点表里就固定下来不让现场手输。5.4 成本类4G 流量跑超现象试点三台机没事铺到五十台月底流量超套餐。原因上报周期设成 1 秒、死区没开、每条报文带完整点位名、断网重传没有上限。还有一个常被忽略的TCP 长连接的心跳包在弱网下反复重连每次重连都带一次全量注册。解决按“单条报文大小 × 每天条数 × 机台数 × 1.5 倍冗余”估算流量先算再选套餐。死区必须开慢变量单独降频。断网缓存设上限比如 7 天或 500 MB超了丢最旧的数据并记日志不要让缓存把存储撑爆。5.5 业务类看板状态和现场对不上现象车间说这台机在调模看板显示停机或者明明停了半小时看板显示一直在运行。原因状态机只取了一个运行信号没覆盖手动模式或者状态跳变没落事件表只存了当前状态事后无法还原还有一种情况是断网补传的数据时间戳被改写运行时段被拉长。解决状态机至少接合模、螺杆位置、报警码、手动模式四个信号状态变化写事件表带开始时间、结束时间、持续时长补传数据保留原始采集时间平台侧按事件时间重算不按入库时间重算。6. 数据验真与 OEE 反推上线后怎么证明这套链路没白搭看板点亮不等于项目成功得能用数据回答车间的实际问题。我习惯在上线第一周做三组校验再做一次 OEE 反推两件事做完这套链路的价值和边界就都清楚了。第一组校验是网关原始值和控制器面板值对照。挑三台机每台选五个点位早中晚各抄一次面板值和网关同时刻的原始值比对偏差超过量程 1% 就回去查点表。第二组是平台入库时间戳和网关本地日志对照重点看断网恢复后的补传段时间轴错位会让后面所有统计失真。第三组是产量计数和车间手工点数对照跑满一个班次误差超过 1% 就查边沿触发和消抖。三组过了之后算 OEE。可用率用运行时间除以计划时间性能用实际产量除以理论产量良品率用良品数除以总数三个相乘。下面这段 Python 从事件表和产量表里按班次算逻辑不复杂关键是口径要提前和车间确认计划时间含不含午休、换模算不算计划停机、试模算不算产量。import pandas as pd # events: machine_no, state, start_ts, end_ts # output: machine_no, shift, good_qty, total_qty, ideal_cycle_sec events pd.read_parquet(state_events.parquet) output pd.read_parquet(shift_output.parquet) def oee(row, ev): plan_sec 8 * 3600 run_sec ev.loc[ev[state].isin([2, 3, 4, 5, 6]), dur].sum() down_sec ev.loc[ev[state].isin([0, 9]), dur].sum() availability run_sec / plan_sec performance (row[total_qty] * row[ideal_cycle_sec]) / run_sec if run_sec else 0 quality row[good_qty] / row[total_qty] if row[total_qty] else 0 return pd.Series({ availability: round(availability, 3), performance: round(min(performance, 1.0), 3), quality: round(quality, 3), oee: round(availability * min(performance, 1.0) * quality, 3), down_min: round(down_sec / 60, 1), }) result output.apply(lambda r: oee(r, events[events[machine_no] r[machine_no]]), axis1) print(result.sort_values(oee))ideal_cycle_sec不要拍脑袋填用历史数据里最稳定的那批循环时间取中位数再和工艺工程师确认。性能算出大于 1 的说明理论节拍定错了先修参数再发报表。down_min单独列出来是为了让设备科看到停机到底集中在哪几台而不是只盯着一个 OEE 数字吵架。进阶一点的用法是把报警事件和停机事件按机台做时间关联同一台机连续三天在同一时段报油温高基本能锁定散热或冷却水问题某台机换模后循环时间整体上移去看模温和保压参数。这些结论不需要多复杂的算法前提就是点位准、时间戳准、状态机口径统一。血泪经验是不要等看板上线才开始对数。点表定稿、网关跑通、平台入库这三个节点各验一次比上线后回头查省十倍力气。从那以后我每次接注塑机项目都先把点位普查表和断网补传日志强制走一遍再谈看板和 OEE。希望帮到你。本文还有配套的精品资源点击获取
