Experience with Keithley 2701E?

[Olli]

Hello,
I'm actually programming instrument setting and data communication of a Keithley 2701E using LabVIEW. The LabVIEW programming is not a problem, but I observed some peculiar behavior af the instrument (O.K. it's not a NI product ;-).
Is there anybody who uses this instrument, too?
Have a nice day,
Olli

[Albert.Geven]

Hi Olli

We use this instrument, I did not see many problems but saw some improvements in the driver.
What version of LabVIEW and driver are you using?

I proposed some changes to the driver that made the initialize clearer (less wrong error messages) and
proposed a better reading of data and interpretation of data.

Albert

[Olli]

Hello Albert,
actually I'm using LabVIEW 7.1. I tried the latest LabVIEW drivers from Keithley for the 2701E only to learn a bit more about the programming sequence. For specific instrument's setting I'm send a list of commands or a query using the TCPIP communication VIs (open, write , read and close). This part works very well. Reading out the buffer of two identical set 2701E devices are one problem. One device is sending only once the latest readings and then nothing until the next data are stored. Once the buffer is full, it sends always all data with the oldest overwritten (like a ringbuffer). The second sends always all data. No matter if automatic buffer clearing is en- or disabled. The query of free buffer capacities (Trace:free?) gives always the same number of data stored in the buffers of both devices. I reported this problem already to Keithley and am waiting for their reply.
The second problem is currently solved with a compromise: Timer triggered data reading of 6 synchroneously (s. in the range of about 100 Milliseconds) started devices drifts out of synchroneousity just after a few hours (about 10 seconds after 12 hours). The explication for this is quite simple: the small drift in the timer counter is accumultated during the measurement duration. One solution with regards of loosing the 2701E's indepency would be the use of an external trigger signal.
Are you doing also longterm monitoring with multiple devices? Did you have any problems with buffer reading?
Greetings from Luxembourg,
Olli

[Albert.Geven]

Hi Olli

I always try to synchronise in hardware. Two independent timers always drift.
In this case I would trigger one with the bus and the other with the trigger out of the first.
Dependend on their location  (close to each other or not). Otherwise I would try to find out if I could trigger them both fast after each other.

I did not use the ethernet (i suppose you used visa and not the old tcp/ip routines)

The software is quite new from keithley and I guess that ethernet is weakest.

I did not see this but was using only one instrument at the same time.

[Olli]

Hello Albert,
concerning the ethernet communication: no, I'm using the old labVIEW TCP functions with the 2701 devices. I also tried the same commands and queries with VISA through both interfaces RS232 and TCPIP socket. The communication part always works fine. But RS232 is not applicable because of the number of devices and the distributed location (therefore the choice of ethernet communication).
Besides there are also three fieldpoint systems which are all synchronised with a timeserver. The fieldpoint system which is closest to the Keithleys could trigger them with a digital output signal.

Connection of the trigger out of one Keithley  to the other is not so good, because then they trigger sequencially not synchroneously.

I'll try also to quantify the synchroneousity of the software trigger send by the Fieldpoints through the ethernet. The measurement devices and controller PXI are connected through a VPN (virtual private network), which should be free of unwanted data traffic. If the complete measurement system's synchroneousity will remain in the range of up to 1 second, this would be sufficient for or application.

The buffered data are still not handled by the instruments as written in the manual. Until this is solved I'm going to clear and reconfigure the buffers after each reading (O.K. it's not elegant, but there is enough time between two scans).