ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

可以拆,而且很适合当前“上料位、吹扫位、测试位”形成流水线的设备节拍。但建议拆为长期运行的异步 Worker 加状态机,不要直接创建多个裸线程

可以拆,而且很适合当前“上料位、吹扫位、测试位”形成流水线的设备节拍。但建议拆为长期运行的异步 Worker 加状态机,不要直接创建多个裸线程 可以拆而且很适合当前“上料位、吹扫位、测试位”形成流水线的设备节拍。但建议拆为长期运行的异步 Worker 加状态机不要直接创建多个裸线程。PLC、主控、搬运机构仍需要严格串行控制否则会再次出现指令交叉、Socket 回读错乱的问题。当前StationControlViewModel.cs的RunAutomaticTestFlowCoreAsync是串行链路上料扫码 - 搬运 - 建文件 - 预测试 - 正式测试 - 持久化 - 下料因此一颗器件未全部结束下一颗无法进入搬运或测试无法发挥三个位置并行工作的能力。建议重构后的站内模型如下搬运任务测试结束后搬运搬运任务上料/下料位扫码完成测试位建文件 - 预测试 - 正式测试 - 实时存储 - 汇总吹扫位吹扫完成下料等待取走建议分成 4 个业务 WorkerLoadWorker检测 PLC 允许上料、执行扫码与上料校验。完成后创建ProductContext状态标为“上料完成等待搬运”。TransferWorker统一负责所有搬运动作根据 PLC 条件和位置状态决定执行吹扫位 - 下料位测试位 - 吹扫位上料位 - 测试位同一时刻只允许一条搬运指令执行。TestWorker测试位有器件且允许测试时执行数据文件创建、预测试、正式测试、实时数据写入、结果汇总。结束后只标记“测试完成等待移至吹扫位”不直接自行搬运。UnloadWorker检测下料位/自动化取料条件执行下料扫码、确认、状态清理。人工下料时保留“等待取走”状态。每颗器件应有独立的ProductContext至少保存器件编码、RFID 工装信息、LOT、配方快照、数据文件路径、当前物理位置、当前流程状态、测试结果和错误信息。这样三颗器件在不同位置时不会把数据文件、工装次数或测试结果混到一起。关键约束如下资源处理原则PLC 读写统一由 PLC 状态采集器读取写指令通过单一串行通道执行主控板单站测试位独占预测试和正式测试绝不能并发搬运机构单站独占三种搬运方向由TransferWorker仲裁负载板卡与测试任务绑定避免搬运任务同时下发控制指令数据文件每个ProductContext独立写入后台队列写 CSV但文件归属不能共享停止/复位使用一个站级运行会话取消源统一停止全部 Worker 并阻止新任务入队搬运优先级建议为吹扫位-下料位测试位-吹扫位上料位-测试位。这样先腾出吹扫缓冲位避免测试完成后无位置可移造成测试位长期被占用。还需要一个统一的PlcSignalWatcher。它周期性读取 PLC 信号更新站内位置快照并通知各 Worker而不是每个 Worker 自己无限循环读取 PLC。这样更快也能减少 PLC 通信冲突。另外当前调用处对RunAutomaticTestFlowCoreAsync(...).ConfigureAwait(true);没有await实际是未受控的后台任务注释与实际行为不一致。改造成 Worker 后应由站级调度器集中保存并等待所有 Worker 任务停止按钮才能可靠取消整条流水线。结论可以拆并且应拆。推荐先将现有 7 步抽成独立方法并保持串行验证再引入ProductContext 工位状态机 Worker PLC 状态采集器。这样风险最低也最利于后续增加双工位、多器件、自动化联机和异常恢复。
返回列表