not executed Commands from Testprograms written in Labview communicating over GPIB

[sly21]

Hello

Sometimes I have the problem that the commands sent from testprograms written in Labview aren't executed from the devices

(for example a counter or a power supply).

An extension of the the wait time between Write and Read couldn't solve the problem (We use VISA-VIs or the Manufacturers-VIs).

First workaround is to send the command again.

Somebody else ever had the same problems to deal with? What did you do?

Many thanks

Best Regards

Silvio

[Pixar]

Hi

So what kind of devices are you using ? LabVIEW version ?

Did you still contact de third party device manufacturer ?

Kind regards

[billko]

Usually stuff like this is caused by incomplete understanding of communications using the GPIB bus (either by the programmer OR by the supplier of the drivers - the latter reason being why I almost always write my own drivers).

Many times, an instrument fails to respond in what we considre a "timely" manner - a prime example is an instrument that takes several seconds to complete a measurement.  Many times, instruments don't queue commands, so if you send a command to an instrument while it is still processing a previous command, it won't be aware of the command you just sent, and you will get a timeout.  In this case, it's best to make the VISA timeout something like 5000 ms and - if your instrument accepts the command - use *OPC? to turn your command into a query.  This way, your application always waits for a response - usually a "1" - from the instrument being commanded before sending the next command. 

Bill

[sly21]

Hi Bill

Fact is, that with the same kind of devices (for example a Agilent counter 53131) and the same test adapter, the same testprogram exe and the same DUT we see different results, that means:

I have tested everything on my computer and then transferred all the equipment in the test room and with some computers it works without any problems with others not (Installation on the computer is the same). We do not use always the same computer to test the same DUT.

Best Regards

Silvio

[sly21]

Oops, I forgot to post the LabVIEW Version we use

We have installed on the computers:

1. the Agilent IO Libraries

2. LabVIEW Runtime Engine 8.2.1 (because we still have programs written in LV 8.2.1 and we don't want to update them)

3. LabVIEW Runtime Engine 2010

The device we always use is the Agilent Data Acquisition/Switch Unit 34970A with measurement and switch modules.

Usually the communication to the computer goes over Agilent USB to GPIB converters 82357, but

we have some computer with a built-in GPIB card. Could that be a problem/difference?

Best Regards

Silvio

[Pixar]

Hi Silvio

So you are not using a LabVIEW development version but only a LabVIEW application (.exe) ?

Then you have to check if you have all the drivers installed like NI-488.2, NI-VISA etc.

If you don't have the source code (LabVIEW project or VI) it will be very hard to find the problem.

Kind regards

[Dennis_Knutson]

You've also added an extra level of complexity by using Agilent GPIB controllers. You have to make sure you add tulip support in order to use these with LabVIEW. I don't quite understand the decision when a controller from NI is the same price and you don't have to change anything in MAX.

[ben64]

---

@sly21 wrote:

Usually the communication to the computer goes over Agilent USB to GPIB converters 82357, but

we have some computer with a built-in GPIB card. Could that be a problem/difference?

---

Well, is there a pattern you can recognize like its working with the USB-GPIB and not with the built-in GPIB card?

Ben64

[sly21]

Hi everbody!

Yes, we have installed all drivers like NI-488.2, NI-VISA.

And, yes, tulip is set in MAX.

I'm not quite sure if it is a problem of the GPIB card or not. That's what I'm trying to find out.

Anybody ever had a problem like that?

Best Regards

Silvio

[Dennis_Knutson]

Can you attach your NI-Spy/NI-Trace file?