Best practice for using InstrumentChannel in SCPI-based drivers

[Q-TWil]

I’m working on writing a set of instrument driver based on an SCPI command set, and I’m unsure about the best way to use the InstrumentChannel class. As an example I'll be referring to the Rigol DG800/DG900 Pro series of AWGs. The programming guide with the SCPI commands can be found here.

My question is:

1. Should InstrumentChannel be used as an abstraction of the physical channels on the device (e.g., the input channels of an oscilloscope)? For instance, for the DG800 Pro, the :OUTPut[<n>]:LOAD and [:SOURce[<n>]]:AM:SOURce commands would be captured by parameters in the same class :

class DG800Channel(InstrumentChannel):
   def __init__(self, parent: InstrumentChannel, name, ch_number):
        super().__init__(parent, name)

        self.add_parameter("output_load", set_cmd=f":OUTPut{ch_number}:LOAD",...)
        self.add_parameter("source_am_source", set_cmd=f":SOURce{ch_number}:AM:SOURce",...)

2. Or is it better to use InstrumentChannel to represent parts of the SCPI command hierarchy instead? In this case, one would create sperate InstrumentChannel classes for all :SOURce[<n>]: commands and another for all :OUTPut[<n>]:, essentially replicating the SCPI hierarchy:

class DG800Output(InstrumentChannel):
   def __init__(self, parent: InstrumentChannel, name, ch_number):
        super().__init__(parent, name)
        self.add_parameter("load", set_cmd=f":OUTPut{ch_number}:LOAD",...)

class DG800Source(InstrumentChannel):
   def __init__(self, parent: InstrumentChannel, name, ch_number):
        super().__init__(parent, name)
        self.add_parameter("am_source", set_cmd=f":SOURce{ch_number}:AM:SOURce",...)

I'm asking because I came across this PR QCoDeS/Qcodes_contrib_drivers#352 which uses the later approach.

What is the recommended best practice here? Should InstrumentChannel primarily reflect physical channels, or is it preferable to mirror the SCPI command hierarchy?

[jenshnielsen]

Hi @Q-TWil, the first method is what was originally intended and as far as I know what most drivers implement. I think this is a better match since ChannelList/Tuple is designed as a container for identical channels where you can run the same command on all channels.

e.g. something like

myinstr.channels.voltage(10)

Which would set the voltage on all channels in the container.

Something like this will not work well if you have an output and a source channel that are different.

[Q-TWil]

Thanks, that indeed seems to be the better abstraction.

That being said, I suppose it would still be possible to make e.g. two ChannelList/Tuple for the source and output commands respectively. Something like:

myinstr.output.load(50)
myinstr.source.am_source(1)

where myinstr.output is a ChannelList/Tuple for all the :OUTPut[<n>]: commands, and myinstr.source is a ChannelList/Tuple for all the :SOURce[<n>]: commands. This would set the output load and am modulation source for all channels.

[jenshnielsen]

Yes from an API perspective I don't see any problems in that. What makes the most sense for a specific instrument probably depends on the specific instrument and how many subcommands it has for each group (source, output etc)