07-23-2021 01:20 AM
Hi,
I have a LabVIEW program that use QMH to control multi-devices including NI-FPGA
I want to create a windows desktop application that uses Qt to build the UI and let LabVIEW be its backend (remaining the property of using QMW to control multi-devices).
I know that Labview can be built as a DLL or web API, but I still have some questions. If anyone knows the answer or have any suggestion and reference, I will really appreciate it!
07-23-2021 12:25 AM
各位版友好,
我現在有一個LabVIEW的程式,使用QMH架構控制多個儀器(包含使用NI-FPGA)。
想詢問有沒有人有經驗,將這種LabVIEW程式包成DLL、API或其他形式,使用Qt做介面控制,最後變成一個Windows桌面應用程式(可安裝)。
目前爬文有看到能將LabVIEW包成DLL或WebAPI,但有以下問題:
另外有查到LabVIEW和.Net的相容性比較高,以上問題如果將Qt換成WPF不知道可不可行,有沒有類似的經驗或參考文獻?
跪求高手解答!!!
07-23-2021 04:27 AM
Hello!
One possibility would be to add a web service to your project so your LabVIEW application can communicate with any other application via web requests (e.g. REST API). Your UI would then be completely independent from LabVIEW and you can use whatever framework you like.
07-23-2021 04:39 AM
Care to tell us why?
Everything you're asking for can potentially be done.
It won't be easy... A crude UI won't be that hard. Sharing large amounts of data between the GUI and LabVIEW might be hard.
07-23-2021 07:08 AM - edited 07-23-2021 07:09 AM
For large amounts of data you can use Websockets and stream it, shouldn't be a problem. But you're right the first question should be why you don't want to use LabVIEW for the UI.
07-23-2021 08:31 AM
@Jens_S wrote:
[...] the first question should be why you don't want to use LabVIEW for the UI.
Or the other way around. When You have to implement the data transfer on both sides and have the know-how to do it in Qt, why not skip the middle-man and go full Qt?
Combining both feels like adding a lot of moving parts that are prone to break and will be extremely difficult to fix. Is this perhaps a XY-Problem ?
07-23-2021 08:48 AM
@LLindenbauer wrote:
@Jens_S wrote:
[...] the first question should be why you don't want to use LabVIEW for the UI.
Or the other way around. When You have to implement the data transfer on both sides and have the know-how to do it in Qt, why not skip the middle-man and go full Qt?
Combining both feels like adding a lot of moving parts that are prone to break and will be extremely difficult to fix. Is this perhaps a XY-Problem ?
I don't disagree....
Qt isn't a programming language, but an API. So, you can make a LabVIEW application that uses Qt by calling the Qt API... Even LabVIEW (development system) seems to use Qt (IIRC for the shared variable browser or something like it).
That could be what OP is really asking. Can I use Qt as the GUI of LabVIEW. Not can I make a C? C++? application that uses Qt and calls LabVIEW.
From LabVIEW, using Qt will become problematic when it comes down to events. Qt events won't connect well to LabVIEW events. You do want the GUI to be event driven...
I really don't think we can give advice without understanding the reasoning. Too much is unclear.