Add remote/local handling for VXI-11 and HiSLIP - #636
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #636 +/- ##
==========================================
+ Coverage 44.19% 44.78% +0.59%
==========================================
Files 30 31 +1
Lines 5410 5468 +58
Branches 531 534 +3
==========================================
+ Hits 2391 2449 +58
Misses 2987 2987
Partials 32 32
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
MatthieuDartiailh
left a comment
There was a problem hiding this comment.
So we add all the required pieces at the protocol level but missed the high level bits... Thanks for the PR !!!
| deassert_gtl goto local disable remote, goto local | ||
| ================ =========== ========================================= | ||
|
|
||
| This is fully conform to what NI-VISA does. |
There was a problem hiding this comment.
Parity with NI-VISA is good but did you check the visa specs ? Some of the above are a bit surprising for VXI-11 (LLO that works but does not lock is weird).
There was a problem hiding this comment.
2 rules:
RULE 6.5.6
An INSTR resource implementation of viGpibControlREN() for a TCPIP System SHALL support the
modes VI_GPIB_REN_DEASSERT_GTL, VI_GPIB_REN_ASSERT_ADDRESS, VI_GPIB_REN_ASSERT_ADRESS_LLO,
and VI_GPIB_REN_ADDRESS_GTL.
OBSERVATION 6.5.1
For a TCPIP device using VXI-11, the modes VI_GPIB_REN_DEASSERT_GTL and
VI_GPIB_REN_ADDRESS_GTL behave identically, putting the device into local mode. Similarly, the modes
VI_GPIB_REN_ASSERT_ADDRESS and VI_GPIB_REN_ASSERT_ADRESS_LLO behave identically, putting the
device into remote mode.
100% conform.
There was a problem hiding this comment.
But I'll adapt the faq to mention that
| valid_modes = ( | ||
| constants.RENLineOperation.address_gtl, | ||
| constants.RENLineOperation.asrt, | ||
| constants.RENLineOperation.asrt_address, | ||
| constants.RENLineOperation.asrt_address_llo, | ||
| constants.RENLineOperation.asrt_llo, | ||
| constants.RENLineOperation.deassert, | ||
| constants.RENLineOperation.deassert_gtl, | ||
| ) |
There was a problem hiding this comment.
This should be a module level constant (private and marked Final).
There was a problem hiding this comment.
overriden by later comment
| method = { | ||
| constants.RENLineOperation.address_gtl: "justGTL", | ||
| constants.RENLineOperation.asrt: "enableRemote", | ||
| constants.RENLineOperation.asrt_address: "enableAndGotoRemote", | ||
| constants.RENLineOperation.asrt_address_llo: "enableAndGTRLLO", | ||
| constants.RENLineOperation.asrt_llo: "enableAndLockoutLocal", | ||
| constants.RENLineOperation.deassert: "disableRemote", | ||
| constants.RENLineOperation.deassert_gtl: "disableAndGTL", | ||
| }[mode] |
There was a problem hiding this comment.
Same, the dict should be a module level constant.
There was a problem hiding this comment.
overriden by later comment
| # Override parsed to take into account the fact that this class is only used | ||
| # for a specific kind of resource | ||
| parsed: rname.TCPIPInstr | ||
|
|
There was a problem hiding this comment.
interface should be narrowed to hislip. Instrument here rather than cast in all methods.
There was a problem hiding this comment.
didn't touch that. Not sure how that will play out, since VXI-11 and HiSLIP use the same methodology. I remember seeing it used/abused somewhere. And there are no VXI11 nor HiSLIP versions of TCPIPInstr.
But can be done, as well as the casts. But if I do this here, the hislip event PR will be a mess to merge. Can we keep that till then or after then?
| constants.RENLineOperation.deassert, | ||
| constants.RENLineOperation.deassert_gtl, | ||
| ) | ||
| if mode not in valid_modes: |
There was a problem hiding this comment.
You could catch the KeyError when looking up the method to avoid 2 look ups.
| ) | ||
|
|
||
|
|
||
| class TCPIPInstrHiSLIP(Session): |
There was a problem hiding this comment.
This class is used only for hislip so it should not cause issues with vxi-11 to properly type the interface attribute. What issue do you foresee for the event support (apart from less casts) ?
There was a problem hiding this comment.
Well, can do it, but I'd prefer to do it after we merged some, as there are quite some overlaps, and I prefer to keep the number of open branches minimal. Let's mark that for a next issue?
| method = { | ||
| constants.RENLineOperation.address_gtl: "justGTL", | ||
| constants.RENLineOperation.asrt: "enableRemote", | ||
| constants.RENLineOperation.asrt_address: "enableAndGotoRemote", | ||
| constants.RENLineOperation.asrt_address_llo: "enableAndGTRLLO", | ||
| constants.RENLineOperation.asrt_llo: "enableAndLockoutLocal", | ||
| constants.RENLineOperation.deassert: "disableRemote", | ||
| constants.RENLineOperation.deassert_gtl: "disableAndGTL", | ||
| }[mode] |
There was a problem hiding this comment.
The previous comment on making this a module/class constant still applies.
There was a problem hiding this comment.
moved. I kept the passage from one dict to another (in hislip.py), as this keeps it readable.
| # need to define session_type to make the set_attribute machinery work. | ||
| session_type = (constants.InterfaceType.tcpip, "INSTR") | ||
|
|
||
| REMOTELOCALOPCODE: Dict[constants.RENLineOperation, str] = { |
There was a problem hiding this comment.
| REMOTELOCALOPCODE: Dict[constants.RENLineOperation, str] = { | |
| REMOTELOCALOPCODE: Final[dict[constants.RENLineOperation, str]] = { |
You may need to import Final from typing.
There was a problem hiding this comment.
yes! was fighting with that. dict in lowercase.....
Done
| ) | ||
|
|
||
|
|
||
| class TCPIPInstrHiSLIP(Session): |
|
strange, my ruff version (latest on python 3.14) did not complain. |
Co-authored-by: Matthieu Dartiailh <marul@laposte.net>
Co-authored-by: Matthieu Dartiailh <marul@laposte.net>
for more information, see https://pre-commit.ci
pre-commitwith no errorsA not so easy merge will be needed between this PR and #633 and potentially also #626
The order of the merges is not important, but I'll need to adapt the code between them. Unless you want to merge them all in one PR.
#626 is the lowest priority of the 3 to me.