LabVIEW für Prüfstandsentwicklung und Test Engineering

Seminarziel

Jede teilnehmende Person verlässt das Seminar mit einer vollständigen Prüfstandsapplikation (QMH-Architektur, PID-Regelung, State-Machine-Ablaufsteuerung, Grenzwertüberwachung mit Alarmierung, TDMS-Logging, automatisches Word/PDF-Prüfprotokoll), dem Verständnis von Prüfstandsarchitekturen (QMH, Producer/Consumer, parallele Loops) und einem angepassten Prüfprofil für das eigene Szenario.

Inhalt

Tag 1: Prüfstandsarchitektur und Datenerfassung
1. Prüfstandsarchitektur: Das richtige Muster wählen

• Warum Architektur entscheidend ist: Prüfstände sind inhärent parallel - Datenerfassung (kontinuierlich), Regelung (zeitkritisch), Ablaufsteuerung (sequentiell), UI (event-driven), Logging (asynchron) laufen gleichzeitig. Ein Single-Loop-Design ist immer falsch.
• Queued Message Handler (QMH): Standard-Architektur für mittlere Komplexität. Message-Queue verbindet Event-Handling-Loop (UI-Events, Timer) mit Consumer-Loop (Aktionen ausführen). Nachrichten als Enum + Variant-Daten. Erweiterbar durch zusätzliche parallele Loops.
• Producer/Consumer mit mehreren Loops: Separation of Concerns - Loop 1 ( Daten erfassen, Abtastrate halten), Loop 2 (Processing: Grenzwerte prüfen, Alarme auslösen), Loop 3 (Regelung: PID berechnen, Stellgröße ausgeben), Loop 4 (UI: Anzeige aktualisieren, Bedienerinteraktion), Loop 5 (Logging: TDMS schreiben). Kommunikation über Queues und Notifier.
• Actor Framework und DQMH als Optionen für komplexe Prüfstände (>10 Module, mehrere Prüflinge gleichzeitig, verteilte Systeme). Entscheidungshilfe: QMH für 80 % der Prüfstände ausreichend.
• Praxis-Übung: Prüfstands-Grundgerüst aufbauen: QMH mit 3 parallelen Loops (Datenaufnahme, UI, Logging). Message-Queue konfigurieren, Nachrichten definieren (Initialize, Start, Stop, Shutdown, Error), Grundgerüst starten und Nachrichtenfluss verifizieren.
• 
  

2. Datenerfassung

• Daten im Prüfstandskontext: Analog Input (Spannung, Strom, Temperatur via Thermocouple/RTD/Thermistor), Analog Output (Stellgrößen, Sollwerte), Digital I/O (Ventile, Relais, Status-Signale), Counter/Timer (Drehzahl, Frequenz, Encoder).
• Task-Konfiguration: Kanäle, Abtastrate, Puffergröße, Trigger, Timing (Finite vs. Continuous). Hardware-Timing vs. Software-Timing - warum Hardware-Timing für Prüfstände Pflicht ist.
• Signalkonditionierung: Anti-Aliasing (Nyquist-Theorem anwenden), Filterkonfiguration (Lowpass, Bandpass), Sensorkorrektur (Offset, Gain, Linearisierung), Kalibrierungsfaktoren anwenden.
• Continuous Acquisition: Loop läuft unabhängig mit fester Abtastrate, übergibt Daten per Queue an Processing-Loop. Callback-basiert vs. Polling-basiert. Buffer Underflow/Overflow erkennen und behandeln.
• VISA/SCPI für externe Instrumente: Multimeter, Oszilloskope, Signalgeneratoren, Netzteile über GPIB, USB-TMC, LAN/LXI ansteuern. SCPI-Befehle senden, Messwerte lesen, Instrumenten-Abstraktion per SubVI-Bibliothek.
• Praxis-Übung: Umfangreichen QMH-Prüfstand aufbauen mit mehreren Loops. Echtzeit-Anzeige auf Waveform Chart.

3. Echtzeit-Visualisierung und Alarmüberwachung

