String/number conversions in LabVIEW

My LabVIEW program is mostly working after a long week. All in all, the design and implementation of the program went well, since it's now working. However, the implementation is very rough and I know that my LabVIEW programming skills can be improved a lot. In particular, I need to decide when global variables are necessary to use and when they're not, make better use of error handling and other forms of feedback for moving through sequences (beyond just using the Wait function for a long time), and make better use of subVI's.

One annoying aspect of LabVIEW that I've learned to appreciate through all of this is its string/number conversions and data types. One 12-hour measurement was wasted because I thought "Convert to Decimal Number" meant that I could take a string such as "42.5" and convert it to a number with decimal places, like 42.5. Unfortunately, inputting "42.5" into this function produces 42 at the output. A quick get-around is to use "Convert to Exponential Number," but I think I'll want to use "Format Value" and supply a format string to ensure that I'm converting correctly.

Here is a list of string/number conversion functions and their descriptions. I will be using this list, as well as the list of numeric data types, more frequently since I find them unintuitive.

There's now an academic Stack Exchange

This morning I was pleased to come across Academia Stack Exchange. Stack Exchange is a network of web forums for collecting crowd-sourced answers to questions. I believe that it originally came from Stack Overflow, a Q&A web forum for programming, and has expanded since.

I hope that such a site will provide academics answers to questions that they just can't find in other places. Academia can be frustrating because there's a large disconnect between people at different levels: post-docs don't understand graduate students, graduate students don't understand faculty, and faculty are just plain space cadets... just kidding about that last one :)

In all seriousness though, I'm glad to see such a support site and I hope to make good use of it.

More on LabVIEW, this time with RS232

My LabVIEW adventures continued today (yes, being close to graduation means you work on US national holidays). I began designing and implementing the pieces of my LabVIEW program for controlling the experimental setup that I discussed briefly in my last post.

After getting all the hardware pieces independently working with LabVIEW example VI's, I started working on some custom VI's that did exactly what I needed each piece of hardware to do. My idea is that I will use each custom subVI in a large control script. This control script should contain the commands to pass to each subVI and the order in which they'll be executed. All the data from the SR400 Photon Counter should be saved at each step, along with the current state of all the hardware pieces.

I started working on controlling the laser I have connected to a RS232 port. This should have been simple, but I my first bit of code simply didn't do anything. If I told the laser to turn off, it wouldn't. To mock me, the example "Basic Serial Write and Read.vi" that's included with the LabVIEW base DID work.

After an hour or two of playing around, I discovered that the strings I was passing to the laser in my custom VI did not contain the line feed ASCII character "\n" that is required to mark the end of a command, even though I included it in the string. The strings were stored in a drop down menu of common commands I frequently use. The line feed character was also included in the string I entered into the example VI and this was actually sent to the laser, which is why it worked.

I ended up fixing the situation using the information on this NI community page. It's a bit strange that it requires this much work to place a line feed at the end of a string, but oh well, it works.

I also ran into some issues with having the commands from the laser echoed back to me when I read the data from its buffer with a VISA read VI. I didn't want the echoes, I wanted the information that each command should return. I fixed this by doing to VISA reads. Apparently, LabVIEW's VISA read only reads until the carriage return/line feed and leaves the rest of the information in the read buffer.

Though I ran into some bumps, I'm very grateful for the help I've been able to find on the NI support and community sites. Without them I probably would still be stuck.

Learning how to operate GPIB buses with Labview

I'm currently engaged in a project which requires me to coordinate four separate pieces of hardware (two lasers, a stepper motor, and a photon counter). As is the case with all good experimental scientists educated in the 2000's, my first thought was to turn to Labview for making this happen.

However, I'm not terribly excited about this. I haven't actually programmed in Labview since my REU studies at the University of Colorado, Boulder, during which I made a visible grating-based spectrometer for working with lasers in vacuum systems. Since then, I've somehow managed to perform ALL of my experiments without automation and by writing down results in my lab notebook. I know that automated data acquisition can make my life easier, but my experiments have been relatively simple until now and learning Labview would have taken too much time.

Furthermore, I'm much more interested in using open-source software whenever I can (PyVISA is one such Python package which might help me). I don't ever want to be dependent upon possessing some company's latest toolbox or software version to do my research.

Despite all of this, I'm under a time-crunch with my current project and Labview is arguably the de facto standard for automation and measurement, so... here I go!

I first installed Labview 2012 on a Windows 7 system. There really wasn't any problem here; the software took a while to install, but it wasn't a big deal.

