Andrea C

Curious which test freq does your 590 have?  100KHz or 1MHz or both?
Which freq do you use?

For the calibration capacitor topic, do you have the 5907 standard caps?  Or supplying your own caps?

Are you connected through the switch when doing the cable compensation with the standard caps?
You should be if you want the method to correct for it.

You mention an unwanted offset of up to 20pF when connected through a switch.  Have you tried the zero method from section 3.10?

Your 590 is likely to be quite old.  When was last time it was calibrated?
How are you determining the value of the reference caps?

In general, I’d try evaluating just the 590 with minimal cabling to the standard caps.  If successful, then start adding in the other aspects such as the switch, etc.

For your finding1 topic:  when blue light is off, if the SMU is in default output off config, then it is behaving as a 0V source with ability to source or sink 1mA.
This should result in 0V starting point.
When you say the voltage was jumping around 0 to 2V, what was the condition of the SMU then?

Any chance there was an open circuit due to probing issue?

NOTE:  for PN junction, if using SMU to force current and forward bias the diode, it is very much possible to trap charge on the PN junction when the SMU returns to 0Amps and the blue light is still on, especially if using a low source range.
Suppose you force current with a 3V limit.  When you return to 0Amps, the SMU has no trouble to allow as much as +/-3V.
This should be fairly steady, but could decay due to leakage in the device, cables or allowed offset of the source range.
You can bleed off the trapped charge by turning output off OR by temporarily setting the voltage limit to smaller value.

the sync_in and sync_out parameters of the Config functions will need to be used.

Wondering if you can just config each SMU to make use of digital line 1.  And then use the digio.trigger[1].assert() to satisfy the digital event.

Also, check your firmware and update to the final release (1.4.2) for these non-A and non-B vintage models.
firmware for 2600 nonA and nonB

If you are using VISA to exchange messages with the instrument, when you clear and then close the session, the REM indicator on the 2600B will go out and the auto initiated local mode readings will resume.
 

import pyvisa
import time


resource_mgr = pyvisa.ResourceManager()
#optional print available VISA resources on this computer
resource_list = resource_mgr.list_resources()
for resource in resource_list:
    print(resource)

try:
     #get a session/handle for one resource
     instrument_resource_string = resource_list[0]  #"USB0::0x05E6::0x2602::4484585::INSTR"
     #"TCPIP0::192.168.1.50::inst0::INSTR"  #
     my_instr = resource_mgr.open_resource(instrument_resource_string)
except(visa.VisaIOError):
     #did not connect.....
     print("Whoops, something went wrong")

my_instr.write("*IDN?\n")
print("*****")
print(my_instr.read())

#put instrument back to local and close connection
my_instr.clear()
my_instr.close()
resource_mgr.close()

 

Looking at the source spec for the 1.5Amp range, you could have as much as +/-4mA of current and still be within spec for source value of 0Amps.
In contrast, when using 1uA range to source 0A, the error budget drops to +/-700pA.

If wanting the SMU to behave like a volt meter, in general, use the most sensitive range available to source the 0Amps.  Set the corresponding voltage compliance limit to a value larger than the DUT can produce.  Measure V.


For your finding1, what was the state of the SMU before landing the probes?  Was it already in Force I, Measure V?  Was blue light on?

Hi Greg,

I doubt if this will help, but just in case I wanted to mention to double check the Windows Device Manager.
If Windows has mistake in how it categorized the USB connected instrument, then it would prevent proper association to the USB Test and Measurement device type, the IVI components, showing up in NI-MAX, etc.
Sounds like your specific unit is not being enumerated at all by Windows.
However, if it was instead being detected and assigned to "Other devices" or something else, this could account for the trouble.
Sometimes, if no driver is present when the usb is first plugged in, an incorrect categorization is made and Windows will just repeat it even after a driver has been installed.
In that case, delete the incorrect entry from Device Manager and then un-plug and re-plug the USB connection and see if it will correct the association to USBTMC.



 

The link to the post on the older forum does illustrate the procedure to update the firmware on the 2200-60-2 and similar models.
The firmware update procedure is expecting a connection on the (otherwise factory use only) RS-232 port.

I'm not sure the revised firmware will address your initial issue of no detection of the USBTMC.
But it is worth a try certainly.
I do not expect the SCPI commands to be functional over RS-232;  only USB or GPIB.

If your PC with NI VISA and that USB cable can detect other instruments (DAQ6510), but not the 2200 power supply, I suspect the 2200 power supply may have a malfunction and requires service.

Do you feel the auto zero needs updated within the 500 second measurement time?  Do you think the instrument is drifting within the 500 seconds?  Is it fully warmed up (1 hr)?
How much drift are you seeing?

Auto zero updates every 2 seconds does not seem likely to give benefit.

If no need to update so frequently, I would just call the auto zero with setting once to force the update then.
Next command to trigger init the 500 second acquisition.

Since you have a number of new changes in behavior, I wonder if one of the power supplies in the 7002 is having some trouble.
The instruction manual on Tek.com for the 7002 has a section on maintenance and running diagnostics.

On the DB9 connector for the digital IO, a 5V supply is available (pin 2).  Look at that on a scope.  Is it steady DC average value?

Our service dept will perform functional check and repair of 7002 still.
https://www.tek.com/en/service-quote

Just expanding on the information provided.

Given that a Keithley SMU is likely to see a few decades of use for perhaps a lot of different tasks, the absence of digital IO for triggering with external equipment is one likely way you will wish you had the 2612B instead of 2614B.

However, there is still the ability to coordinate the SMU action with bus trigger or sending *TRG command to it after arming it for a task.

In the attached PDF, I provide a little more detail on it.