Developing applications

mpylab separates the domain measurement workflow, device topology, and hardware access. An application can combine existing components or extend a specific layer.

The main extension points are:

• configure an existing measurement class through a new script;

• derive a measurement class from Measure;

• add an instrument driver for an existing device base class;

• provide a UI adapter or worker for an operator interface;

• add interchangeable EUT monitoring or report components.

Start with Architecture. The End-to-end developer tutorial then uses a virtual amplifier test to cover configuration, the DOT graph, autosave, testing, and subsequent UI integration.

For immunity applications, Using and extending EUT monitoring covers both configuration of existing measurement classes and development and safe integration of custom EUT monitors.

• Architecture
  • Script or GUI
  • Measure and measurement classes
  • MGraph
  • Device drivers and communication
  • SCUQ
• End-to-end developer tutorial
  • 1. Define the measurement task
  • 2. Virtual workflow configuration
  • 3. Instrument topology in the DOT graph
  • 4. Instrument instances in INI files
  • 5. Measurement values and evaluation
  • 6. Autosave and resume
  • 7. Hardware-independent tests
  • 8. Add a UI
  • 9. Move to hardware
• Developing measurement classes
  • Derive from Measure
  • Measurement workflow
  • Applying an explicit graph context
  • Autosave contract
  • Data structure
  • Evaluation
• Common instrument-driver behavior
  • The base class defines the interface
  • Status and return values
  • Lifecycle and bus policy
  • Active and inactive graph instruments
  • Frequency, triggering, and measurement data
  • Safety and shutdown
  • Virtual and passive instruments
  • Testing concrete drivers
• Developing instrument drivers
  • Choose the correct base class
  • Initialization
  • Communication
  • Units
  • Virtual driver and tests
• Multichannel instrument drivers
  • Controller and facade model
  • Acquisition modes
  • Common INI structure
  • Giga-tronics and R&S power meters
  • LUMILOOP LSPM
  • LUMILOOP LSProbe
  • Field-probe interface
  • Duration-based LUMILOOP acquisition
  • Testing and diagnostics
• Using and extending EUT monitoring
  • Using existing measurement classes
  • Developing a specific monitor
  • Integrating a new application
  • Testing without hardware
• UI adapters and worker interface
  • Responsibility boundaries
  • Adapter methods
  • Binding to Measure
  • Qt adapter
  • Stop and RF-off
  • Manual and automatic EUT monitoring
  • Worker design
  • Implementation checklist
  • Tests
• Measurement quantities, units, and uncertainty
  • Creating quantities
  • Value, uncertainty, and unit
  • Calculating with path corrections
  • Converting units
  • Power and amplitude ratios
• Tool modules and import migration
  • Migration policy
  • Import map
  • Special cases
  • API references
• Testing and commissioning
  • 1. Pure logic
  • 2. Instrument contract
  • 3. Virtual configuration
  • 4. Virtual end-to-end run
  • 5. Autosave and resume
  • 6. Safety and negative tests
  • 7. Qt tests
  • 8. Staged hardware test
  • Local tests and CI
• Conditions, switching matrix, and path corrections
  • Evaluating conditions
  • Switching matrix through SetFreq
  • More complex TEM example
  • Reading the total correction
  • Applying a correction
  • Fast repeated application
  • Validation rules

Core rules

• Hardware access belongs in device drivers and workers, not in the UI thread.

• Measurement values use SCUQ quantities with units and uncertainty.

• DOT conditions receive values through an explicit context.

• RF-off and device limits are safety functions, not UI details.

• Long measurements must be resumable and their results traceable.

• Test new workflows with virtual devices first.