Following this, I quickly discovered that I needed to install the DAQmx software to get nearly all of my lab's previous VI's working. This wasn't a big deal either (it's free if you're registered with National Instruments), but I wonder why something that is apparently so important to Labview is left out of the installation. Some slight perusing on the NI community pages led me to find that since the 2012 version, NI changed up what is included from DAQmx with the base Labview install. I found an old repository for these now "missing" VI's, but it was pretty confusing to navigate.

Now, onto the GPIB control. I found an old NI PCI-GPIB controller card in one of our lab computers, removed it, and inserted it into the computer that I'm currently using. Windows recognized the card but didn't know what to do with it and Labview didn't know it existed. Fortunately, I found and downloaded the NI-488.2 driver, version 3.1.1 from NI's website and installed it without a hitch. After reboot, the card was recognized in NI's Measurement and Automation Explorer (MAX).

Now, I admit that getting the first device, a Stanford Research SR400 Photon Counter, was a breeze. I ran a GPIB cable from the PCI card to the SR400, and another one from the SR400 to my motion controller (of the two lasers, one is controlled via USB and the other via RS232). Both GPIB devices were recognized in MAX. This is what my MAX window looked like after clicking "Scan for Instruments" while having PCI-GPIB "GPIB0" selected in the left-most itemized list:

In this picture I had already renamed the devices in MAX. I could tell which was which by turning one off and rescanning. Most of this information is found on an NI community website: http://www.ni.com/gettingstarted/setuphardware/instrumentcontrol/gpibconnect.htm

One final note: after reading some discussions on the SR400, I found that this particular device is tricky to work with because it's so old. Fortunately, on this same discussion I found custom VI's for working with it from Paul Henning which have worked like a charm.

So far, I'm quite happy with how easy it was to get to this point. This was facilitated by software that worked seamlessly at finding the hardware and a strong user-base for getting specific hardware to work. I still anticipate having some difficulty with the actual programming and getting the instruments to work in sync, but that can't be helped so much.

Kudos to you, NI.

Metamaterials for heat

There's a really cool experiment described in a recent PRL and summarized here about creating a metamaterial for cloaking objects from heat flow.

What connections to metamaterials for light can be drawn? The transport of heat is governed by a diffusion equation, which is very different from the wave equation and Maxwell's equations for governing light transport.

However, the diffusion equation can apply to light transport in disordered materials (see Ishimaru or van Rossum and Nieuwenhuizen). Is there some way, then to cloak objects in randomly scattering media from light?

The trouble with this thought is that one would have to add structure to a random material, and the only way I can think of doing this would be to create large-scale structures from a material with small-scale disorder.

Becoming a scientist

I'm not sure if you can read this without a subscription to Nature Jobs, but if you can read it, please do so.

This is an essay written by a post-doctoral fellow in neuroscience named Thomas Schofield. He was tragically killed in a bus accident in 2010.

This brief essay on becoming a scientist is very insightful and may help others to shed some misconceptions about a career in science.

Cell arrays for collecting a variable number of output arguments in Matlab

I learned some new tricks in Matlab today for dealing with functions that return a variable number of output arguments. I honestly think that there's something less-than-ideal about Matlab if I need to employ tricks to get my code working, but that's an entirely different topic...

If, for some reason, I have a function that returns a comma-separated list of arguments, I would normally write them explicitly like this:

[output1, output2, output3] = someFunction(input1, input2);

This means that myFunction would return three arguments and store them in output1, output2, and output3.

However, I recently wrote some code in which I could not say a priori how many output arguments I was going to have. The number of outputs depended on one of my input arguments, which happened to be a function handle.

To explain what I learned, consider a function of one input called myFunction. The input argument is a function handle @myHandle. The number of output arguments that myFunction returns is the same as the function linked to @myHandle and can change depending on my implementation of @myHandle. The following code first finds the number of outputs of @myHandle, then saves the outputs from myFunction into a cell array:

numArgsOut = nargout(@myHandle);
[myOutputs{1:numArgsOut}] = myFunction(@myHandle);

Tricky, but effective. This post on Stack Overflow helped me.

Today I also learned that I can insert a tilde into a comma-separated list of output variables if I don't want to save a particular variable. For example, if I don't care about output2 from someFunction above, but I do want to keep output1 and output3, I can type (in Matlab 2009 and later)

[output1, ~, output3] = someFunction(input1, input2);

Hoozah!