2025年11月10日 星期一

儀器控制中，寫程式是最簡單的

我總是跟我學生說，儀器控制中，寫程式是最簡單的。「怎麼會呢？」他們總是露出疑惑的表情。或許，我應該說，寫程式是儀器控制中最單純的部分。

想當年我剛進公司的時候，我驕傲的咧！別人要學很久的 Queue State Machine，我一下就學會了，其他一些程式邏輯的部分也都很學得很順利。沒多久，我拿到了我的第一個專案。那個專案挺單純的，需要讀取電壓電流數據、繪製圖表、儲存，就這樣。我想：喔耶！這是我的第一個專案，我要好好表現！我飛快的寫好了整個程式，流程和套件的使用都很順利，我想：「我應該很快就可以結束這個專案吧！」殊不知，這才是惡夢的開始。



我跟客戶約了測試儀器的時間，信心滿滿的帶著我的程式和筆電，和同事一起出發了。到了之後，我自信的把電腦接上儀器，然後......「為什麼電流長這樣！這不合理！」本來應該是平緩弧線的電流，出現了比訊號強度還要大的雜訊。我有一點點慌，我明明就是按照說明書的指示寫的程式啊！還好同事在旁邊穩定了我的心神。那一天開始，我明白了：還沒接上儀器的 LabVIEW，根本沒有難度，難度都在接上儀器之後。

LabVIEW 不像其他程式語言，會放很多很複雜的演算法，因為這不是他的強項。當你需要很多很複雜的演算法時，其實更建議將這些計算的部分，使用 LabVIEW 的內建功能交握給其他程式。LabVIEW 困難的部分不在程式，在物理世界中儀器的千變萬化，下一篇，教你怎麼一步步排除儀器和程式連線中會遇到的問題。敬請期待！

2025年8月4日 星期一

LabVIEW 2025 Q3 Nigel AI Advisor 實測 | 更低的開發門檻？還是更多的幻覺？

這篇文章記錄了我對 NI 最新發布的 Nigel AI Advisor 的初步測試心得。身為 LabVIEW 工程師和重度AI Agent愛好者，純粹是實際使用後的真實感受分享。

Nigel AI Advisor 快速結論

簡介

NI出的LabVIEW程式建議助手，最大的重點就是可以讀.vi檔，不像其他 AI 工具只能處理文字程式碼。

程式碼理解能力：

  • 可以解釋一般大學生寫的混亂程式碼
  • 能夠理解有架構的 QSM、QMH 設計模式
  • 細節理解存在問題（已發現錯誤，但具體影響程度還需進一步測試）
  • 無法生成或繪製 LabVIEW block diagram，連示意圖都無法產出

實用功能評估：

  • 可以查詢 LabVIEW 函數功能，但便利性並未超越傳統的 Ctrl+H 快速說明
  • 能夠針對 VI 提出改進建議，涵蓋架構優化和變數處理方面
  • 建議內容相對一般化，需要使用者明確指定方向才能發揮最佳效果
  • 基於 GPT-4 架構，但專門針對 LabVIEW 開發環境進行調校

Nigel AI Advisor 使用體驗

主要優點

對於熟練的開發者來說，Nigel AI Advisor主要的功能是快速理解一些很混亂的程式。而對於新手而言，則更降低了學習門檻。

技術限制與注意事項

Nigel 建立在 GPT-4 基礎上，因此幻覺問題依然存在且有點嚴重。使用時需要保持警覺，務必驗證 AI 提供的資訊準確性。

就像其他 AI 編程輔助工具一樣，你必須非常清楚自己的需求，主動引導 Nigel。如果你能明確告訴它要使用哪種設計模式或解決什麼具體問題，效果會顯著提升。

介面與操作問題

目前版本存在一些使用體驗問題：

  • 中文輸入處理不完善：有時候還沒選字就會被送出，推測可能是 Event 設計的問題
  • 介面清理機制不完整：輸出結果後有時需要手動清除輸入框的內容

隱私與資料安全

根據 NI 使用者條款，Nigel AI Advisor 承諾不會將使用者資料提供給大語言模型進行訓練。

系統需求與取得方式

安裝LabVIEW 2025 Q3內建Nigel AI Advisor。

Nigel AI Advisor 評測總結

Nigel AI Advisor 目前是個有用但仍有改進空間的開發輔助工具。對於想要快速理解現有程式碼的 LabVIEW 開發者來說是有幫助的，對新手則是個不錯的學習輔助工具。

