Showdown! Qt vs. LabVIEW

JKSH

(See https://forum.qt.io/topic/90275/ for the context behind this thread)

I'm here to compare 2 toolkits that I use regularly: Qt and LabVIEW. I mainly consider how well they help me to get things done as software development toolkits.

Both toolkits are very large and I haven't used all parts of either toolkit, so remember that I'm writing through the lens of my own experiences (>8 years casual experience with Qt, >5 years full-time experience with LabVIEW). Also, since this is a Qt forum, I'm writing for readers who know Qt/C++ but are unfamiliar with LabVIEW.

1. A Brief History of Qt and LabVIEW

The origins and journey of a toolkit heavily influences its qualities.

1.1. Qt

Qt started as a cross-platform, object-oriented, C++ GUI programming toolkit. Over the past 20+ years, it has evolved into multi-purpose framework; it is now a one-stop shop for many popular functional features (e.g. image manipulation, multimedia, communications, mapping, etc.), all available via one coherent, intuitive API.

Qt also provides language features that are absent from the C++ standard (e.g. signals and slots, type registration, introspection, string manipulation APIs). In recent years, C++ is starting to catch up and might obsolete Qt's language features in the future, but that future is still far far away. Even when that future comes, Qt will continue to remain a valuable C++ library.

Qt has grown beyond its C++ roots though by introducing the QML language -- this enables the creation of advanced modern GUIs using much less code than what C++ requires.

1.2. LabVIEW

LabVIEW started as a flowchart-style software that lets scientists and engineers create custom instruments using modular hardware components. Over the past 30+ years, it has evolved into a full-blown programming language in its own right, based on the dataflow paradigm. Major new language features in the past decade include dataflow OOP (LabVIEW 2009) and template functions (LabVIEW 2017).

Products by National Instruments (NI, the company behind LabVIEW) are used in industry applications more than in consumer applications, so long-term stability and support is a priority. Consequently, advancements in LabVIEW tend to be evolutionary rather than revolutionary. Nonetheless, a major revamp was released last year called LabVIEW NXG ("Next Gen"). LabVIEW NXG has not yet reached feature parity with "classic" LabVIEW, so both "branches" of LabVIEW will be developed in parallel in the near future. [EDIT: LabVIEW NXG was discontinued in 2021]

Technically, the language itself is called G while the development environment is called LabVIEW. In reality, both are closely intertwined so people just call everything "LabVIEW".

2. Qt wins in...

2.1. All things GUI

I miss Qt features dearly whenever I have to make complex GUIs in LabVIEW -- so much so that I started making Qt bindings for LabVIEW. The video below showcases some things that can be easily done with good ol' Qt Widgets but not with classic LabVIEW:

Furthermore, Qt Quick enables modern-looking GUIs with minimal coding, while Qt 3D and Qt Data Visualization are powerful for displaying multivariate data (or just for the 'wow' factor). LabVIEW can't really compete in these areas.

2.2. Data structures and algorithms

2.2.1. Variety of container classes

Qt has most containers that C++ does, along with really nice APIs for data manipulation.

LabVIEW has sequential containers too but its associative containers are a bit lacking. ~~We can create maps/sets but the API is hacky and we can only use strings or byte arrays as the key. That means: if we want to use non-strings as keys we need to manually cast them to raw bytes first.~~ [EDIT: LabVIEW 2019 finally introduced the map and set datatypes]

2.2.2. String manipulation

This one deserves a special mention: QString and QStringList are a joy to work with, given their clean and powerful API. Qt blows LabVIEW and STL C++ strings out of the water.

To LabVIEW's credit though, I still find LabVIEW strings nicer to use than std::string.

2.3. Localization and date/time manipulation,

Qt uses UTF-16 strings and has a good selection of text codecs built-in, and it can tap into many more through ICU; Classic LabVIEW only supports 6 languages (de, en, fr, ja, ko, zh-Hans) and requires the target PC to be configured to the correct locale because Unicode isn't supported.

QDateTime, QDate, QTime, and QTimeZone are all very powerful and flexible. In contrast, LabVIEW lacks support for ISO 8601 or timezone functions, so we have to resort to 3rd-party packages or homebrew solutions.

~~LabVIEW NXG has improved things since the video in #2.1: LabVIEW NXG strings are natively encoded in UTF-8. Also,~~ [EDIT: LabVIEW NXG was discontinued in 2021] LabVIEW timestamps also have nanosecond resolution (unlike Qt), which can be useful when working with multi-megahertz signals.

2.4. Ease of change management via a Version Control Systems (VCS)

As a C++ and QML toolkit, Qt-based projects are easily managed under a VCS like Git. Code can easily be diff'ed and merged. We can also easily go through a project history and see what was changed in any given commit.

LabVIEW-based projects are hindered in this area because LabVIEW source files (called "VI"s or Virtual Instruments) are binary files. While LabVIEW has a diff tool, it doesn't integrate nicely with VCS so we can't easily see past changes in detail. [EDIT: LabVIEW 2021 improved Git diff integration] Automatic merging is a pipe dream so merging must be done by hand. In other words, source control for LabVIEW takes more effort than usual.

LabVIEW NXG has improved slightly. Its VIs are now stored as XML documents, which puts them on a similar level as Qt Designer's .ui files. Maybe one day LabVIEW will take the route of QML, and split logic files (.qml) from UI files (.ui.qml) too. [EDIT: LabVIEW NXG was discontinued in 2021]

3. LabVIEW wins in...

3.1. Code elegance (assuming we're comparing well-written code)

3.1.1. Expressing algorithms in general

LabVIEW's dataflow language is a natural fit for describing complex, branching, parallel, and/or looping algorithms. Imperative languages like C/C++ are more awkward for this task because writing branches and parallel code using sequential text involves jumping around the code.

Furthermore, dataflow code implicitly describes which parts of the program must be executed sequentially and which parts can be executed in parallel. The LabVIEW compiler identifies parallelizable code segments, and automatically spawns new threads where beneficial. (The programmer can still micro-manage this and force sequential execution if they wish). As a result, no special code is required for multithreading (unlike C++).

If a programmer is proficient in both C++ and LabVIEW, I daresay it takes them less time and effort to read an algorithm in LabVIEW than in C++. I've personally found this to be true.

3.1.2. Expressing communications and data acquisition logic

Dataflow is also a natural fit for communications and data input/output.

In this example, I've implemented the same simple Modbus master in both Qt and LabVIEW (Connect to a fixed slave, read and display a fixed range of registers every 0.5s, quit upon error and display error messages). Both implementations below are complete; they can be built into executables as-is. If you find a way to simplify the C++ code further, please let me know.

Qt code

#include <QCoreApplication>
#include <QModbusTcpClient>
#include <QTimer>
#include <QDebug>

static void rageQuit(const QString &errorSource, const QString &errorString)
{
    qDebug().noquote() << "Error ("+errorSource+"):" << errorString;
    qApp->quit();
}

int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);

    // Initialize the Modbus master/client
    QModbusTcpClient master;
    master.setConnectionParameter(QModbusDevice::NetworkAddressParameter, "127.0.0.1");
    master.setConnectionParameter(QModbusDevice::NetworkPortParameter, "502");
    if (!master.connectDevice())
    {
        rageQuit("Connecting", master.errorString());
        return -1;
    }

    // Make the master poll the slave every 0.5s until an error is encountered
    QTimer timer;
    QObject::connect(&timer, &QTimer::timeout, [&master]
    {
        const int slaveId = 1;
        const int startAddress = 0;
        const quint16 numberOfEntries = 4;

        QModbusDataUnit readUnit(QModbusDataUnit::InputRegisters, startAddress, numberOfEntries);
        if (auto *reply = master.sendReadRequest(readUnit, slaveId))
        {
            QObject::connect(reply, &QModbusReply::finished, [reply]
            {
                // NOTE: For simplicity, we don't differentiate between protocol errors
                //       and other errors. We don't show error/exception codes either.
                if (reply->error() != QModbusDevice::NoError)
                    rageQuit("Reading", reply->errorString());

                QByteArrayList data;
                const QModbusDataUnit unit = reply->result();
                for (uint i = 0; i < unit.valueCount(); i++)
                    data << "0x" + QByteArray::number(unit.value(i), 16);

                qDebug() << data;
                reply->deleteLater();
            });
        }
        else
        {
            rageQuit("Sending read request", master.errorString());
        }
    });

    // Set up general error handler
    QObject::connect(&master, &QModbusTcpClient::errorOccurred, [&master]
    {
        rageQuit("General", master.errorString());
    });

    // Start polling when the master connects successfully
    QObject::connect(&master, &QModbusTcpClient::stateChanged, [&timer](QModbusDevice::State state)
    {
        if (state == QModbusDevice::ConnectedState)
            timer.start(500);
    });

    // Start the program (Use Ctrl+C to terminate)
    return app.exec();
}

