Andrea C

Here I've managed to attach the document.

As for the warning, I agree with you.  Once KXCI using GPIB is invoked, the GPIB interface can no longer be controller in charge.
So if you had a KULT library that controlled an external item over GPIB bus, seems there would be prohibition to execute that KULT code from the UL and EX of KXCI.....if using KXCI over GPIB.
Can you try LAN for KXCI?  If you use LAN, be sure to append null ('\0') onto your command strings.

What version of Clarius software is on your 4200A-SCS?

Here is an older forum post showing some success, but with different module:

Successful Use of UL and EX with KXCI

Is the external 707x matrix the item you need to control?  Or just using it as a sample?

 

Because the 1000V supply poses a shock hazard, it makes use of an interlock signal.
Ideally, you would have a physical barrier/test fixture with a door and door-switch.
When door open, the open switch prohibits the high voltage operation.
When door closed, the closed switch permits the high voltage operation.

Figure 26 in the Reference manual, pg 314, illustrates this simple open vs. closed connection to the interlock connector.

This is similar to how a microwave oven and the door state behaves.

There is no means to turn interlock off.

 

The 34980A is a 6.5 digit measuring tool, but is full rack and 8 slots for cards to make it multi-channel tool.
If you need the high number of slots for cards, consider our model 3706A and the various 37xx cards.
The 3706A is a 7.5 digit measuring tool and has six slots for cards.

If number of slots for cards is not important, consider the 6.5 digit DAQ6510 which has two slots for various 77xx cards.

 

Hello Abel,

Use of the (now obsolete) 2260B-GPIB-USB was the only sanctioned way to accomplish a GPIB based connection to the 2260B power supply.

The USB on rear of 2260B has to be configured via the F-21 setup.  Set it to value 2 to enable the USB-CDC mode.
If you manage to obtain a 2260B-GPIB-USB, set it to 3 to interface with that adapter.

It seems your options are boiling down to use the USB-CDC based connection or use LAN.
When using the USB-CDC, the simple USB A-B cable can connect the power supply to the PC.
On the PC side, it will look like a COM port (RS-232).
You could use VISA with the ASRLx resource that the COM port will utilize.


NOTE:  the TEK-USB-488 GPIB to USB adapter is expecting to be connected to a USB-TMC compliant instrument.
 

Hi Sébastien,

Unfortunately, it seems the keithley2600 driver posted to Univ of Cambridge github will not be compatible with the older 2612 that does not bear the A or B suffix.
Some commands might work, but sweeps that use the trigger commands will not be understood by the older 2612 model and syntax error will result.

I've attached a PDF document that was written about the time of the older 2612.  It has some sample scripts for FET and BJT tests.
You'll just need to send these commands and read back the results into Python for file save, graphing, etc.

Take a look at PySimpleGUI if you want a form with buttons and graphs and such.

 

Check the exact model of your SMU.
Is it the original 2612 release?  Or does it have 2612A or 2612B letter suffix.

It is only the A or B versions of the 2600x series that have the trigger model and the smuX.trigger.X commands.
It seems the Python driver you are attempting to use made use of those commands, therefore a 2612 cannot use the driver.
You would need to directly call one of the sweep commands of the instrument API (reference manual) or use a for loop in Python to program each source level and single measurement.

The TLINK connector on the 2182A is an 8 pin mini DIN style (google it).

The digital IO on the 2600B is on a DB25.

I'll upload some images for an obsolete accessory product that used to serve this purpose.
The one image has the pinout info for the mini DIN to DB25 connections.


 

You still get the full precision of the instrument according to the range and NPLC settings, etc.

The reason you are encountering range compliance even if current auto range is enabled is because the range change that would occur to get out of range compliance will not commence until you ask for a measurement.
When not connected over the bus to PC, the instrument does continuous init of new measurements in local mode.
But once you go under remote operations, that stops and you have to manage all the details.

I am not 100% sure if this will work:  After you source your new voltage value, you could query the value of the measurement condition register (read the value after this command:  :stat:meas:cond?).  Bit 14 will reflect in compliance or not state.  I'm not sure if both range compliance and real compliance will cause this bit to go to logic 1.  It might only be real compliance.

If using the more complex source-memory sweeps, there is the current range holdoff.
This feature sets the measure range = range needed for the current limit just before sourcing new voltage.
When creating the step change of voltage, there will be a displacement current (I = C * dV/dt) and the higher range gives best chance to not saturate due to current range.
Then it resumes use of the last used lower measure range for the measurement.
 

Since the task is structured as trigger model based source and measure into a buffer then transfer data to PC when all done, the speed of GPIB vs. LAN is not really a factor in my opinion.  The data transfer time is not affecting the speed at which the SMU can source a new value.

And even if the SMU can command a new source value quickly, the analog response to that should be considered and verified.

I suspect the rate limiting factor will be the speed of the sourcing action.
You indicate that it gets a little bit faster when you remove the measurement.

If you want to coordinate second SMU channel:

even though you just want a SMUB measurement for each sweep point in SMUA sweep, I'd still treat this as a "sweep".  Your starting V and stopping V for this SMUB sweep can be the same (bias condition) and you measure the SMUB current.

As SMUA goes through the trigger model, those same stimuli can be used as as inputs to the SMUB sweeping trigger model to keep the two SMU synchronized.

I've uploaded an image of a typical interconnected sweep for the two channels of a 2600B.
The logic gates are available "Event Blenders" and are configurable or OR or AND logic.
In this case, we AND together the measure complete event IDs from each SMU and use that output to control when sourcing occurs.

But to get the very first source value, we use an OR gate and allow the ARMED_EVENT_ID to cause the first source value and to start a measure delay timer.
Both SMU channels will loop until their trigger counts are satisfied.
Important:  as structured in this diagram, when arming these tasks, start SMUB first (smub.trigger.initiate()) so that it can fully arm and be waiting at the Source Event detector.  Then start SMUA.

All these interconnecting lines between the two trigger models are accomplished by TSP commands.

When the two SMU are on physically different chassis (two 2601B for example) then the SMU or Timer or Event Blender events can be "echoed" on the TSP-LINK for the remote nodes to consume.

Bonus info:  sometimes is helpful diagnostics to configure a digital IO line on the rear DB25 connector to strobe when certain event occurs.  This can provide a timing mark to feed a scope and you can see what the trigger model is doing vs. the analog behavior from the SMU channel.

​​​​​​​    -- digital output trigger for external equipment
    -- configure digital IO line 1 to output a active LO/falling edge
    -- pulse at start of each current pulse
    digio.trigger[1].clear()
    digio.trigger[1].mode = digio.TRIG_FALLING  --digio.TRIG_RISINGM
    digio.trigger[1].pulsewidth = 100e-6
    digio.trigger[1].stimulus = node[1].trigger.timer[1].EVENT_ID  -- change this according to your needs