Configuration model¶
An mpylab application deliberately distributes configuration across several formats:
Format |
Purpose |
Typical content |
|---|---|---|
Python |
Workflow configuration |
Frequencies, filenames, name mapping, measurement and evaluation settings |
DOT |
Device topology |
Nodes, paths, conditions, and correction channels |
Device instance |
Driver, bus parameters, channels, limits, and data references |
|
Frequency-dependent measured data |
Path loss, antenna factor, gain, and uncertainty |
|
TOML |
Profiles and tool configuration |
Reports, configuration inventory, and supplementary metadata |
Search paths connect these layers. Resolve relative filenames against explicitly documented search paths rather than accidentally against the current working directory.
Direct entry points¶
Workflow configuration with conf.py connects
conf.pyto input and output files.DOT reference for measurement graphs describes instrument topology and active signal paths.
The INI and DAT reference documents driver, channel, and correction data, including units and uncertainty.
Validate and migrate configurations presents migration and checking tools to use before accessing hardware.
Conditions¶
DOT conditions receive application values through an explicit mapping, for
example FREQUENCY -> frequency. Looking up equally named variables in
outer Python frames is only a legacy fallback.
Validation¶
Validate configurations before accessing hardware. Available tools include
DOT migration, graph validation, and NPORT checks. The following pages derive
their examples from the virtual configurations below script/conf.