相機可以提供有效影像，而拾取控制器接收到的場景過晚而無法使用。在共享相機系統中，延遲可能會影響一個消費者，而另一個則繼續正常拾取。有用的問題不僅僅是影像是否到達，而是每個控制器是否在其追蹤窗口過期前接收到正確的場景。此故障排除程序將獲取故障與陳舊傳送分開，識別數據老化位置，並驗證恢復，而不更改機器已驗證的安全功能。
從場景年齡開始，而不是相機
場景通常結合檢測到的物件、影像參考、傳送帶參考和路由資訊。其有效取決於傳送帶行駛、可達的拾取區域和控制器文件記載的追蹤規則。
舊場景警告本身並不能證明獲取失敗。控制器可能正確拒絕在更新資訊之後或相關對象通過可用邊界之後到達的資訊。
首先保留警告紀錄並準確識別產生該警告的組件。請參閱所安裝軟體版本的製造商文件。確認該訊息是否涉及場景順序、輸送帶位置、經過時間或內部隊列限制；這些是不同的條件。
若發生影像缺失或傳輸中斷，請使用獨立的 擷取失敗故障排除程序。關於觀測值與機器人運動之間更廣泛的關係，請參閱 視覺伺服迴路設計指南。此處的重點在於控制器交接時數據的時效性與識別度。
建立完整交接過程的事件追蹤
擷取一個涵蓋觸發、影像處理、通訊及控制器接收階段的追蹤紀錄。請使用現有的診斷工具或不會大幅改變生產排程的輕量化儀表。
對於每個場景，在設備提供資訊的情況下記錄以下內容：
| 事件或欄位 | 記錄內容 | 有助於區分的內容 |
|---|---|---|
| 實體觸發 | 事件識別碼與觀測到的觸發時間 | 缺失或重複的擷取請求 |
| 影像參照 | 幀識別碼與時間戳含義 | 曝光時間與主機接收時間之對比 |
| 輸送帶參照 | 編碼器計數與座標慣例 | 位置基準不符 |
| 處理完成 | 場景識別碼與完成時間 | 可變檢測時間 |
| 路由決策 | 目的地與物件分配 | 共享相機分配錯誤 |
| 通訊 | 發送時間、接收時間與順序 | 傳輸延遲或重新排序 |
| 控制器結果 | 已接受、已拒絕或待處理，附原因 | 交付與接受 |
| 佇列狀態 | 待處理深度與最舊待處理時間 | 積壓而非單一延遲 |
成功透過網路發送並不代表控制器已接受。同樣地，空的物件清單不一定表示場景遺失：檢測可能已正確完成，只是未找到合格零件。
明確記錄時間戳記定義。相機時間戳記可能代表曝光開始、曝光結束或其他記錄的事件。主機回呼時間戳記通常描述軟體處理結果的時間，而非影像曝光的時間。 相機元資料驗證指南 說明了為何必須檢查元資料含義，而非逕行推斷。
計算可用時效預算
在主機內部，請使用單一單調時鐘來計算經過的時間間隔。跨裝置時，僅在時鐘之間具有記錄在案且具有測量不確定度的同步關係時，才可相減時間戳記。否則，請關聯場景識別碼並分別測量本地間隔。
基本延遲分析如下：
請勿重複累加重疊的測量值。例如，從影像曝光到處理完成的間隔可能已包含相機讀出與傳輸時間。
對於定速輸送帶，可用場景年齡預算的初步估算為：
假設物件在影像參考點時，剩餘可用輸送帶行程為 300 mm。輸送帶速度為 800 mm/s。假設指令與動作餘量為 80 ms，另有 45 ms 的預留量。
算式為：
- 可用行程時間：300 mm / 800 mm/s = 0.375 s = 375 ms。
- 最大場景年齡：375 ms - 80 ms - 45 ms = 250 ms。
- 120 ms 延遲期間的輸送帶行程：800 mm/s × 0.120 s = 96 mm。
若測得的貢獻值為：擷取與處理 25 ms、傳輸 10 ms、下游等待 120 ms 以及接收處理 5 ms，則總年齡為 160 ms。相對於示例預算，剩餘 90 ms。
此為診斷估計值，不能取代控制器的追蹤模型。加速度、拾取軌跡、物件幾何形狀和座標轉換可能會改變可用視窗。請評估最舊的已接受場景和延遲尾端，而非僅評估平均值。
按實際順序測試可能的故障原因。
當影像持續到達且僅有部分接收端停止擷取時，請從下游積壓開始檢查。若追蹤結果指向其他方向，請更改順序；此表格為診斷順序，而非通用故障排名。
| 疑似原因 | 測試 | 修正方向 |
|---|---|---|
| 接收端無法跟上速度 | 比較警告前的最舊待處理時間與佇列深度 | 消除測得的瓶頸，或透過支援的設定降低准入工作量 |
| 緩慢的接收端阻塞共享傳輸 | 比較每個目的地對同一場景的接收時間 | 使用文件中記載的獨立傳輸或排程安排 |
| 場景完成順序變更 | 比較觸發順序與處理完成及發送順序 | 保留必要的順序，或使用文件中記載的順序處理方式 |
| 路由或所有權錯誤 | 追蹤每個物件的分配與目的地 | 修正工作區域映射與分配規則 |
| 通訊暫停 | 將發送至接收的間隔與鏈路及應用程式診斷結果進行比較 | 修正測得的連線或排程故障 |
| 時鐘參考不一致 | 比較本地經過時間與跨裝置的時間計算 | 修正同步，或停止將不相關的時鐘視為可比較 |
| 編碼器參考值不同 | 在同一事件比較計數、方向和重設歷史 | 還原文件化的傳送帶參考配置 |
| 擷取不規則 | 比較實體觸發、畫面識別符和影像接收 | 分別診斷觸發驗收和影像傳輸 |
僅在突發期間增長的佇列即使在平均吞吐量看似充足時仍可能失敗。例如，處理 12 場景/秒的消費者無法維持 15 場景/秒的輸入串流。當這些速率持續時，待處理計數大約增加 3 場景/秒。
減少影像處理時間無法解決完全處理後存在的佇列。在變更階段前先測量該階段。
將共享相機傳輸與物件所有權分離
共享影像不代表共享物件指派。為原始影像、衍生場景和目標特定物件集維護獨立識別碼。這讓您可以區分遺漏的傳送與合法的不為特定控制器指派物件的決定。
對於每個消費者，請檢查：
- 它是否接收所有場景，或僅接收包含已指派物件的場景。
- 空結果是否會推進其場景序列。
- 確認代表已接收、已接受或已完成。
- 不可用的目的地是否會阻止其他目的地。
- 重試是否保留原始場景識別碼。
- 重新指派是否可能導致重複所有權或被遺棄的預約。
想像有兩位消費者接收來自同一影像的結果。一位立即收到；另一位在處理先前工作時暫停。如果傳遞序列化在該慢速消費者之後，延遲最終可能擴散。如果傳遞是獨立的，症狀可能保持隔離。
追蹤單一場景通過兩種路徑。不要從預覽視窗或另一個繼續拾取的機器人推斷系統整體健康狀況。該 相機預覽疊加指南 提供有用的方式來顯示畫面身份和追蹤狀態，但疊加層仍為診斷顯示，而非控制器接受的證明。
檢查編碼器對齊、排序和觸發
場景可能及時到達，但其傳送參考錯誤時可能顯得過時。確認編碼器方向、單位、計數縮放比例、參考捕獲時序以及文件中記錄的計數器溢出處理方式。
舉例來說，設定的比例為 0.10 mm/計數，使 960 個計數的差異相當於 96 mm。如果另一個組件使用不同的比例或原點，它對同一場景的解釋可能立即產生分歧。
除非製造商的程序明確協調該操作與所有消費者，否則不要在主動追蹤期間重置編碼器或更改其參考。即使影像時間戳保持正確，重置也可能使排隊的位置失效。
接下來，比較採集順序與處理完成順序。並行工作程式可能先完成較新的影像。已經前進到較新場景的控制器可能正確拒絕稍後傳送的較舊結果。檢查文件記載的介面如何處理序列間隙、重試和重複。
最後，驗證實體觸發路徑。將觸發事件與擷取的畫面進行比對，而非假設每個脈衝都產生了影像。使用 外部脈衝觸發故障排除指南 當脈衝到達速度快於擷取鏈可接受的速度時。
透過已記錄且受控的順序進行復原。
使用製造商的復原程序和現場核准的機器安全流程。清除佇列、追蹤重設和應用程式重新啟動可能會影響物件所有權和待處理動作。
- 保存證據。 在重新啟動任何裝置前，匯出日誌、佇列狀態、軟體版本和相關配置。
- 建立安全的機器狀態。 進行任何檢查、接線或機械工作時，請遵循核准的停止和隔離程序。
- 解決待處理狀態。 確認佇列中的場景、已保留物件和已發出的拾取指令。僅透過記錄的控制項來清除或核對這些項目。
- 採取一項受支援的修正措施。 記錄設定、軟體變更或連線修復及其預期效果。
- 重新建立參考基準。 在允許新物件進入前，確認記錄的輸送帶參考點和工作區域映射。
- 在安全防護裝置啟動的情況下進行驗證。 使用核准的測試模式和生產重新啟動程序。請勿禁用互鎖或保護功能。
- 重現原始操作條件。 檢查先前產生警告的工作負載與突發模式。
在整個測試過程中記錄合格場景時間、不合格場景原因、最舊待處理時間以及隊列深度。當隊列保持有界且每個合格對象具有一致的結果時，恢復能力是更強有力的證據。
若涉及軟體變更，請使用 軟體升級驗證檢查清單 以保留回滾路徑並重複相關的驗收測試。
僅在定位延遲後選擇硬體
瀏覽 面陣相機 通過 相機搜尋器 當追蹤紀錄識別出既有設備無法滿足的擷取需求時。請將介面、快門與整合需求與應用層級的場景傳遞分開比較。
該 LS-CMR-0395 及 MV-CU020-90GC 是 GigE 個具有全域快門的面陣相機選項。其型錄清單並不代表與特定揀貨應用或其時間戳記、觸發及追蹤介面的相容性。
- 感光元件格式
- 1/2.7"
- 介面
- GigE
- 感光元件格式
- 1/1.7"
- 介面
- GigE
在考慮之前 視覺控制器，請定義所需的相機連接、處理工作負載以及支援的場景介面。單憑埠數無法確定隊列行為、應用相容性或最差情況下的傳遞時間。
若追蹤紀錄識別出不可靠的零件到位事件，請比較 光電感測器 在...中 觸發感測器選型工具. 此 MV-PE5502 是一款具有 NPN 輸出的擴散反射式感測器。在選擇之前，請檢查電氣相容性、目標物行為以及記錄的輸入連接；它不能替代編碼器基準。
- 輸出
- NPN
- 光源
- 紅色 LED
- 感測範圍
- 100 mm - 1 m
- 類型
- 漫反射
不要僅僅因為下游軟體拒絕舊場景而更換相機。更快的擷取速度可能會因增加到達率而使已過載的接收端情況惡化。
最終驗證檢查表
在關閉錯誤調查之前，請確認以下幾點：
- 識別： 每個追蹤的觸發、畫面、場景和目的地都可以在不依賴顯示順序的情況下相互關聯。
- 時間基準： 每個時間戳記皆具有已知含義，且跨設備比較已考慮時鐘不確定性。
- 輸送帶參考： 比例、方向、原點及回繞行為在文件說明的介面中保持一致。
- 交期： 接收與接受是可區分的，包括空場景與重試。
- 佇列： 在代表性突發流量期間，最舊待處理項的等待時間與深度保持在界限內。
- 所有權： 在配置的路由規則下，每個符合條件的物件皆具有一致的分配與結果。
- 復原： 停止、重設與重新啟動行為遵循文件說明的程序，且不降低運動安全性。
- 驗收限度： 測得的延遲尾端符合應用容許範圍，而不僅僅是其平均值。
保留機器配置中的追蹤和驗收限制。當工作負載、路由或軟體稍後變更時，它們提供基準線。
為協助審查交接，請透過傳送觸發率、傳送帶速度、時間戳定義、佇列測量以及代表性事件追蹤 應用支援。如果證據識別出硬體需求，請從 相機配置器 或 觸發設定步驟.
問題
Does stale scene data mean the camera failed?
Not necessarily. A valid image can produce a scene that waits too long in processing, communication or a controller queue. Correlate frame identifiers with scene delivery and acceptance records. Investigate acquisition separately if physical triggers lack corresponding images or the image stream shows unexplained gaps.
Why can one controller stop picking while another continues?
Different consumers can have different queue depths, workloads, assignments and communication delays. Compare the same source scene at each destination, including whether it was expected to receive objects. This reveals whether the delay is shared upstream or isolated to a particular delivery and acceptance path.
Can camera and controller timestamps be compared directly?
Use timestamps for direct age calculations only when their event meanings and clock relationship are documented. Unsynchronized device clocks can create misleading differences. Without a common time basis, correlate scene identifiers and measure elapsed intervals locally at each stage instead of subtracting unrelated timestamps.
Should the stale-scene timeout be increased?
A larger limit does not remove the underlying delay and may admit information outside the useful tracking window. First identify where the scene waits and calculate the available travel budget. Change limits only through documented application settings, with the required engineering validation and safety review.
What evidence shows that the timing fault is resolved?
Retain a correlated event trace, queue-depth trends, oldest pending age, acceptance outcomes and the configuration used during testing. Repeat representative workload bursts with safeguards active. A restart that briefly restores picking is insufficient evidence if pending data begins accumulating again under normal demand.