Die meisten LabVIEW-Testanwendungen fangen klein an: ein DUT, zwei Messgeräte, ein Ingenieur. Fünf Jahre später gibt es zwölf Produktvarianten, drei Messgerätegenerationen und ein großes VI, das niemand öffnen möchte. Das Problem ist selten LabVIEW selbst. Das Problem ist eine Architektur, die nie auf Wachstum ausgelegt war.
Deshalb bauen wir unsere Testsysteme auf DQMH (Delacor Queued Message Handler) auf – einem freien, offenen Framework, das vom DQMH Consortium gepflegt wird und in der LabVIEW-Community weit verbreitet ist.
Was DQMH Ihnen bietet
- Module mit öffentlicher API. Jeder Teil des Systems – ein Messgerät, die DUT-Kommunikation, der Sequenzer, der Logger, die Bedienoberfläche – ist ein Modul. Anderer Code kommuniziert mit ihm ausschließlich über definierte Requests und empfängt seine Broadcasts.
- Ein API-Tester pro Modul. Zu jedem Modul gehört ein Tester, sodass Sie es isoliert ansteuern können – am Labortisch oder noch bevor die Hardware eintrifft.
- Scripting-Werkzeuge. Neue Module und Events werden per Scripting erzeugt, daher sieht jedes Modul gleich aus. Ein neues Teammitglied versteht das zehnte Modul, nachdem es das erste gelesen hat.
- Singleton- und klonbare Module. Ein Netzteil oder acht parallele Testkanäle – dasselbe Muster skaliert.
Was sich in der Praxis ändert
| Typisches Problem | Mit einer DQMH-Architektur |
|---|---|
| Ein neues Messgerätemodell legt die halbe Anwendung lahm | Nur das Messgerätemodul ändert sich; seine API bleibt gleich |
| Niemand kann eine Änderung ohne den kompletten Prüfstand testen | API-Tester und Unit-Tests prüfen Module isoliert |
| Das Wissen steckt im Kopf eines einzigen Entwicklers | Einheitliche Struktur und dokumentierte APIs machen eine Übergabe realistisch |
| Eine neue Produktvariante bedeutet kopierten Code | Varianten sind Konfiguration und Ablaufsteuerung, keine neuen Codepfade |
Migration einer bestehenden Anwendung – Schritt für Schritt
Ein Neuschreiben von Grund auf ist selten die richtige Antwort, solange die Fertigung vom Prüfsystem abhängt. Wir migrieren inkrementell:
- Review. Den bestehenden Code erfassen: Messgeräte, DUT-Kommunikation, Ablaufsteuerung, Datenhaltung, Bedienoberfläche und den gemeinsamen Zustand dazwischen.
- Die Zielmodule definieren samt ihren Requests und Broadcasts – zuerst auf Papier.
- Kapseln statt neu schreiben. Bestehenden, funktionierenden Treibercode hinter der neuen API in Module verlagern.
- Gemeinsamen Zustand ablösen (Globals, Functional Globals) – durch Modulnachrichten, eine Abhängigkeit nach der anderen.
- Jeden Schritt mit Tests absichern – API-Tester und Unit-Tests –, damit die Fertigung durchgehend weiterläuft.
Wann DQMH nicht die Antwort ist
Für ein einmaliges Laborskript oder eine Messung mit einem einzigen Messgerät genügt eine einfache State Machine. DQMH lohnt sich, wenn ein Testsystem mehrere asynchrone Teile, eine lange Lebensdauer und mehr als einen Entwickler hat.
LabVIEW-Code- & Architektur-Review
Ein Review Ihrer bestehenden Testanwendung mit einem konkreten Migrationsplan – ein guter erster Schritt.