Firstly, I thought it’d be nice to show off the labs I work in at my placement (for the record: in no way was this me procrastinating). Our labs are quite small really, but since what were working on is usually only a few square centimetres (never more than 8 inches to a side) and completely non-volatile, its cozy without being cramped.
Ideally, we’d have a whiteboard – instead we use the windows as a space efficiency measure.
As you can see, shit really goes down when it’s time for calculations to get involved*.
One skill I’ve picked up while on my Masters placement at Rutherford Appleton is the use of a programming language called LabVIEW, and at this point you are allowed to groan at the special lengths I’ve gone to to make a double entendre in the title. In a way, though, what you see in the real lab is almost entirely run on the language. In this particular industry, rapidly developing programs which interface with lab equipment, then intuitively handle arrays of data and build images from them is… Well, we’d be left pretty high and dry if we couldn’t.
LabVIEW is a big language, but what I see as it’s primary use is for rapidly producing custom interfaces for lab equipment. An example;
This is the interface for a program I’ve been building to interface with a Time to Digital Converter (TDC) which allows us to make timing measurements on the picosecond scale (several thousands of those measurements a second, if I am to believe the manufacturer). The aim of this is ultimately to be able to do something called a jitter measurement, which is a measure of the inconsistency of the delay on the device’s output. That’s all kinda irrelevant at this point, though. All I wanted to show you was how LabVIEW looks underneath;
If Matlab is the definition of clean efficiency, then LabVIEW is the definition of spaghetti-logic. I know from experience that even with sensible practices, it’s difficult to follow someone else’s code – in fact since I have no formal training in the language, I imagine my code is somewhat unprofessional.
Still, I really like the language because its highly intuitive – to me, it feels a lot like playing with LEGO; once you understand the pieces, it’s just a matter of working out how to fit them together in a way that works. Much trial and error is involved, but then that makes it slightly more fun.
Having said that, programming in LabVIEW is an extremely odd experience. When programming in a text-based language, one has to go through several steps in order to make a functional program;
- Decide the idea of what it has to do
- Decide how that breaks down in terms of individual steps
- Convert those steps to steps that the program can do
- Convert THAT into actual code
- This code then gets compiled into a form that the machine can understand
However, with LabVIEW you have to stop doing that process – it removes several steps and you can almost think of it as a compiler for step 2;
- Decide the idea of what it has to do
- Decide how to break those down in terms of individual steps
- Put the blocks together in that manner
- (LabVIEW does the difficult bit)
- Even more profit!
I hope you can see how much better LabVIEW is in this respect!
I learned to program using Fortran, which is a very traditional (one might even say the traditional) language. The change to working with LabVIEW is somewhat liberating in comparison. I like it, and I hope that as I progress further into my career it becomes even more useful. In fact, over the 19th to 20th of November I attended the NI Days conference in London, where I hoped to solidify my basic knowledge of the language and its uses.
Of course, what actually happened was that I learned lots of new and exciting (but ultimately not directly useful) things. I don’t think that’s bad at all, but it wasn’t what I was expecting. I was hoping to hear a lot of specifics about best practice, but realistically that’s probably something I’d get from a course or something instead. What I did get introduced to was lots of new concepts that I’d never learned about before.
My favourite example of this is Object Oriented programming (“OO”). The language with which this was talked about was quite abstract (“object”, “method”, “class” and so on don’t have the everyday meaning), but what it seemed to boil down to was that an OO program starts by defining relationships between things, and then moves on to when to operate those relationships. It’s a nice concept and it might be useful for me one day.
One thing I did learn is some more about projects – specifically, how to use them. That would have been useful to know when I started writing the program that I showed you above, but then when I started that I was still very new to LabVIEW.
I’d definitely recommend NI Days to anybody looking to learn more about LabVIEW. It’s just a pity it’s only once a year…