So many things to write about...
There are so many topics I could start this blog with...
- Discussing the latest instrument control features of LabVIEW 8.0 and 8.20.
- Building test systems--especially hybrid systems combining instruments from multiple vendors, all using different bus technologies.
- A look at new additions to your measurement toolboxes, such as PXI Express, LXI, and synthetic instruments
And the list goes on and on. But I feel there's some groundwork I need to lay, for those of you who may be somewhat newer to LabVIEW Measurements.
So many ways to talk to instruments...
One of the good things about LabVIEW is that it is a very rich environment. One of the bad things about LabVIEW is that it is a very rich environment. We give you several different ways to talk to 3rd party instrumentation, and it's sometimes hard to sort out all the options. In this article, I'll explain some of the options and give advice for different situations.
As I'm sure most of you understand, test programs talk to instruments using low-level commands peculiar to each instrument. Many instruments are programmed through an ASCII language called SCPI. Some are programmed by writing to registers mapped into a program's address space. Some use proprietary protocols.
Fortunately, if you can find out the language that an instrument speaks, you can talk to it from LabVIEW. Vendors usually include their particular command set as part of an instrument's documentation. Most GPIB instrumentation uses SCPI, so I'll use that as an example.
LabVIEW 7.0 introduced a feature called Instrument I/O Assistant (IIOA), which makes it easy to create and test VIs that send commands to and read responses from instruments. You can place an IIOA block on your diagram, select the instrument you want to send a command to, and type in the command--e.g., "CONF:VOLT:AC" might be the SCPI command to set a multimeter to measure AC volts. Test it out, click OK, and you have your first instrument control VI.
VISA: A software standard for instrument communications
When I first started working on LabVIEW, we had two sets of icons for instrument communications... the GPIB VIs and the Serial VIs. Back then, most instrumentation had one or the other kind of port on the back of it. These days, it's not uncommon for an instrument to also have a USB port or an Ethernet port. If you throw in buses found inside PCs, we've also seen NuBus, AT-bus, EISA-bus, PCI, PXI, PCI Express, PXI Express, VME, VXI...
But, we didn't want to add a new set of icons to LabVIEW every time a new bus technology came out. In the early 1990's, National Instruments and other vendors (part of the VXI Plug and Play Systems Alliance) created VISA (Virtual Instrument Software Architecture).
The full story of VISA is best left for others, but suffice it to say that it lets us have one set of icons in LabVIEW that knows how to talk to a bunch of different buses and instruments.
We still have GPIB functions in LabVIEW. They're useful for legacy applications, and they're easier to use if you're trying to do advanced, low-level control of GPIB. But for most instrument control applications, VISA is a better approach.
Interestingly, we (more specifically, I) removed the older serial functions from LabVIEW in version 7.0. You can still do RS-232/RS-422 serial I/O in LabVIEW; you just use VISA to do this. The rationale for this decision could be another lengthy post. In short, NI's VISA implemented serial I/O faster and better than the old code, so we made the switch. But we still hear complaints about my decision.
Instrument Drivers make programming easier
An "instrument driver" is a collection of VIs that provide a higher-level interface to programming an instrument. Instead of having to remember several low-level commands to configure a multimeter or oscilloscope, you can use a single high-level function called "Configure Measurement".
Instrument drivers come in a lot of different flavors. LabVIEW Plug and Play, IVI-C, IVI-COM, VXIpnp, etc. I'll sort all those out in a future post.
The main point I want to make here is that using an instrument driver can save you a lot of time. If you can find an instrument driver for your instrument, you're almost always better off using it than using low-level SCPI commands.
LabVIEW 8 adds an Instrument Driver Finder which can help you search for instrument drivers. You can also visit IDNet, an instrument driver repository that contains drivers for thousands of instruments from various vendors.
Look for more on instrument drivers in a future post.
Post your comments. What do you want me to write about?
6 comments:
"You can still do RS-232/RS-422 serial I/O in LabVIEW; you just use VISA to do this. The rationale for this decision could be another lengthy post."
I looked quickly through the posts and I think this is the sentence I was refering to about "leaving it for another time". I understand the reasoning behind this - less code to maintain, easier porting between TCP/serial/etc., performance (apparently), but what is inconvenient about these things is their distribution. VISA, as far as I remember, is reasonable but DAQmx requires installing the 400 and something MB driver for every computer where I want to install an application using it? Aren't there run-times for these things?
BTW, it was worth reading this just to learn about the I/O assistant. With all the stuff in the tools menu I just never noticed it and might be helpful.
Thanks for the note. The size of the VISA runtime was something I personally agonized over when we were deciding to kill "serpdrv". The fact that VISA had a runtime certainly helped the situation, and I put pressure on our VISA group to make it smaller. It's still non-zero, though.
I'm not sure about the DAQmx runtime situation. You make a good point. I'll try to find out more and talk about these issues in a future post.
Deployment is a pretty complex issue. We made some significant strides in LabVIEW 8, but we're not done yet.
Just to make it clear - the VISA VIs themselves are significantly better than the old ones in that they use standard wiring schemes and even its distribution is as simple as setting a checkbox in the AB (at least in 7.0). I read Kennon's valiant attempts of explaining the new system to the users, but I haven't used it yet myself.
I just ran into the need for using and distributing DAQmx for the first time recently, and as far as I understood from the documentation, there is no run-time. Maybe I understood incorrectly?
BTW - I looked now and I realized why I did not find the IIOA - it's not in the Tools menu! Instead, it's an express VI, which I simply ignored.
P.S. It would also be nice if you can set the blog to send alerts to users who input their emails when there are responses to posts they commented on.
And one last P.P.S - Congratulations again.
I don't see a way to change the email subscription to report comments. Sorry.
Could you write about NI's work in synthetic instruments (h/w not just s/w i.e. Virtual Inst.)? Seems like Agilent is pretty serious and NI is catching on to SIs potential. Just heard about NI's venture with BAE.
FYI,
http://www.reed-electronics.com/tmworld/index.asp?layout=articlePrint&articleID=CA385792
http://www.mwrf.com/Articles/ArticleID/10906/10906.html
It's interesting that you say that NI is only now "catching on to SI's potential", since Synthetic Instrumentation is equivalent to (or perhaps more properly, a subset of) Virtual Instrumentation. We've been talking about Virtual Instrumentation for years.
I first learned about SIs by listening to Chris Nadovich, who wrote the book Synthetic Instruments. His definition is a little too pure for me. The way I understand his view, a synthetic instrument test system can't tolerate a traditional instrument such as an oscilloscope or multimeter, since those should be derived from a digitizer and math. I think real SI test systems are likely to be a combination of synthetic and traditional instrumentation.
More about Synthetic Instrumentation sounds like a good future topic. Thanks for the suggestion.
In the meantime, here are a couple of links to other articles...
Creating a Synthetic Instrument with Virtual Instrumentation Technology
Cabled PCI Express as a Standard Interface for Virtual and Synthetic Instruments
Post a Comment