LabVIEW code
LabVIEW Modbus code

Outputs
Qt output LabVIEW output

3.1.3. Expressing FPGA logic

We can use a subset of the high-level LabVIEW language to implement FPGA logic.

Just as C made life much easier for programmers who previously wrote Assembly, LabVIEW made life much easier for programmers who previously wrote VHDL.

3.2. Rapid prototyping

LabVIEW has many many nice features that let us produce a functional program faster. By themselves, they are small conveniences; combined together, they are serious productivity boosters.

3.2.1. Seamless integration with hardware and industry-standard protocols

LabVIEW shines when used for data acquisition, signal generation, or communication with other devices. Several factors contribute to this:

LabVIEW comes with tooling for hardware discovery and configuration (i.e. no coding or minimal coding required)
- This is most powerful for NI hardware
- Certain 3rd-party hardware are supported too (e.g. EtherCAT motor drives, GigE Vision or USB3 Vision cameras)
LabVIEW has intuitive APIs that follow IVI Foundation specs for instrument interchangeability
LabVIEW has intuitive APIs for a myriad of communications protocols
- Just to name a few: RS-232/422/485, Modbus, PROFIBUS, CAN, J1939, EtherCAT, EtherNet/IP, HTTP, FTP, OPC-UA, DDS...
- More are added regularly
The LabVIEW language is a natural fit for data input/output and communications (see #3.1.2.)

Programmers can start interacting with the world with minimal coding or package hunting.

Qt is catching up on the protocol front, through recent work in Qt Serial Bus, Qt MQTT, Qt KNX, etc.

3.2.2. Simple linear 2D plots

This is the one GUI area where LabVIEW beats Qt (e.g. Qt Charts, Qwt, and QCustomPlot).

It is boringly easy and fast to start visualizing data (whether the plot is point-by-point or chunked, single-series or multi-series): Just place a plot "widget" on the GUI and draw a wire from the data source to the plot terminal. Done.

Nonetheless, the Qt-based plots do have more plot types (e.g. pie charts, candlesticks) and flexibility for customizing the plots.

3.2.3. Lots of useful little debugging helpers

Every function can be executed independently
- Just open a function, set its input values, run it, and see its outputs
- No wrapper code required
Code doesn't even need to be saved to disk to be compiled and executed
- Want to verify a piece of logic? Just create a new "code file" in memory, copy+paste a code fragment across, set variable values, and run the fragment
After we finish running temporary files, simply close it to make it disappear
On-the-fly compilation:
- The LabVIEW compiler kicks in as soon as we edit a code fragment unless there's a syntax error (without slowing down the PC!)
- As soon as we finish coding, we can just click "Run" -- no need to wait for compilation
Highly dynamic debugging:
- LabVIEW supports the usual breakpoints and single-stepping
- We can also probe specific variables and watch them update while the app is running at full speed
- If full speed is too fast, we can artificially slow down the execution speed of selected functions
Automatic bounds checking and reference checking
- LabVIEW detects invalid references and alerts us when they are accessed
Integrated static code analyzer and profilers

3.3. Software distribution

3.3.1. Deploying your own apps/libraries

Imagine that you've just finished writing and testing your app. Imagine that Qt Creator's GUI presents you a list of your app's dependencies/plugins. Imagine that you can edit this dependency list and configure your installer in the same place. Imagine that, with a few more clicks, you get a neatly-packaged installer (containing all dependencies) to distribute to your users -- there was no need to separately configure/run windeployqt and the Qt Installer Framework.

Qt users have been wanting this for years; LabVIEW users have been doing this for years.

3.3.2. Finding and installing 3rd-party libraries

Imagine a GUI that lets you browse inqlude.org/qpm, select 3rd-party add-ons, and install them in just a few clicks. Imagine that when you launch Qt Creator, you see the 3rd-party widgets already integrated into Qt Designer, and the 3rd-party examples ready to run. Imagine also that, as a library author, you can publish your work into this officially-supported, officially-promoted repository for Qt users to discover worldwide. Imagine free and commercial libraries intermingling in this one-stop-shop.

Qt users have been wanting this for years; LabVIEW users have been doing this for years.

4. Both toolkits are neck-to-neck in...

4.1. Creating web apps

Both Qt and LabVIEW are joining the race to support web app creation.

Earlier in 2018, the ~~LabVIEW NXG Web Module~~ [EDIT: Now called the G Web Devepment Software] was released. This lets LabVIEW developers write familiar LabVIEW code to produce web apps (HTML + JS + CSS).

Qt will soon launch a tech preview of Qt for WebAssembly. This lets Qt developers write familiar Qt code to produce web apps (bytecode). There's also an experimental 3rd-party QmlWeb project which interprets QML into standard HTML + JS.

The LabVIEW NXG Web Module has a head start, but I believe WebAssembly is better than HTML in the long-run for fully-featured web apps.

Both toolkits' web offerings are still in their infancy; who knows how they end up? I won't be using them in real projects for a few years still, but I will be keeping an eye on their progress.

4.2. Supporting keyboard ninjas

Good C++ programmers boost productivity using keyboard shortcuts of their favourite IDE. Qt Creator provides the venerable Locator alongside other shortcuts, autocomplete, and custom macros.

The same goes to LabVIEW programmers. Serious ones learn keyboard shortcuts and wield LabVIEW's Quick Drop which provides autocomplete functionality and custom macros.

Why am I mentioning this? Because I've seen people transition from one environment to another and then complain how "slow" the new tool is. It is not slow; we just need to learn the shortcuts.

5. Conclusion

Qt and LabVIEW were created for very different purposes, which gives them different strengths and weaknesses. Nonetheless, they have overlapping capabilities too.

This post highlighted their most useful (IMHO) strengths compared to each other, without attempting to provide a comprehensive list. In particular, Qt is excellent for creating powerful GUIs; LabVIEW is excellent for writing industrial test, measurement, and automation applications -- especially when combined with the right hardware.

As with all tools, the most important thing is to pick the right tool for the right job. You can also use different tools for different parts of the same job; they are not mutually exclusive.

SGaist

Hi,

Thanks for the thorough and very good analysis !

MrShawn

Good Post,

(Skip Following if you don't care to read background)

First is that I am less qualified than you but I will give you my experiences/opinions.
To follow your orig post for context I am much like you I went to school for Engineering Physics Concentration ECE, I was originally interested in Quantum Physics but pretty quickly realized that was not my Jam. I fell into coding freshman year for my first time. My advisor screwed the pooch and said I had to take a programming course which he suggested Fortran, I said yea probably not, I took c++ instead with CompSci. However due to my concentration in ECE I also took C that same semester these courses were actually back to back. I loved it, both C and C++. End my programming education there. Just kidding, I went to take a lot of robotics classes which required a great deal of C coding, and also took several MEE courses which required a great deal of Matlab coding (special place for Matlab) then I also took some other simulation and numerical courses for math which required me to use R. My Capstone made extensive use of C/C++ but really I was largely unaware of what a framework even was. At some point in grad school I took Parallel/Cluster computing, which was probably my favorite class, even though I was lightly exposed to multi threading, this class really opened the doors for me on that. Then I graduated and got my first job. They wanted me to use, LabVIEW so I learned it to an extent, pushed through to GOOP, and other ref based G#, also looked into actor framework and thought that would be what I wanted - it wasn't. I remembered Qt from when I was looking at Job posting wanting 60+ years of Qt experience so I decided to look into Qt some more and actually haven't really touched LV since. I will say I put more time into learning LV than the Qt Framework but experience for both is less than a year. Paling in comparison to you multiple years in both.

(End Skip)

I missed out a little on your previous post as well.

A few things I would like to add/discuss:

1)Database Connectivity
I have found Qt's database capabilities far superior to that in LabVIEW. My experience with LV's Database Connectivity Toolkit is minimal but I have used it (I had to upgrade to professional before I could have access to it). Before that I was calling invoke nodes onto .net ado objects which was conceptually very awkward to me. From when I looked INTO the database connectivity it was just a wrapper around that.

In Qt I setup my DB and query object and pretty easily do what I need to do. The data types from variants are very easy to convert into what I need. It also does a lot of extra work helping me guard from SQL Injections. It also has the ability to adapt to model view programming.

2)OOP

