Recently, I ran across Data Wrangler, a web-based tool for cleaning, re-formatting and re-shaping data. The demo video is worth checking out: it shows how one can interactively automate the otherwise tedious task of transforming data into a more useful shape. With live previews of actions, as well as a feature that exports the actions performed thus far as a script, this seems like a tool that belongs in every scientist’s toolbox.
(Note: documentation of the app can be found elsewhere).
VI reentrancy is a relatively basic concept in LabVIEW. While a VI can normally only be active ‘once’ (just like a physical instrument: there’s only one of it), reentrancy allows you to have LabVIEW create multiple copies that can run in parallel. Not understanding this concept, or forgetting about it, can get you some nasty performance issues — like I found out recently when getting bitten by some code I wrote a long time ago.
There’s one particular pitfall in LabVIEW programming that can quickly turn your experience into a very nasty one.
Do you encounter one or more of the following symptoms?
If so, you’re likely having cross-linking issues. Follow these instructions to resolve them.
When you see these dialogs popping up unexpectedly, you’re likely having cross-linking issues in LabVIEW. Read this post to learn how to fix these.
If you come from the world of text-based programming languages, some of the first questions you will ask when encountering LabVIEW are: where’s the source code? And: where’s the compiler?
LabVIEW’s unique paradigm makes the answers to those questions somewhat less straightforward.
Sometimes, it’s the nice little details that positively catch your attention when using a piece of software. Last week, I noticed that LabVIEW is quite intelligent about removing an In Place Element Structure from your Block Diagram:
Select an In Place Element Structure, open the right-click context menu, and choose “Remove In Place Element Structure”. Voilà!
Nice, eh?
Now back to being annoyed at LabVIEW’s complete lack of any keyboard shortcuts in its dialogs…
In the previous parts of this small series, we’ve covered the technical aspects of making VI icons: how to use the Icon Editor, and how to be more efficient by using templates and glyphs. But this hasn’t really taught us anything about what exactly makes a VI icon great — for all we know, we might have become more efficient at making awful icons.
So what’s the secret sauce?
In the previous part of this series, we looked at an efficient workflow for quickly creating great-looking VI icons. An important part of this workflow was assembling an icon from the pre-made templates and glyphs that are provided with LabVIEW.
But what do you do if you desperately need to have a rainbow in a bunch of your VI icons? Draw them by hand each time?
Fortunately, you don’t have to: extending the template and glyph libraries is easy. In this third part of the series, I’ll show you how to add your own creations to the libraries. Or, if your inner pixel artist feels like taking a break, where you can get more stock collections of glyphs.
Let’s look at a simple workflow for creating great VI icons, using LabVIEW’s built-in Icon Editor. Using these simple tips, creating an icon for a VI shouldn’t take more than a minute or two.
Note: this tutorial assumes you’re using LabVIEW 2009 or higher.
Amongst the many flame wars in the programmers’ universe, the ones about naming conventions rank highly. Why? Part of the answer is that naming things right is important. Another part is that it’s rather difficult.
In LabVIEW, we face the even more challenging task of distilling a VI’s functionality into an icon of 32×32 pixels. The importance of this is obvious from the above snippet, taken from the project I’m currently working on. What code would you prefer to work with?
If your answer is (3), then follow me on this little 4-part tutorial on creating great icons for your VIs!
Part 2: Using the Icon Editor Effectively
Part 3: Working With Glyphs and Templates
Part 4: What Makes a Great Icon?
For the purpose it was originally created for, LabVIEW undeniably shines. It is very easy to create a small data-flow application that interacts with the world just like a physical electronic instrument would — at just a fraction of the costs. The built-in user interface controls reflect this ‘virtual instrument’ (VI) paradigm: on LabVIEW’s palettes, you’ll find buttons, switches, levers and knobs.
But in the decades since its inception, LabVIEW’s scope has expanded, to the point where it is arguably considered a full-grown programming environment. Developers have used it to create a wide range of applications, including web servers, a remake of a popular game involving pigs and cranky poultry, and even controllers for nuclear power plants. Surely, with projects like these, LabVIEW can be considered a mature and useful tool (1).
But with this increasing breadth of applications, LabVIEW’s original VI paradigm has been stretched significantly. Might it be overstretched? In this series, we’ll take a look at a number of areas in which this may be the case — and see how LabVIEW stacks up to other programming languages. In this first article: custom user interfaces.
Science & Wires 