InstroELoad
InstroELoad is a hardware abstraction layer (HAL) that provides a unified interface for programmable electronic loads. The category class defines the vendor-independent API (set_mode, set_level, get_voltage, …). A vendor-specific driver (e.g. BK85XXB) owns its connection details and translates those calls into vendor commands.
Supported Vendors
- B&K Precision: 85xx Series via SCPI/VISA (
BK85XXB)
Key Concepts
Driver Composition
AInstroELoad is built from a concrete driver:
BK85XXBowns the connection setup and vendor-specific command mapping.InstroELoadowns the category-level workflow: measurements, commands, publishers, the background daemon.
Lifecycle
The typical InstroELoad workflow:- Construct: instantiate the vendor driver and pass it to
InstroELoad. open(): establishes the VISA connection.- Configure and measure: set operating mode, level, range, and read measurements.
start(): begins a periodic background daemon. (Optional)stop(): ends the background daemon (if started).close(): disconnects from hardware.
Operating Modes
Electronic loads can operate in four modes:- CC (Constant Current): the load draws a constant current regardless of voltage
- CV (Constant Voltage): the load maintains a constant voltage across its terminals
- CR (Constant Resistance): the load simulates a constant resistance
- CP (Constant Power): the load draws constant power
Mode Configuration RequiredThe operating mode must be set using
set_mode() before you can configure the level or range. Not all electronic loads support all four modes. Consult your instrument’s manual.Creating a InstroELoad Instance
Parameters
name: A name for this electronic load instance. Used as a prefix for channel names when publishing.driver: A concreteELoadDriverBaseinstance (e.g.BK85XXB) configured with the connection details for that model.publishers: Optional list of publishers to attach.**kwargs: Additional keyword arguments become default tags when using a publisher that supports tags (likeNominalCorePublisher).
Choosing a Driver
Choose the concrete driver that matches the electronic load model, then pass the instrument connection settings to that driver. For B&K Precision 85xx Series loads, useBK85XXB with the VISA resource string for the instrument.
To inspect a VISA instrument’s identity before choosing a driver:
Examples
All measurement methods returnMeasurement objects. This is common amongst all Instrument objects.
Basic Usage
Background Daemon for Continuous Monitoring
start()begins a background daemon, executing a function or list of functions periodically.stop()ends the background daemon.
Default ELoad Background DaemonFor each :
- Output voltage (via
get_voltage()) - Output current (via
get_current())
background_interval property.- To define your own background daemon, call
define_background_daemon(method, *args, **kwargs), which replaces the registered daemon functions. - To add a method to the background daemon stack, call
add_background_daemon_function().
Important Note about PublishersData is published as a direct result of an instrument method being called.For example, when you call
get_voltage(), this not only queries the instrument for the voltage but also causes all attached Publishers to publish the measurement response automatically.Therefore the background daemon, when calling these instrument methods, is publishing data in the background as well!Published channels
Every measurement/command call produces a channel keyed under{name}.{descriptor}, where {name} is the constructor argument and {descriptor} is the row below. Substitute {N} with the actual channel number (1, 2, …). If you need the pre-v1.0 channel names instead, pass legacy_naming=True to the constructor.
| Method | Descriptor | Type |
|---|---|---|
set_mode(channel=N) | ch{N}.mode.cmd | command |
set_level(channel=N) | ch{N}.level.cmd | command |
set_range(channel=N) | ch{N}.range.cmd | command |
set_slewrate(channel=N) | ch{N}.slewrate.cmd | command |
output_enable(channel=N) | ch{N}.enabled.cmd | command |
short_output(channel=N) | ch{N}.short.cmd | command |
get_voltage(channel=N) | ch{N}.voltage | telemetry |
get_current(channel=N) | ch{N}.current | telemetry |
Method Reference
| Method | Purpose |
|---|---|
InstroELoad(name, driver, publishers=None, legacy_naming=False, **kwargs) | Construct a InstroELoad with a vendor driver |
open() | Establish VISA connection to the electronic load |
close() | Disconnect from electronic load and close all publishers |
set_mode(mode, channel=1) | Set operating mode (CC, CV, CR, or CP) |
set_level(value, channel=1, curr_limit=None) | Set the operating level (A, V, Ω, or W depending on mode) |
set_range(value, channel=1) | Set the operating range for auto-ranging |
set_slewrate(direction, rate, channel=1) | Set current slew rate in A/μs |
output_enable(enable, channel=1) | Enable (True) or disable (False) the load input |
short_output(enable, channel=1) | Short the load channel (occurs immediately) |
get_voltage(channel=1) | Read measured input voltage |
get_current(channel=1) | Read measured input current |
start() | Begin background telemetry daemon |
stop() | End background telemetry daemon |
Custom Driver Development
This section is for developers implementingInstroELoad support for electronic loads that aren’t supported out of the box.
Overview
Driver developers subclassELoadDriverBase and own whatever transport their instrument needs. The caller chooses a concrete driver, and that concrete driver exposes connection parameters that make sense for its protocol:
InstroELoad’s vendor-independent API (set_mode, set_level, get_voltage, …) into vendor-specific commands.
Driver Responsibilities
An electronic load driver must:- Expose a protocol-native constructor: accept inputs like
visa_resource,host,port,unit_id,interface, ornode_id, depending on the instrument. - Own transport setup: create and store the transport internally. Do not require users to pass a
VisaDriver, socket client, Modbus client, or other transport object. - Own lifecycle: implement
open()andclose()by opening and closing the underlying transport. - Map commands: translate each abstract method into vendor-specific commands.
- Parse responses: convert instrument responses to the expected Python types (
float,bool, etc.).
ELoadDriverBase Interface
All electronic load drivers subclassELoadDriverBase and implement these abstract methods:
_check_errors() helper and call it from your write/query paths (see the representative driver below).
Talking to the Instrument
Concrete drivers should hide transport details behind private attributes. For VISA-backed drivers, create aVisaDriver internally and use it for all I/O:
self._visa.write(command): Send a SCPI command (no response expected).self._visa.query(command): Send a SCPI query and receive the response string.
VisaDriver owns the resource lock. Concurrent write / query calls against the same driver are serialized automatically.
See the VisaDriver guide for the full transport reference, covering configuration, terminators, timeouts, serial settings, and the raw-byte I/O path.
For non-VISA instruments, follow the same shape with the protocol client your driver needs:
Implementation Example: B&K Precision Driver
Here’s the complete driver implementation for B&K Precision 85xx Series electronic loads:Using a Custom Driver
For drivers that aren’t shipped in the library, constructInstroELoad with your own driver instance. The driver should accept connection settings directly and create its transport internally:
Summary
Driver development requires careful mapping of vendor-specific behavior to the unifiedInstroELoad interface. Focus on:
- Subclassing
ELoadDriverBase - Designing a constructor around natural connection parameters for the instrument
- Hiding transport construction inside the driver
- Implementing all abstract methods on
ELoadDriverBase - Using the correct vendor protocol or command syntax
- Converting instrument responses to the expected Python types
- Adding a private
_check_errors()helper if your vendor exposes an error queue or status register - Testing with actual hardware to ensure commands work as expected