Konfigurationsmodell ==================== Eine mpylab-Anwendung verteilt Konfiguration bewusst auf mehrere Formate: .. list-table:: :header-rows: 1 :widths: 16 32 52 * - Format - Aufgabe - Typische Inhalte * - Python-``conf.py`` - Ablaufkonfiguration - Frequenzen, Dateinamen, Namen-Mapping, Mess- und Auswerteparameter * - DOT - Gerätetopologie - Knoten, Pfade, Conditions und Korrekturkanäle * - :doc:`INI ` - Geräteinstanz - Treiber, Busparameter, Kanäle, Grenzen und Verweise auf Daten * - :doc:`DAT ` - Frequenzabhängige Messdaten - Pfaddämpfung, Antennenfaktor, Verstärkung und Unsicherheit * - TOML - Profile und Werkzeugkonfiguration - Reports, Konfigurationsinventar und ergänzende Metadaten Suchpfade verbinden diese Ebenen. Relative Dateinamen sollten relativ zu explizit dokumentierten Suchpfaden aufgelöst werden, nicht zufällig relativ zum aktuellen Arbeitsverzeichnis. Direkteinstieg -------------- * :doc:`workflow` verbindet ``conf.py`` mit Ein- und Ausgabedateien. * :doc:`dot` beschreibt Gerätetopologie und aktive Signalpfade. * Die :doc:`INI- und DAT-Referenz ` dokumentiert Treiber-, Kanal- und Korrekturdaten einschließlich Einheiten und Unsicherheiten. * :doc:`validation` zeigt Migrations- und Prüfwerkzeuge vor dem Hardwarezugriff. Conditions ---------- DOT-Conditions erhalten Anwendungswerte über ein explizites Mapping, zum Beispiel ``FREQUENCY -> frequency``. Die frühere Suche nach gleichnamigen Variablen in äußeren Python-Frames ist nur eine Legacy-Rückfallebene. Validierung ----------- Konfigurationen sollten vor Hardwarezugriff geprüft werden. Dafür stehen unter anderem DOT-Migration, Graphprüfung und NPORT-Prüfwerkzeuge zur Verfügung. Die folgenden Seiten leiten ihre Beispiele aus den virtuellen Konfigurationen unter ``script/conf`` ab. .. toctree:: :maxdepth: 2 workflow dot instrument-data validation