線上修改成功後 還要確認狀態怎麼遷移
程式接受線上修改，不代表所有執行中資料都原封不動。本篇以CODESYS功能塊為教學範圍，區分只改程式內容、改變實例宣告與完整下載，再建立可以逐欄觀察的初始化試驗。重點是讓你能判定資料為何保留或重建，而不是背一句「線上修改不會清值」。
先把工程環境記錄完整：IDE版本、實際編譯器版本、裝置描述版本、runtime版本、目標控制器與使用的函式庫。只寫CODESYS 3.5不足以重現行為。同一IDE也可能使用不同編譯器設定；測試結果應附在這一組環境上，不能直接推廣到所有CODESYS設備，更不能視為三菱Q系列的線上修改保證。
| 操作 | 你要關注的變化 | 不能互相代替的原因 |
|---|---|---|
| 只改程式內容 | 可能只替換程式碼 | 未必重建資料區 |
| 新增FB欄位 | 實例布局與資料複製 | 可能涉及初始化生命週期 |
| 完整下載 | 應用替換與資料重建 | 不是同一條線上變更路徑 |
| 停止再RUN | 執行狀態切換 | 不等同Reset或重新下載 |
測試在不接實體輸出的副本中進行。先保留可還原的基線與數值快照，再一次只改一項內容。若同時改變欄位、保持屬性及初值，即使某個值變成零，你也無法分辨是哪一項變更造成，這樣的試驗不能形成可靠結論。
先理解功能塊的複製與初始化順序
CODESYS官方方法文件說明，功能塊宣告改變而需要搬移實例時，涉及舊實例的FB_Exit、新實例的FB_Init、舊值複製到新實例，以及存在時執行的FB_Reinit。關鍵在於FB_Init在複製之前，FB_Reinit在複製之後。不能以為在FB_Init寫入的新值，必然就是遷移後最後看見的值。
| 教學觀察點 | 動作 | 可能影響 |
|---|---|---|
| 舊實例離開前 | FB_Exit | 釋放或交接外部資源 |
| 新實例複製前 | FB_Init | 建立新資料區初始狀態 |
| 搬移既有資料 | 複製舊值 | 部分初始結果可能被舊值取代 |
| 複製完成後 | FB_Reinit若有實作 | 應用自訂程式可能再次改值 |
若只修改實作內容而沒有宣告變更，不能假定上述生命週期都會執行。程式是否採快速線上變更、哪些實例列入複製，以及編譯器產生什麼初始化處理，應查看工具提示與指定版本文件。不要為了測試而在生命週期方法中控制真實輸出；可在隔離專案記錄方法呼叫及簡單診斷計數。
指標與參照需要特別核對。實例地址改變時，先前保存的地址可能不再指向預期資料；不能只因指標數值非零就認定有效。外部檔案、Socket或其他資源也有生命週期，是否可延續要依對應函式庫契約。單看一個計數器保留成功，不足以證明整個功能塊可無縫延續。
用一個欄位變更建立觀察表
建立一個只含計數與設定資料的測試FB，讓OldCounter在測試前固定為37，避免它繼續每掃描加一而難以比對。基線沒有NewLimit，修改版新增初值10的NewLimit。先確認變更清單只包含這項宣告，再記下哪些實例將被搬移。這份案例的既有計數保留是應用需求，實際是否達成仍要測。
| 試驗欄位 | 變更前 | 要觀察的結果 | 本文執行狀態 |
|---|---|---|---|
| OldCounter | 37 | 是否仍為37及變更原因 | 填入觀察結果 |
| NewLimit | 不存在 | 是否按新宣告初始化為10 | 填入觀察結果 |
| 診斷呼叫紀錄 | 基線快照 | 哪些生命週期方法被呼叫 | 填入觀察結果 |
| 實例地址 | 保存觀察值 | 是否搬移及參照是否有效 | 填入觀察結果 |
第二個試驗要從基線重新開始，只把某個普通變數的宣告初值由5改9，執行中值另設為37。觀察值若是37、9或其他數字，分別追查舊值複製、初始化與應用程式賦值。不要在套用後立刻手動寫9，否則你改掉了要觀察的證據；也不要把初值與每掃描賦值寫在同一位置。
第三個試驗只修改一行純計算內容，不改宣告。比較此次提示、資料地址及方法紀錄與前兩次是否不同。每個試驗都保存變更前後的工程檔、編譯訊息及完整觀察表。未觀察到的欄位填未測，不能因為整體仍在RUN就填保留成功。
保持資料與特殊屬性不能只看名稱
Persistent資料也不是任意改版都能保留。CODESYS官方文件指出，保持清單中名稱或型別的變更會被視為新宣告；複雜型別內部的小改動也可能影響整個變數的重新初始化。因此把大型結構全部放入保持清單，再頻繁增加欄位，可能增加遷移風險。先備份並設計版本化轉換，別把PERSISTENT當成永遠保留的承諾。
某些屬性會明確改變線上變更時的複製或初始化行為，例如no_copy與init_on_onlchange。讀到屬性名稱還不夠，必須連同快速線上變更的例外閱讀；官方init_on_onlchange文件說明，快速路徑可能不產生初始化程式碼。本文不要求你加入這些屬性，而是教你檢查既有專案是否已使用它們。
不要把停止再RUN、暖重置、冷重置與原始重置合成一個「重啟」測試。它們是不同操作，對普通、Retain與Persistent資料有不同契約。測試紀錄應寫出工程工具的實際命令名稱與選項，尤其要保留是否完整下載、是否改了保持清單，以及是否執行自訂初始化程式。
若線上修改後流程狀態仍為執行中，而資源或參照已重新建立，就可能出現狀態與資料不一致。針對這種情況，應用程式需要明定恢復政策，例如拒絕新工作直到初始化完成，或讓既有工作進入可診斷的中止狀態。這個政策由流程需求決定，不能讓碰巧保留的Step值替你決定下一個動作。
完成後應看到什麼結果
完成教學試驗後，你應有一張按操作分類的前後差異表，能把每個欄位標為保留、按宣告初始化、被自訂方法修改或尚未確認。新增NewLimit的案例，須同時說明OldCounter與NewLimit，不能只驗證新欄位存在。實例搬移時還要確認參照及外部資源是否仍有效，才能評估繼續執行的條件。
失敗時先查哪裡
先查本次到底是線上變更還是完整下載，再查編譯器與變更清單。既有值突然改變時，搜尋FB_Init、FB_Reinit、保持屬性與其他賦值位置；新欄位看似沒有初值時，查宣告與工具提示及監看更新。若只有某一個實例出錯，核對實例配置與參照，不要把單一案例推論成平台全部清值。
常見問題與適用限制
一、工具允許線上修改就代表流程可繼續嗎？不代表，仍需確認資料與資源的一致性。二、只改初值一定立即改執行值嗎？不能跨操作與版本一概而論，應做獨立試驗。三、Persistent能保住任意改版資料嗎？不能，型別與清單變更需要遷移設計。四、換版本後應核對什麼？請重新核對初始化、保持資料與實例地址，並記錄執行結果。