單元測試之 JKI VI Tester in LabVIEW

這裡要實作的是JKI VI Tester,我的習慣使用流程如下
1. 開啟專案,在Tools -> VI Tester -> New -> Test Case,建立測試物件
2. 將測試物件放在test -> VI Tester實際的資料夾下,並命名為“測試名+TestCase.lvclass”
3. 將專案中的測試物件移到test的虛擬資料夾下。
4. 在展開測試物件,在”testExample.vit”點下右鍵,點選“New from Template”,建立新的測試案例
5. 撰寫測試案例
6. VI存檔
7. 專案存檔
8. 再從專案下Tools -> VI Tester -> Test VIs…
9. 執行測試

建立測試物件
新增所出現的檔案架構
從模板建立測試VI,減少重覆的工作。
測試模板,減少拉線的時間
撰寫測試VI
開啟VI Tester測試畫面
除了可以有UI看到測試結果,也可以透CLI輸出文件

參考資料來源
LAF Q2 2015 – Unit Testing with the JKI VI Tester (Casey Lamers)
Testing a VI with VI Tester using Pass/Fail Criteria
Creating a Test Case and Test Method in VI Tester
此專案原始碼
JKI VI Tester by JKI – Toolkit for LabVIEW Download

關於4~20mA 電流訊號的二三事

4-20mA電流訊號被廣泛使用,有以下幾個優點:
支援遠距離傳輸:相較於電壓訊號,電流訊號的抗干擾能力較強。 它不受電源電壓的波動和傳輸線路電阻的影響,因此可以在工業環境中保證資料的準確性,特別是在長距離傳輸時。
方便偵測設備故障:4-20mA的電流訊號在設備斷開或故障時,電流會下降到0mA或其他值,這樣就可以輕易偵測出設備的故障。
然而,儘管4-20mA電流訊號有其優點,但其中一些設備(如微處理器、資料擷取設備、單晶片等)的介面往往是基於電壓的。 這就需要將4-20mA 的電流訊號轉換為對應的電壓訊號,以方便這些設備的介面進行處理和解析,進行下一步的控製或資料分析。
另外,電壓訊號也可以提供更高的分辨率,對於一些需要高準確度的應用場合,可能會優先選擇電壓訊號。

本著錢要用在刀口上,所以就稍為整理的了一下,得到以下想法
要便宜不怕麻煩就自己組,目前看起來是用Arduino R4 Uno + 轉換模組,約1000元,精度夠,但是資料取樣率就看Arduino怎麼寫了,但可以想像速度是一般般了。
只要有功能又不要太貴,精度跟時間不在意的就可以選表頭,5百元有找,但是精度跟取樣率不確定,還有要處理通訊協定。
需要有功能加上好的服務,又可以在LabVIEW有好的整合性 WPC Ethan-1,重點是有量測需求可以找他們討論,免得浪費時間。
如果有品牌情節請直上NI or 研華 or 凌華的DAQ

參考資料
WPC 資料擷取裝置 (DAQ)
電流轉電壓模組 4-20mA、0-20mA 轉0-3.3V 0-5V 0-10V
Arduino UNO R4 Minima 控制板(正宗原廠_品質保證)
【才嘉科技】0-10V 0-20mA 2-10V 4-20mA 數位訊號顯示表 類比量輸入顯示表 數顯表頭 RS485
ADLINK Technology USB-1903
CT-2012 4-20MA控制/警報表頭 產品型錄

LabVIEW跨平台開發的注意事項 (Windows or Linux)

因為在Windows上用LabVIEW進行開發也超過20個年頭,但是一直忘了當初為什麼沒有想到用Linux下進行LabVIEW開發,直到最近因為要用GitLab CI/CD與在Line群上討論到,所以今天就把他寫下來,之後有更新來這裡回顧。

