故障復歸按鈕連續操作時如何只接受一次

2026-09-17 · 站長

分開按鈕邊緣、忙碌工作與網路請求身份，建立一次復歸的接受與拒絕規則，避免重送和長按反覆執行。

先定義一次復歸的範圍

復歸按鈕被按住、快速連按或由HMI重送時，不應讓同一件復歸工作重複啟動。先定義一次是一次有效按壓、一個請求身份，還是一個尚未完成的工作。這三者不同；只加一個上升沿，就不一定能解決網路重送與跨掃描工作的重複問題。

本文用Q系列PLC應用設計情境說明接受、執行與回覆的分工，不給未驗證的三菱指令。故障確認、清除診斷、解除流程故障和機台重新啟動是不同動作。即使本次復歸成功，也不能自動推論可以啟動負載或恢復自動流程。

先寫復歸資格：故障原因已依設備設計解除、必要保護與現場條件已確認、沒有另一件復歸工作執行中。按鈕只提出請求，不取代資格。若條件不符，要顯示拒絕原因，而不是接受後不斷清除同一個仍存在的故障。

本例設定三段應用狀態：可接受新請求、處理中、處理結束待釋放。新請求只有在資格通過且輸入已具備新按壓條件時才接受。狀態名稱是教學設計，不是QCPU原生診斷碼，實際控制與安全反應需由設備工程確認。

同一個實體按鈕可能有彈跳，HMI按鈕也可能在斷線後留下舊值。先辨識訊號路徑和有效性，再選處理方式。不要把所有來源都當成毫無延遲的乾淨接點，或用任意延時當成萬用去重。

對單一可信布林按鈕，本例要求先觀察到釋放0，再接受下一個0到1變化。啟動後第一筆若就是1，只建立狀態，不立即當新復歸。這避免PLC或HMI重新連線時，把已按住的舊狀態當成新的操作。

接受後分配一個本次工作身份並進入處理中。按鈕保持1不會再次接受，處理期間即使再次出現0到1，也依本例規格拒絕並回報忙碌，不排隊到稍後自動執行。拒絕與排隊是不同產品行為，必須明確選定。

工作完成後仍要求釋放，下一次才可重新按下。本例不在按鈕仍為1時自動重試失敗工作；否則故障持續存在就會每隔幾掃描重做一次。失敗結果應保留，讓操作員先處理原因，再提出新的請求。

離線時間線：第0筆0建立可按狀態，第1筆1接受J7，第2筆1保持忙碌，第3筆0釋放但J7仍處理中，第4筆1新按因忙碌被拒絕，第5筆J7完成且按鈕仍1。預期接受總數是一，不補執行第4筆；待再次釋放後，下一個新按壓才可接受J8。

如果輸入資料未知，不能直接當成0來重新武裝。依本例策略標資料失效，等來源恢復後先取得有效釋放，再允許新按壓。這樣斷線恢復由未知到1時，不會製造一個假的上升事件。

HMI或上位系統如果會重送，除了按鈕邊緣，還要有明確請求身份。假設請求R52已被接受成工作J7，HMI因回覆延遲再次送R52，控制器端應回覆既有工作狀態，不建立第二件J8。這是去重契約，不能只靠收到時間不同就當新操作。

身份至少要能區分來源、請求序號與來源重啟世代。序號循環或HMI重啟後可能再次使用52，若沒有世代或其他不重複規則，就會把新請求誤認成舊請求。具體資料寬度、保留期限與比對方式依雙方通訊設計確認。

回覆也分接受、處理中、成功與失敗。收到通訊成功回覆只證明某個階段的交握，未必表示復歸已完成。保存工作身份和狀態轉換，操作員才知道是在等回覆、等設備條件，還是已完成但畫面尚未刷新。

斷電發生在動作已執行而完成結果尚未保存時，重啟後可能無法判定是否要重做。先查設備狀態和原工作證據，不宣稱一個請求序號就能保證實體動作恰好一次。若動作不可安全重複，恢復策略要由工程規格另行定義。

外部身份去重與本機忙碌限制需要一致的接受邊界。多個來源同時請求時，不能讓兩條程式各自看到閒置就都接受；優先規劃單一流程管理工作，再依平台確認資料交換。本文不把一個共享Busy位元當成跨上下文的原子鎖。

復歸前保存當前故障與原因狀態，復歸後確認所需條件真的回復。只清掉HMI訊息不代表控制器故障已解除；只清控制器錯誤也不代表現場元件恢復。每個工作結果要寫它完成哪一層，避免用成功兩字涵蓋所有設備狀態。

故障仍有效時，本例拒絕復歸並顯示原因。若某個產品允許清除後立即重報，要按該功能的原廠條件處理；不能用重複按鈕讓畫面短暫不紅，就說機台恢復。需要先保存證據再依正確復歸程序執行。

測試至少包含長按、彈跳、新按時忙碌、未知資料恢復、同身份重送及重啟中斷。每次記接受次數、工作身份與最終結果。長按十個掃描應只接受一次，但若你改成十次不同有效新請求，預期就依忙碌與資格策略重新判定。

失敗時先查計數增加發生在接受點還是執行點。若接受一次卻執行多次，問題在工作狀態或執行條件；若接受多次，查按鈕重新武裝、網路身份及多來源競態。分開計數才能避免只改前端按鈕，卻留下PLC內部重複執行。

完成後應有一份請求與工作對照表，能證明哪個請求被接受、哪個因忙碌拒絕，以及重送如何對到原工作。本文只提供規格與對應結果。

問：用上升沿就能解決所有重複嗎？答：只能處理已定義布林來源的可見邊緣，網路重送與工作重複還需身份和狀態管理。

問：忙碌時按下，完成後要自動補做嗎？答：本例拒絕而不排隊，若需求要排隊，必須另外定義容量、有效期限與取消規則。

問：未知資料可當0讓下一個1被接受嗎？答：本例不可以，先恢復有效來源並確認釋放，避免憑空產生新請求。

問：復歸成功是否同時啟動機台？答：不是同一動作，啟動需另外符合設備模式、許可與操作意圖。