Mit Software das Signal messen
Mit der soliden Mechanik wird nun das Signal reproduzierbar. Trommeln und Schütteln ist nicht mehr nötig. Die Schwingung an der Maschine erscheint wunderbar gleichmässig etwa hundertmal pro Sekunde. Mit einem kleinen Trick kann ich an der Maschine einen Lagerschaden simulieren und – oh Glück! – das Schwingungsbild ändert sich recht stark. Anstatt wie bisher maximal etwa 10 Millisekunden auf High zu bleiben, bilden sich nun breitere Berge von bis zu 40 Millisekunden Dauer aus.
Relativ gleichmässiges Schwingungsbild
Schwingung mit supponiertem Lagerschaden
Das Python Programm möchte ich nun so modifizieren , dass es bei den schmalen Schwingungsbergen nicht reagiert, bei den breiten Buckeln aber eine Aktion auslösen kann. Vorerst soll mal nur eine Meldung auf dem Bildschirm erscheinen, später dann ein Mail an mein Postfach gesendet werden, wenn die Buckel breit werden.
Die Zeit zwischen steigender und fallender Flanke
Ein eleganter Versuch
Mit Python kann der Raspberry sogar erkennen, ob das Eingangssignal ansteigt oder abfällt. Damit sollte es eigentlich möglich sein, die Signaldauer einfach zu messen. Zur Vorbereitung wird dieser Befehl verwendet:
IO.add_event_detect(20, IO.RISING)
IO.BOTH macht es möglich, sowohl die steigende als auch die fallende Flanke am gleichen Eingang zu detektieren.
Eine Bibliothek „time“ wird noch geladen um Zeiten zu bestimmen. Mit einem derartigen Konstrukt kann die Zeit gemessen werden:
while True:
if IO.event_detected(20):
Start = time.time()
Um hier nicht beliebig lang zu werden (denn ich wurde es bereits in den Versuchen): Der Interrupt auf steigende und sofort wieder fallende Flanke ergibt bei diesem Signal keine brauchbare Auswertung. So geht es leider nicht, über die Gründe kann ich nur mutmassen.
Die banale Lösung
Wenn es physikalisch hübsch nicht so recht will, dann muss halt eine Methode mit dem Holzhammer her. Und die geht so: Sobald der Eingang auf 1 steht, wird die Zeit in eine Variable gespeichert und ab diesem Moment in einer Schleife der Eingang abgefragt, ob das Signal noch anliegt. Ist dies unterbruchsfrei über die Dauer von beispielsweise 50 Millisekunden der Fall, so ist klar, dass es sich um eine richtig lange Welle handelt.
Die Möglichkeit besteht bei dieser Methode, dass zwischen den punktuellen Messungen das Signal mal kurz auf Null stand und damit der Buckel unbemerkt einen Unterbruch hatte. Theorie oder wahr? Das hängt vor allem davon ab, wie schnell das Signal ist und wie schnell die Schleife durchlaufen wird. Sofern der Rasp nicht mit anderen Aufgaben belastet wird, schafft mein Pi diese Schleife ziemlich genau 100’000 mal in der Sekunde. Die Abfrage mit 100kHz ist deutlich schneller als die kürzeren Unterbrüche im Sensorsignal. Hingegen kann zum Beispiel ein print-Befehl, welcher zu Testzwecken in der Schleife eingebaut ist um eine Kontrollausgabe auf den Bildschirm zu bringen, die Schleife extrem verlangsamen. In diesem Fall würden Täler unbemerkt bleiben. Ohne eingebaute Bremsklötze funktioniert aber die gewählte Abfragemethode ohne Fehler.
Raspberry Pi ruft Monteur
Wie soll eigentlich der „call to action“ funktionieren? Aus der Fülle der Möglichkeiten entscheide ich mich auch hier für einen einfachen Weg: Es soll ein E-Mail gesendet werden. Die Schwierigkeiten dafür wurden bereits von netten Zeitgenossen aus dem Weg geräumt. Es gibt in Python eine Bibliothek, die man zuerst laden muss: import smtplib und danach das Mail vorbereiten:
from email.message import EmailMessage
def send_mail(to_email, subject, message, server=’yyy.zzz.ch‘, from_email=’m.siegenthaler@topsoft.ch‘):
msg = EmailMessage()
msg[‚Subject‘] = subject
msg[‚From‘] = from_email
msg[‚To‘] = ‚, ‚.join(to_email)
msg.set_content(message)
print(msg)
server = smtplib.SMTP(server)
server.set_debuglevel(1)
server.login(from_email, xxx) # anstatt xxx das Passwort einfügen
server.send_message(msg)
server.quit()
print(‚Mail erfolgreich gesendet‘)
Um das Mail wirklich zu senden, genügt dann folgender Ausdruck:
send_mail(to_email=[‚monteur@zzz.com‘], subject=’Vibration Maschine 1′, message=’Die Maschine 1 hat übermässige Vibrationen gezeigt, bitte mal schauen. Danke!‘)
Das funktioniert auf Anhieb, bei heftigem Schütteln wird wie gewünscht ein Mail mit dem Hilfetext gesendet.
Nach diesem programmtechnisch rohen Grundstock könnte nun noch jede Menge Feintuning erfolgen. Ein paar Themen: Bessere Schadenerkennung, keine repetitiven Mails, Senden von Diagnosedaten, hübsches Userinterface, Fremdzugriff, etc. Der Fantasie sind kaum Grenzen gesetzt, der Geduld oder allenfalls einem Budget aber schon eher. Im Moment interessiert mich der Ausbau aber weniger als die Frage, wie denn nun wirklich der Monteur auf den Platz kommen könnte.
Die Sache mit dem ERP – LIVE!
Meine fixe Idee ist es, dass das Mail vom Rasp an eine Firmenadresse gesendet wird, welche ein ERP im Einsatz hat. Das ERP-System verarbeitet das ankommende Mail und macht daraus beispielsweise eine Aufgabe, welche mit dem Kunden und der betroffenen Maschine verknüpft ist. Die Aufgabe kommt vielleicht in einen Aufgabenpool, welcher von den Monteuren abgearbeitet wird. Mit der Aufgabe wird auch die gesamte Geschichte der Maschine sichtbar und die Kundendaten. Selbstverständlich soll dann durch den Eingriff an der Maschine vor Ort das aktuelle Schadensereignis der History hinzugefügt werden und die Reparatur mit den notwendigen Ersatzteilen und den Personal-Einsatzzeiten die Rechnung generieren.
Ob das so funktionieren kann? Ja. Am Software-Contest in Bern, am 17. April 2018, haben wir das live durchgespielt. Von den 5 Anbietern auf der Bühne haben zwei die Meldung im Sinne von "preventive maintenance" direkt im ERP empfangen und weiter verarbeitet.
Hier die Auflösung, welche Maschine für den Versuch verwendet wurde:
IoT mit einem Spinnrad Jahrgang 1799 (sogar der Autor ist jünger)
Resumée
- Hardware zu beschaffen ist banal. Ein Raspberry Pi kann extrem viel und ist zudem ausbaubar. Kostenmässig schlägt die benötigte Hardware bei zu überwachenden Produktionsmaschinen nicht allzu stark zu Buche im Vergleich zu Maschinenkosten in vielleicht fünfstelliger Höhe. Eine Payback-Periode könnte man wohl in einem konkreten Fall berechnen.
- Die Software zu schreiben ist Aufwand, aber lösbar.
- Die Maschine zu kennen und potenzielle Störfälle mit entsprechenden Schadensbilder zu detektieren anhand von Sensordaten ist sehr zentral und erfordert Wissen und Erfahrung. Achtung: Das ist nicht banal!
Autor: Dr. Marcel Siegenthaler