用明確的狀態建立 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 具備某項通訊功能。

相關閱讀

選型前請先閱讀相關的選型與應用指南。如需工程評估，請提供樣品影像、所需達到的結果、運作條件以及已填寫完整的測試紀錄。