While writing up a VNA class instrument, I am looking at how to handle multiple traces, windows, and markers.

For a Keysight 5071 two port VNA, you have 16 channels available for rapidly switching between different configurations. Each channel has upto 16 unique traces that could be S-parameter measurements or absolute measurements that take the ratio between a port or two ports and displayed in various formats like using Logmag, Polar Plot, Smith Chart, phase, etc.

Shared between the up-to 16 traces for a channel are 8 markers.

Is it possible to nest channels within channels to account for both a channel and a trace? I am going to experiment to see if I can but I figured it wouldn't hurt to ask and try to explain what I am trying to do.

One instance is a SCPI command CALC{ch}:PAR{tr}:DEF S12 to set trace of a channel to measure S12.

It looks like it might be possible to assign trace 1-16 to channels 1-16, or at least define how many channels and how many traces are to be used when initializing a Instrument so that I could chain the trace to the channel like this vna.ch_1.trace_1.measurement_parameter = 'S12' as long as I initialize the traces in the channel class with something other than 'ch_ as the placeholder.

Another example would be reading the value of multiple markers. If I have a phase plot and I want to read the phase of marker 3 on trace 5: print(vna.ch_1.trace_5.marker_3.value) or print(vna.ch_1.marker_3.value). The SCPI command in this instance would be CALC{ch}:MARK3:X? which simply reads the currently active trace for the channel. I am trying to avoid using tuples to pass which marker to select and what frequency to to move it to for readability.

Another case is I have to first send a command to declare how many traces are used for the channel before selecting a trace to define its parameters by sending CALC{ch}:PAR:COUN {1-16} for the number of traces on that channel.

It would be nice to be able to chain the properties of the instrument so the active channel and the active trace could be kept track of to switch to the appropriate channel, trace, marker, etc or issue the necessary commands to allow use when needed but not slow down the communication by sending them when not needed.

I'll experiment with nesting the MultiChannelCreator function within Channel classes.

I think I can use the get_process and set_process to intercept the selected trace, channel, marker, or whatever value to identify if I need to issue commands first before completing the command to ensure it executes successfully such as making a trace active.

I would like to dynamically update the channels, traces, markers available as instrument properties but I think its not possible with how the library is written to prevent overwriting instrument properties.