Add new command DMM_CMD_SETUP_LOCAL for setting device back
to "local" mode. If device implmements this command, it is
sent when driver is closed and after device "scan".
Define DMM_CMD_SETUP_LOCAL for GWInstek meters, so they get
returned to local mode automatically after use.
Any order is as arbitrary as any other. The alphabetical order of vendor
and model names might be the most robust during maintenance: easiest to
remember, easiest to use when checking for presence, and easiest to add
to or resolve conflicts during merges. Vendor renames (HP to Agilent to
Keysight, et al) are ugly but can't be helped easily.
Address minor style issues: Need not assign NULL after g_malloc0(), need
not check for NULL before g_free(). Rephrase diagnostics messages which
are user visible by default, remove internal development details. Reword
a few comments, and adjust their grammar for consistency across the code
base. The sr_analog_init() routine executed immediately before getting
measurements, need not (re-)assign endianess or floating point details,
except those which do change after initialization (double vs float).
Rephrase model dependent checks for easier adjustment during maintenance.
Unobfuscate string comparisons.
The current implementation of the SCPI DMM driver is conservative about
checking the device's being operational, but the *OPC? queries are found
in unfortunate locations. Run the OPC query right before running the
next "actual" command, not afterwards. And certainly not between sending
requests and potentially gathering responses in subsequent calls.
This commit does not change current behaviour, but improves maintenance
before pending commits.
The "get MQ" helper routine communicates SCPI responses and translates
them to internal "MQ and flag" values. Optionally return the MQ table
entry reference to callers, so they don't have to repeat the table
lookup when the function's default precision is required, or should
future "start acquisition" requests need to refer to the meter's current
function.
Supported SCPI DMM devices will differ in the set of options and whether
parameters can get queried or configured. Use a "generic" set of devopts
during scan and for simpler models, prepare support for other sets of
devopts for more complex models.
Implement the scpi-dmm driver in such a generic way that it could work
with several protocol variants and with differing models which happen to
use any of these protocol variants. Prepare a list of supported models
with their respective SCPI command set, set of DMM functions and their
precision.
Add support for Agilent 34405A. The ten functions of this device got
tested and are operational, in continuous mode as well as with sample
count or capture time limits. The driver can query the current meter's
function, can change the function, and can run acquisitions in either
the current mode or with a user specified function selection. There is
some potential for improvement: AUTO/MIN/MAX/HOLD indicators are not
supported by this implementation.