Siglent extension#1
Merged
Merged
Conversation
Read the device-measured power (watts) from the Sigilent backend via MEAS:POWE?, exposed both as new power_watts() helper and as an extra field of power_show(). The 'labgrid-client power show' output now also prints the power value. This work was sponsored by OIP Sensor Systems Signed-off-by: oip <thomas.vreys999@gmail.com>
Add tests for the Siglent power backend (on/off/get, show including the measured power, and voltage/current configuration) and document the power show/config actions in the configuration, usage and development guides. Regenerate the labgrid-client man page for the new power sub-actions and options. This work was sponsored by OIP Sensor Systems Signed-off-by: oip <thomas.vreys999@gmail.com>
Rubusch
approved these changes
Jul 19, 2026
Rubusch
left a comment
Owner
There was a problem hiding this comment.
LGTM. Note, I cannot verify reading out Watts, my available Hardware does not offer reading out power directly, so I guess you probably verified it.
- I just noted, you are modifying client and siglent driver, so, there was no need to adjust also the power protocol? AFAIR I needed to add still something to make this work for U and I. Perhaps just double-check this.
- About the tests, also here I'm unsure if this is needed, but reading out Current, Voltage and Power is highly optional. Shouldn't there be a test that, not having these settings around, or just having Voltage and Current around, but not power (...), does not break? Perhaps this is already covered by other tests.
BTW. I highly appreciate your effort, thank you so much! This to me answered now many questions on how to document and how integrate the test setup. I'm sorry that you needed to fixed actually the not-so-fun parts (documentation and tests) for me.
Author
|
I did make another PR: #2 where I answered your comment. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This builds on top of your
lothar/siglentbranch (upstream PR labgrid-project#1926) and is intended to be picked up there, so the upstream PR can be completed with the open checklist items.It adds reading the measured power from the device, as suggested by @vermaete in the upstream review:
siglentbackend: queryMEAS:POWE? CH<n>inpower_show()(newwattskey) and add a dedicatedpower_watts()function. The power is read directly from the instrument.labgrid-client power shownow prints the power, e.g.:remote/client.py:showno longer queries the PSU twice (thedrv.show()result was fetched and then fetched again), and the unusedProgrammablePowerProtocolimport is removed.It also completes the checklist items from the upstream PR:
tests/test_powerdriver.py.doc/configuration.rst,doc/usage.rst,doc/development.rst.man/labgrid-client.1.How it was verified
tests/test_powerdriver.py.NetworkPowerDriver.Checklist
Outlook: USB support
I would also like to support USB-connected PSU's. That doesn't fit the current design: the backend is built on
NetworkPowerDriver/NetworkPowerPort, which assumes a network transport (host + TCP socket), and the backend hardcodes theTCPIP0::<host>::5025::SOCKETresource string. Since PyVISA can already talk to the same devices viaUSB0::...resource strings, the cleaner long-term structure is a dedicatedSiglentSPDDriverbound to a PyVISA resource, where the transport (TCPIP or USB) comes from the YAML configuration instead of being baked into the driver. I have a first draft of that locally and would propose it as a separate follow-up PR, happy to discuss the direction here.