I like OOP... And I struggle to write OOP in LV. Yes you can do it but as soon as you want to do some pretty complicated objects that need to do things asynchronously and maintain its data the dataflow paradigm breaks down and LV starts to get a little awkward. Solutions exist like reference based OOP in G, or even the Actor Framework but I found myself asking why do I have to deal with all the muck when other languages do this so easily. Basically because when you fork the wire a new instance of the object is created, so I cannot update in one area of my code and read in another. Like I said reference based OOP is not bad but then you have inheritance issues because you are not passing the wire of the object but instead a reference to the object in which case your dynamic dispatching goes out the door.

3)Complexity
LV is conceptually easier to follow IMHO. Follow the wire, watch the data flow, you can pretty much see what is happening. Things are more or less straight forward. If you want to change FP properties you can easily use property nodes, want to update the value of an indicator/control, drag your wire into it. Everything is very straight forward and can taken more or less be taken at face value. That comes with a price, I feel like you lose a lot of potential power, power that is still there when using Qt/c++. Prototyping is definitely quicker and easier in LV.

4)Moving files around on the disk (probably my biggest gripe coming from text based language or non-binary files)
LV remembers too much. I cannot simply replace files or move them very easily without complaints. If you do these kinds of things without using the project manager LV is going to complain and probably start searching all over your file system picking up some VI(s) you did not want it picking up then you have to figure out how to undo all that. It is very picky about where things were, what they were like, etc. You have to be REALLY careful to make sure LV is using the VIs that you want it to use. I do not have this problem when not using binary files. In Qt i say specifically in the project file, look here, and don't look anywhere else if you don't find it. I can replace the .h and .cpp files at any point with updated version developed separately without issues.

