How do I use Python (and no installed IO Library) to talk to my instrument?

Hello everybody,

Our newest support engineer and I have decided to learn Python (https://www.python.org/) so that we can generate programming examples.  We are hearing that more and more customers are using Python so we figured that we would get on the front side and learn some Python.  This blog represents my first attempts at doing anything in Python so there are probably better methods to do this but I wanted to get this out since I am pretty excited about it.  

What we are going to do is do use Python with Telnet and LAN to directly send SCPI commands to my instrument.  The major advantage of this is that with this method, you do not need to use an IO Library so you can use it in different operating systems.  Since we are going to be using Telnet with Python, the first thing that we are going to need to do is to make sure we understand how telnet works with our power supplies.  For all my work here, I will be using my N7953A Advanced Power System (APS) because it is on my desk and it is awesome.  The APS uses port 5024 for telnet.  On my PC running Windows 7, I enter the following in my command window:

Figure 1

Once I hit enter, I get our very friendly welcome screen:

Figure 2

Note the text “Welcome to …”, this will be important later.

To send commands or do queries, you just need to enter the SCPI command after the prompt.   The response to the query will automatically appear after you hit "Enter".  Here is how you do a *IDN? Query:

Figure 3

Note that the query response ends with a new line.  This will be important later.  The prompt also re-appears after every interaction.  In the case of the APS, the prompt is the model number ("N7953A>").  On some other instruments , the prompt is "SCPI>".  Either way, you need to know what the prompt is so that you can account for it later.

 Now that we are Telnet experts, we are going to switch to Python and send a *IDN? query to my APS.  The first thing we are going to do is to import the telnet library.  After that we are going to create our APS object by opening a telnet session to the instrument (sorry these screenshots might overflow the frame a very tiny bit):

Figure 4

Basically, we are at the same point we are at in Figure 1.  We essentially just hit the "Enter" key.  We need to get to the equivalent to Figure 2 so that we can send a command.  That means that we need to read out all of that welcome text from the power supply.  Luckily, the Python Telnet Library has a read_until function that will read text until it encounters a predefined string.  We know that our prompt to enter text in this case is "N6753A>" so that is what we are going to use:

Figure 5

Let’s send our *IDN? query.  You use the write command to write to the Telnet session.  Helpful tip: all commands sent through telnet need to be terminated with a newline ("\n"):

Figure 6

So now that we sent a query, we need to read the buffer to get the response.  Remember that the query response ends with a newline so we are going to use read_until and use the newline ("\n") as our read_until text:

Figure 7

As you can see we get the same response as before.

So now we sent our command and read the response, we need to read out the prompt again so that our power supply is ready to accept the next command sent to it.  We will just use the same read_until that we used before:

Figure 8

Now we are set to send the next command.

When you are done with programming the instrument, you end the Telnet session with the close command:

Figure 9

So that's an extremely basic example of how to use Python and Telnet.  I used the shell because that is what I used to figure this all out.  You can also write scripts.  As Chris and I learn more about Python, we will be releasing more examples.  Stay tuned for those.

Power Supply Programming: How Should I Send Commands to my Instrument

Hi everyone!  Happy Labor Day to all you readers in the US!  Every month I struggle with what I am going to write and wind up waiting till the end of the month to do my posting (and I am keeping that streak alive).  In order to combat that, I came up with a series of topics on programming instruments, focusing on our power supplies.  Let’s say that this is the first in a series of three (or maybe four I am not sure).  Please note that anything that I state here is my opinion and not Agilent policy.  Today I am going to focus on the how to send commands to your instrument.  In other words, what sort of IO library do you use to send the commands?

All of my suggestions will be based on the Agilent IO Libraries as that is the environment that I am most familiar with.  There are two major options: direct IO where you use the SCPI from the instrument and drivers where there are functions that you call.

First let’s talk about direct IO.  I learned how to program instrument using HPBASIC as my programming language so this is where it all began with me.  Agilent has two modern standards for doing this.  The first and the older standard is the VISA library.  VISA works very well when you are programming an instrument in the C programming language.  Here is a snippet of C code from a N6700 example with VISA (I have intentionally not provided comments to show the program in its purest form): 

VISAstatus=viOpenDefaultRM(&defrm);

VISAstatus=viOpen(defrm,”GPIB0::5”,VI_NULL,VI_NULL,&session);

viPrintf(session,"VOLT 5,(@1) \n");

viPrintf(session, "OUTP ON, (@1) \n");

viPrintf(session, "MEAS:VOLT? (@1) \n");

viScanf(session,"%s",&voltmeasurement);

viClose(session);

viClose(defrm);

It works pretty well and makes sense once you know it.  The viPrintf and viScanf functions are very similar to some basic C functions so if you are a C programmer, this is really the way to go.

There is also a newer option that works pretty nicely in languages that support COM.  This option is called Agilent VISA COM.  VISA COM works well in Visual Basic and C#.  Here is the same program to the above written in VB:

Set ioMgr = New AgilentRMLib.SRMCls

Set Instrument = New VisaComLib.FormattedIO488

Set Instrument.IO = ioMgr.Open("GPIB0::5")

Instrument.WriteString " VOLT 5,(@1)"

Instrument.WriteString " OUTP ON, (@1)”

Instrument.WriteString "MEAS:VOLT? (@1)”

Result = Instrument.Readstring

Instrument.IO.Close

In my opinion, this is easier to read than VISA.  When I have to write a program now, I tend to stick with using VISA COM and Visual Basic. 

The other option is to use a driver.  We presently offer two different driver types for our instruments: VXI Plug and Play and IVI COM.  VXI Plug and Play drivers are obsolete now though so I will not reference them further today.  Here is an example of our program using the IVI driver (in C#):

driver = new Agilent.AgilentN67xx.Interop.AgilentN67xx();

IAgilentN67xxProtection2 protectionPtr;

IAgilentN67xxMeasurement measurementPtr;

IAgilentN67xxOutput3 outputPtr;

int channel

driver.Initialize(“GPIB0::5”, idquery, reset, initOptions);

outputPtr = driver.Outputs.get_Item(driver.Outputs.get_Name(channel));

protectionPtr = driver.Protections.get_Item(driver.Protections.get_Name(channel));

measurementPtr = driver.Measurements.get_Item(driver.Measurements.get_Name(channel));

outputPtr.VoltageLevel(3.0, 3.0);

outputPtr.Enabled = true;

mVolt = measurementPtr.Measure(AgilentN67xxMeasurementTypeEnum.AgilentN67xxMeasurementVoltage);

driver.Close();

As you can see, the driver is much more complex than the direct IO examples. There are a few reasons to use a driver though.  The first and most common reason is that your system itself it designed to use drivers.  Another good reason is portability.  There are instrument classes in the IVI driver that should work for any DC power supply that is compatible.  One of the main downfall of our IVI drivers is that the functions almost always map 1 to 1 with SCPI so there are not many functions that work at a higher level and you don’t save any time programming there.

My main approach is to use VISA COM in Visual Basic.  I find it to be the easiest for me to program and it is what works for me.  Of course no opinion is wrong though and we are happy that our readers are out there buying and programming our instruments.  Thanks!