DC sources

[MatthieuDartiailh]

I think it is time to start writing some drivers to find any remaining issues in the core (the subsystems instantiation might need some rework for examples). I will start with DC current/voltages sources. I have three at my disposition to try to define a kind of standard (Yokogawa 7651, Yokogawa GS200, and Bilt rack with high stability DC voltage source card), if anybody has some it would be interesting to share the manual. As I will be clearer what we can and can't do I will write real driver to serve as a base for the discussion.
We could also target Lock-in and RF sources in the near future I think.

Edited
The following diagram summarize the state of the discussion and the proposed standard hierarchy so far.

• driver :
  • output : channel
    • mode : Issue self-changing for some, settable for others, could be kept outside of the standard.
    • voltage : Float
    • current : Float
    • voltage_range : Unicode
    • current_range : Unicode
    • voltage_limit_behavior : Unicode, {'Trip', 'Regulate'}
    • current_limit_behavior : Unicode, {'Trip', 'Regulate'}
    • enabled : Bool, Issue self-changing is case of tripping
    • is_output_tripped : Action
    • measure : Action, optional
    • ovp/ovc (over voltage/current protection) : subsystem, optional
      • enabled : Bool
      • behavior : Unicode
      • level : Float
      • reset : Action
      • read_status : Action
    • trigger : optional, (to be discussed)
      • mode : Unicode
      • source : Unicode
      • delay : Float
      • arm: Action

[crazyfermions]

I have a fair amount of experience with DC sources, since our lab has about 8 different kind of source including high precision single sources like the Yokogawa 7651, custom built multi channel sources from Delft University as well as simple DAC cards.

I personally think we should start with the IviDCPwr specifications, since I found them very useful when programming my drivers.

[MatthieuDartiailh]

You can look at my associated PR. I basically followed ivi but took a bit of distance from it as not all instrument can be either voltage and current source and as the protection specification was not exactly fitting my instrument (I was not very motivated to implement stuff for hardcoded behaviour of the instruments but this is mainly laziness and being short on time). Please comment your input would be very valuable to me.

[crazyfermions]

First of all, I think you did a good job by implementing almost all the functions of the instruments which gives us a good starting point of the discussion. Let's focus for now on the Yokogawa drivers since the trigger feature of the BE* is a more advanced one which can be discussed later.

1) So far, no separation between the instrument itself and the output channel
Every device usually has instrument-wide settings and settings per channel (which is okay for the Yokogawa, but there exist many voltage sources with more than one channel). I think lantz supports sth. like a list of features, inst.voltagelevel[i] = xx, where i is the channel number. This leads to

2) Everything is now accessed as a method/attribute of the instrument
Here is the point where we should decide whether we want a flat API (everything inst.feat) or more like a tree with several levels, like inst.foo.feat, inst.bar.feat, ...
IVI divides the namespaces into logical groups, in this case inst.outputs[i].voltagelevel = xx. In IVI terms, this is called a "repeated capability", which makes intuitively sense because most instruments are in fact built like that (but I don't know if lantz supports sth. like that).
If I remember correctly, someone wrote that IVI tends be "over divisive" which might be true, but on the other hand I think it is not a good idea to have all functionality on one level, because it easily gets very messy and more difficult to work with the driver.

3) Access to lantz functionality
You should also have a look at inherent capabilities, if you haven't; it defines the API for generic instrument functions (mainly 3 different types of functionality groups, DriverOperation, Identity (also see *4 below) and Utility). While not everything makes sense to directly copy to lantz, the general idea is still valid, namely: DriverOperation handles driver options like caching (for lantz there could be the aspect of units for example), of course there can be no final decision before the featureset of lantz is fixed -- but I think this would be an important thing to put into an "official" API.

4) Access to *IDN?
IVI defines a standardized access to the *IDN? query, the idea of which I found useful.

I have some additional minor points, but I am out of time for now, maybe you can comment especially on 1) and 2), because these are the main issues here.

[MatthieuDartiailh]

I will try to answer all of your point :

1. Lantz does not support that kind of list of feature (python-ivi does) because it chooses a more object oriented approach where each channel is represented by a an object and then setting a feature on that object dispatch to the correct channel. This is what is done in the Bilt driver : the rack itself (BN100) is not a voltage source and does not follow the standard but the its channel BE2100 is a voltage source and follow the standard for voltage source.

bn100 = BN100('resource')
bn100.be2100[1].voltage = 1

