Help with programming a Keithley 220 Current Source in C++

[graphene]

Hello guys,

I want to program a Keithley 220 Current Source using C++. (C++ is m only option).
(My task is to find out the V-I relation of a certain sample for which I want to program the current source).
I am having problems getting the device into remote operation mode.
I try to communicative with the device using 'send' defined in the the 'ieee-c.h' library.
Though the manuals that came along with the device have examples on a HP-8s machine running BASIC, I was not able to figure out the commands to be used on C++.

I would appreciate if anyone here is able to help me with the commands to be used.
Example code snippets would be appreciated.

:)

 

[James Skowronek]

Hi, did you ever get this figured out? I'm working on the same challenge, but it doesn't seem worth the time with this particular piece of equipment.

 

[berkeman]

Hi, did you ever get this figured out? I'm working on the same challenge, but it doesn't seem worth the time with this particular piece of equipment.

Welcome to PF, James. This thread is 11 years old, and the OP was last seen in 2013, so they likely will not reply.

However, we are still happy to help. From the datasheet, it looks like this instrument only has a GPIB connector for control and monitoring, correct? What interface are you going to use to connect to GPIB? What language(s) are you comfortable programming in?

https://www.tek.com/manual/model-220-programmable-current-source-instruction-manual-rev-h

 

[James Skowronek]

Thanks for the reply! I figured it might be worth asking the question, even if it's a long shot.

I'll be somewhat verbose in case knowing the path I've already taken ends up being useful for future posterity.

You are correct about the GPIB limit, but that's fine by me as long as I have the pertinent communication language library. I've been following the manual you linked, but no luck getting any consistent results. I've also been trying to use pieces of code from examples for other Keithley devices, but still no consistent or good results.

I'm using the pyvisa wrapper, but I'm comfortable using any language that implements a SCPI wrapper. One of the explainer videos I watched uses MATLAB. But all wrappers seem to require knowledge of the specific device's library - seems obvious enough why that would be.

I wasted a bunch of time trying to get pyvisa to even communicate with my equipment, because I'm dead set on bypassing LabVIEW. I found other options - e.g. using Keysight interfacing - but it seemed at first that most references pointed to NI somehow. I finally realized all I needed was a backend for pyvisa to work off of, which NI has freely available as a LabVIEW runtime engine. I wasted so much time just trying to get pyvisa to work after having installed NI-488.2 and NI-VISA, but not the runtime, because they include the necessary drivers.

Here are most of the explainer links I've been following:

How To Automate Rigol [and most other] Test-Equipment With Python and SCPI

PythonAutomationSeries 4 writing your first program

Keithley Live: Programming a 2600B SMU

eevt002 - Controlling Measurement Equipment with Python and SCPI via VXI-11 and USBTMC

Software tools and SCPI protocol

[pyvisa]: A more complex example

Thanks again for any help!

 

[berkeman]

Have you at least been able to get a reply to an *IDN? query?

 

[James Skowronek]

Actually, I'm using the Keithley 220 programming manual I found here, not the instruction manual you linked; that one doesn't say much about programming, it just references this other one.

The only code that works for me is the one you asked about, *IDN?; none of the other standard IEEE codes seem to do anything, e.g. *RST?.

Just like the person who asked this question originally, it's unclear from the programming manual how integral the HP-85 BASIC commands are. Most of the time it seems they are just a particular, non-unique abstraction used for examples of how a handler routine utilizes the actual underlying code of interest; but they are introduced in 3.3.2 as "... statements that are essential to Model 220 ... operation.".

 

[berkeman]

How are you reading the replies from the instrument? I ran into an issue where I was missing the uplinked messages because of timing and buffer management issues...

 

[James Skowronek]

They're returned in the ipython console by the calling object's query function, in my case src.query('*IDN?').

 

[berkeman]

If you do multiple *IDN? queries in a row, do you get valid responses to all of them?

 

[berkeman]

And are you sure you are putting the instrument in Remote mode? I think *IDN? gets answered even if the instrument is in Local mode...

 

[James Skowronek]

Re multiple requests: yes.

I'm not sure anymore at what point remote becomes enabled, because I was testing *IDN? without thinking about anything else at that moment. It might be that any query I sent enabled remote mode, because after I had tested *IDN? I was testing other commands that were enabling remote mode (the Remote LED lit up on the 220), but I wasn't able to turn it off programmatically.

I'll do some more tests in a few hours to see if *IDN? enables remote mode, if that is what you're wanting to know. I don't know if it remains in local mode after sending *IDN?.

 

[James Skowronek]

Update: I'm in talks now with a Keithley AE who has verified that the 220 is so old that it's from a time before SCPI, when dinosaurs roamed the earth. The manual indeed implements an example using HP BASIC as an abstraction of the device commands.

He will try to put together some code using a few commands that I can use to infer how to interpret the rest of the commands.

I'll update here again if I learn anything useful. Otherwise, thanks for trying to help!

 

[f95toli]

I don't think have ever programmed a 220. However, I have programmed many, many other instruments including some old Keitley models.

I suspect part of the problem is that you expect the instrument to be "well behaved" and follow a standard (SCPI). The reality is that whereas most modern instruments (but far from all) implement some version of SCPI, you should not expect any instrument to actually follow the full standard. Especially when using GPIB you should think about the communication as simply sending text messages back and forth. There are some instruments that implement *OPC? and the other (nominally) standard commands, but most do not (including new instruments) or do it in non-standard way.

Hence, if the *IDN query is working there is a pretty good chance that the "communication" part is working, but this does of course mean that the instrument is does what you want it to do.
That said, the things to keep an eye out for are buffer overflows, not reading/emptying the whole buffer (which can cause many instruments to lock up) and if you are using binary transfer (unlikely for a 220) the standard used.

In terms of software PyVIsa should be fine. You do need the VISA drivers as well, but for the 220 any library should work (NI. Tek, Keysight) and you certainly don't need Labview; the only time you typically need to worry about which driver you ar using is when using instrument that transfer large amount of binary data .(e.g. transferring wavefoms to/from AWGs, oscilloscopes etc)