How do I suppress error messages from displaying in GPIB calls?

[sbus]

I use GPIB Read and GPIB Write to access instruments on the bus. Both vi's supply status on error out.

I sometimes call these routines in situations where I do NOT want to reap error status, so I leave the error out terminal unconnected.

Here's the problem: I get error popups that display the GPIB errors (when there are some)  even though I don't connect the error out terminals to simple error or general error.

How can I suppress the error messages??? I do NOT want them to display...

As always, thanks in advance for the assist!!!

[Dennis_Knutson]

Not sure why you would not want to handle errors and I'm not sure why you are using the GPIB functions instead of VISA but with unwired error connections, you will get pop-up messages if you have automatic error handling turned on. Disable it at Tools>Options>Block Diagram.

You might want to think about a better error handling technique than just ignoring them.

[TroyK]

By default, automatic error handling is switched on for all vis.
When any vi produces an error that isn't wired into something to handle it, LabVIEW will pop up a default error window.

There are a number of ways to stop the error windows from popping up:

1. turn off automatic error handling for the vi as follows... (Note: this is NOT recommended)
Right click on the VI icon in the block diagram and select 'VI properties'
Select the 'Execution' category and uncheck 'Enable automatic error handling' (This will disable automatic error handling for just this vi.)

2. To ignore ALL errors from a particular vi, wire a general error handler vi to it's error out terminal and wire a 'no dialog' constant into the 'type of dialog' input terminal.

3. Wire a general error handler vi to the vi's error out terminal and set 'exception action' to 'cancel error on match'
      and the 'exception code' to the specific code you want to ignore. (recommended, if you still want to ignore the error)



Looks like Dennis beat me to it with another way to disable the error dialogs, but as he said, the errors should be handled properly.


Message Edited by Troy K on 04-01-2008 12:12 PM

Message Edited by Troy K on 04-01-2008 12:13 PM

[sbus]

PROBLEM SOLVED.

Thanks gentlemen. But... now I have to defend myself!

1. I have both old non-488.2 and newer 488.2 instruments on the same bus. When I send *IDN? to the old instruments, they generate errors. When I send model-specific (non 488.2) commands to the newer stuff, they sometimes error. I have to 'search' the bus and identify specific instruments (by mfg/model) that I'm looking for; I don't know what address they're at. So I go thru a loop (the index is the GPIB address) and for each address I try the old-style probe; if it fails, the new style; if neither succeeds, no one is home at that address. The problem is that in cases where I try the wrong probe for the device first, it frequent gets 'trapped' in the input buffer of that device causing it to incorrectly respond to its correct probe when I finally get to it. So I have to clear the device before sending it the probe to make sure its listening. Can't use *CLR since many devices don't recognize it; and since I can't send a command (yet) because the device is screwed up. So.... I figured out what I have to do to get the devices listening. The NEAT-3xx controllers are happy *after* they receive a null command with a LF (EOS) character - but they generate errors while processing the digital enema just described. The HP spectrum analyzers I use work fine when they get *IDN?, but generate an error on the bus when they receive the probe designed to get the NEAT controller to respond. So what I do is always send an EOS character first to each address before each probe - and then issue a GPIB read. I ignore the errors generated, and the data returned. Then when I probe, I always get a good response (if the probe type matches the device!) instead of an artifact from the garbage the instrument had to listen to. It's like drinking a beer after your wife calls you and nags - it clears your head and makes you ready to move forward. So now you know why sometimes I wanna ignore errors, but thanks for asking.

2. Why don't I use VISA? Well, find me a VISA driver for the NEAT-3xx family of controllers, and I will... I use raw GPIB reads/writes (and nothing else) in my 'scan the bus and probe each address' loop described above. I use raw GPIB commands for the NEAT controllers, and VISA for the HP. You guys designed this stuff, not me... What I don't know (and what you might help me with) is whether there's a 'raw' interface that allows you to talk to instruments using VISA calls when there is NOT a VISA driver for the device... kinda like "I wanna use the GPIB read/write, but use the VISA interface so all my code looks the same" deal...

Thanks again!

[Dennis_Knutson]

Personally, I did not design anything that you are using. I think I would have remembered that.

The 'raw' interface for VISA is the VISA functions. Look at the code of a driver and you will see a lot of VISA Writes and VISA Reads. These are equivalent to GPIB Write and GPIB Read.