Ablaufkonfiguration mit conf.py =============================== Eine ``conf.py`` verbindet Messskript, Historien-Pickle und Gerätekonfiguration. Sie ist ausführbarer Python-Code und darf daher nur aus vertrauenswürdiger Quelle geladen werden. Grundstruktur ------------- Die Skripte erwarten ein Dictionary ``cdict``. Typische Schlüssel sind: .. code-block:: python cdict = { "pickle_input_filename": None, "pickle_output_filename": str(OUTPUT_DIR / "measurement.p"), "autosave_filename": str(OUTPUT_DIR / "measurement-autosave.p"), "log_filename": str(OUTPUT_DIR / "measurement.log"), "minimal_autosave_interval": 3600, "descriptions": ["example"], "measure_parameters": [{...}], "evaluation_parameters": [{...}], } Nicht jedes Skript benötigt alle Schlüssel. Die mitgelieferten Templates sind für die jeweilige Messklasse maßgeblich. Effektive Konfiguration ansehen ------------------------------- Mehrere Konfigurationsquellen werden von links nach rechts angewendet. Die vollständig zusammengeführte Konfiguration lässt sich ohne Messstart anzeigen: .. code-block:: console mpylab-config-show script/tem-immunity.py \ /opt/mpylab/gtem/conf/immunity_conf.py local_conf.py Die Ausgabe ist deterministisch, zeigt für jeden skalaren Wert die zuletzt ändernde Quelle und blendet Schlüssel für Passwörter, Secrets und Tokens aus. Die gemeinsamen Qt-Starter zeigen denselben Snapshot im read-only-Tab **Configuration**. Der Snapshot entsteht vor dem Anhängen von UI- und anderen Laufzeitobjekten. **Stop / RF Off** bleibt unabhängig vom gewählten Tab sichtbar. ``update_conf`` bleibt für bestehende Anwendungen mutierend und gibt weiterhin ``None`` zurück. Neue Programme können ``resolve_config_chain`` verwenden, wenn sie zusätzlich die geordnete Quellen- und Änderungsprovenienz benötigen. Historie und Dateien -------------------- ``pickle_input_filename`` Lädt die vollständige Historie einer vorausgehenden Messung. ``None`` erzeugt eine neue Instanz. ``pickle_output_filename`` Enthält nach erfolgreichem Abschluss die erweiterte Historie. ``autosave_filename`` Wird während einer laufenden Messung aktualisiert. Ein vorhandenes Autosave hat beim Wiederanlauf Vorrang vor dem normalen Eingangs-Pickle. Alle Laufzeitausgaben gehören in ein separates ``output``-Verzeichnis. Pfade werden vorzugsweise ausgehend von ``Path(__file__).resolve().parent`` gebildet und sind damit unabhängig vom aktuellen Arbeitsverzeichnis. Messparameter ------------- Jeder Eintrag in ``measure_parameters`` beschreibt einen fachlichen Messdatensatz. Der Schlüssel ``description`` wird vom Skript aus ``descriptions`` ergänzt. Typische Parameter sind: * ``dotfile`` und ``SearchPaths``; * Frequenzen, Pegel und Messzeiten; * ``names`` zur Abbildung logischer Namen auf DOT-Knoten; * Preflight- und Schutzparameter; * messklassenspezifische Geometrie oder EUT-Einstellungen. Mehrere Beschreibungen können denselben Parameterblock verwenden oder positionsgleich auf mehrere Blöcke abgebildet werden. Für nachvollziehbare Historien sollten Beschreibungen kurz, stabil und fachlich eindeutig sein. Benannte TEM-Uniform-Areas ~~~~~~~~~~~~~~~~~~~~~~~~~~ Die TEM-Starter akzeptieren ``uniform_areas`` als Mapping von stabilen Namen auf Flächendefinitionen. Der Mapping-Schlüssel muss mit ``name`` in der Definition übereinstimmen. Jede Definition enthält vollständige Breite und Höhe, den Mittelpunkt und genau eine Ebenenposition ``h`` oder ``z``. ``uniform_area`` bezeichnet weiterhin die Standarddefinition für ältere Konfigurationen. Ist zusätzlich ``uniform_areas`` vorhanden, registrieren die Starter alle benannten Flächen und vermeiden eine doppelte Registrierung des Standards. Eine erneute Definition desselben Namens mit abweichender Geometrie wird abgelehnt, damit ein History-Pickle seine Bedeutung nicht stillschweigend ändert. ``Measure_Verification`` verarbeitet pro Messdatensatz genau eine Fläche. Bei mehreren Flächen muss jeder Parameterblock den gewünschten Namen ausdrücklich unter ``uniform_area`` auswählen. Da Konfigurationsketten Listen vollständig ersetzen, sollte ein ``update_config(config)``-Hook vorhandene ``measure_parameters`` gezielt kopieren oder ergänzen, statt einen bereits hardwarekonfigurierten Block unbeabsichtigt zu verlieren. Auswerteparameter ----------------- ``evaluation_parameters`` enthält ausschließlich Entscheidungen der Auswertung, beispielsweise Referenzdatensätze, Interpolationsverfahren oder Ausgabekanäle. Ein Messparameter sollte nicht ein zweites Mal mit abweichender Bedeutung in der Auswertung konfiguriert werden. Sichere Anpassungsstrategie --------------------------- #. Passendes virtuelles Beispiel kopieren. #. Ausgabe- und Pickle-Pfade anpassen. #. Frequenzen und Beschreibungen für einen kurzen Lauf reduzieren. #. DOT-, INI- und DAT-Dateien austauschen. #. Preflight und virtuelle Tests ausführen. #. Erst danach reale Busparameter aktivieren.