![]() |
Infomationstechnik Cocktailmaschine Leertrinkbetrieb |
Sommersemester 2020 Rogg, Fabian Mezger, Felix |
|
|||
Anmerkung: Dateien, in denen für den Leertrinkbetrieb programmiert wurde. ESP-Memory(alles) ESP-Bestellen: Bestellen.ino, functions.h,functions.cpp, Leertrinkbetrieb.h, index.h, jquery.h Beginnen möchten wir mit der Vorstellung des Aufgabengebietes: Auswertung der Informationen Wie bereits erwähnt, wurde die Auswertung auf zwei ESPs verteilt(ESP-Memory, ESP-Bestellen). Der erste Codeausschnitt zeigt die erste Auswertung auf dem ESP-Memory: Gesendet wird eine stock[8] dieser wird abgefragt und entsprechend der Bedingung wird das Array transfer_data mit bool-Werten befüllt. Die Logik ist in dem File ESPnow.cpp in der Funktion OnDataReceive implementiert. Anschließend wird transfer_data[8] via UART gesendet. Der zweite Teil, der auch wesentlich umfangreicher ist, übernimmt die ESP-Bestellen: Das Auswertungs_array, welches mit dem Transfer_data_array beschrieben wird, wird hier ausgelesen. Hier werden die einzelnen Zutaten mit ihren jeweiligen, aktuellen Werte beschrieben. Nun kommen wir zu der eigentlichen Auswertung(welche Cocktails sind überhaupt machbar). Hierzu werden die einzelnen Zutaten Funktionen übergeben, die auswerten, ob ein Cocktail möglich ist, oder nicht und das Ergebnis in einem Array für alkoholische Cocktails und antialkoholische Cocktails wieder mit bool Werten beschreibt. Natürlich wird dasselbe auch für die antialkoholischen Getränke gemacht. Zu finden ist dieser Teil des Codes in der Bestellen.ino, genauer gesagt in der loop(da es ja immer wieder kontolliert werden soll. Die Funktionen sind ausgelagert in den functions.cpp und functions.h. Noch ein kleiner Ausschnitt aus der functions.cpp, der Vollständigkeit halber. UART-Kommunikation Nun kommen wir zu der UART-Kommunikation. Betrachten müssen wir hier den Code in ESP-Memory und den Code in ESP-Bestellen. Wir beginnen wieder mit der ESP-Memory. Zu sehen ist die vollständige Loop der Ino Datei. Die vielen auskommentierten Zeilen sind ein Überbleibsel eines komplizierten Handshakes zwsichen ESP-Bestellen ESP-Memory, welcher aber im Endeffekt eher negative Auswirkungen hatte, deshalb wurde auf ein Handshake zwsichen ESP-Bestellen und ESP-Memory in dem Sinne verzichtet. Wichtig ist allerdings der programmierte handshake, der im Prinzip signalisiert, dass alle Daten von ESP-Wiegen angekommen sind und somit als Startzeichen für die UART-Kommunikation dient. Anschließend wird das halb ausgewertete Array transfer_data(siehe obere Erklärung zu Auswertung) via UART versendet(Serial.write). Die counter-logik mit dem Reset des ESPs wird eingeführt, um die Kommunikation zu synchronisieren, da erst beim Reset des ESP-Memory richtige Daten bei der ESP-Bestellen ankommen, bzw. die Kommunikation im richtigen Rhythmus ist. Vor dem Hintergrund eines Zwischenspeichers ist es jedoch klar, dass die Kommunikation, insbesondere die Synchronität bzw. das Detektieren von richtigen Nachrichten kein einfaches Unterfangen ist. In Bezug auf unser Unterfangen ist jedoch ein gewisses Zeitfenster gegeben, da sich die Zutaten für ca. 10-15 Sekunden in aller Regel nicht verändern(Auswahl Getränk, Zubereitung etc.). Das heißt unsere Kommunikation sollte alle 10-15 Sekunden eine "richtige Nachricht" versenden bzw. empfangen. Stand jetzt ist dies gewährleistet, sofern synchronisiert(geresetet wird). Kommen wir nun wieder zu dem ESP-Bestellen. Hier befindet sich die UART-Logik logischerweise in der Bestell.ino / loop. Der Handshake ist wie auch bei der ESP-Memory auskommentiert. Mit Serial.available() wird überprüft, ob die Kabelverbindungen(RX/TX) besteht. Die Abfrage hat sich insofern als nützlich erwiesen, da wenn keine Verbindung besteht, die Loop nicht ausgeführt wird! Mit Serial.read wird die Nachricht ausgelesen. Da wir wie bereits erwähnt mit einem Synchronisationsproblem zu kämpfen hatten, wurde ein Filter implementiert der die falschen Nachrichten(immer nur 1er) rausfiltert und nur Nachrichten, mit unterschiedlichen Werten in das auswertungs_array schreibt. Ferner bestand das Problem, dass für eine gewisse Zeit immer diesselbe Nachricht geschickt wird, obwohl die Nachricht an sich nicht mehr dieselbe war. Auch dieses Problem war verschmerzbar, da das Empfangen von gleichen Werten unproblematisch ist, wenn nach einer gewissen Zeit, wieder eine Synchronität hergestelllt werden kann. Schlimmer wären unterschiedliche falsche Werte, da dies bedeuten würde, dass sich die Leertrinkfunktion(welche Cocktails sind darstellbar ..) sich verändern würde. Halten wir also fest: die Kommunikation ist ein fragiles Gebilde, bei dem die Synchronität der Nachrichten und das Empfangen der richtigen Nachricht komplex ist. Wichtig für die UART-Kommunikation: Die beiden ESPs, die miteinander kommunizieren über die UART, benötigen unbedingt eine gemeinsame Masse! . Das heißt ESP-Memory und ESP-Bestellen In Anbetracht der aufgebrachten Zeit für das Projekt gehen wir zwar diesem Problem nach, allerdings belassen wir es darauf, das Problem zu detektieren und ggf. schnell zu beheben. -Stand 24.04.2020 /*Nachtrag/* Erste Test haben gezeigt, dass höchstwahrscheinlich nur ein Problem der Bezugsmasse vorhanden ist. Wenn ESP-Bestellen und ESP-Memory den gleichen Massebezug besitzen, spielt es keine Rolle von welchem Gerät die Energieversorgung stammt. Dynamische Webseite Der ESP-Bestellen erstellt verschiedene Dateien, die für das Bilden der Webseite notwendig sind. Dazu gehören die design.css, die alle Anpassungen des Aussehens der Webseite enthält, die cocktails.json, die die Informationen über die Verfügbarkeit der Cocktails enthält und die jquery, die notwendig ist, um die Webseite teileweise neuzuladen, ohne dass ein neues Bilden der Webseite Cocktailmaschine gemacht werden muss. Index.h in der die Verlinkung des empty_drink_mode implementiert ist. Schlussendlich noch die Leertrinkbetrieb.h in der teilweise statische Elemente implementiert sowie dynamsiche Elemente umgesetzt sind. Beim Aufruf des Links empty_drink_mode auf der Index Seite der Cocktailmaschine wird im Hintergrund ein Javascript ausgeführt, dass im Intervall von 5 Sekunden die Lister der alkoholischen und anti- alkoholischen Cocktails aktualisiert. Dabei wird die Cocktail.json geparst, um die Information der verfügbaren Cocktails auszulesen. Die noch verfügbaren Cocktails werden über eine Abfrage dann in einem HTML String gepackt. Durch eine AJAX-Programmierung(Asynchronous JavaScript and XML), die das partielle Neuladen einer HTML-Webseite ermöglicht, wird der String, der noch verfügbaren Cocktails, geladen. Nachfolgend wieder ein paar gut auskommentierte Programmzeilen. Momentan bereitet der Bestellbutton noch Probleme, d.h. man kann keinen Cocktail bestellen auf der empty drink_mode Seite.(Stand 24.04.2020) Zu finden ist dieser Codeausschnitt in ESP-Bestellen, Bestellen.ino in der setup-Funktion. Nachfolgender Codeausschnitt ist in der Leertrinkbetrieb.h zu finden. |
Mit Unterstützung von Prof. J. Walter | Sommersemester 2020 |