Controlling two Agilent E5810 LAN/GPIB Gateways with LabVIEW

[StefG]

Hi!

I've been using LabVIEW 6.1 to control two Keithley 2701 multimeter (Ethernet based) and a Yokogawa WT230 (GPIB based) via an Agilent E5810 LAN/GPIB gateway successfully via an Ethernet network for quite a while. Other than the odd lost Ethernet connection during start-up it has been a very reliable little system.

I now require to expand the system by one, potential two additional Yokogawa's, via two additional E5810, and that's when the problems started. Looking at just one additional Yokogawa for now (beacause I can't even get that to work), I've done the following:

1) Controls for the second Yokogawa were added to the LabVIEW program

2) VISA sessions for the Yokogawa's were set as follows : TCPIP::169.254.058.009::gpib1,11::INSTR for Yoko1, and TCPIP::169.254.058.010::gpib0,11::INSTR for Yoko2.

3) The program (including te Keithleys) works fine with just one Yoko activated. The new controls for the second Yoko work fine, too, as long as the first Yoko isn't activated.

4)You can even activate the first Yoko, start the measurement, stop, deactivate the first and activate the second Yoko, and start the measurement again - all working fine.

5) However, when I activate both Yoko's and start LabVIEW, the following happens:

a) Both Yoko's get initialised fine, no problems

b) The first Yoko doesn't start reading data

c) The second Yoko does read data fine, no problems

d) The Keithley's are fine, too (they don't seem to be affected at all, whatever I try with the Yoko's/E5810's)

e) When I press the 'stop' button in my program (not the 'stop' at the LabView menu) LabVIEW crashes.

d) When I press the 'stop' button of the LabVIEW menu, LabVIEW won't crash but when I start the measurement again the first Yoko won't initialise properly.

Looks to me that there is some sort of clash between the E5810's (as the Yoko's are GPIB-controlled) ... The system works without any problems if I connect the to Yoko's to the same E5810 via GPIB, no problem at all. However, this won't work in the field because too great distances between the Yoko's, so I'm runnig out of ideas now. Even tried to run two separate LabVIEW VI's in parallel, each with one Yoko, and excactly the same happens: The first Yoko stops reading as soon as the second is initialised, the second works fine until I hit 'stop' and LabVIEW crashes.

Any ideas out there?? Thanks for your help, greatly appreciated!!

[JonBowers]

Hi,

Have you tried just comunicating with the instruments through VISA in MAX. If you look at the block diagram for the VI's in the instrument driver you are using you should be able to see what commands you need to send. Try opening up two VISA sessions in MAX one to each instrument and see if you can recreate the same behaviour.

Regards

Jon Bowers
Applications Engineer
NIUK

[Anonymous]

The problem sounds like a race condition in the LabVIEW / NI VISA
TCP/IP implementation.

You may want to consider downloading the latest version of the Agilent
I/O Libraries Suite. It is available at
http://agilent.com/find/iosuite. You have a license to use it thanks
to your installation of the E5810A's. You will have to uninstall the
NI VISA I/O software if it is installed on your controller. This
shouldn't be a problem as it sounds like you are not using any
NI-specific I/O devices and LabVIEW is compatible with Agilent's
version of VISA.

Normally you could have both NI and Agilent I/O installed
simultaneously, but the E5810A is unique in that it is not supported in
this configuration.

Once the Agilent I/O Suite is installed you can continue to use the
same I/O addresses you are currently using or you can install the
E5810A's using the Agilent Connection Expert I/O configuration
software. Thereafter, the E5810A's will appear to be
directly-connected GPIB devices and you'll have I/O addresses that look
like:

GPIB0::11::INSTR
and
GPIB1::11::INSTR

for your two Yokogawa devices. The problem may still occur if it is
fundamental to NI's LabVIEW software as opposed to their I/O software.

Good Luck!

Dave
----
David Gladfelter
Software Engineer
Agilent Technologies

[SachaE]