注意事項
1. LabVIEW專案所使用的硬體是否有支援Windows與Linux.
2. LabVIEW專案所使用的硬體是否有提供對應的dll 與so檔
3. LabVIEW專案是否有用到.net framework元件,如果有用到,則只能在Windows OS下運作
4. LabVIEW專案在那個OS下的編譯出來可執行二進制檔案,也只能回到該作業系統示運作
5. 如果只是要進行code review,因為沒有要編譯成可執行二進制檔,則沒有上述限制

參考資料
LabVIEW and Microsoft Windows Compatibility
LabVIEW 與 Linux 作業系統相容性

LabVIEW 單元測試與執行檔編譯的自動化

感謝國外各路大神提供的各項toolkits,目前整理過後,已經可以自動化的進行單元測試後,再編譯成執行檔。但其步驟和細節太多了,只能慢慢的補上設定過程。

這裡先說,這次的gitlab-runner是用SAS G-CLI Tools Documentation裡的設定,與之前用的powershell不同。

我這個專案的GitLab路徑
LabVIEW-CICD

參考資料
SAS G-CLI Tools Documentation
LabVIEW Project Template
Caraya-CLI-extension
Caraya CLI Extension by G Open Source Project for LabVIEW – Toolkit for LabVIEW Download

當windows更新一直有不存在的印表機要更新驅動程式

使用”printui /s /t2“叫出列印伺服器,將不存在的硬體移除後,windows update就不會去抓新版的驅動程式,然後告訴你安裝失敗。

參考資料
https://answers.microsoft.com/en-us/windows/forum/all/windows-update-will-not-download-optional-update/a7971253-e3a5-4929-8ecd-c623f9d3a396

LabVIEW + GitLab Server 硬體環境怎麼配置

因為公司政策,程式碼不能放在外網,而我又需要專案可以進行CI/CD的自動化,所以只好來研究一下怎麼配置來滿足我的需求。

我的想法是用一台 Windows筆電 Intel i7/ 16GB RAM 掛上 VirtualBox + Ubuntu Server + gitlab server
VirtualBox 設定 2 cores CPU及4G RAM來滿足GitLab server的需求

會這樣做的原因是已經有看到人在Windows上要架GitLab server的教訓,所以我也就不多想,直接使用VM+Ubuntu+GitLab的組合來做。

那為什麼不是直接在筆電上直接安裝Ubuntu呢?答案很簡單,因為我的程式絕大多數是有GUI的程式,所以gitlab-runner需要跑在Windows上。

以上的思考是用只有一個開發人員的情境下進行的規劃。真的專案多了,有多個專案要跑CI/CD我想應該也是沒有辦法用的,需要再優化。

參考文章
How to Install GitLab on Ubuntu 22.04 Step-by-Step
Windows環境下安裝GitLab的心得(不是安裝教學)

LabVIEW + GitLab CI + Windows + Docker可行嗎?

2024/03/02 更新,原來在用Docker有太多細節我沒有注意到,所以一開始在Docker建立Image就出問題,所以後續動作當然就無法進行了,但是建置過程確實沒有這麼簡純,也只能慢慢破關了。
————————————-以下為原始發文————————-
找了一整天的資料,我得到的心得是,即便建置完成,日後處理問題的時間應該會大於用他的時間 ,最後還是問了一下chatGPT跟Gemini後,我短時間內應該會中止這個計畫,有需要還是用VirtualBox就好。

