LabVIEW的莫名其妙Build Application的問題

今天上群組的討論,隨身做個記錄,我相信還會有下一次
一開始原始的發問如下:
專案執行起都很正常,但是要轉執行檔時,都會出現下面錯誤,跑過mass compile,沒有看到問題,請問各位有遇過這樣的問題嗎?又該如何處理呢?

2024/03/26 更新
最終解決方法,移動一下這個property的位置後,一切就恢復正常了。對,沒錯,程式都沒改,就只是移動property的位置後,再build執行檔。就正常了。

2024/03/26 更新,就只是移動一下,上面紅框的物件,build執行檔就沒有問題了。


後來有發現到我的兩台開發電腦,只有一台有這樣的狀況。

line群裡的大大給的建議有下面幾個方向
1. 檔名太長
2. CDS toolkit
3. builder有問題,重新建置
4. Actor Children會不會被改壞了

最後的解決方案有兩個方式
方案一
開啟Enable debugging就可以正常轉出執行檔


方案二
1. 取消勾選在build specification中的Additional Exclusions->Remove unused members of project libraries.
2. 修正“C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\drjdpowell\SQLite Library\Lookup\Open (with Attributes).vi” 這個broken問題;但如果只是單純修好這個VI,不勾選上面這選項,問題依然存在。


雖然我正常的電腦不作上面的動作也能正常build執行檔,但為了兩台電腦都有一致性的環境,也就先這樣吧。

Remove unused members of project libraries後,Build執行檔會出現這個問題,所以要修正Open (with Attributes).vi後,才能正常轉檔

參考資料
line群
How To – LabVIEW建立執行檔時遇到1502&1055錯誤的可能解決方式
LabVIEW Error 1502 When Building an Application
LabVIEW 2023 Q3 crashes while building exe on Windows 11

GitLab CI/CD之“原來gitlab-runner也可以設定登入帳戶”

因為目前都是用一台電腦跑完CI流程後,在CD的部份是希望可以直接上傳到google drive,本來想說不就直接用雲端硬碟電腦版複製過去了就好,但是萬萬沒有想到,在跑gitlab-runner時,一直出現權不足,無法複製的情況,搞了好久才找到原來是gitlab-runner的登入帳號是本機系統帳號,是沒有辦法寫入個人的雲端硬碟的,需要改變gitlab-runner的登入帳號,才能夠正常讀寫個人的雲端硬碟。

開啟電腦管理,到服務這找到gitlab-runner,就可以看到是預設的本機帳戶
進到gitlab-runner,修改登入帳戶。
修改後,就可以看到登入帳戶為個人帳號。

可以為LabVIEW建立自己的Docker image使用容器技術來進行自動化的CI/CD嗎? ->答:目前還不行

目前NI的授權方式關係,以及NIPM與JKI VIPM的安裝方式,在無法完全在command line interface作業的狀況下,很顯然只能期待未來NI授權方式改變及NIPM與JKI VIPM可以完全支援command line interface作業的狀況下再來研究了。

參考資料
Support VIPM installation on a Docker container (Windows)
LabVIEW + Docker + Windows = Match?
20 分鐘入門 Docker,建立屬於你自己的 Docker Image|六角學院|2023 鐵人賽 #23
自建 Docker Image
docker全套工作流的白话教程实用入门指南 快速掌握docker的基本操作 全套工作流的白话教程 堪称喂饭|拉取镜像|创建容器|运行容器|修改容器|容器打包成镜像|推送自己的镜像
Understanding Docker for Windows
Part 4 – Making Windows Containers for Docker to Work
“Contain” your excitement!

不完美的LabVIEW + gitlab-runner CI流程

2024/03/14 更新
原來是自己沒有注意跑了兩個runner,所以資源衝突造成的,移除多餘的runner之後就正常了。

不知道是不是因為架設一台實體電腦跑gitlab-runner,所以在常常開關LabVIEW之後,就出現下面的狀況,在windows管理員中,看到LabVIEW的執行緒就卡住了。即便手動關閉後,讓這一次可以正常執行完CI流程,但再下次執行CI流程後,還是很容的再出現相同的狀況,看來還是需要進到容器,再來觀察這個狀況會不會有所改善。

從GitLab中,看到工作被中斷的狀況
這個是目前維一有看到什麼服務被卡住,很多時候只看到LabVIEW的執行緒沒有被關閉卡在那。
這個就是常態,上面這張圖還是重開電腦第一次執行CI時,就中招了。

單元測試之 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

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

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,今天終於試出來可以正常安裝的方式,就是要進到”系統管理語言設定”下,變更“系統地區設定”,將預設的”繁體中文(台灣)”改為“英文(美國)”之後,再進行安裝即可。

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