用明确的状态构建 PLC 与视觉系统的握手

问题与前置条件

过短的触发脉冲和未被应答的结果，可能导致漏掉工件或沿用旧的判定。先约定好状态行为，再把它映射到实际的电气信号或工业协议。附录是概念性伪代码，不是线路上实际传输的命令。

准备测试

定义 Ready（就绪）、Busy（忙碌）、Result（结果）和 Fault（故障）四种状态，外加工件标识符和与之匹配的应答。本示例假设处理截止时间为 200 ms、应答超时为 500 ms；实际限值要从工位预算中获取。

先把握手写成应用层面的约定，再把它映射到数字 I/O 或网络协议。要明确由哪个控制器生成请求标识、各个状态归哪一方所有、完成时如何应答，以及故障期间如何保留实物工件的处置信息。Ready、Busy、Result 和 Fault 在此只是概念性状态，不是承诺提供的寄存器名称或协议命令。到所选设备的手册中确认它们支持的触发和结果接口。电气或网络时序，要与检测耗时分开记录。如果物理接口没有事务标识符，就要设计并评审一种关联方法，而不要假定下一个结果一定属于下一个工件。用控制器的跟踪记录或合适的信号测量手段，观察实际发生的交互。

操作步骤

1. 仅在 Ready 状态下接受新请求，并在置为 Busy 之前绑定其标识符。
2. 完成采集和检测；把标识符与结果一起发布，并保持二者稳定不变。
3. 只有收到对同一结果的应答之后才回到 Ready；拒绝不匹配的应答。
4. 处理超时或采集故障时，发布 Fault，并防止旧的 OK 被当成当前结果。
5. 测试 Busy 期间到来的请求、重复请求、应答丢失和重启；恢复必须由明确的操作来完成。

VENDOR-NEUTRAL PSEUDOCODE — state semantics, not protocol commands
# Serialize these application events; names below are conceptual.
state = READY
generation = new_generation()
active_token = none
on_request(id):
    if state != READY: record_rejected_request(id); return
    active_token = (generation, id)
    state = BUSY
    arm_processing_deadline(active_token)
    start_bounded_inspection(active_token)
on_completed(token, value):
    if state != BUSY or token != active_token:
        record_stale_result(token); return
    cancel_processing_deadline(token)
    if not application_payload_valid(value):
        enter_fault(token, INVALID_PAYLOAD); return
    publish_stable_result(token, value)
    state = RESULT
    arm_acknowledgement_deadline(token)
on_acknowledge(token):
    if state != RESULT or token != active_token:
        record_unmatched_acknowledgement(token); return
    cancel_acknowledgement_deadline(token)
    clear_published_result()
    active_token = none
    state = READY
on_timeout(token, expected_state):
    if token != active_token or state != expected_state:
        record_stale_timer(token); return
    enter_fault(token, TIMEOUT)
on_acquisition_failure(token):
    if state == BUSY and token == active_token:
        enter_fault(token, ACQUISITION_FAILURE)
enter_fault(token, reason):
    cancel_all_deadlines(token)
    invalidate_pass_result()
    record_fault_and_pending_part(token, reason)
    state = FAULT
on_authorized_recovery:
    if state != FAULT: return
    resolve_part_disposition()
    stop_pending_work_and_clear_events()
    generation = new_generation()
    active_token = none
    state = READY

处于 Ready 时，接受一个有效请求，并在开始采集之前绑定当前生效的标识。处于 Busy 时，保持该标识不变，并按约定的设计明确拒绝后续请求或将其排队；不得悄悄替换当前标识。完成时，把判定和标识一起发布，并保持到收到与之匹配的应答为止。收到针对其他标识的应答时予以忽略，不要清除当前结果。超时、采集失败或结果数据无效，都按已定义的 Fault 转换处理，并使之前发布的任何合格结果失效。回到 Ready 之前，必须有经授权的恢复操作，先处理好受影响的实物工件。这只是功能层面的过程协调，不能取代机器人或设备独立的安全控制。

测试记录示例

以下为示例性假设，并非 Deyi 的实测性能。请将这些数值替换为你自己经签字确认的测试记录。

对于 T300，要让结果及其标识符保持稳定，直到收到匹配的应答或发生已定义的故障转换。在 Busy 期间再发一个请求，再发一个针对 T299 的应答，制造一次超时之后才到达的完成事件，再让控制器重启。每种情况都要记录最终状态和实物工件的处置情况。取消旧的定时器，或对其做代次校验，使已过期的 T300 定时器不会让后来的请求进入故障。附录描述的是行为；实际的信号和报文格式要依据所选控制器的协议。

每个超时都要有负责方、起始边界以及对应的请求代次。示例中的处理截止时间和应答截止时间，检验的是不同的等待，二者不可互换，也不是推荐的设备设置。离开某个状态时取消相应的定时器，或者在处理到期事件之前先核对标识和代次。迟到的完成事件应记为诊断证据，但在请求已经进入故障或已被替换之后，不得再让它发布。应答丢失要与检测失败分开处理：此时工件可能已经有了有效判定，而这笔事务仍未了结。要明确恢复时是重发稳定的结果、围堵该工件，还是需要操作员人工核对。采用所用传输方式文档中记载的重连行为；网络连接恢复正常，并不会自动把上一个工件的事务核对清楚。

流程的两种视图

故障排查

• 脉冲比接收端能够观测到的时间更短时，需要重新设计协议或信号。
• 应答了另一个标识符，说明队列或顺序控制出现了故障。
• Fault 被自动清除，可能掩盖一个未经检测的工件；要明确定义恢复和处置方式。

验收与交接

跟踪每一个发出请求的工件，直到它走到唯一的终态结果，期间没有悄悄覆盖。验证两端的超时和复位行为，包括断电。200/500 ms 这两个值只是假设，不是对兼容设备的保证。

测试前先设定验收限值，并保留原始证据。此处的示例并不能说明所供型号具备相应能力。

依据测试之前备好的预期状态表来验证各状态转换。覆盖正常完成、Busy 期间的另一个请求、错误应答、重复应答、缺图、迟到的完成、连接丢失和控制器重启。对每一种情况，都把观察到的状态、当前生效的标识、稳定的结果和实物处置情况与规格进行比对。验证重启不会把旧的合格结果恢复成新的判定。在边界附近注入故障，以暴露过期的定时器和结果竞态，然后重复一次已验收的正常交互。交接材料包括状态定义、定时器规则、跟踪记录、获批的恢复方式以及实际的信号或协议映射。这份中立的附录需要对照所选设备审查其实现；其中的逻辑操作名称既不是可执行的 PLC 指令，也不代表 Deyi 具备某项通信功能。

相关阅读

选型前请先阅读相关的选型与应用指南。如需工程评审，请提供样品图像、所需达到的结果、运行条件以及已填写完整的测试记录。