Set behavior differeing between Keithley 2400 and 2450

[aaronsharpe]

Hi all,

Our lab has started using Keithley 2450s but they behave quite differently from 2400s. We use them to output a voltage with a finite step size when changing their output because we need to slowly ramp the output voltage for the safety of our devices.

When changing the output voltage of a 2400 (k2400.volt(some number)), this ramp function would prevent any further execution of code until the ramp is finished. This is the desired behavior because we usually need to let the system get to the final voltage and settle before continuing with anything else.

Keithley 2450s however don't do this. They just take in any number of set commands which go into the instruments buffer to be executed, but the code keeps trudging along. I can force the desired behavior by forcing a read command on the instrument, so at worst, I can set this up.

I am not really sure what is happening at the lower levels given that the commands sent are exactly the same. But my best guess is that the 2400s were blocking because they forced an update on the SENSE parameter (current in our case) with their set output level command at the end of the set command. This is clearly not the case on the 2450 as the screen doesn't get updated without a read command (except for the little number showing the output level)

Any help is greatly appreciated!

[jenshnielsen]

In general this type of behavior is up to how the instrument is implemented by the manufacturer and qcodes typically just reflects that. I would recomend reading the manual of the instrument to understand how it is meant to be used. This looks like the one for the 2450 https://www.tek.com/en/keithley-source-measure-units/keithley-smu-2400-series-sourcemeter-manual/model-2450-interactive-sou

If you find a way to do what you want from the instrument manual we can help getting that integrated into the qcodes driver

[aaronsharpe]

Thanks for the quick reply. I am glad to hear there isn't something I missed within qcodes. I will play around with this and report back.

[aaronsharpe]

I made some changes and tested them in my fork here (aaronsharpe@90916e8)

I was trying to implement a kwarg in the set function (similar to what is done in the ami430 code which I haven't tested), but I kept getting an error that parameter_base was getting an unexpected kwarg.

Otherwise, if the changes look good, I am happy to submit a pull for the main branch. Happy to iterate. This seems to work well for us!

[jenshnielsen]

Sounds good, I think I would prefer this approach to a kwarg in set. If you open a pr I am happy to review

[aaronsharpe]

Just opened one. Thanks so much for the help!

[brycelynn-bailey]

Hi @aaronsharpe I am having some similar problems with our 2450s and wanted to know if your research group ever ran into the SMU severing communication when sensing the current? With our devices, we normally have the current limit set to 1nA. I initially noticed that the SMU will stop communicating when it reaches the current limit, and that it is inherent to the SMU to prevent damaging itself based on the SMU manual, however, the I/O error occurs even if the current limit has not been met. When this occurs, the only way to clear the error is with a power cycle.

[aaronsharpe]

I have much more experience with the 2400s and can tell you that I haven't seen similar behavior there. The SMU will not sever communication when sensing current even when it is at compliance. Happy to see if I can help further if you want to send me an email