先把現象縮成可以重播的問題
現場常說兩個模組的資料偏了，但這句話仍不足以讓別人重現。最小重現專案的目的，是把控制器型號、工程軟體版本、模組排列、變數宣告與一組輸入值固定下來，讓另一位工程師在不接機台的情況下看到同一個偏移。本文的案例是教學用資料，不代表任何 Q 系列實際位址；真實位址必須從硬體組態與模組手冊核對。
案例有兩個相鄰類比模組。第一模組提供四個通道，第二模組提供兩個通道。本篇刻意在應用層的六筆合成陣列中，把第二模組起始索引誤填為2，正確應為4，因此向前錯了兩個元素。這是教學用的映射錯誤，不是由模組通道數自動推導的真實硬體位址。畫面顯示的不是隨機亂數，而是穩定地把通道三、四的值當成第二模組的通道一、二。這種規律是很有價值的線索，應先保存，不要急著改索引。
| 項目 | 固定內容 | 不應省略的證據 |
|---|---|---|
| 平台 | 控制器與工程軟體版本 | 專案資訊頁與版本字串 |
| 硬體 | 模組順序與通道數 | 組態截圖或匯出文字 |
| 輸入 | 每通道不同的合成值 | 測試表與寫入方式 |
| 結果 | 原始、映射與畫面值 | 同一時間戳的三份紀錄 |
先給六個通道各自不同的值，例如 101、202、303、404、505、606；不要全部寫成零，否則位置錯誤會被掩蓋。記下值是由模擬器、線上監看或測試變數提供。若使用實機，先確認輸出被隔離，本文只討論資料觀察與映射，不把最小專案接到危險致動器。
保留兩模組的最小硬體組態
先複製專案並確認副本能重現，再逐項移除無關流程、HMI畫面或函式庫；每移除一項就重跑同一輸入。若現象消失，恢復該項並記下它可能是必要條件，不要一次刪光後失去重現原因。保留原始模組的通道數與排列，因為把第二模組改成同樣大小可能讓偏移消失。若工程軟體要求裝置描述檔，應記錄檔案版本；不要用另一個相似模組代替而仍宣稱已重現。
保留原專案唯讀備份，在副本中縮小；如需建立空白對照，選相同目標平台並另標為對照案例。
依原案順序加入兩個模組，逐一記下通道數、資料型別與更新方向。
只建立原始資料陣列、映射索引與輸出快照三層變數，不先加入修正公式。
編譯並保存空白基線，確認沒有強制值、隱藏初始化或殘留程式。
用六個互不相同的測試值重播，保存第一次出現偏移的掃描或更新週期。
最小專案需要一個明確的預期表。假設第一模組的四通道應填入 101 到 404，第二模組的兩通道應填入 505 與 606；若程式用錯起點，第二模組可能讀到 303 與 404。此時偏移量是兩個元素，但不能直接把數字二寫死成修正，因為換模組組態後通道數可能改變。
| 通道 | 正確來源索引 | 錯誤來源索引 | 預期與錯誤值 |
|---|---|---|---|
| 模組一 CH1 | 0 | 0 | 預期101 實取101 |
| 模組一 CH4 | 3 | 3 | 預期404 實取404 |
| 模組二 CH1 | 4 | 2 | 預期505 實取303 |
| 模組二 CH2 | 5 | 3 | 預期606 實取404 |
若最小專案在模擬器正常、原專案異常，下一步比較的是任務更新、別名變數和資料複製順序，而不是立刻否定案例。若兩者都異常，才有理由檢查裝置描述檔、通道排列或實際模組資料格式。每次只改一個因素，並保留上一份工程檔。
從硬體組態追到程式索引
排查時畫三欄對照：硬體通道、控制器原始資料位置、應用程式標籤。先由官方模組資料確認每個通道的資料寬度與排列，再查工程軟體的 I/O 映射，最後檢查程式是否另外複製或重新排序。只看到 HMI 數字而沒有原始資料，無法判斷偏移發生在哪一層。
兩模組案例的關鍵是把邊界也測出來。第一模組最後一通道和第二模組第一通道應使用完全不同的值；若只有中間通道出錯，可能是單一通道禁用或型別寬度問題。若所有第二模組值都向前移兩格，才支持起點計算錯誤。將這個判斷寫入驗收，而不是只寫『數值正確』。
讀取硬體組態中的模組順序，列出每個通道的正式名稱。
在原始輸入層觀察 101、202、303、404、505、606 是否仍按預期排列。
在映射層逐項列出來源索引與目的標籤，禁止用未註解的魔術數字。
在應用層檢查縮放、單位與品質旗標，確定偏移不是顯示格式造成。
重播通道邊界值並截取三層資料的同一時刻。
程式修正應以可讀的映射表或明確索引計算表達，並把模組通道數作為組態資料。若平台提供自動 I/O 變數，優先使用工程軟體產生的名稱；若必須使用陣列，至少集中定義每模組起點，並在啟動時檢查陣列長度。這些是可維護性措施，不是跨平台語法保證。
用資料快照分辨偏移與更新時序
有時資料看起來偏移，其實是兩個任務在不同時間更新。把原始輸入、映射結果與畫面快照放在同一個遞增序號下，並在每次任務完成時一起更新。若原始資料序號是 18、映射序號仍是 17，問題是更新時序；若兩者都是 18 但數值仍向前兩格，才回到索引與組態。
| 序號 | 原始模組二 CH1 | 映射 CH1 | 畫面 CH1 | 解讀 |
|---|---|---|---|---|
| 17 | 505 | 303 | 303 | 穩定偏移 |
| 18 | 505 | 303 | 303 | 索引仍錯 |
| 19 | 505 | 505 | 303 | 畫面更新慢 |
| 20 | 606 | 606 | 606 | 恢復或條件切換 |
不要只在線上監看中逐個點選變數，因為點選時間本身可能跨過不同任務更新。快照應包含任務序號、資料品質、模組診斷狀態與目前模式。若平台不能原子地讀取整組資料，明確寫出這個限制，改用平台支援的同步快照，或經核對原子性、記憶體可見性與更新中標記的版本方案；單純讀兩次相同值並不保證一致；不能把一次畫面刷新當成一致快照。
修正後先不接回完整流程，在最小專案中讓兩模組連續產生數組不同值，測試上電、重新啟動、模組暫時無效與組態下載後的第一次更新。每一項都要留下預期和實際。若模型不支援某種故障注入，標示未測，不用模擬成功取代實機證據。
封存專案並讓別人可以打開
重現完成後要保存的是可打開的專案包，不只是幾張截圖。CODESYS 官方說明的 Project Archive 可由 File → Project Archive → Save/Send Archive 開啟，勾選要保存的物件，也可加入 Additional Files 與 Comment。這些選項能把裝置描述檔、測試資料和重現說明一起交付；未自動納入的外部檔案仍要逐項確認。
以不含客戶機密的副本建立歸檔，檔名含平台、版本、日期與案例編號。
把測試值表、硬體組態匯出檔與映射對照加入 Additional Files。
在 Comment 寫明原始現象、重現步驟、已知限制與目前結論。
在另一個工程環境開啟歸檔，重新編譯並執行相同資料序列。
把第二台環境的結果與原始快照比對，記錄任何版本差異。
歸檔不是自動包含所有未保護函式庫的保證。官方文件提醒，某些未編譯函式庫因 know-how protection 不會自動接受；若明確選取可能出現警告。遇到警告要記錄，並依授權與公司規範取得必要依賴，不能把缺檔專案交給下一位卻宣稱可重現。
交付摘要至少包含：原專案看到的偏移、最小組態、輸入序列、錯誤索引、修正候選、尚未證實的假設，以及需要目標硬體確認的項目。這份摘要讓維護者知道哪一部分是觀察，哪一部分是推論，也避免另一個人重新做同樣的猜測。
驗收與常見排查問題
| 驗收項 | 通過條件 | 失敗時先查 |
|---|---|---|
| 組態 | 兩模組順序與通道數一致 | 裝置描述檔與硬體樹 |
| 資料 | 六個測試值按來源排列 | 原始 I/O 與資料寬度 |
| 映射 | 第二模組起點不偏移 | 起點計算與複製段 |
| 時序 | 快照序號一致 | 任務更新與畫面刷新 |
| 交付 | 他人能重開並重播 | 缺少外部檔或版本 |
問：可不可以直接把第二模組索引加二？只有在硬體組態、通道數和資料格式都已確認，而且修正後測試覆蓋變更邊界時才可提出；固定加二不是通用解法。問：畫面數值正確就算修好嗎？不算，還要確認原始層、映射層與品質狀態。問：沒有相同模組怎麼辦？建立合成資料重現邏輯，並明確標成未完成的硬體驗證。問：歸檔能代替版本控制嗎？不能，歸檔是交接與重現包，版本策略仍要依團隊流程。
適用型號與限制：本文採 CODESYS Project Archive、任務快照與一般 I/O 映射概念示範；Q 系列的模組位址、緩衝排列、線上監看及下載行為須依實際 CPU、模組與工程軟體版本核對。未提供可直接編譯的 GX Works 程式或任何廠牌的固定寄存器。