Sampling time for SMU 2460

Hello,

I have a question concerning the sampling time of SMU 2460:

In my application I generate a DC current ramp and measure the voltage and current readback. I have some functions to handle it with a for loop and some conditions. The stopping of the ramp depends on the voltage variation between 2 samples and gives the current value.

However, with the same code and the same parameters I have 2 different behaviors concerning the generation of the DC current ramp:
- 1st time I call the function: the slope is around 160mA/sec
- When I call the same function with the same parameters the other times the slope becomes around 230mA/sec

My question is why the sample time might differ when the same function is called with the same parameters?
Is there a document to detail how to calculate or estimate sampling time depending on code, NPLC... or to master this sampling time?

Thanks for your answer,

Best regards,
Alex

 

How are you measuring the ramp speed? Looking at your image, the slope on all those runs is the same but runs 2+3 are starting at a higher current level so they reach the cut off point faster.

I would look at how you're determining the starting point for each ramp.

Hello and thank you for your feedback!

I measure the ramp speed with an oscilloscope and a current probe (I join an example) on the different ramp.
Then I put sliders to calculate di/dt directly on the scope.

In our method, we adapt the Istart signal based on the previous result to reduce the test duration. The same function is called with the same parameters (only start current value is adapted).

However, a few days ago, I did some tests to try to understand why the ramp might change between the 1st ramp and the other: 

To do that, I had no change the function's parameters (start and end current, ramp speed...). What I do is:
- Disconnect / Reconnect SMU: first ramp lower than the others
- Start a function (one pulse) then the ramp function: same, first ramp lower than the other
- I also did some tests in my code like removing the current readback: same behavior.

Thanks!

Alex

Hmm, can you share your code?

Hello,

I join the code. Thanks for your support!

The issue is you placed the smu.measure.autozero.enable = smu.OFF command too early. By placing it with the source commands, before you set smu.measure.func, you are setting the autozero behavior for the smu.FUNC_DC_CURRENT measure function. Move that command below smu.measure.func = smu.FUNC_DC_VOLTAGE and you'll get the faster ramp behavior every time.

How I discovered this (since the same process can help with script debugging in general):

1. I noticed that reset() always resulted in the first run having the lower ramp rate. This means it must be something in the instrument settings.
2. I created 2 config lists, MySourceList and MyMeasList
3. In the code, before starting the sweep, I added commands to save the current settings to those config lists: smu.source.configlist.store("MySourceList"), and the equivalent for MyMeasList
4. After running the function twice, to see the problem behavior, I opened the ConfigLists from the front panel. The front panel interface highlights what settings change between each ConfigList entry. There were no changes in the Source list, but the Meas list showed that on the second run, smu.measure.autozero.enable was set to smu.OFF, so it must've been on the first run.

A other few notes:

• You're setting "smu.source.autodelay = 1e-3", but smu.source.autodelay can only be on or off. Do you mean to be setting smu.source.delay to 1e-3? Right now you are turning autodelay off, but keeping smu.source.delay at 0.
• You are measuring twice at each sweep point with smu.measure.read(), your code accounts for it, I'm just curious why?

Hello,

Many thanks for your comments and your support!
I will test it next week and give you the feedback.

Regarding your notes:
- For the smu.source.autodelay: this is an error from me for sure. 
- "Twice at each scan point with smu.measure.read()": I do this to differentiate between the actual voltage level and the previous sample. When the difference between these 2 samples exceeds a threshold, this indicates that our product under test has been triggered. 

Best regards,

Hello Bradley,

Thanks to your help, my process with the SMU works properly, ramp speeds is now constant and repeatable.

Thanks again for your support!