Here is an example, say I have 3 VIs a.vi, b.vi, c.vi. Lets also say a calls b which calls c. Say I have them all in a folder called ProjectA. If I move them into folder ProjectB (not using LV project manager) by cutting and pasting then try to run the VIs they are not going to work because a.vi knows that it needs to use b.vi but it knows specifically that b.vi is in ProjectA folder which is no longer there. Lets say I COPY and paste so the files still exist in ProjectA and now also in ProjectB. This is especially scary because even though you think you are using VIs in ProjectB folder - remember that they are actually using the VIs in ProjectA folder(because the binaries were compiled as such) and you will not notice this unless you inspect the filesystem view on the LV project manager. This could lead to you breaking the ProjectA program.
(NOTE: I have noticed that setting ownership in LV where you put the VIs into a .lvlib file USUALLY solves issues with moving VIs but a few times even after doing so I have inadvertently edited the WRONG VIs!)

They may also say well use VIPM to build your shared code and deploy it - well good luck doing that with actor framework because any actor compiled will not work with the non-compiled version of the actor framework.

My overall view is that LV is good for doing smaller equipment based programs. I fear using it on large projects where I have hundreds of VIs that I have to navigate through (there is one such program that I work with in LV that is rather massive and to the credit of the developer he made it work and do what it needed to but god the rest of us look at each other and fear it). I don't particularly like the visuals provided by the stock LV. I also do not like organizing wires, only to have to make a change and need to reorganize all over again, it is very tedious in that department. You can tell LV was originally designed for equipment. People have been able to make really great programs with LV but there is a massive paywall imo. (RANT INCOMING) I was tasked to quote out some LV vision system in which case we already paid for multi ide bundle (x4) which comes with professional LV version, the vision toolkit does not come with LV professional so we have to buy that. But wait, they ask: do you plan to deploy this program to a machine other than the development machine? DUH, of course I do I want it to run on the equipment on the floor when I am done. Well you need to buy a deployment license... Thankfully I pointed out to the sales person that there is one deployment license included when purchasing the toolkit (something I had to point out that they did not know). I asked them well could I just work on the raw array for the pixel values instead of using their specific vision data type and their like oh yea I guess you could do that... (END RANT)

