You don’t have to use LabView

You don’t have to use LabView

LabView works for a wide range of automation tasks, and lots of people are glad to use it.  Others don’t care for it.  Fortunately for its detractors, there’s other options out there, and here I’m going to highlight my current favorite.

Why c++ and Qt?

I started out writing automation code in LabView.  Some people like its signal-oriented approach, but I prefer a procedural approach.  While it worked fine for smaller projects, I don’t think it scales well to larger ones.  In graduate school I joined a group where a lot of existing code was written in c with LabWindows/CVI.  This was a lot closer to my liking, and while I hadn’t previously worked in c, I quickly picked it up and switched over.  In a lot of ways, LabWindows/CVI keeps the things I like about LabView (easy GUI development, lots of existing drivers) while getting rid of the things I don’t like (dragging wires around and millions of windows for sub-vi’s).  It’s not perfect — it’s not very portable, GUI development can involve a lot of boilerplate code, and it costs a lot of money.  Lastly, c is not MatLab — even simple data manipulation can be annoying to implement.

The equipment drivers we call from LabWindows could be called in a lot of different ways, and the only value I was getting out of LabWindows was its mediocre GUI design tools.  I started looking around for an alternative that would work with a language that I already knew, and while there’s a few options, I settled on Qt and c++.  Qt comes with a number of advantages:

  • It’s available under a free license for noncommercial use, which means you can use the same framework at work and for projects at home.  Everyone needs a blender you can operate over the internet after all.
  • Qt Creator (specifically Qt Designer) makes it easy to put together UI’s.  A layout tool is not always necessary, but sometimes you want to move a bunch of UI components around without needing to fiddle with a bunch of code for layout rules.
  • Qt Core and other modules have lots of helpful things for automation that you might otherwise have to patch together in c++ — dynamic vectors and network tools for example.
  • QCustomPlot allows you to generate pretty much any plot you could want, and the quality and customization are high enough that they could easily be turned into figures in a paper.
  • Lots of people use it, even for big-kid projects like VLC Media Player, which makes finding answers to common issues relatively easy.

Why wouldn’t you want to use it?

  • You would rather code in something higher-level than c++ (although Qt does have python bindings).  Currently 1/3rd of our research group uses Qt, 1/3rd uses python with PyGTK, and 1/3rd uses LabWindows/CVI.
  • The Qt toolchain with its meta object compiler can seem like overkill for simple projects, and lead to more complicated builds and relatively large file sizes.  Also Qt itself is huge.
  • Qt can let you develop programs that are largely platform independent, but that doesn’t help if you have equipment that can only be controlled through an ActiveX driver or hardware that only works with Windows XP (shudder).
  • You like wires (the digital kind).

Just my two cents — LabView works well for a lot of people and in a lot of situations, but it’s not the only option.  If anyone thinks I’ve missed something or otherwise wants to weigh in, I would be glad to hear from you via email.

Comments are closed.