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:

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:

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

  1. Passendes virtuelles Beispiel kopieren.

  2. Ausgabe- und Pickle-Pfade anpassen.

  3. Frequenzen und Beschreibungen für einen kurzen Lauf reduzieren.

  4. DOT-, INI- und DAT-Dateien austauschen.

  5. Preflight und virtuelle Tests ausführen.

  6. Erst danach reale Busparameter aktivieren.