PLC任務超時如何檢查重入與工作積壓

2026-09-17 · 站長

用工作身份與時間線區分跨掃描等待、請求積壓及共同狀態覆寫，再依Q系列排程限制設計驗證。

先把超時的種類分清楚

任務超時不一定是程式重入。先確認你看到的是CPU看門狗、固定週期執行延遲，還是通訊工作沒有在期限內完成。三者需要的證據不同；只因同一功能被多次呼叫，就把超時歸因重入，容易修錯地方。本文教你先分類，再用時間線追工作身份與進出順序。

以Q06UDVCPU為核對背景，QnUCPU手冊第3.16節說明看門狗與END處理的關係。中斷或固定掃描程式增加處理時間可能影響這個條件，但業務工作等待外部回覆超時不等於CPU看門狗超時。先保存實際診斷原文、模式、程式版本與發生時間。

本文把重入定義為前一次執行尚未離開，同一處理邏輯又由另一執行路徑進入，可能共同使用尚未完成的狀態。主掃描每次呼叫一個需要跨掃描完成的狀態機，則可能只是正常輪詢。要知道它是新工作、續做舊工作，還是真的疊入執行，必須追身份與狀態。

先列出功能的所有入口：主掃描、固定週期、中斷、其他程式呼叫與外部請求。外部請求到達不一定立刻執行PLC函式，它可能只是設定旗標或排入資料。將請求、接受、開始、結束四個時刻分開，避免看到兩個請求就宣告同時執行。

這是一份診斷與測試設計教學，不提供可以直接貼入現場的鎖定或中斷控制程式。實際任務與中斷行為依CPU、程式類型及參數核對，未取得對應證據前，不任意放大看門狗期限或重設看門狗來掩蓋超時。

先查目前功能由哪種程式執行。QnUCPU手冊第2章對一般中斷說明了等待與再執行情況，同一因素再發生時的保存規則也依因素類型不同。這表示新觸發可能排隊或合併，而非立刻重入；高速度中斷等另有章節，不能把一般說明套到全部功能。

保存週期設定、優先關係、啟用條件和呼叫者，再對照原專案交叉參照。若同一FB實例被多個路徑使用，特別查其內部工作資料是否共享；同一FB型別但不同實例，與同一實例被重複存取並不是同一種風險。

紀錄欄位至少包含工作編號、實例、入口、請求時刻、接受時刻、開始與結束時刻、忙碌狀態及結果。若現有記錄缺少這些欄位，先以只讀資料能支持的範圍判斷；新增追蹤會改變負載，須在受控副本設計及驗證，不假裝原平台已有通用追蹤欄。

兩條BEGIN沒有看見END，可能是重入，也可能是記錄遺失、同名不同實例、時鐘不同步或重啟。比對執行上下文與來源序號，再查是否真的使用同一份狀態。沒有證明共同狀態和時間重疊，就先列候選，不用一個Busy旗標代替完整診斷。

若只取得每秒HMI資料，也無法精確判斷毫秒級呼叫順序。記錄其採樣間隔和來源更新時刻，必要時規劃平台支持的取樣或離線追蹤。監看沒看到重入，不代表每次執行都沒有重疊。

案例A是跨掃描通訊工作。請求J17在0毫秒被接受，外部回覆於120毫秒取得；PLC在10、20、30毫秒再次呼叫同一狀態機，都是檢查J17是否完成。只要沒有建立第二個工作或破壞狀態，這是續做舊工作，不是因呼叫三次就算三次重入。

案例B每100毫秒到一個新請求，單一服務者每件需120毫秒完成，且只能串行處理。第一件等待零毫秒，第二件等二十毫秒，第三件等四十毫秒，積壓逐漸增加。這是服務能力不足的排隊問題；若等待是跨掃描非阻塞狀態，不可把120毫秒外部等待直接當成CPU忙運算120毫秒。

案例C假設同一實例在主程式進入時保存工作J17，尚未返回時另一條有證據的執行路徑也進入並寫成J18，之後前一條路徑以J18狀態繼續。這才是需要查共同狀態被覆寫的情境。是否可能如此執行，仍須由實際平台排程與追蹤支持，不能單憑概念案例斷言QCPU一定會如此。

另看CPU負載案例：一項每10毫秒觸發的處理，若每次本身就耗24毫秒，同時還有其他控制工作，就無法長期按原節奏完成。先確認量測是CPU執行耗時而非外部等待，再查資料量、迴圈上限與觸發率；單純加Busy可能只是開始丟工作。

完成這三種對照後，報告應能分出正常跨掃描等待、請求積壓和共同狀態覆寫。它們可以同時存在，但修正不能共用一句避免重入。先解釋哪份證據支持哪個原因，再安排針對性的驗證。

對積壓問題，先明確決定新請求忙碌時要拒絕、排隊還是依規格合併。這些策略的資料效果不同：不能把三次獨立投料請求合成一次，也不能無限排隊。需求要列容量、逾時、拒絕回覆與重試識別，再由控制設計選實作。

對共同狀態，優先考慮讓單一受控流程擁有工作狀態，其他來源只提交請求。這是架構方向，不是加一個布林Busy就保證互斥。多個執行上下文都先讀Busy再寫Busy，可能仍有競態；實際同步方式必須是平台明確支持且已驗證的機制。

對長迴圈或大量資料處理，檢查是否能在不破壞一致性的前提下分批完成。跨掃描分批後，輸入快照、進度、取消及異常恢復都需要重新定義。不可只把迴圈上限改小，卻讓外部設備以為全部資料已完成。

驗收先列正常請求、忙碌中第二請求、佇列滿、外部回覆遲到、取消與重啟六類。每類記工作身份是否唯一、是否重複接受、狀態是否被別的工作覆寫，以及CPU最壞掃描是否符合設計。對應結果和實機結果分欄，沒有執行就留待驗。

失敗時回到最早不一致的身份或狀態變化，而非只看最後超時碼。若新增追蹤後才出現更長掃描，將追蹤負載列為變因；若延長期限只是讓故障晚一點出現，仍需找出產生積壓或錯誤狀態的原因。

交付包含超時種類、執行路徑、工作時間線、平台限制及候選原因。對尚未能證明的重入寫待確認，不以通用多工經驗代替Q系列手冊。本文案例和負載算術用來設計調查。

問：Busy一直為1就代表重入嗎？答：可能只是同一工作尚未完成，先查工作身份、入口與開始結束關係。

問：每100毫秒來一件、處理120毫秒會怎樣？答：單一串行服務者會逐步積壓，需先確認需求及服務能力，不能只看CPU模式。

問：把看門狗時間加大就能結案嗎？答：不能以此代替根因分析，先辨識超時類型和設備反應期限。

問：加一個Busy旗標就一定不重入嗎？答：多執行上下文可能仍有競態，需核對單一狀態擁有者或平台支持的同步方式。