DC electronic loads

[Christopher Johnson]

I don't think there is a class for DC electronic loads (not in IVI specs). I want to try adding an electronic load but I'm not sure what is the best starting point. Should I make it's base as a DMM or DC supply and add methods? Or should I create a whole new instrument / class? I'm leaning towards a whole new class but want to check.

I'm still working on my other drivers (scope, DC+DMM, etc..) but I have a need to add basic support for my electronic load at the moment.

[Jeffrey Wurzbach]

What make/model?

On Tue, Mar 25, 2014 at 8:41 AM, Christopher Johnson <chris...@gmail.com> wrote:

I don't think there is a class for DC electronic loads (not in IVI specs). I want to try adding an electronic load but I'm not sure what is the best starting point. Should I make it's base as a DMM or DC supply and add methods? Or should I create a whole new instrument / class? I'm leaning towards a whole new class but want to check.

I'm still working on my other drivers (scope, DC+DMM, etc..) but I have a need to add basic support for my electronic load at the moment.

--
You received this message because you are subscribed to the Google Groups "python-ivi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-ivi+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Forencich]

The omission of the DC load class has certainly been noticed, however
nothing has been done to mitigate that as of yet due to lack of time.

I think it would be a good idea to include extra non-IVI compliant base
classes for things like electronic loads. I also think it would be a
good idea to try to build one from the ground up instead of putting
together a kludge from existing base classes. I'm thinking it should be
based on the DC power class, but it should stand on its own.

I have some time this week, so I will sit down and see what I can figure
out.

Also, there is no reason that you have to have a base class to implement
a driver - there are several drivers in Python IVI that do not inherit
from base classes. However, this does hamper extensibility if the
drivers do not agree with each other.

Alex Forencich

[Christopher Johnson]

Thanks! Just looking for some guidance and wasn't expecting someone to do it for me.

The DC load is a Prodigit 3311C. It's not exactly a top of the line brand or model used everywhere but it does have an SCPI programming manual. It functions it supports are pretty standard for DC electronic loads.

Just a quick list of what I was thinking I would implement:

• # of input channels
  
• specs per input channel (max voltage, max current, also add maximum wattage?)
  
• dynamic and static load settings
  
• for dynamic load add slew rate, timings
• load level selection (high or low) to switch between two levels
  
• short (short inputs together)
  
• limiting and protection (OCP)
  
• memory storage and recall
  
• sense mode
  
• voltage sensing
• add current monitoring (?)
• measurement support (voltage, current)
  
• triggering
  

[Jeffrey Wurzbach]

Hi Christopher,

I have some pretty basic stuff put together for a single channel Agilent load and an Agilent mainframe style load (it's written procedurally and hacked together to get the test done).  This is why asked for the make and model.  Does your unit support SCPI commands?

Alex and I were chatting about the things that a load class would require earlier today and we came up with basically the same things you've outlined.

-jeff W

[Christopher Johnson]

The Prodigit does support SCPI. In the past I had hacked together a script using PyVISA and sending the SCPI commands. This was before I found python-ivi.

I was able to dig out the SCPI manual here: http://wenku.baidu.com/view/8ba043ea6294dd88d0d26b70.html

I'll test out some more basic functions and support for it today. I can probably adapt or merge what I create into any style your or Alex have defined.

[Alex Forencich]

Nice.  I think if we can take a look at a couple of different SCPI implementations, then we will have a better sense of how the common functionality should be implemented.  We will work on this more this week and try to come up with a good solution for non-IVI base classes. 

Also, I just recently updated Python IVI to support PyVISA as a backend instrument communication interface.  If PyVISA is installed, Python IVI will use it as a 'fall-back' interface if it cannot load a driver.  For example, if you install python-vxi11 and PyVISA, connecting with TCPIP will go through python-vxi11 while connecting with GPIB will go through PyVISA. 

Alex Forencich

[Jeffrey Wurzbach]

The Prodigit does support SCPI. In the past I had hacked together a script using PyVISA and sending the SCPI commands.

This is basically where I am at...

The style we were thinking about using is something like this:

load.function.channel[]

-Jeff W

[Christopher Johnson]

Just checking, should it be load.channel[].function?

From what I know scopes use scope.channels[].function and dc power supplies use dcpwr.outputs[].function.

scope.channels[] are strings formatted like C1, C2, C3, C4 ..

dcpwr.outputs[] are integers starting at 0 (or 1?)

Regards,

Chris

[Alex Forencich]

Yeah, the implementation will be more like this:

load.outputs[0].mode = 'constant_current'
load.outputs[0].voltage = 12.0
load.outputs[0].current = 5.0
load.outputs[0].enable = True
load.outputs[0].short = False
i = load.outputs[0].measure('current')
p = load.outputs[0].measure('power')
etc.

Also, this may not be particularly well advertised, but you can access stuff with both string names as well as 0-based indicies.  So things like this are equivalent:

psu.outputs[0]
psu.outputs['output1']

scope.channels[0]
scope.channels['channel1']

scope.channels[4]
scope.channels['digital0']

The names can usually be read out like so:

psu.outputs[0].name # returns 'output1'

scope.channes[0].name # returns 'channel1'

scope.channels[4].name # returns 'digital0'

In terms of the electronic load base class, I think the main questions right now are:

1. Do we need separate DC load and AC load classes? (personally, I don't think so, but we may need to move more parameters into extension groups)
2. what parameters do we need to support?
3. how will the parameters be divided into extension groups?  What goes in the base class?

I just added a new directory to python-ivi for storing these extra base classes and extension groups.  Currently, the only thing in there is the overcurrent extension group for DC power supplies.  The new load base class will be created in there.  I will also be adding extension groups for some common functions, like memory save/recall, screenshots, etc.

Alex Forencich

[Paul de Vries]

Coming back to this question. I would like to add a Chroma active load. It has a mainframe which (could) has different channels/modules. First I think it can be very similar to a DCPwr class with some extensions.
What I do not understand yet how to deal with the frame and the channels (which can be different modules). When connecting to the frame you can do a Ask(*RDT?) which will return a list of channels. So I guess in the init() of the frame you query the *RDT? and than load the correct modules per channel. Example: frame is a 6312A with one channel installed a 63115A.

load = ivi.chroma.chroma6312A("USB0::xxxx::INSTR")
load.outputs['63115A'][0].mode = 'constant_current'     # as module can have multiple channels we need [module][channel]

Not sure if this is supported by IVI
You could always do:

load.outputs[0].mode = 'constant_current'

But i think it is more difficult to tell which channel is which.

@jeffery how did you solve this fir the Agilent?

[Jeffrey Wurzbach]

Hi Paul,

The Aglient load I used worked roughly the same way, except I did everything manually (I had complete configuration control over the load and no one messed with it, so auto config was not something I worried about).

-jeffw