Drivers: structure of the package and drivers for DC power source#9
Drivers: structure of the package and drivers for DC power source#9MatthieuDartiailh wants to merge 29 commits intomasterfrom
Conversation
They would be worth to expand !
Codecov Report
@@ Coverage Diff @@
## master #9 +/- ##
=======================================
Coverage 98.68% 98.68%
=======================================
Files 28 28
Lines 2282 2282
=======================================
Hits 2252 2252
Misses 30 30 |
|
A few quick documentation questions: section 4.1.1 |
|
Just pushed a documentation fix. The quick answer is |SubSystem| for the first and mro: Method resolution order for the second (hence we use the left most class in the class declaration that defines a particular subsystem/channel). |
lcontami
left a comment
lcontami
left a comment
There was a problem hiding this comment.
Had a quick look, didn't test anything on a real source.
The Bilt driver is not done right ? I can see different elements coded but I don't see how they come together.
i3py/drivers/base/dc_sources.py
Outdated
| #: Care should be taken that this value may not be up to date if a | ||
| #: failure occurred. To know the current status of the output use | ||
| #: read_output_status, this feature only store the target setting. | ||
| o.enabled = Bool(aliases={True: ['On', 'ON', 'On'], |
There was a problem hiding this comment.
'On' written twice; I guess you meant on
i3py/drivers/base/dc_sources.py
Outdated
| o.voltage_range = Float(unit='V') | ||
|
|
||
| #: How does the source behave if it cannot reach the target voltage | ||
| #: because its reached the target current first. |
There was a problem hiding this comment.
typo: its -> it
(idem later on for voltage_limit_behavior)
| o.voltage = Float(unit='V') | ||
|
|
||
| #: Range in which the voltage can be set. | ||
| o.voltage_range = Float(unit='V') |
There was a problem hiding this comment.
Is a float sufficient ? Don't you need a tuple ?
(certain sources can have a range - lim -> + lim, others 0 ->lim.
There was a problem hiding this comment.
For the one I add access to so far it is sufficient. But a source can add stricter limitation like the Bilt does. The fact is that there is never a direct mapping between the range and the associated limits.
|
|
||
| @o | ||
| @Action() | ||
| def read_output_status(self) -> str: |
There was a problem hiding this comment.
Is it the type annatotation that bothers you or the double decoration ?
There was a problem hiding this comment.
the type annotation. I saw the python page about it. I didn't know it existed !
i3py/drivers/yokogawa/gs200.py
Outdated
| """Driver for the Yokogawa GS200 DC power source. | ||
|
|
||
| Because the over-voltage (current) protection is always enabled in | ||
| current (voltage) mode, they basically act as limits and fully the same |
i3py/drivers/yokogawa/gs200.py
Outdated
| o.voltage_range = set_feat(getter=True, | ||
| setter=':SOUR:RANG {}', | ||
| checks=(None, 'driver.mode == "voltage"'), | ||
| values=(10e-3, 100e-3, 1.0, 10.0, 30.0), |
There was a problem hiding this comment.
You could use your VOLTAGE_RESOLUTION keys instead of rewriting it (idem below)
| if self.mode == 'current': | ||
| ran = to_float(self.current_range) # Casting handling Quantity | ||
| res = CURRENT_RESOLUTION[ran] | ||
| if ran != 200e-3: |
There was a problem hiding this comment.
Great behavior from the source :D
|
The bilt is complete and tested (just like the others, as far as the test scripts do their job at least). You need to look at the base class of the rack which declares the modules it can drive. |
|
FYI there's a pytest notice in the CI log:
|
|
Thanks @bilderbuchi I fixed that in other repos but I forgot this one. |
|
@lcontami @galactikvoyager feel free to merge when you have no more questions. |
4 participants
So far only the "standard" for DC power source is implemented and used for:
@Exopy/owners I would appreciate if you can give this a look, hopefully the documentation (http://i3py.readthedocs.io/en/latest/?badge=latest) should be enough to understand the magic happening behind the scene. I would appreciate to get as much feedback as possible since this is the future for drivers.
I will work on implementing a generic task giving access to any feature/action of such a driver which will reduce the burden of developing super specific task for just setting a parameter.