先確認是不是多處寫入
當輸出明明被自動流程打開，卻在下一個掃描又關閉，先不要猜感測器壞掉。先找同一個輸出或變數的所有寫入點。最常見的情況是主流程在前面寫 ON，另一段預設邏輯在後面無條件寫 OFF；PLC 依程式執行順序保留後面的結果。不同品牌對重複線圈、重複賦值是否警告或允許可能不同，不能把某軟體的警告當成所有平台規則。
| 寫入點 | 條件 | 寫入值 | 可能作用 |
|---|---|---|---|
| A 自動流程 | AutoRun=1 | OUT=1 | 先要求輸出 |
| B 預設邏輯 | 未寫條件或 Stop=0 | OUT=0 | 後面覆寫 |
| C 手動命令 | Manual=1 | OUT=1 | 第三個來源 |
| D 警報處理 | Alarm=1 | OUT=0 | 通常應有最高優先 |
| 輸出層 | 集中決策 | OUT=允許值 | 唯一實體寫入 |
把『命令來源』和『實際輸出』分開。AutoRequest、ManualRequest、AlarmBlock 可以有多個寫入或計算來源；真正的 OUT_Y0 只在輸出決策層寫一次。這樣即使結果是 OFF，也能知道是未請求、互斥、停止條件或警報阻擋。
用交叉參照追蹤最後寫入者
以輸出位址、符號名稱和別名各搜尋一次，避免只搜到其中一種寫法。
區分讀取點、寫入線圈、SET/RESET、MOV/賦值和功能塊輸出連接。
按主程式、子程式、任務或網路的實際呼叫順序排列寫入點。
為每個寫入點記錄條件、值、掃描位置和來源命令。
在監看中同時看來源旗標和最終輸出，逐掃描比對。
通用偽碼（僅示意，不代表任何 PLC 可直接編譯）：
AutoRequest := AutoRun AND StepReady;
ManualRequest := Manual AND JogButton;
Block := Alarm OR Stop;
OutputCommand := (AutoRequest OR ManualRequest) AND NOT Block;
OUT := OutputCommand;
這種結構把命令來源保留到最後才寫實體輸出。若平台要求直接線圈、SET/RESET 或特殊輸出更新，請依該平台手冊改寫。
若交叉參照顯示 OUT 只有一個寫入點，仍要查別名、陣列索引、功能塊 IN_OUT、間接位址和其他任務。多處賦值不一定都長得像兩個線圈；有些寫入透過資料搬移或功能塊輸出發生。
虛擬案例 自動開啟後又被關閉
假設 AutoRun=1、StepReady=1、Alarm=0、Stop=0。程式段 A 將 OUT:=1，程式段 B 的預設條件卻在每掃描將 OUT:=0。若 A 先執行、B 後執行，掃描結束看到 OUT=0；把 A、B 對調則可能看到 OUT=1。這是合成案例，用來核對執行順序，沒有宣稱任何實機輸出已動作。
| 掃描 | A 寫入 | B 寫入 | 最後值 | 應追的證據 |
|---|---|---|---|---|
| 1 | OUT=1 | OUT=0 | 0 | B 是最後寫入 |
| 2 | OUT=1 | OUT=0 | 0 | 條件仍成立 |
| 3 | OUT=1 | OUT=0 | 0 | 不是輸出硬體先關 |
| 4 | 改成集中決策 | 無其他寫入 | 1 | 命令與阻擋條件可見 |
| 5 | Alarm=1 | 集中決策 | 0 | Block 優先 |
| 6 | Alarm=0 | 集中決策 | 1 | 恢復條件明確 |
完成後應看到：交叉參照只剩一個實體 OUT 寫入點；自動命令成立且沒有 Block 時輸出 ON；Alarm 或 Stop 成立時輸出 OFF；監看畫面能分別看到 AutoRequest、ManualRequest、Block 和 OutputCommand。若只有 OUT 一個燈，卻看不到命令來源，除錯資料仍不完整。
命令優先層與測試矩陣
| Auto | Manual | Stop/Alarm | 預期輸出 | 驗證重點 |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 無命令 |
| 1 | 0 | 0 | 1 | 自動命令 |
| 0 | 1 | 0 | 1 | 手動命令 |
| 1 | 1 | 0 | 1 或依規格 | 互斥或優先需明訂 |
| 1 | 0 | 1 | 0 | 阻擋優先 |
| 0 | 1 | 1 | 0 | 阻擋優先 |
| 1 | 1 | 1 | 0 | 不可被命令越過 |
失敗時先查的順序是：一、輸出是否真的有第二個寫入或間接寫入；二、最後寫入段的條件是否每掃描成立；三、任務、子程式、SFC action 的執行順序；四、輸出模組是否有另外的安全、模式或強制狀態。不要先改輸出接點位置來碰運氣。若平台編輯器有重複線圈或多重賦值檢查器，先讀警告內容，再用交叉參照核實。
若兩個命令需要互斥，先建立命令矩陣，再決定輸出。自動和手動同時成立時，可以拒絕兩者並報衝突，也可以指定一方優先；關鍵是不要讓程式排列順序偷偷決定。把拒絕原因和阻擋條件輸出到診斷資料，維護人員才知道輸出 OFF 是正常策略還是被錯誤覆寫。適用型號與限制：本文適用 PLC 程式除錯的一般方法，包括 Q06UDVCPU、FX、S7 等，但重複線圈是否可編譯、警告等級、任務順序、輸出更新時機和交叉參照功能要依工程軟體版本確認。本文未使用特定 GX Works 專案。
常見問題與附錄
| 問題 | 回答 |
|---|---|
| 後寫入一定會贏嗎？ | 在同一執行模型和同一輸出資料上，常見結果取決於最後寫入；任務與特殊輸出可能有不同規則，必須查平台。 |
| SET 和一般線圈混用可以嗎？ | 可以造成難追的保持與覆寫關係；要先定義解除優先和唯一責任。 |
| 找不到第二個線圈怎麼辦？ | 查別名、MOV、功能塊輸出、IN_OUT、間接位址、子程式和其他任務。 |
| 把所有程式段合併就能修好嗎？ | 合併前先定義命令優先矩陣；沒有規格的合併可能只是換一種覆寫。 |
列出輸出的所有寫入來源和執行順序。
保留 Auto、Manual、Stop/Alarm 等命令來源。
只在一個輸出決策層寫實體輸出。
用七組命令矩陣逐一測試，再將未完成驗證列為待辦。
修正後要做回歸測試：只開 Auto、只開 Manual、兩者同時、Stop 途中成立、Alarm 解除、模式切換和重新啟動。每一組都要記錄命令來源、Block、OutputCommand 及實體輸出。若輸出與命令不一致，先查決策層的條件，再查輸出模組；不要因為刪掉第二個線圈就認定問題結束。對需要保持的輸出，另測試斷電、重新 RUN 和人工復歸的定義。
交叉參照是找線索，不是唯一證據。搜尋結果要和程式執行順序、線上監看以及變數來源一起核對。若同一符號在不同 POU、任務或功能塊中出現，先確認它是讀取還是寫入；若是 IN_OUT 或參照傳遞，還要追到真正修改資料的位置。修正時保留命令來源，可以讓後續新增自動模式、手動模式或警報條件時，不必再把實體輸出散落到各處。
在正式修改前先保存原始版本和交叉參照報告。修正後重新編譯或檢查，逐一確認原本需要輸出的命令仍能成立，阻擋條件仍有優先權，而且沒有把輸出責任轉移到未命名的中間位元。如此才能把『剛好不再閃爍』和真正可維護的設計分開。