Hence the yokogawa doe snot bother with channels as it has none, while we can easily add them to the Bilt.

2. I was the one who said IVI was over-divided to my taste. Meaning that if I have a voltage source I expect to directly access its voltage as it is its main setting. Lantz support hierarchical subsystems but I was thinking to reserve them for more advanced/clearly separated features, such as the features of a lock-in oscillator, the pulses management of a RF source (as suggested by IVI), and such. In IVI it seems there is nothing at the root of an instrument which I find weird.

3. I will give a look at the inherent capabilities and see how they can fit into the standards. Thanks for pointing this out.

4. I will see what IVI says about IDN. But note that access to IDN is already provided through the Identify mixin class found in standards.ieee4888. But there is probably room for improvement.

Thanks for your feedback and feel free to give more.

[alexforencich]

What if the card has more than one channel? I just took a look at the Bilt site, they will be releasing the BE2141 soon, which has 4 channels in one card. So you will need to support bn100.bn2141[m].channel[n].voltage . Might as well implement that now so you don't need to do that later, and so you can present a unified interface.

[MatthieuDartiailh]

We can easily do that using Lantz. We will be able to add that later, I would prefer to focus on stabilizing Lantz API and tests those drivers using pyvisa-sim for now.

[MatthieuDartiailh]

Furthermore I don't have access to the be2141 manual so I don't even know how the internal channel is selected.

[alexforencich]

The point is not to support switching channels, it's to create a uniform API that is self-consistent. Have a power supply? Change the voltage with [whatever].channels[n].voltage. Keep the channels[n] even if it only has one channel so that it will be consistent with devices that have more than one channel.

[MatthieuDartiailh]

I disagree such a system would not scale well. For the yokogawa you would end up with two level of nesting for an instrument which does not have even have channels ! From my point of view it makes more sense to require a certain type of interface for a function (DCvoltage source) and let the user code pass whatever is the appropriate object (full driver, subsystem or channel). Otherwise the day we discover an instrument composed of even more modules we would have to rewrite everything to add a false level of nesting.

[alexforencich]

I say it needs a channels[] layer for consistency. If you don't add that, then you end up with a very different API between single channel and multichannel power supplies, which is not very clean. And why would you need to rewrite everything to add a layer of nesting? Isn't the architecture set up in such a way that things can be nested easily? Besides, most instruments are not card-cage based, and even so, I would say one level for card cage and one level for channel is not so bad. And you would only implement the card-cage level for specific instruments that are built that way.

[MatthieuDartiailh]

I am still not convinced as this seems very artificial to me. I mean as we cannot hope to cover every corner case and stuff I would really prefer to have consistent subsystem and channels as I described above (meaning that if you only access the standard spec you can pass anything respecting the standard whether it be a full driver, a subsystem or a channel) rather than adding artificial layers. I would really like the others point of view on that. @hgrecco, @arsenovic Could you please comment on this ? @crazyfermions your opinion is of course welcome.

[alexforencich]

Take the Agilent E3633A and E3631A power supplies, for example. One has 3 outputs. One has a single output. As per the IVI spec, both power supplies present the same interface, psu.channels[0].voltage_level, etc. even when only one channel is present. So, you are recommending that we implement two non-interchangeable APIs within the same line of power supplies from the same manufacturer, just because some of the power supplies only have 1 channel and hence do not need a channels[] layer? And the same goes for your mainframe, as it appears that they have power supply cards with multiple channels. Is it really a good idea to completely reorganize the API for devices with more than 1 channel, just to remove one layer for devices that have only 1 channel?

[MatthieuDartiailh]

I see your point. What kind of bothers me is that we will end up having that everywhere : for any instrument we will have to assume that one vendor created a multiple channels version even if we don't know about one yet (I got a two channel RF signal generator two weeks ago, while all my previous where single channel ones). I really need to think about that...

[alexforencich]

That's a good point. I think it might make the most sense to implement the 'extra' layer when a device is commonly available as a multichannel device for consistency - things like power supplies and arbitrary waveform generators - and then implementing devices that are commonly single-channel as multichannel devices only when necessary for the particular series.

[MatthieuDartiailh]

We could do a kind of hack by using getattr (which is called only if an attribute is nowhere to be found). What we would do would be to match the name against something like 'any character'[0]' and if we have a match we return self. This way we write flat instrument and if somebody needs to use in an indifferentiate fashion instruments with and without channel he can. WDYT ?