一 先分區再談不足
PLC記憶體不足不能用PC工作管理員的RAM數字直接判斷。先把問題分成程式/參數檔、裝置與保持資料、檔案寄存器或資料記錄、標籤編譯配置、線上變更保留區。每區有自己的容量口徑和生命週期；某區有餘量不代表另一區能接收新增內容。
本文採Q06UDVCPU與GX Works2作為工程背景，但所有實際容量以目標CPU、專案設定和編譯配置核對。QnUCPU手冊2.1.3把寫入記憶體的檔案以file size unit計算，這與「陣列有效payload」不同，不能把兩者相加後當成保證值。
盤點輸入包括CPU型號、專案版本、是否使用label、程式和參數檔、陣列宣告、FB實例數、裝置範圍、檔案寄存器設定、記錄週期及online change reserve。輸出是每區的來源、公式、估算和待編譯核對事項。
容量盤點的第一張工作表用「來源」欄固定證據位置：程式與參數引用專案檔及版本提交，裝置與保持引用參數和資料範圍，檔案寄存器引用檔案設定與筆數，label引用編譯輸出。使用量沒有來源就標Unknown，不能把工程師口頭估計填入。
不適用情況是只有警告截圖、沒有專案或型號，或把未知的SM/SD當通用容量指標。這些只能標待核對，不應補造數字。
二 用陣列數值建立可核對基準
以INT16陣列先做可重現的payload計算。[0..99]含100個元素，每個INT16以2 bytes計，有效payload=200 bytes；[1..100]同樣是100個元素，也是200 bytes；[0..100]則是101個元素，payload=202 bytes。索引起點改變不會改變元素數，終點多一格才會改變。 這裡用INT16、REAL32及方括號作型別寬度與索引說明，並非可直接貼入GX Works2的宣告語法。
三十二位元浮點數每元素有效資料為四bytes，一百個元素為400 bytes。這只是資料本體，不能當成編譯後整個專案配置；FB其他成員、工作資料與配置方式另算。對齊或額外空間是否存在及大小，以實際工具報告與手冊確認，不替編譯器假設固定成本。
建立陣列表時同時列下界、上界、元素數、型別、每元素bytes、payload和用途。陣列改為[0..100]後，除了202 bytes，循環上限、初始化筆數、邊界條件和外部資料契約都要同步檢查。
不要用刪除陣列元素來掩蓋容量警告。若需求允許把記錄週期由1s改為5s，資料筆數在相同期間約降為五分之一；把週期縮短反而增加資料量，必須先算筆數和檔案成長。
邊界計算要把下界也納入公式：元素數=上界−下界+1。INT16[5..104]仍是100個元素，payload仍200 bytes；若外部協定從0開始而程式從5開始，這是索引契約問題，不是容量節省。初始化迴圈若仍跑0..100，也會造成邊界異常，需在程式審查表中列出。
| 宣告 | 元素數 | 每元素 | 有效payload |
|---|---|---|---|
| INT16[0..99] | 100 | 2 bytes | 200 bytes |
| INT16[1..100] | 100 | 2 bytes | 200 bytes |
| INT16[0..100] | 101 | 2 bytes | 202 bytes |
| REAL32[0..99] | 100 | 4 bytes | 400 bytes |
三 FB alias與程式契約
20個FB實例各自擁有一個100元素REAL32工作陣列時，有效payload合計為20×100×4=8000 bytes。這個8000 bytes只表示20份工作資料的算術合計，不保證GX Works2的實際配置；FB實例可能還有其他成員、對齊和編譯資料，必須在編譯配置中核對。
若20個FB共用一個一百元素REAL32陣列，且設計明確配置到D100..299共二百字，底層有效資料只算一次400 bytes；若每個FB各有獨立陣列，才是8000 bytes。盤點時列出owner、底層裝置範圍和是否alias，避免同一資料被重複計算。
另一個十六位元例子：D100至D199含一百字，共200 bytes。若兩個標籤RawBuffer和RecipeView經配置證明指向同一範圍，底層只算200 bytes一次；一百個REAL32則需要二百字，不能塞成同樣的一百字。名稱相似不代表共享，必須查配置。
陣列縮小後，循環上限、初始化清零、外部通訊筆數和配方格式都要修改並測試。例如外部契約仍送101筆，而程式只接受100筆，應拒收並記錄，不讓越界寫入成為「省記憶體」方法。
FB盤點還要分「每實例資料」與「共享資料」。20個FB各自持有REAL32[0..99]時是20份400 bytes；若FB依專案設計共用同一D100..299資料，則二百字底層資料仍只有400 bytes，別因20個名稱就重複相加。若編譯器為每個實例配置額外狀態，必須等待編譯配置，不用payload猜測。
| 配置 | 數量 | 有效payload | 注意 |
|---|---|---|---|
| 20獨立FB×100REAL32 | 20 | 8000 bytes | 非實際配置保證 |
| RawBuffer與RecipeView alias | 同一底層 | 只算一次 | 核對D範圍 |
| 外部101筆/內部100筆 | 101/100 | 契約不符 | 拒收或修約 |
四 檔案大小與QnUCPU容量口徑
QnUCPU手冊2.1.3的file size unit表把CPU和記憶體區域分開；Q06UDVCPU列在對應型號，程式記憶體、Standard RAM與其他區域不是同一個單位。這章的計算範例是Q26UDHCPU，不可把範例總數1141 steps當成Q06UDVCPU容量或結果。
手冊範例先把參數檔464 bytes換成116 steps，再把程式525 steps與online change reserve 500 steps合計，得到該Q26UDHCPU例的總容量。教學重點是分區與換算方法，不是把Q26UDH數字搬到Q06UDV。
GX Works2的label專案要先編譯，程式才能取得實際配置；陣列元素數改變還可能要求修改使用該陣列的程式。盤點報告把有效payload、編譯配置、檔案大小單位和online reserve分欄，避免混成一個百分比。
另作檔案配置的純算術練習：假設某區以512 bytes為一個配置單位，檔案內容513 bytes就需兩單位、共1024 bytes；內容500 bytes需一單位。這是對齊單位的示例，使用前須先從本機與該記憶體區的表格確認單位，不能把每區都設成512。
資料記錄檔或檔案寄存器若以1s改5s，先按記錄列數、欄數、每列大小和保留天數估算，再以工程工具和目標CPU設定核對。週期變短時資料量上升，不能寫成一定能釋放空間。
固定每秒一筆時，一天86400筆；每五秒一筆為17280筆，相差69120筆。若假設每筆有效資料二十bytes，兩者分別為1728000和345600 bytes，尚未含檔案表頭、索引或時間欄。這只影響該記錄內容，不能用來抵銷程式區不足。
五 控制站14盤點與驗收
建議盤點順序是保存V30、建立陣列表、核對INT與REAL有效資料、核對FB實例及共用範圍，再於副本用適用工具編譯V31並比較配置。這是待執行步驟。
驗收逐項檢查：INT16[0..99]=100元素/200 bytes；[1..100]仍100/200；[0..100]=101/202；100 REAL32=400；20獨立FB=8000有效payload但標待編譯；alias只算D100..199一次；循環與外部契約邊界一致；記錄週期方向正確。
問：有效資料等於實際配置嗎？答：不等於，要與編譯配置、其他成員及檔案單位分開核對。
問：縮短記錄週期能省空間嗎？答：同期間通常增加筆數。一秒改五秒才降低固定週期筆數，也要確認需求允許。
問：同一底層的兩個標籤算兩次嗎？答：底層只算一次，但先證明它們確實共享範圍，而不是名稱相似。
問：Q26UDH示例可當Q06UDV容量嗎？答：不可以。只學計算順序，型號、記憶體區域與配置單位均須另外核對。
最後保存專案版本、陣列表、裝置範圍、記錄設定、編譯輸出與待核對事項。若實機結果與離線估算不同，保留兩者並以型號手冊與工程工具結果為準，不刪除原始盤點。
控制站14若編譯輸出顯示不足，先保存V31和V30差異，再在離線副本調整一個因素：減少保留天數、改記錄週期或重構共享資料。每次變更都重新計算筆數和契約，最後由型號手冊與工程工具核對。
若盤點發現記錄週期由1秒改為5秒，先按相同保留期間比較列數，再核對每列欄數和檔案單位；只有在需求允許較慢採樣時才可採用。反向把5秒縮成1秒會增加五倍左右的列數，可能使檔案區更快達到上限。
驗收報告最後保留原始專案、陣列表、計算表、編譯輸出和版本差異，讓下一次容量檢查能從同一基準開始。
若來源不足，結論標待核對，不以推估數字結案。
參考：GX Works2 Version 1 Operating Manual Common, PLC diagnostics and label programming sections