Qt on the other hand really feels genuine and to be honest I am much more comfortable in a text based language than I am in LV's visual language. The Qt salesman was very knowledgeable about his product and very pleasant and flexible which I am grateful for. I have a lot more control in C++/Qt framework and continue to discover new features and capabilities which simplify my programming. I am definitely pro Qt which sucks because the other software guys here are LV :*(

If you do read all this crap, thanks for reading, be well.

-MrShawn

mzimmers

I'm relatively new to the Qt framework, but I've been using Creator for years, IMO, there's another angle to this analysis (or, for that matter, to any comparison to Qt) that is difficult to quantify, but nonetheless important:

Qt gets it.

The more time one spends programming in/with Qt, the more obvious it becomes that Qt is truly built by developers, for developers. The niceties in the code browser and editor, the excellent front end to debuggers, the richness of the class library, and the quality and consistency of the documentation, all make it clear that Qt was built to exceedingly high standards. You simply don't see that in LabView (which I do like), MSVS, Eclipse, EWARM or any other IDE that I'm aware of. Qt wins the hearts and minds, simply because it was built with hearts and minds.

JKSH

@MrShawn said in Showdown! Qt vs. LabVIEW:

1)Database Connectivity
I have found Qt's database capabilities far superior to that in LabVIEW.

