Problem reading voltages in a DC sweep setup with DC current source 6221 and nanovoltmeter 2182

Dear Tektalk community,

I have a few technical questions concerning the connexion between the Keithley current source model 6221 and the Keithley nanovoltmeter 2182A. I am trying to interconnect both instruments to remotely perform an IV curve measurement of my DUT using a basic sweep function. I interconnect both instruments using an RS232 and Tlink cable, as explained in the manual, using a GPIB connector to connect the 6221 model and the computer. I am using python 2.7 in a Windows 10 computer, and the python library pyvisa to communicate with the instruments. Attached you’ll find the python code that I have written. 

In my code, I made sure that the Baud rate of both instruments is 19.2k using the following command:

SYSTem:COMMunicate:SERial:BAUD 19200

I also make sure that the instrument setup is the one I intend with the following instructions:

:SYST:COMM:SERIal:SEND "SYST:FFIL ON"

:OUTP:ISH OLOW

:outp:lte OFF

Following that first section of the code, the rest of it consists of a copy of the ‘DC current sweep and measure’ and ‘DC current meas. Data collect’ scripts from the KI6221 example software provided by Keithley. When I run the code, everything seems to work nicely, the 2182A resets and readjusts the voltage range (hence I know the communication between 6221 and 2182A works), the sweep is armed in 6221 and it is performed. However, when I use keithley.query('SYST:COMM:SERIal:SEND "TRAC:DATA?"') command, as suggested in the keithley example script, the 6221 always shows an ERROR -420, which from the manual it consists of an attempt to read data from an empty output queue. Would this mean that the buffer from 2182A is empty? Furthermore, I have realised that this error message is displayed every time I try to do a query from 2182A, e.g., keithley.query(':SYST:COMM:SERIal:SEND ":TRAC:POIN?"'). It looks to me that the information flow between 6221 and 2182A is for some reason unidirectional, only working from 6221 to 2182A but not the other way around. 

In order to overcome this issue, I decomposed the query instruction in two commands. First I write 'SYST:COMM:SERIal:SEND "TRAC:DATA?"' and next I read the state of the RS232 bus received by 6221 using keithley.query_ascii_values('SYST:COMM:SER:ENTer?', separator=','). Using these two commands, I manage to get the values of the voltage measured for a sweep provided that the number of points in the sweep is smaller than 16. This makes me believe that the 2182 can actually send information to 6221A, hence I don’t understand the nature of the ERROR -420 when using a query function as explained before.

Would you have any suggestions to solve this issue? I have been stuck with it for a few days now…

Let me know if more information is required. 

P/S: the commented lines in the code are the tests that I performed described above. The parameters in the ‘Input parameters section’ are the values that I use which allow me to accurately measure a 18 Ohms resistor in a 4-wire measurement configuration.

Thank you very much,

Javier

Hello,

This sounds very much like the Delta Mode operations available to the 6221/2182A.
This mode creates a system of instruments with TLink and RS-232 between the instruments and sets the 6221 as the 'master' node.
All control operations and data will be handled on this unit, while the 2182A would only be used as a 'software' controlled voltmeter.
Typically, this removes any ability to communicate directly with the 2182A and all data would appear from the 6221 through that link.
I am not sure what additional handshaking occurs through the delta mode backend code to allow for this, unfortunately.
I have shared this post within our development group and hope others will comment with information that may be helpful to you.
 

Here is some additional information related to your request:

There’s 2 levels of communication here. Unlike with TSP link or TSP net where we can directly reference the nodes in the system and the lead node handles divvying out the responses, we have to explicitly tell the 6221 to communicate back and forth with the 2182A before communicating with the PC.

The SYST:COMM:SER:SEND sends a command to the 2182A. If that command is a query like TRAC:DATA? The 2182A places the requested information into the output buffer of the 2182A. The 6221 still has to read that information with the SYST:COMM:SER:ENT? Command which grabs the info from the 2182A output buffer and puts it in the 6221 output buffer so that it can be read to the PC. The SYST:COMM:SER:SEND command itself is not a query, nothing is put in the output buffer of the 6221, so when you try to read in python, there’s no response to read from the 6221 and an error is produced.

The code should do the following:

Write(SYST:COMM:SER:SEND “TRAC:DATA?”) – tell the 6221 to tell the 2182A to put the data in its output buffer

Query(SYST:COMM:SER:ENT?) – tell the 6221 to check for output from the 2182A and put the response in the 6221 output buffer where we can read it.

Hi Jake,

Thank you very much for your answer. That is exactly what I suspected, that in order to do a query from 2182A I needed to send the query to 2182A and then read the output of the RS232 link with the SYST:COMM:SER:ENT? command. However, using this method I cannot implement a sweep with more than 16 points, which is very inconvenient. Basically, using the code that I previously shared, everything works perfectly fine if the number of points for the sweep is smaller than 16. If I increase the number of points to 17, the variable 'voltage_meas' where I store the data read from Query(SYST:COMM:SER:ENT?) (see attached 'voltage_meas_17_points.png') only shows 16 values instead of 17 as we would expect. In addition, the first ('3\n') and last ('+8.21553742E) measured values do not correspond to voltage values. If I further increase the number of points to 25, we observe the same result (see attached 'voltage_meas_25_points.png') with only 16 read values, where the first and the last one do not correspond to voltage values. 

From the 2182A manual I know the maximum number of points that can be stored in 2182A buffer is 1024, hence I don't believe the problem comes from 2182A. The maximum size of the 6221 buffer is 65536 and I have tried to set it up so it corresponds to the number of points of my sweep, hence I neither think the problem comes from 6221 buffer. I suspect that the element limiting the number of data that can be read is the RS232 cable. However, if I use the example software KI622O.exe provided by Keithley, I am capable to perform a sweep with up to 1024 points using exactly the same setup described before (GPIB from 6221 to the PC and RS232 + Tlink between 6221 and 2182A). Therefore, I believe there must be a way to perform the sweep with high number of points using this setup. The reason why I do not use the KI6220.exe software is because I cannot save the measured voltage values, which is critical for my experiment.

I hope you can help me on how to increase the number measured points. Let me know if further information is required.

Thank you very much.
Javier

 

Hi Jake,

An update on the issue: I have noticed that the Query(SYST:COMM:SER:ENT?) function only reads 16 values from the 2182A buffer. Hence by repeating Query(SYST:COMM:SER:ENT?) several times I can retrieve all the data from 2182A buffer. I have updated my code (see attached) to repeat as many times as required the function  Query(SYST:COMM:SER:ENT?) until the 2182A buffer is empty. It seems to work quite nicely for a sweep with maximum 100 points. When I try with 150 points or more, I always find a -363 error message in 6221, which consists of an input buffer overrun. As I mentioned previously, I know the capacity of 2182A buffer is up to 1024, and I set up the buffer to have the same dimension as the number of points that I want to measure. Where does this buffer overrun comes from?

P/S: I have tried to set the flow control to 'XON' as from my understanding this should prevent any overrun in the input buffer of 6221, however the error -363 doesn't disappear.