AutomaticPipelineExecutionContext本身不会造成等待。它只是一个参数对象用来把以下信息统一传给流水线阶段Product Stage CancellationToken TestPassed当前代码varcontextnewAutomaticPipelineExecutionContext(product,AutomaticPipelineStage.Loading,linkedCancellation.Token);AutomaticPipelineStageResultresultawait_handlers.ExecuteAsync(context);实际执行过程是LoadWorker - ExecuteAsync(context) - _handlers.LoadAsync(product, token) - StationMaterialService.LoadAsync - LoadProduct.StartAsync - 等待 PLC 上料条件 - 扫码也就是说它和之前的逻辑本质等价LoadProductResultresultawait_handlers.LoadAsync(product,linkedCancellation.Token);ExecuteAsync只是多做了两件事1.根据 Stage 选择对应的业务委托2.将 ProcessStepResult 转换成 AutomaticPipelineStageResult不会增加 PLC 等待也不会增加扫码等待。真正可能造成等待的位置有以下几个。1. 初始上料条件等待时间过长LoadProduct.cs中privateconstintPlcPollingTimeoutMs3000_000;这等于3,000,000 毫秒 3,000 秒 50 分钟因此如果以下任意条件不满足LoadProduct.StartAsync最长可能等待 50 分钟允许上料标志位 true 上料位载盘检测 true 吹扫完成标志位 ! 52. 扫码失败后的退料等待StationMaterialService.LoadAsync中如果已经取得部分 SNif(result.RequiresUnloading){awaitScanFailureUnloadAsync(productCodes,...,CancellationToken.None);}此时会继续等待允许取料 器件被取走 光幕恢复 上料位对应光电无料 载盘仍在位取料等待最长可能达到 100 分钟。这是为了防止器件已经放入设备却被取消后遗留现场。3.linkedCancellation只是合并取消信号CancellationTokenSource.CreateLinkedTokenSource(cancellationToken,product.LoadCancellationToken);它表示以下任意一个取消都会触发当前上料流程取消整条流水线停止 当前产品的上料请求被取消但取消是否立即生效取决于LoadProduct内部是否正确使用该 Token。它本身不会主动阻塞。4. 当前和旧逻辑的真正区别旧逻辑LoadProductResultresultawait_handlers.LoadAsync(product,token);当前逻辑AutomaticPipelineStageResultresultawait_handlers.ExecuteAsync(context);当前逻辑只是把返回值包装成AutomaticPipelineStageResult其内部的LegacyResult仍然保存原来的LoadProductResult因此单纯改回旧写法不能解决等待问题。结论问题不在AutomaticPipelineExecutionContext也不在_handlers.ExecuteAsync(context)真正需要检查的是PLC 是否满足初始上料条件PlcPollingTimeoutMs 3000_000是否误设置成了 50 分钟扫码失败后是否进入了ScanFailureUnloadAsync是否因为CancellationToken.None持续等待现场取料日志中是否出现以下关键记录初始上料许可等待PLC条件 等待取料许可 取料完成条件建议暂时保留AutomaticPipelineExecutionContext它只是框架封装。应先在LoadWorker前后增加日志确认具体卡在“上料许可、扫码、退料”哪一步而不是删除 Context。