No arguments there!

Many aren't satisfied with LabVIEW's native SQL API, so 3rd party libs became quite popular (e.g. SQLite A, SQLite B, MySQL)).

2)OOP

I like OOP... And I struggle to write OOP in LV. Yes you can do it but as soon as you want to do some pretty complicated objects that need to do things asynchronously and maintain its data the dataflow paradigm breaks down and LV starts to get a little awkward... Basically because when you fork the wire a new instance of the object is created, so I cannot update in one area of my code and read in another.
...
Like I said reference based OOP is not bad but then you have inheritance issues

As I mentioned in https://forum.qt.io/topic/90275/, LabVIEW OOP is designed for Value objects, not Identity objects. I actually find LabVIEW object references (pointers) quite useless because, as you discovered, dynamic dispatch stops working. Custom property nodes don't work either.

In case you need to do more LabVIEW work in the future, I'll share my approach for writing Identity objects in LabVIEW:

The class data should consist of "reference" types only (e.g. a physical channel reference, VISA comms reference). There should be no plain data types like strings, Booleans, or numbers. Instead, wrap plain data in a Single Element Queue (SEQ) and store the SEQ in the class -- the SEQ acts like a pointer .
Write "constructor" and "destructor" VIs to initialize/clean-up these references.
- If you create a subclass, run the parent constructor in your subclass's constructor.
Write accessor VIs as you normally would.

That's it. There's a bit of boilerplate code involved, but you can now create objects which can be accessed from different parts of your code at the same time, while fully supporting inheritance. Forked wires will not create a new "instance" of your object.

Solutions exist like... the Actor Framework but...

The Actor Framework isn't actually a "way to do OOP". Rather, it is an application architecture for creating components to send/receive messages, and this framework just so happens to be built on OOP. Implementing Actor objects involves following specific patterns, which makes it quite different from implementing generic objects from scratch.

3)Complexity
LV is conceptually easier to follow IMHO. Follow the wire, watch the data flow, you can pretty much see what is happening. Things are more or less straight forward. If you want to change FP properties you can easily use property nodes, want to update the value of an indicator/control, drag your wire into it. Everything is very straight forward and can taken more or less be taken at face value.

Yes, and this helps with code readability (assuming it's well-written).

That comes with a price, I feel like you lose a lot of potential power, power that is still there when using Qt/c++. Prototyping is definitely quicker and easier in LV.

This "loss of power" isn't due to the dataflow paradigm, but due to the design of LabVIEW's GUI API.

IMHO, the main weaknesses of LabVIEW's GUI API are:

There is no (good) dynamic resizing/layouts for GUI components
There is no dynamic creation/destruction of GUI components.
- LabVIEW NXG has introduced this which is a step in the right direction, but classic LabVIEW will never have this.
There is no clear boundary between edit-time and run-time components.
There is no clear boundary between the display and the data type.

It is possible to have all this with dataflow/wires/graphical programming, but unfortunately it isn't implemented.

4)Moving files around on the disk (probably my biggest gripe coming from text based language or non-binary files)
...
LV is going to complain and probably start searching all over your file system picking up some VI(s) you did not want it picking up then you have to figure out how to undo all that.
...
say I have 3 VIs a.vi, b.vi, c.vi. Lets also say a calls b which calls c. Say I have them all in a folder called ProjectA. If I move them into folder ProjectB (not using LV project manager) by cutting and pasting then try to run the VIs they are not going to work because a.vi knows that it needs to use b.vi but it knows specifically that b.vi is in ProjectA folder which is no longer there. Lets say I COPY and paste so the files still exist in ProjectA and now also in ProjectB. This is especially scary because even though you think you are using VIs in ProjectB folder - remember that they are actually using the VIs in ProjectA folder(because the binaries were compiled as such) and you will not notice this unless you inspect the filesystem view on the LV project manager. This could lead to you breaking the ProjectA program.

