Checking whether a GPIB device is switched on

[AndyI]

Hi all.  Pretty new to LabVIEW, so be understanding!  I've searched and searched for a solution for what has to be a very common problem so I must be mssing something very simple.

I'm writing a vi to control up to three GPIB units.  The problem is that they will not be switched on at all times, and people steal them for other measurement rigs (sometimes they even give them back, occasionally with their GPIB address unaltered).

The thing is, I don't want the vi user to rely on all the units being there, with the correct GPIB address specified, and switched on.

I know that LabVIEW will give me an error 14, halting the execution, if it doesn't see a unit at a given address, but this seems amazingly crude and I'd much rather handle the error in other ways (disable the measurement part, give an error message etc - details to be decided!).

So.... how do I check that there's a powered-up GPIB device at the specific address without sending a command that triggers the very program error (such as error 14) that I'm trying to avoid?

All works fine when all units are powered up and correctly addressed.

I am very vague about what VISA is (or whether it's even relevant to this question), and haven't got into it (and won't if I don't have to).  I just use "GPIB write" and "GPIB read" functions.  I'd appreciate a minimum of jargon, please.

Thanks all!

Andy

[Spectre_Dave]

You could use VISA Find Resource to determine what instrument is connected at which address.

It is in the VISA Advanced palette.

[AndyI]

Thanks Spectre Dave, but I can't seem to find what I need from that.

Using the search expression "?*", I get the following output irrespective of whether the unit is switched on or off (I'm hoping to see an instrument at GPIB address 15):

Search Mode 0

ASRL1::INSTR

ASRL3::INSTR

ASRL4::INSTR

ASRL6::INSTR

and so on

Search Modes 2 and 4

COM1

COM3

COM10

COM6

etc

Search Mode 3

LPT1

COM1

COM3

COM6

etc

Does that help me?  If so, how?

Or any other thoughts?

[Dennis_Knutson]

Using the VISA Find Resources will not help you unless you first do a search for instruments in MAX. You can do this in your code. Turn on NI-Spy, do a search in MAX, and copy the actions taken into your program.

You also have some serious misconceptions. First, an error does not halt execution unless you have programmed it to do so or you have selected that option. You can easily get the error code from the cluster and take whatever action you want - branch to a different state, open a dialog, etc. Doing a *IDN? at the beginning is perfectly acceptable and I don't see why you think it crude. What is crude is improper error handling.

Since you are using the low level GPIB functions, you are not using an NI Instrument driver. Did you attempt to find one for your instruments? VISA is a high level API that abstracts the actual hardware being used. It has been the established standard for instrument communication for many years. By using VISA, you have portable code that can be used with little or no modification with GPIB, serial, USB, Ethernet, PCI, and PXI. It also allows you to use GPIB controllers from other vendors. It is something you should really be using.

[AndyI]

Thanks Dennis.  I'll look into Visa, but as I am very close to a working system in low-level GPIB and I'm taking valuable weeks out of a heavy work schedule to get this up, I'm not very keen!  My initial impression is that the VISA drivers do exactly what my code does, but in a 'black box' format.  I have a reasonably extensive programming background, and I like to be low-level as I'm a bit of a control freak.  But please, let's not get into a discussion about the pros and cons of VISA - I will happily accept your advice on face value.  For NEXT time.

Just to clarify how misconceived my misconceptions are - perhaps I chose the wrong word, but if you try to do a "GPIB write" to an instrument which you've recently powered off will cause the program to suspend/halt/pause and give an error 14.  I've seen it, so it's real.  If as I think you're saying, the halt/pause generates a useable error code from the "GPIB write" function, which can be used to handle the error and get the program resumed, I don't know how to use that error info in that way, and would appreciate help in doing so (I do understand how to unbundle the cluster to get at the goodies in an error wire).

Clarifying again - 'crude' is having this type of program halt or pause with loss of function when in an ideal world a simple prompt to the user will get it back on track.  In other words, my error handling is crude, yes, and I wanted to know how to un-crude it - I wasn't trying to trash-talk LabVIEW or "?IDN*".  I just have no idea how to do "?IDN*" to work in LabVIEW (I've done it OK in MAX, but I don't want it done in MAX here, I want it done by a LabVIEW function - I know where my instruments SHOULD be).

So, I can either wait for the error 14 and use some generated error to divert the execution, or I can scan for attached GPIB devices and avoid the error in the first place.  I'd prefer the latter if possible.  So - I'd very much appreciate simplified help on one of the options.  Thanks!

[Dennis_Knutson · Accepted solution]

You need to turn off automatic error handling (Tools>Options>Block Diagram) and wire up the error in/out clusters. An Unbundle by Name will get you the error code.

Below is a simple error handler that pops up a message. If this error happens, I would set the next state (you are using a state machine, aren't you?) to retest the connection.

 

You should probably take the LabVIEW tutorial to get a better understanding of the error in/out cluster.

[AndyI]

Thanks Dennis - that's absolutely brilliant!  I can do all sorts with that.

Much appreciated.