-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-channel instrument consistency #156
Comments
I scrapped all my progress on this and started again. I finally have the start of this refactor with all the tests passing. |
I am currently tackling this in the The approach I'm taking is to attach a Next, the abstract classes are given an abstract For both of these functions, they conditionally call the other, based on the value of This change is a drop-in improvement for all the existing instrument drivers that inherit from these base instruments and only have 1 channel. It gives a consistent API across similar instruments independent of the number of channels. |
Taking a look at the changes required to do this for the |
Since this is on the list for v1 as well, I wanted to see if I can help out with it as well (I don't there touch the async task...). As far as I can see, the |
Yeah, That goal is something similar for most of the base images, but maybe this isn't needed for v1. And honestly the async stuff should just wait. We can keep adding features for years and just continue the versioning paralysis. |
So I've been working on the PR for the Minghe MHS5200 (PR #150). The problem here is that this is a multi-channel function generator, which was not taken into account in the original
FunctionGenerator
ABC. What I'm trying to do is make sure that a user can go from a single-channel fgen to a multi-channel fgen without having to change any of their program code.Here is an example use case. Lets say a user starts with a single-channel fgen, like so:
Then, the user moves up to a multi-channel function generator, but is only using the first channel. This is not a new problem for IK; we already have single-/multi-channel instruments (eg, power supplies). However in this case, the
FunctionGenerator.amplitude
property is the tricky one. The ABC provides a concrete getter/setter, which in turn call_get_amplitude_
and_set_amplitude
. This is because the concrete impl provides the support for amplitudes specified in Vpp, Vrms, or dBm.After playing with different combinations of ABCs, conditional decorators, etc etc, I think the best course is to do some refactoring. What I'm proposing is that, for development, we treat all of these single- vs multi-channel instruments as multi-channel, but with just one channel.
So how would this work? Basically in development, you would work assuming you are developing a >1 channel device, but you would just set
_channel_count = 1
in the constructor. Then, by inheriting fromFunctionGenerator
, you also get a set of concrete properties that pass requests onto the appropriate channel.Let me show you:
Now you'd have a consistent API independent of which direction (single to multi, or multi to single) you move in. It also simplifies development, since all instruments of the same type are developed in the exact same way.
It does leave one open question about implementation specifics, but I'll type that up later.
The text was updated successfully, but these errors were encountered: