WIP : DC sources

[MatthieuDartiailh]

This is heavy WIP but I like the idea of having feedback as soon as possible (at least on general stuff like the structure).
For the time being I separated the standards into their own package (with a subpackage for SCPI as to me it is never a really functional driver). I tried to inspire myself from ivi but I need to add more stuff.

Please comment @LabPy/owners (and also look at LabPy/lantz_core#7 needed for Yokogawa 7651).

[MatthieuDartiailh]

The main parts of the drivers are implemented. I will let the programming capabilities of the Yokogawas for a latter PR and the measurement also (will come back to it when dealing with multimeters as the GS200 looks a lot like one when it comes to measurements). Of course I still need to test this (and for that I will need to expand pyvisa-sim) but I would appreciate comments.

[MatthieuDartiailh]

I added some of the standards commands defined by the IEEE488 (got them from slave as it has the nicest separation from my point of view). I have not implemented all of them but the most common are there.

[MatthieuDartiailh]

I just moved to the channel based stuff. Actually one thing do bother me and I would like your opinions @LabPy/owners. In the BE2100 that I considered as a full DC voltage source (considering that each card in a rack should act pretty much as an independent instrument), I ended up putting everything even the trigger subsystem into the channel as I don't know how the new card will work (given what the trigger does it looks more natural).
Test are still missing but a review would be nice.

[alexforencich]

I have not looked at the trigger system yet, but I will say that 'mode' is a very uncommon parameter in power supplies. Generally they only have voltage and current limits and occasionally overvoltage and overcurrent limits. All of the supplies that I have access to or have programming manuals for will automatically switch between current and voltage mode based on the characteristics of the load (tektronix, agilent, rigol, chroma). They have separate source:current:level and source:voltage:level commands and no source:mode command. The IVI spec also uses voltage_level and current_limit and has no provisions for mode.

[alexforencich]

Also, accessing the same instrument parameter from two different driver parameters is going to completely screw up the cache and possibly cause damage to a DUT. Something needs to be done to prevent this. Not sure if that means reworking the interface so there is a 1:1 mapping or perhaps changing the mode when one of the driver parameters is changed. Or 'locking out' or disabling one of the driver parameters and either ignoring the setting or throwing an exception.

[MatthieuDartiailh]

I indeed forgot to discard the cache when switching mode I will add it. Actually looking at the base classes you will notice that the voltage related stuff enforces mode == 'Voltage' and it is the same for current.
Could you please either update the wiki with your instruments or at least send me the manuals, I cannot guess what they look like. I must say I am a bit surprise you say they have no mode, does it mean that they are voltage only sources and that you can only regulate the current ?
I use those sources to apply DC voltage on gate electrodes I do not want them to decide on their own that they should try to enforce a current but yours might be different. They have a mode because they can act both as voltage sources and as current sources if yours can only be used as voltage sources then they should inherit from DCVoltageSource which has no mode.

[alexforencich]

All of the supplies I have seen have a voltage limit and a current limit and will switch between them automatically. Perhaps I set the supply for 5V and 3A. So long as the load requires less than 3A, it will get it at 5V. Now, if the load impedance drops, the current will peg at 3A and the voltage will drop to less than 5V. The supply automatically switches over to current mode and then back to voltage mode. Now, there is usually a status register that can be read to see what mode it is in, but cannot be set manually.

Alex Forencich

On June 6, 2015 4:01:26 AM PDT, Matthieu Dartiailh [email protected] wrote:

I indeed forgot to discard the cache when switching mode I will add it.
Actually looking at the base classes you will notice that the voltage
related stuff enforces mode == 'Voltage' and it is the same for
current.
Could you please either update the wiki with your instruments or at
least send me the manuals, I cannot guess what they look like. I must
say I am a bit surprise you say they have no mode, does it mean that
they are voltage only sources and that you can only regulate the
current ?
I use those sources to apply DC voltage on gate electrodes I do not
want them to decide on their own that they should try to enforce a
current but yours might be different. They have a mode because they can
act both as voltage sources and as current sources if yours can only be
used as voltage sources then they should inherit from DCVoltageSource
which has no mode.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[MatthieuDartiailh]

Ok then it means that I was wrong in considering the Yokogawas as power sources as they definitively don't act the way you describe. They are more like a combination of a pure DC Voltage source and a pure DC current source : in voltage mode only the current limit can be specified and the source trip if it cannot reach the specified values (and vice versa). Should I rename the base class to DCVoltageCurrentSource instead of DCPowerSource or should I for the time being get completely rid of it ?
I actually just checked the IVI driver registry, Yokogawa as a vendor is listed but the two sources I am using are not listed, which supports my idea that they do not fit the standard.

[MatthieuDartiailh]

I started to update the drivers to the most recent development of #3. This is heavy wip and actually to make it tractable I will have to add new construct to the core (constant, conditional, LinkedTo, Alias) but I will open new issues in the core repo for that. Nonetheless some comments would be nice.
Because none of the instrument truly the standards some Feature becomes dummy ones in certain cases that are read-only and have a fixed value. This allows to present the same common interface.

[alexforencich]

What's the deal with the ranges on the agilent devices? The E3631A has only one range per output, while the E3633A has two ranges (0-8V, 0-20A or 0-20V, 0-10A). I think most of the devices in the E36xxA series have a switchable high range/low range on each output, the E3631A being the exception as it does not have this feature. So the E3631A should have a single entry in each of the range specifiers, and they will be different for each channel, while the E3631A will have two entries for its single channel.

[MatthieuDartiailh]

Sorry I added the files but I have not really started yet to work on those two. I hope to do some work today. Otherwise it will have to wait for a week as next week will be pretty busy.

[alexforencich]

I see. Also, how does the limit checking work with the resolution? If the device only supports, say, 1 mV increments and I try to set the output to 1.2345 volts, will the driver coerce that to the closest allowed value and accept it, or will it throw an error and reject it? I certainly understand complaining about an out of range issue, but if it also complains about getting too many significant figures we may have to add a configuration option to turn that off.

[MatthieuDartiailh]

Currently it raises and error. We could make it automatically round but it may be tricky as dome instruments (Bilt) have non unit step (1.2 muV).

[alexforencich]

Oh, that has the potential to get extremely annoying very, very quickly. Just saying. We need to be able to disable that. Possibly by default.

[MatthieuDartiailh]

Could you open an issue in lantz_core for that so we do not forget to address it. Also for the time being the returned value when we have unit support is a Quantity. As you are not super fond of that if I remeber correctly we could also add an option about this.

[MatthieuDartiailh]

I made some progress on the keysight drivers (I will refactor the common points into a base class later).