Reading measurement data from Keithley SourceMeter 2602A

Hello dear community,

I'm currently trying to do a sweep operation from 0 to 10V via Python with the Keithley SourceMeter 2602A and at the same time measure the current at each step. My problem lies in the reading of this measurement data. For example, if I run a SweepOperation with 100 steps, I don't get a problem and I can see all the measurement data in the program. But if I did SweepOperation with 200 steps I would get this error.

Here is the error:
pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.

Here is the code to read the measurement data:

system.inst.write("printbuffer(1, smua.nvbuffer2.n, smua.nvbuffer2)")

After starting the SweepOperation I also added the command "waitcomplete" but I still get this error.
This post is my first post in this forum so forgive me if I made a mistake.
I would be very happy if you could help me with this.

Best regards

Ali EGIN

Hello,
Can you supply a copy of your code?
This will help diagnose where the issue may lie.
 

Thank you for your answer.
Attached you could find my code in a zip file.

This is fairly common issue to coordinate the state of the Python code with the state of the instrument.

For the 200 point sweep, it clearly requires more time to conduct the sweep vs. the 100 point case.

The VISA session has a timeout parameter, in msec.  Default value is 10 seconds for most VISA versions.

If your 200 point sweep needs more than 10 seconds to complete, then is very possible to receive a VISA timeout from the VISA read following your printbuffer() command.

There are a number of strategies to deal with this.

One would be simply to set the VISA session timeout to a larger number.  Default is 10000 msec.
Downside of longer VISA timeout is that for real error conditions, it will take longer to raise the error.

Or introduce a time.sleep(seconds) on the PC side before asking for the data.

Alternately, it is possible to have the instrument assert an SRQ when the sweep completes and your Python can do status polling and ask for data only when the instrument signals that is has some ready for you.

Really depends on how fancy you want to get in the code.

Hello,

thanks for your helpful recommendations. I would like to apply these recommendations today.
I have another question about this measurement process. A SweepOperation with 100 steps takes about 0.5 second, although I already set NPLC value to 0.001. We want to perform a SweepOperation with 2000 steps within 100ms. Do you know if this is possible or if there is such a fast product at Keithley.

Also, I just noticed that changing NPLC value has no effect. I would like to ask if I made a mistake somewhere.

Best regards

Ali EGIN

As for speed of the source-measure sweep, pg 30 in the 2600B series datasheet gives an idea.

Max expected rate for source and measure operations into memory is 12000 per second.

The 2600A series will have similar capability.

In your pulse mode Python code, the pulse period would need changed to 83.3usec to attempt that 12K rate.

Hello Andrea,

As you wrote, I have set the pulse period to 83.3usec. Now my problem is that I can't read out all 2000 values. The program just gives me about 100 values. I changed Pulse Width afterwards because it should be shorter than Pulse Period. This time I got more values, but the program still doesn't deliver the 2000 values. Do you have any idea what could be the problem here?

Also, I looked up datasheet of 2602A and 2600B and saw that both SMUs have almost the same characteristics. My question here is whether I should consider "Source measure to GPIB". This value is 5900. I use a GPIB cable as the interface.

Best regards

Ali EGIN

Hello,

Also, the time allocated for the measurement, needs to be less than the Pulse Width.
As a test, set the smuX.measure.nplc = 0.001

This is the minimum allowed value for 2600X.

When you say you do not get all values:
Is the sweep completing?  Or is the sweep "stalling" because maybe there is a timing problem with nplc, pulse width and pulse period.

The print(smuX.nvbufferX.n) will indicate how many values are in the buffer.
Let us knw if expected number of readings are in the buffer, but you are not successfully transferring all the data.
I take it you using LAN connection now?

Hello Andrea,

I had already set the NPLC value to 0.001. When I start the program, I see on the SMU display that SweepOperation is finished. But like you said it could be a timing issue.

I thought about it again last week and so simplified the task. But I'm not sure if it's possible:
1 - I don't actually need a measurement on channel A. Therefore it would be sufficient if I only did a sweep operation (from 1.5mA to 5.5mA with 3000 steps) on channel A. A SweepOperation goes pretty fast without measurement as I would like.
2- I don't really need a sweep operation on channel B, I just want to measure the current 3000 times.
3 - Each step of SweepOperation must be synchronous with each measurement on channel B.
I would like to ask you if I can synchronize these two processes with Timer. If yes, do you think this process can happen within 100ms.

Also, I still use GPIB connector. Is it faster if I connect to LAN?

Thank you again and I wish you a nice day.

Best regards

Ali EGIN

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