先把問題拆開 定義狀態 請求與完成條件
把流程卡住視為可診斷事件，而不是讓線圈一直等。案例固定走PREPARE、WAIT_SENSOR_B、VERIFY、DONE；每次進入步驟都記EnterStep並將Elapsed歸零，只有指定的Sensor B條件成立才能離開等待。
| 項目 | 應定義 | 不要混淆 |
|---|---|---|
| 未開始 | Permit/Start未成立 | 當成逾時 |
| 進行過慢 | Elapsed達上限 | 清除快照 |
| 回饋矛盾 | 輸入與狀態不符 | 假裝完成 |
| 逾時重試 | RetryCount | 無限制重試 |
教學先用虛擬狀態與監看欄位，不接實體輸出。每一步都寫前置、操作、預期結果與失敗先查位置；這樣你在工程軟體中才能逐項核對，而不是只看最後一盞燈。
建立流程 先做狀態表 再寫轉移
建立EnterStep、EnterTime、Elapsed、TimeoutB、SensorB、FaultStep與ErrorCode。進入WAIT_SENSOR_B時記錄EnterTime；Elapsed為現在時間減進入時間，不能每掃描隨意加一當毫秒。本例Elapsed≥5000 ms即逾時，逾時優先於同次觀察的到位；尚未逾時才檢查SensorB。
進入 WAIT_SENSOR_B，記錄 EnterStep 與輸入快照。
讓 Sensor B 維持 0，使用已核對時間來源更新Elapsed。
到5000 ms時確認 FAULT、TIMEOUT_B、FaultStep。
Reset 前確認輸出停止、前提合理，先回IDLE，再由新Start進PREPARE。
完成後應看到：狀態、操作請求、資料欄位與虛擬輸出一致。若不同，先查是否有其他程式段改寫狀態、在錯誤分支清除記憶，或取樣時機不一致。
具體合成案例 逐掃描核對正常與邊界
案例從進入WAIT起算時間。t=0記錄起點，t=1000、3000、4999 ms仍未到位，保持等待；t=5000 ms進FAULT。這是五個觀察時刻，不是五個PLC掃描等於五秒。若t=4999 ms已到位，可進VERIFY；若直到t=5000才同時看到到位，依本例逾時優先，不回成功。
| 進入等待後時間 | 輸入觀察 | 狀態 | 預期處理 |
|---|---|---|---|
| 0 ms | SensorB=0 | WAIT_SENSOR_B | 記錄EnterTime |
| 1000 ms | SensorB=0 | WAIT_SENSOR_B | Elapsed=1000 |
| 3000 ms | SensorB=0 | WAIT_SENSOR_B | Elapsed=3000 |
| 4999 ms | SensorB=0 | WAIT_SENSOR_B | 未達期限 |
| 5000 ms | SensorB=0或剛變1 | FAULT | TIMEOUT_B 逾時優先 |
本例每次只採用一個狀態轉移，故障優先於一般操作；取消、停止與完成的細節依下列固定案例核對。不同設備改用其他政策時，文字、事件表與程式必須一起修改。
用故障快照決定復歸之前要查什麼
先把故障當下的資料保存一份，包含等待步驟、進入時間、經過時間、感測器值、來源品質與命令狀態。故障後的感測器可能才變化，若畫面只顯示目前值，維護人員會看到已到位，卻不知道逾時當下其實仍未到位。快照讓兩個時間點能分開比較。
本例在期限到達時優先判逾時，這是一個可驗收的規格選擇。若工程需求改成同時到位視為成功，就必須一起修改判斷順序、邊界表和驗收答案。不要只改某個比較符號，讓正文寫大於等於，程式卻只在大於時故障，留下難以重現的一個取樣差。
復歸前先看原因是否已排除。感測器回饋矛盾、資料品質無效或外部模組仍忙碌時，不能因操作員按了重置就直接回等待。將復歸被拒絕的原因顯示出來；重置命令只提出意圖，程式仍須檢查可以重新開始的條件。
復歸成功後，本例回待機，由新的啟動重新走準備步驟。這樣可以重新建立計時起點和輸入前提，不沿用失敗工作的時間或完成旗標。若需求允許原步重試，則要另外定義哪些資料可保留、哪些動作可能重複，以及最大重試次數，不能只把故障位元清零。
沒有到位訊號也不一定就是接線斷線。先查輸入模組是否有對應變化，再查程式讀取的位址與極性，接著查到位訊號是否短於取樣間隔，最後才判斷等待時間是否不合理。每改一個條件就重跑正常、不到位與期限邊界三組案例，保存修改前後的證據。
本篇五秒是假設上限，選擇真正上限時應納入設備動作時間、允許延遲與通訊更新時間。不能因故障頻繁就一直加長，直到表面沒有告警；若機構變慢或回饋品質惡化，較長等待只會延後發現問題。先用時間紀錄分辨正常變動與異常延遲，再決定合理設定。
失敗先查 適用限制與常見問題
故障復歸固定由Reset觸發：先停止輸出、保留錯誤記錄，確認故障原因已排除且復歸前提成立後清除目前ErrorCode並回IDLE，歷史紀錄保留。完成結果是每一個等待都有上限；失敗先查目前FaultStep和Elapsed，再量測SensorB實際狀態，最後檢查TimeoutB單位與計時器基準。
三個常見問題
所有等待都用同一 Timeout 可以嗎？不建議，不同步驟合理時間不同。逾時能直接回等待嗎？要先停止輸出並完成復歸。Sensor B 一直 ON 就是壞嗎？先查前提、極性與位址。
逾時設計要避免兩個極端：上限太短會把正常延遲誤判成故障，上限太長則讓維護人員等待沒有診斷訊號。請從流程需求取得合理時間，再考慮掃描週期、感測器更新、機構慣性與允許重試次數。每次進入狀態只初始化一次計時；持續等待時保存 Elapsed，不要每掃描重設。故障畫面至少顯示 FaultStep、ErrorCode、EnterTime、Elapsed、輸入快照和 RetryCount。復歸後重新走前置檢查，若 Sensor B 仍矛盾就再次停在故障，而不是用 Reset 連續跳過問題。
建議把逾時和感測器品質分開記錄。Sensor B=0 可能是尚未到位，也可能是輸入斷線；若模組能提供品質位元，先判斷品質再判斷值。若沒有品質位元，至少保存最後變化時間與連續 0 的長度。逾時後的 FAULT 應可由維護人員重現：相同前提下再次測試，ErrorCode、FaultStep 和輸入快照要一致。
建立故障紀錄時，ErrorCode 不要只寫數字。至少同時保存文字說明、FaultStep、輸入極性、進入時間和復歸次數。維護人員依紀錄先重現相同輸入，再判斷是感測器、接線、條件設定還是流程時限。若修正上限後故障消失，仍要確認新上限沒有掩蓋機構未到位，並把修改前後的測試資料保留。
操作驗收與適用限制
驗收結果是SensorB及時到位才進VERIFY並Done，逾時則固定進FAULT且ErrorCode=TIMEOUT_B、FaultStep=WAIT_SENSOR_B。限制是Elapsed的單位與計時基準取決於你的PLC程式和設定，不能把本文的5000 ms直接套用到所有CPU。
先測成功到位、永遠不到位、剛好逾時三個邊界。重新啟動前確認輸出已關閉與故障原因已記錄；若Reset後立即再逾時，優先查SensorB接點邏輯、TimeoutB單位及EnterTime是否只在進入步驟時記錄。
適用型號與限制：概念可套用具備位元與狀態資料的 PLC；實際指令、資料型別、計時單位、模式切換與復歸行為必須依目標 CPU、工程軟體和設備規格確認。