先使用適合量時間差的時基
起始Tick為250，現在讀到14，直接相減是負236，但計時器可能只是走過最大值後重新從零開始。本篇用八位元教學計數器，帶你算出正確的20毫秒，並說明何時這個答案已無法代表真實經過時間。學會後，你要能分辨正常回繞、控制器重新啟動，以及因取樣太久而失去整圈資訊。
日曆時間用來回答事件發生在幾點，單調計時來源用來量經過多久。日曆可能被校時或人工修改；若拿它直接做短時間逾時計算，時鐘往回調會改變結果。Tick一詞本身不保證單調，也不保證停機或休眠時會繼續走。選定API前，要確認時間來源、型別、解析度、回繞及重新啟動行為。
| 規格 | 本篇教學設定 | 真實專案要查的內容 |
|---|---|---|
| 數值範圍 | 0 至 255 | 回傳型別與實際有效位元 |
| 每格時間 | 1 毫秒 | 解析度及頻率穩定度 |
| 回繞週期 | 256 毫秒 | 最大值加一乘每格時間 |
| 量測前提 | 同一次連續運行且少於一圈 | 重啟識別及最大可能間隔 |
這是刻意縮小範圍的教學時基，並非指定PLC真的使用八位元毫秒時鐘。CODESYS官方文件說明SysTimeGetMs使用毫秒與UDINT表示，完整三十二位元範圍相當於約49.710天；但實際專案仍需確認目標runtime及函式使用方式，不能把這個API名稱直接當作Q06UDVCPU指令。
把差值放在足夠寬的型別中計算
本篇採用容易手算的分支公式。當目前值不小於起始值，經過格數等於目前減起始；當目前值小於起始值，經過格數等於256減起始，再加目前。先在可以表示256及計算中間值的較寬型別中運算，最後再依需要轉成時間單位。不要用八位元變數存常數256，因為它已超出0至255的範圍。
| 起始 | 目前 | 計算步驟 | 推定經過時間 |
|---|---|---|---|
| 20 | 30 | 30 − 20 | 10 毫秒 |
| 250 | 14 | 256 − 250 + 14 | 20 毫秒 |
| 255 | 0 | 256 − 255 + 0 | 1 毫秒 |
| 100 | 100 | 100 − 100 | 0 毫秒 需符合少於一圈前提 |
先從250數到255共有五格，再由255走到0還有一格，從0走到14再十四格，合計二十格。常見錯誤是用最大值255減起始再加目前，這會少算回到零的那一格。公式使用的是模數256，也就是狀態總數，而不是最大可顯示數值255。
某些平台的無號減法會依固定位元寬度自然回繞，因此可以用模數差計算，但中間型別、編譯器與運算規則必須確定。本文刻意用較寬型別加分支說明數學意義，避免把有號負值直接轉型當成通用解法。真正使用三十二位元模數時，常數4294967296也需要更寬的表示型別。
少於一圈是必要條件
同樣的250到14，真實經過時間也可能是276毫秒，甚至532毫秒。因為每多走256毫秒，讀值又會相同。只看前後兩個Tick，無法知道漏掉幾圈。所以本篇計算成立的條件不是「目前值比起始值小就只繞一次」，而是已由系統設計保證實際間隔小於256毫秒。
| 真實間隔 | 起始250後的讀值 | 公式會得到 | 能否直接信任 |
|---|---|---|---|
| 20 毫秒 | 14 | 20 | 可以 前提已成立 |
| 276 毫秒 | 14 | 20 | 不可以 已漏掉一整圈 |
| 0 毫秒 | 250 | 0 | 可表示同一格內 |
| 256 毫秒 | 250 | 0 | 不可以 已走完整一圈 |
即使目前值大於起始值，也不代表中間沒有回繞。起始20、目前30，可能過了10毫秒，也可能過了266毫秒。用大小比較猜是否超時，只是看到一部分資訊，不能代替最大量測間隔的保證。長時間工作應選擇更寬的時間來源，或用可靠的週期更新機制累積增量並監看更新中斷。
本篇討論的是經過時間的模數差。另一類問題是比較未來截止時間誰先誰後，某些模數排序算法需要把可比較跨度限制在半圈內。不要把兩種條件混寫：本篇已知方向的經過時間要求少於一整圈；若使用截止時間排序方法，必須另外證明其半圈等限制，不能直接照搬。
重啟與暫停會破壞原本的量測關係
假設保存了舊起點250，控制器重啟後Tick從0開始，再讀到14，公式仍會算出20，但那不是同一次運行的時間差。時間資料應與啟動世代或其他可確認的連續運行識別一起使用；偵測到重啟就將量測標示無效並重新建立起點。僅把起點設為保持變數，不會自動得到跨停電的可靠計時。
任務暫停、斷點停住、線上修改及runtime行為也要列入測試範圍。有的時間來源繼續走，有的來源或呼叫更新受執行狀態影響，不能憑API名稱推論。若應用要求停電期間也算入經過時間，應使用具有明確持續性與校時策略的時間系統，並處理時鐘品質，而不是硬把Tick差當成日曆時間。
判定逾時之前，先確認量測仍有效，再比較經過時間與門檻。本篇測試門檻為15毫秒，20毫秒應逾時，10毫秒尚未逾時；規則是大於或等於門檻即成立。若資料無效，要回報計時來源或量測中斷問題，不應把無效結果當作零而讓流程無限等待。
計時器解析度也限制能分辨的最短時間。兩次事件發生在同一毫秒格內，Tick差可能為零，並不代表物理時間完全沒有經過。若需要更高解析度，就選擇符合需求且已核對的時間來源，並注意讀取開銷、排程抖動與事件捕捉位置，不只是把結果單位由毫秒改成微秒。
完成後應看到什麼結果
用離線的八位元測試資料，逐列驗證公式。250到14應得到20，255到0應得到1，20到30應得到10。加入真實間隔276的反例後，你應能指出公式仍輸出20但前提不成立，不能把它列成計時通過。再加入啟動世代不同的案例，結果應無效並等待新起點。
失敗時先查哪裡
差一格先查使用最大值還是模數；出現負值先查有號型別與轉型時機；隔一段時間才突然變小，先查是否超過回繞週期或任務停止更新；每次重啟後錯誤，先查起點是否被保持而時基重置。若數值固定差一千倍，先查Tick每格代表秒、毫秒或微秒。
常見問題
一、看到目前值變小就一定回繞嗎？不一定，也可能重啟或換了時間來源。二、只要用無號整數就安全嗎？還需確認運算規則及最大間隔。三、較寬Tick永遠不會回繞嗎？仍有有限範圍，只是週期更長。四、能用系統日期避免回繞嗎？日期時間仍有校時、時區及持續性問題，應按用途選擇。
適用型號與限制
本篇提供通用模數計時方法，CODESYS作為公開API規格的參考來源。對三菱Q系列、其他PLC或上位機，必須各自核對時間指令、計數寬度及重啟行為。表格是可重複的演算法驗收資料，硬體上仍需確認實際時基與任務行為。