Michele Sardo

@bilderbuchi I agree some guidelines could be extremely useful, prior to this I would make some effort to clarify the software architecture and what we target with `Instrument` and what...

In my understanding, looking at the code, I see the following: - Adapter class/subclasses: they allow to abstract different physical instrument interfaces, for example: VISA, Serial, Telnet, Prologix. Probably Serial...

> > > Are users allowed to reimplement read and write method when subclassing Instrument? In which cases ? > > The most frequent pattern is Channel classes derived from...

> Huh, I never understood our "adapter" as a (GoF) design pattern, but as encapsulating the hardware comm/protocol side of things (as opposed to the command set, which belongs to...

My gut feeling is that last draft proposal from @bilderbuchi is preferred. In my mind, it is a more linear approach. Some points are not clear to me, for example:...

> > Regarding the Instrument write/read/ask/values methods, I would define them as proper method and not as bypass to the Adapter class. > > I'm afraid I don't fully understand....

> > My gut feeling is that last draft proposal from @bilderbuchi is preferred. > > Sorry for not numbering my alternatives. I'm assuming you mean this approach "put the...

@bklebel thanks a lot for your effort and energy to try to shed some light in this complex subject. > Did I understand you correctly now? (sorry for the lengthy...

Unfortunately Prologix is not supported by `pyvisa `and this is, I believe, the only reason why `SerialAdapter `exists.

Indeed, my idea was to make the parameters available as command line options to be able to configure them. Obviously the graphic part will not be available, but log messages...