What version(s) of LabVIEW did you use?

I've only really worked with LabVIEW 2012 and newer, so I don't know what the older versions are like. But in all the versions I've worked with, your example will be fine. VIs remember their links each other using relative paths, so your 3 example VIs can still find each other after being moved.

I copy+paste source code file between projects quite often.

In Qt i say specifically in the project file, look here, and don't look anywhere else if you don't find it. I can replace the .h and .cpp files at any point with updated version developed separately without issues.

Again, in the versions I've worked with:

If a VI is not found in the expected place, LabVIEW searches the system libraries and the folders which contain your project files. It won't search anywhere else.
If LabVIEW finds a VI in an unexpected place, it pops up a confirmation dialog. The dialog shows the path where the VI was expected, and the path where the replace VI is found. It then asks you to choose the correct option before it re-links the VIs.

My overall view is that LV is good for doing smaller equipment based programs. I fear using it on large projects where I have hundreds of VIs that I have to navigate through (there is one such program that I work with in LV that is rather massive and to the credit of the developer he made it work and do what it needed to but god the rest of us look at each other and fear it).

I don't see a fundamental difference between LV and Qt in this aspect. When it comes to making a large program maintainable, the programmer's technique and discipline is far more important than the choice of toolkit.

There exists fearsome C/C++ code, fearsome LabVIEW code, beautiful C++ code, and beautiful LabVIEW code.

People have been able to make really great programs with LV but there is a massive paywall imo.

Many people have called for NI to do something about that paywall. I think Qt's dual-licensing model works very well; it would be great to have a free (or heavily discounted) LabVIEW for hobbyists too.

(RANT INCOMING) I was tasked to quote out some LV vision system in which case we already paid for multi ide bundle (x4) which comes with professional LV version, the vision toolkit does not come with LV professional so we have to buy that. But wait, they ask: do you plan to deploy this program to a machine other than the development machine? DUH, of course I do I want it to run on the equipment on the floor when I am done. Well you need to buy a deployment license... Thankfully I pointed out to the sales person that there is one deployment license included when purchasing the toolkit (something I had to point out that they did not know). I asked them well could I just work on the raw array for the pixel values instead of using their specific vision data type and their like oh yea I guess you could do that... (END RANT)

I agree that it is bad form for a sales rep to be unaware of their own offerings and options.

NI's vision product line is a bit messy, I think partly because NI bought it over from another company and kept the structure. The VAS is all you need for camera access. I would only buy the VDM if I want access to the advanced machine vision and/or image processing functions; otherwise, I'd roll my own algorithms.

Qt on the other hand really feels genuine and to be honest I am much more comfortable in a text based language than I am in LV's visual language. The Qt salesman was very knowledgeable about his product and very pleasant and flexible which I am grateful for. I have a lot more control in C++/Qt framework and continue to discover new features and capabilities which simplify my programming.

Great to hear!

Qt is always growing too, so new features and capabilities are added regularly. I can't seem to keep up anymore :-(

I am definitely pro Qt which sucks because the other software guys here are LV :*(

I believe in choosing the right tool for the right job. I sometimes use both Qt and LabVIEW for different parts of the same project.

Are your colleagues "reasonable" people? If so, I'd keep an open, ongoing conversation with them. That helps avoid an "us-versus-them" scenario which makes things more pleasant. You might even be able to win them over to Qt's strengths.

First is that I am less qualified than you but I will give you my experiences/opinions.
...
If you do read all this crap, thanks for reading, be well.

This is your experience, which is definitely not crap. Thank you for sharing your story.

Our interests, our education, the people we meet, etc. all contribute to our skillset and preferences -- it is perfectly valid to dislike organizing wires or dated 2D graphics.

Again, a belated welcome to the Qt community. Happy coding!

JKSH

@mzimmers said in Showdown! Qt vs. LabVIEW:

difficult to quantify, but nonetheless important:

Qt gets it.

+1

Back when I was trying out GTK and Qt, I felt the difference immediately.

With Qt Creator, we can definitely tell that Qt engineers eat their own dogfood!