chatGPT上網搜尋之後的回答如下:
Docker 原始設計主要是用於建置和部署後端服務型的應用,並不直接支援運行圖形化介面應用例如 Windows 的桌面程式。
對於你的問題,目前並沒有標準的或廣泛被接受的做法用以在 Docker 容器中運行 LabVIEW 的應用程式。主要原因是,LabVIEW 是一種具有圖形化介面的開發環境,並且它一般被用來開發具有豐富用戶交互特性的桌面程式,這些並不符合 Docker 的標準使用情境。
然而,如果 LabVIEW 應用程式被設計為不需要使用者界面,來執行一些自動任務,則可能能夠在 Docker 容器中運行。但是這需要對 LabVIEW 程式做特殊的設計和調適,並不是直接將一個通常的 LabVIEW 桌面應用程式放進 Docker 容器中運行。
總結來說,盡管有某種可能性在 Docker 中運行一些特殊設計的 LabVIEW 應用程式,但 Docker 並未直接提供支援 Windows 顯示或桌面環境,因此不適合用來部署具有完整用戶交互介面的 LabVIEW 桌面應用程式。如果需要在虛擬化環境中運行這類應用程式,可能需要尋找其他的虛擬機軟體,例如 VMware 或 VirtualBox 等。

Gemini也很好笑,給了完整的dockerfile的建置步驟,不過只是正經八百的畫虎爛,完全是沒有辦法用,中間還問他,他給的連結問題,他的回答是“這件事我幫不了忙,我只是個語言模型。”

這個image只能用在linux下嗎?
另一個image雖然可從dockerhub拉下來,結果還是不能用,因為他也是Linux系統為基礎,沒有搞懂原始開發者怎麼用。

2024/02/24 這個時間點環境如下:
Windows 11 23H2 OS build:22631.3155
LabVIEW 2020 SP1 32Bit
Docker 4.27.2
gitlab-runner 16.8.0

參考資料
LabVIEW + Docker + Windows = Match?
Building LabVIEW 2018 Programs In A Docker Container
Using LabVIEW in a Docker Container
20 分鐘入門 Docker,建立屬於你自己的 Docker Image|六角學院|2023 鐵人賽 #23
Docker是什么?【Docker教程1】

如何安裝VI package -> G CLI套件

開發者已經收到我的訊息,有機會在G CLI 3.0.1.98之後的版本是否可以在不改“系統地區設定”的情況下,就可以正常安裝。在這個版本之前,也就只能改“系統地區設定”後再進行安裝了。
在繁體中文的Windows作業環境下,在預設的情況下,似乎是unicode的關係,導致VIPM無法正常安裝G CLI,今天終於試出來可以正常安裝的方式,就是要進到”系統管理語言設定”下,變更“系統地區設定”,將預設的”繁體中文(台灣)”改為“英文(美國)”之後,再進行安裝即可。

只要到“系統管理語言設定”內設定系統地區修改
語言改為英文,要重新開機後再安裝就可以正常安裝了。
正常安裝後的畫面

LabVIEW mass compile時間

2024/02/23 目前程式已經大到進行compile要接近12個小時了

LabVIEW 的 Mass Compile 功能其主要目的是更新你的 VI(Virtual Instrument)或專案檔案到最新的LabVIEW版本,或提升其效能。

在 LabVIEW 中,每個 VI 會儲存資訊像是資料流程、使用的函數和子VI。然而,當 National Instruments 更新 LabVIEW 時,一些底層的實作方式可能會更改。在這種情況下,LabVIEW 會嘗試保持子VI與主VI的一致性,確保所有的 VI 都使用同樣版本的 LabVIEW。

Mass Compile 也可以找出有問題的 VI,幫助你修復這些 VI。當你運行 Mass Compile 時,LabVIEW 會打開每個 VI,並且重新編譯所有的程式碼。在此過程中,如果 LabVIEW 發現任何錯誤或警告,它會顯示在 Mass Compile 的結果視窗中。

Mass Compile 的時間長短取決於你的專案大小及其複雜性。一個包含許多 VI 和複雜資料流程的專案需要比一個簡單專案更多的時間來編譯。此外,如果你的電腦性能較低,或者你同時執行了其他處理器密集型應用,Mass Compile 可能會需要更多的時間。

這是一個必要的過程,確保你的專案能在最新的 LabVIEW 版本上正常運行,並且優化 VI 的效能。然而,由於它可能會需要一些時間來完成,所以建議你在不需要立即使用電腦的時候,或者是在非工作時間進行 Mass Compile。