有趣的是，LabVIEW本來就是以易學難精著稱，AI是否讓這個程式更易學？對於精又有什麼幫助？這樣的AI Advisor會對生態造成什麼影響呢？

LabVIEW 2025 Q3 Nigel AI Advisor 測試介面截圖


2025年7月29日 星期二

AI時代，我們還需要LabVIEW嗎？

身為一個LabVIEW工程師。我常常思考一個問題：在這個AI寫程式的年代，我們還需要LabVIEW嗎？ 講結論：要！ 做為一個重度AI使用者，我自然探索各種AI寫程式工具。事實上在這個時代，Google有超過25%的程式由AI撰寫[1]，Microsoft表示大約有20~30%的程式由AI撰寫[2]。行業巨頭Anthropic更表示風靡Vibe Coding界的Claude Code有80%程式碼都由AI完成[3]。

LabVIEW最為人所知的就是三個大優勢：

  1. 快速開發
  2. 圖形化介面
  3. 深入的硬體支援 
但在這個Prompt魔法師的年代，文字語言開發超級快，又只需要用自然語言描述，難道LabVIEW要走入歷史了嗎？

AI幻覺（Hallucination）對儀控的致命風險

AI 最為人詬病的問題之一，就是「幻覺」（Hallucination）。它會自信地產生看似合理卻完全錯誤的資訊。在一般軟體開發中，這可能只會導致程式錯誤或功能異常；但在儀控領域，這卻是致命的。 想像一下，AI 為你的馬達控制程式產生了一段錯誤的指令，導致馬達超速運轉；或是在讀取壓力感測器時，給了一個不存在的函式，讓系統誤判壓力正常而導致工安意外。這些都不是可以簡單重啟解決的問題，而是可能造成昂貴設備損壞，甚至危及人員安全。 LabVIEW 的價值在於其確定性與可靠性。它不是猜測，而是精確的邏輯實現，這在分毫都不能出錯的自動化與量測應用中，是無可取代的。

AI看不到儀器

AI很會讀書，但它從沒進過實驗室。AI的知識全來自網路上的PDF和說明書，它能背出示波器的所有規格，卻不知道你桌上那台的BNC接頭有沒有鎖緊。接地干擾？訊號飄移？這些工程師每天處理的「鳥事」，對AI來說就像是異世界魔法。 但LabVIEW不一樣，它就是為了這些「鳥事」而生。在寫下第一行程式前，我能用NI MAX先跟我的DAQ卡「打聲招呼」，確認每個通道都正常。

流程即程式

為什麼自動化工程師喜歡LabVIEW？因為我們的思考方式就是流程圖。從「啟動馬達」到「讀取溫度」再到「壓力過高時停止」，這整個流程，在LabVIEW裡幾乎是直接「畫」出來的。你的程式，就是你的設計藍圖。 這點AI生成的程式碼就差遠了。就算AI能給你上百行完美的Python，但三個月後，當另一個同事（甚至是你自己）要來維護時，誰能快速看懂那錯綜複雜的邏輯？LabVIEW的圖形化程式碼就像一份共通語言，讓機械、電機、軟體工程師都能圍著同一張「藍圖」溝通。這不是什麼花俏的功能，這是工程實務的硬需求。

優秀的硬體支援

連接新硬體，是工程師的惡夢之一。你要去K那本厚厚的通訊協定手冊，處理底層的VISA、TCP/IP，一個指令一個指令地試。AI現在也許能幫你看手冊，給你一段看起來像樣的程式碼。但然後呢？連線不穩怎麼辦？儀器沒回應怎麼辦？你終究還是得親自下海去debug，花費的時間可能比自己寫還多。 LabVIEW最強大的地方，就是它數十年累積下來的「軍火庫」，也就是上萬種儀器的驅動程式。這是NI和各大廠商真金白銀砸下去開發、驗證過的。對我們來說，這代表著「隨插即用」的安心感，讓我們能把時間花在真正的挑戰上，而不是在搞定通訊這種基本功。

如何使用AI輔助LabVIEW開發

在NI推出他們專屬且能用的Code Assistant之前，我們顯然不能期待跟寫Python一樣「講一句話完成一個程式」，但這不代表我們沒辦法搭上AI這台高速列車。 AI很會讀書，那就讓他讀書，落落長的儀器手冊丟給NotebookLM，讓他讀完，問問題還會附上原文。