MeasurementFunctionMapping in ivi.scpi.dmm

59 views
Skip to first unread message

Alson van der Meulen

unread,
Aug 3, 2017, 8:14:19 AM8/3/17
to pytho...@googlegroups.com
Hi,

I am implementing support for the Keithley 2000 DMM in python-ivi. This
is a SCPI DMM that is quite similar to the Agilent 34401A in features
and age. I copied agilent.agilent34401A to keithley.keithley2000 and
changed all relevant values. It will now initialize (with id_query=True)
correctly and return a reading with k2000.measurement.fetch() when set
to ACV. A difference I ran into is that the Keithley 2000 will return
"VOLT:DC" when set to DCV, instead of "VOLT" as the Agilent driver
expects. I am not exactly sure what IEEE 488.2 dictates, but the
behavior seems sensible to me.

The Agilent 34401A driver defines a MeasurementFunctionMapping
dictionary that looks like it should override the one in scpi.dmm, but
the scpi.dmm.Base._get_measurement_function() and
_set_measurement_function() methods are hard-coded to use
scpi.dmm.MeasurementFunctionMapping. This produces an error in
_get_measurement_function if the meter is set to DCV/DCI: the meter will
return e.g. "VOLT:DC", which does not exist as a value in
scpi.dmm.MeasurementFunctionMapping.

My thoughts for solving this:
1. Make MeasurementFunctionMapping (and also Range, AutoRange,
Resolution and Source Mapping) scpi.dmm.Base class attributes (so
classes could define _MEASUREMENT_FUNCTION_MAPPING etc) so they can be
easily overridden.
2. Copy methods like _get_measurement_function() from scpi.dmm.Base to
keithley.keithley2000. This is the less invasive, but also ugly and less
maintainable option.

Option #1 would be the obvious solution to me, but I would like Alex's
opinion before modifying the base class as not to complicate future
merging. If this is considered a violation of the SCPI standard that
should be solved in the instrument-specific code, I could do solution
#2. Thoughts? Alternatives?

Alson
Reply all
Reply to author
Forward
0 new messages