Hi,

  After Revision K of the Agilent I/O libraries it is possible to install Agilent VISA (Agilent I/O Libraries) and NI-VISA side-by-side. The necessary instructions are included in the attached document.

NI-VISA will only function as the primary VISA and therefore only one visa32.dll can be registered at a time, rev K of the Agilent I/O libraries provides a second DLL named agvisa32.dll. Any program linked to this DLL will have access to Agilent’s VISA without requiring that Agilent VISA be primary. The same PC can run some programs with NI-VISA and other programs with Agilent VISA. PnP drivers will only work with the VISA that is primary.

Without having the hardware setup here to be able to investigate fully, we need to be systematic about how we approach this.

Are you using low level visa calls, or an instrument driver that was downloaded? (If downloaded, where from?)

From a look on google for the Agilent interface you're using, it appears that Agilent's E5810 only implements the VXI-11.3 Instrument functions,like Write,Read,SerialPoll and Clear,and does not implement the VXI-11.2 Interface functions. The E5810 does have some non-standard VXI-11commands that increase its interface capability however, which is probably why using the Agilent VISA would help the situation.

Since the E5810 is a single client only, it shouldn't really be getting confused since you have two separate IP addresses for it. This would leave me a little confused about the race condition, since the messages would be going to individual interfaces, and therefore isolated entirely from each other. It's not based on IVI, so there's no state cacheing going on, and it should simply be passing on the information. How have you got the network setup - are they connected via a switch, or a hub etc? If it's through a hub, and the first instrument/E5810 combination is blasting lots of data backwards and forwards, it could be causing the messages to not get through to the other instrument/E5810. It should happen eventually though.

The crash on stop is quite bizarre too though.

It might be plausible to try a different E5810, or even try a National Instruments ENET-GPIB - please call into the office on 01635 572400 for the UK, and talk to your internal sales engineer to discuss a loan of one of these.

Please let us know the results of your testing.

Thanks

Sacha Emery
National Instruments (UK)

[StefG]

Thanks Gents, it's working now!

However, I have cheated a bit and didn't do it properly as you guys suggested. Must confess that - as we are under a bit of time pressure here at the moment - I didn't dare to download any drivers or change the primary VISA's etc ... didn't want to upset the rest of the system, if you know what I mean.

As both Yoko's worked fine separately, I've re-written my program so that only only one E5180 connection is open at any one time. That obvioiusly means that the Yoko's now won't take readings in sync but as they are quite fast (app. 3 values/sec, much faster than the mulitpexer cards of the loggers), the scan rate for our test will be app. 30 sec, and we are looking at steady test conditions anyway, this is totally acceptable.

Certainly a quick fix for the near term only but it does what we want it to do. We'll get it sorted properly when we have a bit more time, I guess.

Thanks again,

Stefan

[f.grasdepot@laposte.net]

Hi,

could you tell us how you did ?

Is it possible to have time reproducibility in programming instruments
at different TCP/IP addresses with your solution ?

Faithfully ,

FG

[StefG]

Hi!

I have used a 'Sequence Structure' from the 'Structure' menu. The first frame of the sequence structure contains the initialisation for the first Yokogawa (via the E5180), triggers the Yokogawa to read the data, and closes the connection again. ( I've used standard Sub-VI's from Yokogawa for these tasks). The second frame does exactly the same for the second Yokogawa/E5810, and so on. As the initialisation of the Yokogawas is quite fast, and so are reading the data and closing the connection, we are able to get app. 3 readings/second from each Yokogawa. Obviously not simultaneous readings but close enough for our application. We do get the measurement time stamp for one Yokogawa, and pass it on through the sequence structure with a 'Sequence Local' (right-click on the frame of the structure) to the other Yokogawas. That way we get the same time stamp for the data files for each Yokogawa. Not 100% correct, I know but we are talking miliseconds here, which is as mentioned above acceptable for our application.

Hope the above makes sense,

Cheers