Die Frage nach allem… – die Antwort: 42

Wie bereits erwähnt und auf den Wunsch eines Einzelnen hin (hat zwei Daumen und schreibt grade diesen Beitrag) wurde das Programm ein wenig auf Umwegen simuliert. Dabei sind einige Schlüsselmomente und Erfahrungen entstanden, die ich an dieser Stelle im Werdegang des Projektes durchaus nicht vorenthalten will. Zusätzlich dazu ist es ein Fortschritt, der es wert ist, dokumentiert zu werden.

Wo kommen wir her?

Zunächst aber einmal kurz die Ausgangssituation rekapituliert: Der aktuelle Code für den Rapsberry Pi sieht (funktionstüchtig mit SPS getestet) vor, dass Sensorwerte über den Raspberry Pi – wenn auch teils derzeit noch als reine Rohdaten – an die SPS mittels der Bibliothek von snap7 übertragen werden. Hinzu kommt, dass die Daten gleichermaßen über diese Bibliothek auch ausgelesen werden können. Zusätzlich werden die Daten auch in die auf dem Raspberry Pi installierte Datenbank MariaDB geschrieben – das allerdings auch nur, wenn die Daten einer gewissen Mindestabweichung entsprechen. Diese Abweichung ist am Anfang des Codes in einem Array als CoV = [0.1, 1, 0] festgelegt. Zu erwähnen ist vielleicht an dieser Stelle, dass der Variablen-Name von dem durch andere Technik bekannten Change of Value (kurz CoV) abgeleitet ist. Diese Methode ist bspw. in BACnet sehr verbreitet und dient dazu, die Netzwerklast / den Traffic zu reduzieren, indem Werte nur dann weitergegeben werden, wenn sie eine gewisse Mindestabweichung gegenüber den vorherig gemessenen Werten haben. Um auf MariaDB zugreifen zu können, benötigt man die Bibliothek mysql-connect für Python. Diese beinhaltet Funktionen, die eine Arbeit mit der Datenbank deutlich erleichtern – allerdings kommt man trotz allem um ein wenig SQL-Code nicht herum… gehört halt zur Arbeit mit Datenbanken dazu.

PLC.connect(
		'192.168.0.1',	#IP
		0, 				#rack
		1				#slot
		)
DB10_Data = plc.db_read(
		10, #DB-No.
		0,  #byte to start
		7)	#bytes to read
# ---- snipping Bool-Byte into seperate information	
StateCh0 = snap7.util.get_bool(DB10_Data, 0, 0)	#ON / OFF
CmdCh0 = snap7.util.get_bool(DB10_Data, 0, 1)	#AUTO / MAN
PlantCh0 = snap7.util.get_int(DB10_Data, 2, 2)	#INT

StateCh1 = snap7.util.get_bool(DB10_Data, 4, 0)
CmdCh1 = snap7.util.get_bool(DB10_Data, 4, 1)
PlantCh1 = snap7.util.get_int(DB10_Data, 6, 0)
		
PLC.disconnect()

if ((StateCh0 == 1 && PlantCh0 > 0) || (StateCh1 == 1 && PlantCh1 > 0)):
	FbState = 1
else:
	FbState = 0
		
time.sleep(PausingTime)

Ansonsten bleibt zur generellen Funktion zu sagen, dass in einer while-Schleife zunächst stetig überprüft wird, ob Bits aus einem Datenbaustein gesetzt sind, die sich auf ein „ON / OFF“, „AUTO / MAN“ und einen Integer-Wert für die Wahl der Pflanze beziehen – das für beide Kammern. Ist eine der beiden Kammern aktiv, wechselt die while-Schleife zum ständigen Abfragen der Sensoren, dem Schreiben und Lesen der SPS und so weiter (wie oben erwähnt).

Warum sind wir hier?

Das hier soll einfach mal ein kurzes Update zum Zustand des Codes werden. Durch die Erkenntnisse aus den Simulationen und den verschiedenen Szenarien, die ich bisher testen konnte, ergeben sich einige Punkte, die in dem bisherigen Code geupdated werden müssen. Zum einen wären da einige grundlegende Fehler, die mir mit Python an der Stelle leider unterlaufen sind, da ich ursprünglich aus der OOP mit C++ komme, was die Thematik der Programmierung auf einem Endgerät betrifft. Daher sind mir bei den bool’schen Verknüpfungen das && und das || mit reingerutscht… das funktioniert leider bei Python nicht. Diese Programmiersprache arbeitet in der Tat eher mit Verschriftlichung der Operationen (bspw. and, or, is). Gut, das ist eben ein Punkt, den man beachten muss. Etwas gravierender ist dagegen allerdings die Fehleranfälligkeit des Codes ausgefallen. Ist in der Simulationsdatei bspw. ein Wert nicht vorhanden gewesen, ist der komplette Code mit einer Fehlermeldung ausgestiegen.

Dass dies passiert schadet weder dem Raspberry Pi, noch der SPS. Allerdings stoppt damit gleichzeitig das Programm auf dem Raspberry Pi, was dazu führt, dass eben weder eine weitere Sensorabfrage, noch irgendwelche anderen Daten an die SPS übertragen werden. Es kommt also zum Programmstop – in der Automatisierung eher nicht so gut, wenn das passiert… vor allen Dingen, wenn das unbeaufsichtigt passiert. Und in einem gewissen Rahmen haben wir in der Automatisierung ja den Anspruch, dass ein System bis zu einem gewissen Punkt weiterläuft (sofern es sich um ein kontrollierbares Risiko handelt) und mit Fehlern entsprechend umgehen kann. Zusätzlich haben sich bei der Simulation noch einige Punkte zur Optimierung des Codes ergeben, um diesen übersichtlicher zu gestalten.

Wo gehen wir hin?

Die Aufgabe besteht nun also darin, die entsprechenden Code-Anpassungen vorzunehmen. Zum einen natürlich ein sinnvolles und brauchbares Error-Handling mittels try:, except: und finally: einzubauen (wichtig, damit das Programm nicht abstürzt, sofern ein Fehler auftritt), zum anderen natürlich den Code überhaupt ausführbar zu machen, indem die bool’schen Verknüpfungen angepasst werden. Zusätzlich wird eine kleine Versionierung und ein Change-Log in den Kommentaren hinterlegt, damit die Änderungen später noch nachvollziehbar sind. Weiterhin wird die Code-Version gespeichert, damit ein effektiver Verlauf der Versionen später noch einsehbar ist. Im Übrigen erfolgt auch noch eine Anpassung für die Adressierung auf dem Datenbaustein, um Fehler an Sensoren und andere Daten an die SPS zu übergeben, so z.B. ein Life-Bit der Sensoren, um vorab und auch von einer möglichen inaktiven Kammer einen Fehler zu einem Sensor am HMI gemeldet zu bekommen (ganz im Sinne der Thematik „Instandhaltung“).