Ein Schwingungssensor an der Spindel eines Bearbeitungszentrums, ausgelesen über OPC UA mit Python. Das Rohsignal aus der Hardware herauszubekommen war der schwierige Teil. Ein passives Abonnement lieferte nichts, deshalb habe ich einen zustandsbehafteten Command-and-Retrieve-Ablauf zur Datenerfassung gebaut.
Eigenständige Masterarbeit an einer Maschine, nur im intakten Zustand.
Echte Maschinenfehler wurden nicht getestet, und es wird keine Fehlererkennung behauptet.
In einem Test an der intakten Maschine führte ein künstlicher Stoß auf den Sensor zu einem Kurtosis-Ausschlag von etwa −0,1 auf über 230, und die Alarmlogik hat reagiert.
Die Kette oben bleibt fest. Die Zeichnung darunter ändert sich mit jeder Stufe. Alle Zeichnungen sind eigene Schemata, keine Messdaten.
Untersuchungsgegenstand ist ein vertikales Bearbeitungszentrum Spinner VC850 mit Heidenhain-TNC-640-Steuerung in einem Hochschullabor.
Ein Piezo-Beschleunigungssensor IFM VSA004 ist mit einer Stiftschraube am Spindelgehäuse befestigt. Er speist ein Modul IFM VSE100, das ein OPC-UA-Server IFM VOS050 (mit Gerätelizenz VOD001) einem Python-Client zur Verfügung stellt. Die Lizenzen hat IFM bereitgestellt.
Der erste Ansatz war ein passives OPC-UA-Abonnement der Sensordaten. Das Abonnement lieferte keine Rohdaten.
Ohne Rohdaten gab es nichts zu verarbeiten, deshalb wurde dies der schwierige Teil des Projekts.
Mit UaExpert, einem OPC-UA-Client eines Drittanbieters, habe ich den Server durchsucht und seine Methoden (StartRecording, Open, Read und Close) samt Argumenten untersucht. Daraus habe ich in Python einen zustandsbehafteten Command-and-Retrieve-Ablauf gebaut: eine Aufnahme anstoßen, warten bis sie fertig ist, sie öffnen, lesen und schließen, dann die Daten dekodieren und in die Warteschlange legen. Der Ablauf entsprach dem Handbuch des Herstellers.
Die Erfassung läuft in einem Producer-Thread. Eine FIFO-Warteschlange gibt jeden Puffer an den Consumer weiter, der die Analyse durchführt und das Dashboard speist. Das Ergebnis ist ein Near-real-time-Erfassungszyklus.
Jeder Puffer wird von seinem Trend befreit, mit einem Butterworth-Filter 4. Ordnung bandpassgefiltert und per Z-Score normiert. Die Z-Score-Normierung skaliert ein Signal mit seinem eigenen Mittelwert und seiner Standardabweichung.
Aus dem verarbeiteten Signal berechnet das System im Zeitbereich RMS, Spitzenwert, Crest-Faktor und Kurtosis sowie im Frequenzbereich eine FFT.
Die Referenzwerte wurden an der intakten Maschine aufgenommen, thermisch stabilisiert und im Leerlauf ohne Werkzeug, bei diskreten Spindeldrehzahlen.
Die Schwellen für Alert und Alarm wurden in der Arbeit aus der Statistik der Referenzwerte mit μ+2σ und μ+3σ festgelegt. Auf die Kennwerte wird eine regelbasierte Diagnoselogik angewendet. Die Kennwerte werden zur Verlaufsbeobachtung an dauerhafte CSV-Dateien angehängt.
Stoßtest. In einem Test an der intakten Maschine führte ein künstlicher Stoß auf den Sensor zu einem Kurtosis-Ausschlag von etwa −0,1 auf über 230, und die Alarmlogik hat reagiert.
Lastvergleich. Eine Maschine, ein leichter Planschnitt in Aluminium 6061, eine Spindeldrehzahl (2000 U/min).
| Zustand | RMS roh | Normierte Kurtosis |
|---|---|---|
| Ohne Last | 0,03 g | 26,29 |
| Leichter Schnitt (Planfräsen, Aluminium 6061) | 0,03 g | 26,13 |
Die Kurtosis-Werte waren in beiden Zuständen ähnlich und werden hier nicht gedeutet; eine Maschine, ein leichter Schnitt, eine Spindeldrehzahl. Dies ist keine Validierung einer lastunabhängigen Überwachung.
Ein Ort, um genau nachzuprüfen, was diese Arbeit ist und was nicht.
Ein öffentlicher Stand des Codes vom August 2025. Er enthält das Streamlit-Dashboard, die Command-and-Retrieve-Erfassung, Signalverarbeitung, Referenzwerte und Diagnose sowie die Verlaufsbeobachtung. Er stammt aus der Zeit vor der Abgabe der Arbeit und unterscheidet sich in einigen Details von der Umsetzung in der Arbeit. Er ist nicht die endgültige Umsetzung der Arbeit.