• UI-Design für Prüfstände: Operator-Perspektive (große Anzeigen, klare Farben, Alarm-Status sofort sichtbar), Ingenieur-Perspektive (Detail-Ansichten, Konfiguration, Debug). Tab-basiertes Layout: Übersicht / Messwerte / Konfiguration / Alarm-Log.
• Waveform Chart vs. Waveform Graph vs. XY Graph: Chart (Rolling Display, ideal für kontinuierliche Überwachung), Graph (gesamter Datensatz, ideal für Nachbetrachtung), XY Graph (Kennlinien, Hysterese-Kurven).
• Grenzwertüberwachung und Alarmierung: Für jeden Messkanal: oberer Warnwert, oberer Alarmwert, unterer Warnwert, unterer Alarmwert. Bei Warnung: Anzeige gelb, Log-Eintrag. Bei Alarm: Anzeige rot, akustisches Signal, optionale Notabschaltung (Safety Interlock).
• Alarm-Log: Zeitstempel, Kanal, Wert, Grenzwert, Schwere (Warnung/Alarm) - als scrollbare Tabelle in der UI und als File-Log für Nachvollziehbarkeit.
• Safety Interlocks: Bei kritischem Alarm (z.B. Temperatur > 150 °C): automatischer Stopp der Prüfung, Stellgrößen auf sichere Werte fahren, Bediener informieren. Implementierung: separater High-Priority-Loop für Safety (nicht vom UI-Loop abhängig).
• Praxis-Übung: UI für den Prüfstand aufbauen: 4-Kanal-Waveform-Chart, numerische Anzeigen, Alarm-LEDs (grün/gelb/rot), Alarm-Log-Tabelle. Grenzwertüberwachung implementieren: Grenzwerte konfigurierbar, bei Überschreitung -> Alarm-LED rot + Log-Eintrag + akustisches Signal. Safety Interlock: bei Kanal-3-Alarm -> DAQ-Output auf 0 setzen.
• 
  

Tag 2: Regelung, Ablaufsteuerung und Datenspeicherung
4. PID-Regelung für Prüfstands-Sollwerte

•  Warum Regelung im Prüfstand? Prüfstände müssen Sollwerte einregeln - Temperatur halten, Drehzahl fahren, Druck stabilisieren, Last aufbringen. Ohne Regelung: Sollwert vorgeben und hoffen. Mit PID: Sollwert regeln und garantieren.
• PID-Regler in LabVIEW: PID.vi aus der PID and Fuzzy Logic Toolkit. Eingänge: Setpoint (Sollwert), Process Variable (Istwert), PID Gains (Kp, Ki, Kd). Ausgang: Output (Stellgröße -> Analog Output oder Instrumenten-Befehl). Anti-Windup für Integral-Begrenzung.
• Regelungs-Loop als separater zeitkritischer Loop: Feste Zykluszeit (z.B. 10 ms), höhere Priorität als UI-Loop, Istwert aus Loop per Shared Variable oder Queue, Stellgröße an Output oder Instrument.
• Tuning: Ziegler-Nichols-Methode, manuelles Tuning (Kp erhöhen bis Schwingung, Ki hinzufügen, Kd für Dämpfung). LabVIEW PID Autotuning VI.
• Rampengenerator: Sollwert nicht sprunghaft, sondern als Rampe vorgeben (z.B. Temperatur von 20 °C auf 80 °C in 10 Minuten). Profil-basierte Sollwert-Vorgabe: Tabelle mit Zeit-Sollwert-Paaren (Prüfprofil).
• Praxis-Übung: PID-Regelung für einen simulierten Temperaturprozess implementieren: Sollwert-Rampe (20->80->120->80->20 °C in 5 Stufen), PID-Regler mit Autotuning, Regelgröße und Stellgröße auf Chart anzeigen. Alarm bei Regelabweichung > 5 °C.

5. Ablaufsteuerung: Prüfsequenzen programmieren

