先把問題拆開 定義狀態 請求與完成條件
模式切換先回答誰可以接手。本篇規定FEEDING中拒絕切換，CurrentMode維持AUTO；操作員先依正常停止流程回WAIT，再重新提出模式請求。ModeRequest只代表意圖，CurrentMode才是已生效模式。故障不能靠切模式清除。
| 項目 | 應定義 | 不要混淆 |
|---|---|---|
| WAIT | 接受並進SAFE_CHECK | 等待輸出撤銷與前提確認 |
| FEEDING | 拒絕，維持原模式 | 不延後偷偷套用舊請求 |
| FAULT | 拒絕切換 | 須排除故障並完成Reset |
| PAUSED | 拒絕切換 | 先取消或完成既有工作 |
教學先用虛擬狀態與監看欄位，不接實體輸出。每一步都寫前置、操作、預期結果與失敗先查位置；這樣你在工程軟體中才能逐項核對，而不是只看最後一盞燈。
建立流程 先做狀態表 再寫轉移
建立ModeRequest、CurrentMode、Permit、State、Busy與RejectReason。操作員改模式時只寫ModeRequest；PLC在掃描中依State判斷。WAIT可接受請求並進SAFE_CHECK，FEEDING一律拒絕並保留AUTO，FAULT須先排除原因，依Reset條件復歸。切換成功後才更新CurrentMode，再由它產生手動或自動Permit。
建立 ModeRequest、CurrentMode、Permit、State、Busy、RejectReason。
WAIT 提出手動，確認 CurrentMode 在允許點更新。
FEEDING 提出手動，確認拒絕並維持AUTO。
切換後清除不適用的佇列、計時器與一次性請求。
完成後應看到：狀態、操作請求、資料欄位與虛擬輸出一致。若不同，先查是否有其他程式段改寫狀態、在錯誤分支清除記憶，或取樣時機不一致。
具體合成案例 逐掃描核對正常與邊界
案例從AUTO的FEEDING開始：S2要求MAN被拒絕；S3完成另外的受控停止回WAIT。S4重新提出MAN並做SAFE_CHECK，S5模式生效但不自動輸出，S6才接受新的手動操作。表中每列是假設前提已達成的一次觀察，停止可能跨多個掃描，不能把表列當成固定停止時間。
| 掃描/條件 | 判斷 | 狀態 | 應看到的結果 |
|---|---|---|---|
| S1 | AUTO FEEDING | FEEDING | 原工作執行 |
| S2 | ModeRequest=MAN | FEEDING | RejectReason=BUSY 模式不變 |
| S3 | 受控停止已完成 | WAIT | 自動輸出撤銷 |
| S4 | 新模式請求 | SAFE_CHECK | 檢查前提 不啟動手動 |
| S5 | 檢查通過 | WAIT | CurrentMode=MAN 只開手動許可 |
| S6 | 新的手動操作 | 依手動命令 | 不沿用切換前按鍵 |
本例每次只採用一個狀態轉移，故障優先於一般操作；取消、停止與完成的細節依下列固定案例核對。不同設備改用其他政策時，文字、事件表與程式必須一起修改。
模式切換後第一個命令最容易出錯
把模式切換分成請求、檢查及生效三個階段，畫面也分別顯示。操作員按手動後若流程仍在送料，顯示切換被拒絕及忙碌原因；不要立即把畫面標題改成手動，卻讓控制流程繼續自動送料。兩個名稱若不一致，操作員會用錯誤的期待操作下一顆按鈕。
待停止完成後，重新提出手動請求。檢查自動輸出命令已撤銷、既有工作已結案或明確取消、沒有未處理故障，才讓手動模式生效。這裡的條件必須由實際設備定義；某個輸出位元為零，不一定代表機構已停止，可能還需要驅動器或位置回饋。
手動生效的第一個掃描不接受切換前已按住的點動鍵。先要求按鍵回到未操作狀態，再接受新的按下。否則操作員一手按切換、一手仍按著舊按鍵，模式剛生效就可能出現非預期命令。這個重新操作要求要同時寫進畫面提示與測試表。
從手動回自動也有同樣問題。自動啟動請求即使曾經成立，也不能在模式回來時直接補執行。先清除或取消過期請求，保存取消原因，再要求新的啟動。若需要恢復未完成批次，應另走批次恢復程序，檢查工件、配方版本與既有結果，而不是只切回模式。
練習時把拒絕、停止、重新請求、生效及新操作五個事件依序記錄。正常結果是拒絕時模式不變，停止完成時沒有自動補送，生效時也沒有立即點動。若其中任何一步跳過，先查原請求是否被持續保存，或程式是否把模式允許直接接成動作輸出。
最後比較兩個故障情境：第一個是模式切換被拒絕，第二個是設備本身故障。拒絕訊息不應清掉設備故障，設備復歸也不應自動接受先前被拒絕的模式請求。將兩種原因各自保存，操作員才能知道現在是要停止工作、排除故障，還是重新提出切換。
失敗先查 適用限制與常見問題
測試時把ModeRequest、CurrentMode、State、Permit與RejectReason放在同一監看表。切換成功時CurrentMode等於請求且Permit只開對應模式；失敗先查State是否仍在FEEDING、停止條件是否成立，再查模式切換邊界是否被同一掃描的舊命令穿透。
三個常見問題
切到手動一定要立即停嗎？不一定，要按風險和流程選政策。CurrentMode 可直接綁按鈕嗎？按鈕應寫請求。切回自動要重做嗎？依流程重新核對前提與快照。
本例拒絕FEEDING中的切換請求，因此既有計時器與工作資料不因拒絕而重設。待停止完成回WAIT後，先把未執行的自動請求標成取消並留紀錄，再接受新模式。切到手動後要先釋放舊按鍵，重新操作才產生命令，避免長按訊號穿過模式邊界。
切換矩陣最好再加入佇列策略：立即取消要丟棄哪些請求、完成後切換要保留哪些請求、拒絕切換要不要通知操作者。若手動模式允許點動，進入手動前必須確認自動輸出已撤銷；離開手動前也要清除長按中的命令。測試不要只用理想輸入，還要在切換瞬間讓 Stop、故障與完成同時成立，保存每一掃描的決策證據。
做完矩陣後，再以畫面操作走查：模式按鈕只寫 ModeRequest，畫面同時顯示 CurrentMode、State、Busy 和 RejectReason。若操作員在 FEEDING 反覆按手動，本例拒絕後要重新提出請求，但不可製造多個切換事件。完成後把切換前後的佇列數、計時值和完成件數存成測試紀錄，日後才能判斷是模式問題還是流程本身延遲。
操作驗收與適用限制
驗收結果是切換成功時CurrentMode與Permit一致；FEEDING中要求切換時CurrentMode保持AUTO並顯示BUSY；FAULT中只能走Reset。限制是模式名稱與停止條件屬本例定義，不能直接當成任何Q系列程式的固定裝置或系統訊號。
請分別測試WAIT切換、FEEDING拒絕、FAULT復歸與重新啟動。每次記錄ModeRequest、CurrentMode、State，若畫面顯示已切換但輸出仍動，先查Permit生成條件與同掃描命令順序。
適用型號與限制：概念可套用具備位元與狀態資料的 PLC；實際指令、資料型別、計時單位、模式切換與復歸行為必須依目標 CPU、工程軟體和設備規格確認。