鋼材線上輪廓量測系統：分散式雷射量測，產線上即時拼出斷面、自動判合格

為一家工業量測設備商開發、已在鋼材產線日常使用。為了保密，這頁不提公司、客戶、現場、型號與廠牌，數值也都一般化，只留技術與方法。量測系統本身是實機驗證；頁尾可以試用的狀態畫面 Demo 是只用模擬驗證的重寫版，機台、數值、名稱全是虛構的。

鋼材在產線上連續移動，要在不停線、不接觸的情況下量出每一支的斷面尺寸——圓鋼、方鋼、H 型鋼、角鋼、槽鋼，還有客戶自訂的形狀都要能量。更難的是：現場不是只有工程師，操作員也要一眼看懂「機台現在能不能量、不能量的話要先做什麼」。

這套系統的做法是：多組雷射感測器圍著產線各看一段弧，程式即時把它們拼成一個完整斷面，當場量尺寸、判合格，結果同時送到操作畫面、資料庫與產線 PLC。

試試看

• DG-1 示範量測機（狀態畫面）：一個純網頁的狀態畫面示範，把「複雜設備做成任何人都看得懂」這件事濃縮成一頁——一句結論（可以量測／還不能量測：原因）、門型機台圖、感測頭與溫區即時上色、下方流程鏈顯示資料流到哪斷掉，還能「注入故障」（服務當掉、感測器斷線、溫度飄移、電源過載）看畫面怎麼反應。機台、數值、名稱全是虛構的，只用模擬驗證，資料不會送到任何地方。

挑戰

• 每組感測器只看得到斷面的一段弧，要即時拼成一個封閉斷面。
• 每秒約百次的資料量，要在多台電腦之間穩定傳送，不能掉資料。
• 不同斷面要不同的量測邏輯；自訂斷面還要能直接從圖面轉成量測計畫。
• 溫度、校正、多台電腦協同，任何一環出問題都要找得到、說得清。

我做了什麼

角色是團隊裡的軟體開發。

• 分散式架構：十多個模組——影像擷取、斷面拼接、各種斷面評估、狀態監控、顯示與資料庫、流程控制、圖面編輯、產線 PLC 閘道——模組之間用 MQTT 溝通，壞一個不會拖垮全部，也方便一台台電腦分工。
• 效能：持續每秒約百次掃描，斷面完整覆蓋、拼接不掉資料（實機驗證）。
• 圖面到量測計畫：從 DXF 圖面讀出尺寸與公差標註，自動找出封閉輪廓，直接產生量測計畫——自訂斷面不用再另外寫程式。
• 驗收與交付：驗收清單、現場操作手冊、交接文件；另外建了一套準確度紀錄法（條件 → 指令 → 原始輸出 → 判讀），靠它把毫米級的誤差一路追到「相機安裝沒共面」這個實體原因。
• 訓練與狀態平台：在模擬機台上練開機、校正、排障；狀態頁用「一句結論＋機台圖＋從這裡開始」讓非工程師也看得懂；多語系；帳號到期與浮水印防外流。上面的 Demo 就是這個平台的去識別化重寫版。

成果

• 多組感測器、多台主機的系統，已在產線日常使用。
• 持續每秒約百次掃描，斷面完整覆蓋，拼接不掉資料。
• 自訂斷面可以直接從圖面建立量測計畫，不用另寫程式。

架構

部分	用什麼
感測與拼接	多組雷射感測器，各看一段弧；程式即時拼成封閉斷面
模組溝通	十多個 C++／Python 服務，之間走 MQTT
斷面評估	依斷面型別套不同量測邏輯；自訂形狀從 DXF 建計畫
對外介面	操作畫面、PostgreSQL 資料庫、產線 PLC（OPC UA 閘道）
圖面解析	DXF 讀尺寸與公差標註、找封閉輪廓
訓練與狀態平台	模擬機台＋狀態頁（three.js／原生 JavaScript），多語系、帳號到期、浮水印

幾個做的時候學到的事

• 毫米級的誤差，往往不在程式裡。把每次量測的「條件 → 指令 → 原始輸出 → 判讀」都記下來，才追得出問題其實是相機安裝沒共面這種實體原因，而不是算法。完整的檢查順序與誤差公式整理在筆記〈量測尺寸差了幾毫米？先檢查角度，再調尺寸補償〉。
• 把感測器拆開各看一段，比想辦法一次看全部務實。單組看不到全斷面沒關係，拼接交給程式，硬體就能用便宜、好佈的方式圍一圈。
• 狀態畫面要先回答「現在能不能用」。現場最需要的不是一堆數字，是一句話加一張圖告訴操作員下一步做什麼——這也是上面那個 Demo 想示範的。

適合哪些情況

連續產線上的線上尺寸量測、多感測器即時拼接、CAD 圖面自動轉量測／檢驗計畫、分散式即時資料管線，以及讓非工程師也能操作的設備狀態畫面。想把類似的量測或檢驗流程做成系統，歡迎聊聊。

← 回到作品