Ein Bücherwurm auf Abwegen

Es meldet sich an dieser Stelle Zukunfts-Florian zu Wort, der dem Vergangenheits-Florian gerne mal ein paar Zellen wieder grade rücken würde… aber gut: Was passiert ist, ist passiert. Ich habe also am Montag die komplette Montageplatte inkl. dem HMI mit zu mir nach Hause genommen, um die Problematik mit dem Raspberry Pi auszubügeln und schlussendlich das ganze System nochmal zu testen. Dieser Bericht ist also eine Dokumentation von Verzweiflung, Wut und innerlicher Genugtuung.

Wieder von vorne

Also… den Ablauf kennen wir ja nun inzwischen denke ich alle. Aber hier nochmal für die frisch zugestiegenen eine kurze Zusammenfassung:

  1. SD-Karte formatieren (das alte Betriebssystem bringt ja jetzt nix…)
  2. Raspberry Pi Imager starten und diesmal das KORREKTE Betriebssystem auswählen (kleiner Tipp: es befindet sich bei den Legacy-Versionen und hört auf den Namen „Bookworm“)
  3. Image installieren lassen
  4. Raspberry Pi starten, einrichten und Software / Bibliotheken installieren (ja.. schon wieder…)

Vorbereitung des Tests

Unser Python-Programm für den Raspberry Pi hat sich ja inzwischen nochmal ein wenig geändert. Entsprechend mussten an der Stelle hier und da noch ein paar Anpassungen auf der Seite der S7-1511C vorgenommen werden – konkret mussten die von uns angedachten DBs ein wenig umstrukturiert werden, um die vorgesehenen Datenpunkte auswerten zu können.

Gleichzeitig musste allerdings auch in der Datenbank auf dem Raspberry Pi hier und da eine Anpassung vorgenommen werden, damit hier die Daten korrekt abgelegt werden können.

Bug-Busters – deine Schädlingsbekämper (hier geht’s um’s Debuggen)

Bei allem, was nun endlich wieder lief, blieb ein Punkt bisher auf der Strecke: Der Test des eigentlichen Codes, um das System soweit zum Laufen zu bekommen. Und hier steigen wir mal etwas tiefer in die Programmierung ein, denn in den Tiefen des Debuggings lauern viele ungemütliche Eigenheiten, die einen erwarten können.

Grundsätzlich muss man allerdings sagen, dass Python an sich schon (wie auch an anderer Stelle bereits erwähnt) viele Hilfestellungen gibt. Funktioniert der Code nicht komplett oder hängt an einer Stelle, so wirft einem die Kommandozeile schon durchaus einige Hinweise darauf vor die Nase. Auf der anderen Seite kann es natürlich auch zu Fehlern kommen, die nicht direkt ersichtlich sind – aber gehen wir mal ein paar Beispiele hierzu durch:

Als ein erstes Beispiel möchte ich hier eine fiese Falle aufzeigen, vor der man sich nur schützen kann, wenn man sich permanent auf dem neusten Stand hält… ein Update von Bibliotheken – und ja, ein Update hat schonmal immens Probleme mit sich gebracht. In diesem Fall hielt sich die Thematik jedoch einigermaßen im Rahmen. In diesem Fall beziehe ich mich explizit auf die Bibliothek von Adafruits ads1x15, die zu Beginn des Oktobers ein Update erhalten hat. Hier hat sich gleichzeitig auch die Syntax ein wenig geändert, um die Funktionen der Bibliothek zu nutzen:

vorher

nachher

Der Aufruf der Funktionen hat sich leicht geändert und die Adressierung der Pins hat sich angepasst. Im Grunde erstmal keine wesentliche Änderung, allerdings wirft die Fehlermeldung dazu schon erstmal ein paar Fragen auf, da der Interpreter immer wieder davon spricht, dass die Funktion in der zuerst aufgeführten Form nicht zugeordnet werden kann. Bei solchen Problemen lohnt sich dann ein Blick in die jeweilige Dokumentation der Bibliothek.

Ein weiterer Fehler (an dem ich allerdings unweigerlich selbst dran schuld bin) wird meist durch inkonsistenten Code entstehen – wobei zu erwähnen ist, dass einem hier allerdings die meisten IDEs deutlich unter die Arme greifen. Inkonsistent bezieht sich hierbei auf die Benennung von Variablen und die entsprechende Verwendung. Da Python case-sensitiv ist, muss gerade hier auf die Schreibweise der Variablen geachtet werden, um Fehlern im Code und daraus resultierenden Problemen im Programm zu entgehen.

vorher

nachher

Was ist hier also passiert? Die Variablen „Result“ und „Cursor“ wurden entsprechend zunächst mit großem Anfangsbuchstaben geschrieben, im Verlauf des Codes allerdings mit kleinem Anfangsbuchstaben. Das führt unweigerlich im Code zu Fehlern, da plötzlich Variablen verwendet werden sollen, die nicht existieren.

Im späteren Verlauf der Tests ging es dann um die Thematik der Schleifen und insbesondere wie, warum und warum nicht und auch gerade wann die einzelnen Schleifen ihre Abbruchbedingungen erfüllen und wann die nächste Schleife ausgeführt wird. Das alles im Detail hier nochmal aufzuschreiben, würde den Rahmen maßlos sprengen… allerdings möchte ich an dieser Stelle einen allgemeinen Trick kurz erwähnen, der schonmal viel Arbeit abnimmt und meist auch zu schnellem Verständnis des Problems führt: Die Funktion print()

Ich bin mir nicht sicher, ob ich das bereits in einem früheren Beitrag schonmal erwähnt hatte, allerdings bewirkt ein gut platziertes print() mit entsprechendem Inhalt an einigen Stellen im Code wahre Wunder. So kann man beispielsweise im vorliegenden Fall prüfen, ob die erste Schleife überhaupt einen gewissen Punkt erreicht, oder das Programm bereits vorher abstürzt. Zusätzlich kann hinten dran direkt geprüft werden, ob die Schleife überhaupt verlassen wird und ob die nächste Schleife beginnt. Das alles lässt sich mit print() dadurch gut lösen, da diese Funktion eine Ausgabe in der Konsole erzeugt und das auch nur, wenn genau diese Zeile abgearbeitet / interpretiert wird. Heißt im Umkehrschluss: erreiche ich ein von mir erstelltes print() nicht, muss der Fehler zwischen dem vorherigen print() und diesem liegen – was den Bereich schonmal deutlich eingrenzt.