• State Machine für Prüfabläufe: Zustände als Prüfphasen (Idle, Initialize, Warmup, Test Phase 1, Test Phase 2, ..., Cooldown, Report, Shutdown). Übergänge durch Bedingungen (Phase fertig, Sollwert erreicht, Alarm, Benutzer-Abbruch).
• Prüfprofil-basierte Ablaufsteuerung: Prüfablauf als Konfigurationsdatei (CSV, INI, XML): Phase-Name, Sollwert, Dauer, Grenzwerte, Messkanäle. State Machine liest die nächste Phase aus der Datei -> konfigurierbare Prüfabläufe ohne Code-Änderung.
• Timing: Phasen mit definierten Haltezeiten (z.B. „10 Minuten bei 80 °C halten"), Wartezeiten (z.B. „Warten bis Temperatur stabil ±2 °C für 60 Sekunden"), Timeouts (z.B. „Wenn Temperatur nach 5 Minuten nicht erreicht -> Abbruch").
• Benutzer-Interaktion während des Prüfablaufs: Start/Stopp/Pause, manueller Skip einer Phase, Notaus (Emergency Stop -> Safety Interlock), Parameternachführung (Sollwert während Prüfung ändern - mit Bestätigung).
• Abbruch und Fehlerbehandlung: Bei Instrumenten-Fehler oder Alarm -> geordneter Abbruch (Cleanup-Phase durchlaufen, Stellgrößen auf sichere Werte, Teilprotokoll speichern).
• Praxis-Übung: State Machine mit 6 Phasen bauen: Idle -> Initialize (Instrumente verbinden) -> Warmup (Rampe auf 80 °C, warten bis stabil) -> Test (10 Minuten bei 80 °C, alle 10 Sekunden messen) -> Cooldown (Rampe auf 20 °C) -> Report. Prüfprofil aus CSV laden (3 Varianten vorbereitet). Benutzer-Pause und Abbruch implementieren.

6. Datenspeicherung und Offline-Analyse

• TDMS als Prüfstands-Datenformat: Technical Data Management Streaming - NIs binäres High-Performance-Format. Hierarchie: File -> Groups -> Channels. Properties für Metadaten (Prüfer, Datum, DUT-Seriennummer, Prüfplatz). Streaming-fähig (Daten während der Prüfung schreiben, nicht erst am Ende).
• TDMS Best Practices: Ein File pro Prüflauf, Groups für Phasen oder Messgruppen, Channel-Namen = Kanalbezeichnungen. Properties für Konfiguration (Abtastrate, Einheit, Sensor-Typ). TDMS File Viewer für schnelle Inspektion.
• Alternative Formate: CSV (universell, aber langsam und groß), HDF5 (Python-kompatibel), SQL-Datenbank (für Langzeitarchivierung und Auswertung über Prüflinge hinweg). TDMS-to-CSV und TDMS-to-HDF5 Konvertierung.
• Praxis-Übung: TDMS-Logging in die Prüfstandsapplikation integrieren: Während der Prüfung alle Kanäle + Reglerstellgröße + Alarm-Status kontinuierlich in TDMS schreiben. Properties setzen (Prüfer, DUT-ID, Prüfprofil-Name). Nach der Prüfung: TDMS-File in Excel öffnen (oder TDMS File Viewer), Daten visualisieren, Statistik berechnen.

Tag 3: Prüfprotokolle, Normkonformität und Praxisprojekt
7. Prüfprotokolle automatisch generieren

• Anforderungen an Prüfprotokolle: Eindeutige Identifikation (DUT-Seriennummer, Prüfplan-ID, Prüfer, Datum/Uhrzeit), Prüfergebnisse (Messwerte, Grenzwerte, Pass/Fail pro Prüfpunkt), Diagramme (Temperaturverlauf, Kennlinien), Zusammenfassung (Gesamtergebnis, Bemerkungen), Unterschrift (digital oder physisch).
• Word-Report aus LabVIEW: Microsoft Office Automation (ActiveX/COM) - Word-Vorlage mit Platzhaltern (Bookmarks) -> LabVIEW füllt Platzhalter mit Daten -> Tabellen mit Messwerten -> Diagramme als Bilder einfügen -> als PDF speichern. Vorteil: Vorlage vom Qualitätsmanagement pflegbar (kein LabVIEW nötig).
• HTML-Report als Alternative: HTML-Template mit CSS -> LabVIEW füllt per String-Manipulation oder XSLT -> Browser-basierte Anzeige, PDF-Export über Browser-Print. Vorteil: plattformunabhängig, kein Office nötig.
• Diagramme im Report: LabVIEW-Chart/Graph als Bild exportieren (Invoke Node -> Export Image), in Word/HTML einfügen. 
• Report-Workflow: Prüfung beendet -> State Machine wechselt in Report-Phase -> Daten aus TDMS lesen -> Word-Template befüllen -> PDF generieren -> in Archiv-Ordner speichern (Ordnerstruktur: Jahr/Monat/Prüfling-ID) -> optional: per E-Mail an Qualitätsmanagement.
• Praxis-Übung: Word-Prüfprotokoll-Template erstellen (mit Bookmarks für DUT-ID, Datum, Prüfer, Ergebnis-Tabelle, Diagramm, Gesamtergebnis). LabVIEW-VI bauen, das TDMS-Daten liest, Template befüllt, Diagramm als Bild einfügt und als PDF speichert. Automatisch in Report-Phase der State Machine integrieren.

8. Normkonformität und Qualitätsanforderungen

• ISO 17025 (Prüf- und Kalibrierlaboratorien): Anforderungen an Messsysteme: Kalibrierung, Rückführbarkeit, Messunsicherheit. LabVIEW-Umsetzung: Kalibrierungsfaktoren als Konfigurationsdatei (nicht hartcodiert), Kalibrierintervall-Tracking, Audit-Trail (wer hat wann welche Konfiguration geändert).
• GMP/GLP (Pharma, Medizintechnik): Datenintegrität (ALCOA+: Attributable, Legible, Contemporaneous, Original, Accurate), Audit Trail, elektronische Unterschriften, 21 CFR Part 11. LabVIEW-Umsetzung: Benutzermanagement, Zugriffsschutz auf Konfiguration, Änderungsprotokoll in Log-Datei.
• IATF 16949 (Automotive): Statistical Process Control (SPC), Measurement System Analysis (MSA), Prüfplanverwaltung. LabVIEW-Umsetzung: Cpk-Berechnung aus Messdaten, R&R-Studie-Support, Testergebnis-Export für SPC-Software.
• Audit Trail in LabVIEW: Jede Konfigurationsänderung (Grenzwerte, Kalibrierungsfaktoren, Prüfprofile) protokollieren - Timestamp, Benutzer, alter Wert, neuer Wert. Unveränderbar in Log-Datei oder Datenbank speichern.
• Praxis-Übung: Audit-Trail-Modul implementieren: Bei Grenzwertänderung -> Eintrag in Audit-Log (Timestamp, User, Parameter, alter Wert, neuer Wert). Kalibrierungsfaktoren als externe Konfigurationsdatei mit Änderungsschutz (Benutzerberechtigung). Benutzermanagement: Login, Rollenkonzept (Bediener/Ingenieur/Admin).

9. Praxis-Workshop: „Unser Prüfstand"
Phase 1 - Anforderungen und Architektur (15 Min):

• Prüfstandsszenario aus eigener Organisation wählen (oder vorgegebenes Szenario: Temperaturwechselprüfung mit 4 Messkanälen, PID-Regelung, 5-Phasen-Profil, Grenzwertüberwachung und Prüfprotokoll).
• Architektur skizzieren: Welche parallelen Loops? Welche Kommunikation? Welche Hardware?

Phase 2 - Implementierung vervollständigen (40 Min):

• Die im Seminar gebaute Prüfstandsapplikation für das eigene Szenario anpassen: Messkanäle, Prüfprofil (CSV), Grenzwerte, PID-Parameter, Report-Template.
•  End-to-End-Durchlauf: Initialize -> Prüfprofil laden -> Prüfung durchführen (mit simulierten Signalen) -> TDMS speichern -> Prüfprotokoll generieren -> Ergebnis-PDF inspizieren.

Phase 3 - Peer-Review und Stresstest (20 Min):

• Prüfstandsapplikation vorstellen. Feedback: Ist die Architektur sauber getrennt (Datenaufnahme/Regelung/UI/Logging)? Was passiert bei Sensorfehler? Ist der Report normkonform?
• Stresstest: „Thermocouple bricht während der Prüfung - was passiert?" „Bediener drückt Notaus während Phase 3 - sind die bisherigen Daten gespeichert?" „Auditor fragt: Wer hat den Grenzwert letzte Woche geändert?"