Sammelpost – iTender Entwicklung

Konzept v1

Das erste Konzept haben Tobias Hopp und Nick Thiele zusammen entwickelt.

Es basierte auf einem Kasten, welcher hinten 4 Behälter haben wird und generell irgendwie ein Getränk ausgeben kann.

Uns kam die Idee auf ein Display zu verwenden. Zu diesem Zeitpunkt waren wir allerdings noch sehr weit weg von der Umsetzung und konnten erst von einfachen Knöpfen mit einem kleinem zweizeiligen LCD-Display träumen.

Das System sollte auf einem Raspberry Pi mit ein paar Knöpfen und ein bis zwei Pumpen basieren.

Konzept v1 war somit abgeschlossen und eine Skizze des Gerätes war fertig. Leider steht diese Skizze derzeit nicht mehr zu Verfügung.

Konzept v2

Die zweite und aktuelle Version des iTender ist uns wirklich gelungen.
Gemeinsam mit Herrn Hornbogen haben Tobias Hopp und Nick Thiele ein Gerät entwickelt, welches selbst dem aktuellen Markt konkurrenz macht.

Wir haben uns einige bereits auf dem Markt etablierte Cocktail-Mischer angeschaut und unsere Ideen zusammen mit etwas inspiration in ein kleines 3D-Modell und das Konzept v2 einfließen lassen.

Zur Version 1 ist kein Vergleich mehr möglich. Die zweite Version ist auch sehr überdimensioniert für ein Schulprojekt, allerdings hat Tobias Hopp, welcher der Entwickler des Programms ist, sehr viel Freude an dem Projekt und versucht es deshalb groß aufzuziehen.

Oberfläche

Die Oberfläche soll dem Benutzer ein einfaches System vorspielen, welches im Hintergrund aber sehr komplex und hoch konfigurierbar ist.
Der endgültige Benutzer, welcher seinen Cocktail ins Glas bekommt, soll nichts von dem Hintergrundsystem mitbekommen und nur die schön gemachte Oberfläche zu sehen bekommen.

Für das Wartungspersonal sind die Menü-Optionen da.
Das Menü ist auch sehr einfach gehalten. Es gibt 4 Möglichkeiten fortzufahren.

Unter Behälter befinden sich die Zutaten und Füllstände der einzelnen Behälter.
Hier kann das Wartungspersonal neue Zutaten den Behältern zuweisen bzw. andere Füllstände.

Unter Statistiken kann der Endbenutzer aktuelle Statistiken des iTenders einsehen.
Von wie viele Drinks generell zubereitet wurden bis wie viele Drinks und Zutaten im System sind.

Unter den Einstellungen können wir aktuell nur einen Menü-Punkt hinterlegen.
Derzeit befindet sich dort der Taster um die Getränke von der Cloud zu aktualisieren.
In Zukunft soll hier aber beispielsweise die Ambiente-Farbe sowie das WiFi eingerichet werden.

Hardware

Wie bereits oben erwähnt möchten wir einen Raspberry Pi als „Hauptplatine“ nutzen.
Diese Entscheidung viel uns relativ leicht, da wir bereits im vergangenen mit diesen kleinen PCs gearbeitet hatten und er alle Zwecke erfüllte.
Ein Arduino bzw. ioT Entwicklungsboard hätte nicht genug Rechenleistung um die Webseite darzustellen und die einzelnen Drinks zu berechnen.
Er hätte schlichtweg einfach zu wenig Arbeitsspeicher um die Drinks zu verarbeiten.
Da wir allerdings Ausgänge in Form von Anschlusspins benötigen, blieb uns nur noch der Raspberry Pi übrig.

Für die Pumpen haben wir uns in Konzept 2 für Peristaltikpumpen entschieden. Sie haben entscheidene Vorteile gegenüber normalen mechanischen Pumpen. Zum einen ist die Flüssigkeit vor Schmutz und Resten der Produktion gesichert, da der Schlauch im inneren dieser Peristaltik (auch Schlauchpumpe genannt) in einem halbkreis zusammengedrückt wird, wodurch er Flüssigkeit einschließt und danach auf der anderen Seite freigibt.
Zum anderen ist die Pumpe sehr genau. Ohne den Motor kommt keine Flüssigkeit durch die Pumpe selber wie es teilweise bei anderen Pumpen so ist. In dem End-Schlauch wird sogar ein kleiner Unterdruck erzeugt, welcher die überschüssige Flüssigkeit drin behält.

Sollte der Schlauch anfangen zu gimmeln, kann man ihn einfach austauschen, aber die Pumpe behalten, da sie von außen nichts mitbekommt.
Die von uns gewählten Peristaltik-Pumpen sind von Gehreke. Eine Marke welche sich bereits früher in den Themen Pumpen und Anschlüssen für Wasser und Gas sehr behaupten konnte.
Sie arbeitet mit einer Betriebsspannung von 12 Volt Gleichstrom (DC), weshalb sie nicht direkt an den Raspberry Pi angeschlossen werden kann.
Auch mit 5 V wäre der Anschluss nicht ratsam, da die Kraft des Stroms dann über die Platine des Raspberry Pis geleitet werden müsste, was ab 3 Pumpen problematisch wird.
Die Pumpe arbeitet mit circa 150-300mA, was dennoch einen sehr niedrigen Stromverbrauch darstellt.

Software Version 2

Das iTender-Produkt, das von Tobias Hopp programmiert und in zusammenarbeit mit Nick Thiele entworfen wurde, hat ein Versionsupdate von v1 auf v2 erfahren. Dieses Update hat weit über 100 Stunden Programmierarbeit in Anspruch genommen und beinhaltet zahlreiche Neuerungen und Optimierungen.

Zunächst wurden einige Features entfernt und verschoben, während gleichzeitig neue hinzugefügt wurden. Eine wichtige Änderung betrifft das Volumen, das nun nur noch in der Zutaten-Auswahl zu finden ist. Bei Auswahl wird dann das eingestellte Volumen als 100% interpretiert und der Wägesensor stellt sich entsprechend ein.

Eine weitere wichtige Änderung betrifft die Ultraschall-Sensoren, die entfernt wurden, da sie nicht wartbar sind und einige Fehler aufweisen. Dazu gehören unter anderem eine ungenaue Messung, keine genauen Ergebnisse ohne Kalibrierung und kein schneller Behälterwechsel. Diese Änderungen haben dazu beigetragen, das Produkt zu optimieren und die Benutzererfahrung zu verbessern.

Ein neues Feature namens Arduino-Proxy wurde hinzugefügt. Dieses Feature ermöglicht es, einen Arduino einzusetzen, der Befehle vom Raspberry Pi aufnimmt und so bis zu 100 Pumpen oder 50 Sensoren steuern kann. Die Kommunikation erfolgt über die serielle Schnittstelle des Arduinos und des USB-Ports des Raspberry Pi. Der Arduino wird beim Installieren sowie Updaten automatisch vom iTender programmiert. Im Setup kann nun auch ein bestimmter Pin bei jedem Behälter ausgewählt werden.

Eine weitere wichtige Änderung betrifft die Erweiterung des Systems auf bis zu 50 Behälter. Das System wurde optimiert, um nun bis zu 50 Behälter zu ermöglichen. Diese Erweiterung ermöglicht es, das Produkt noch flexibler und leistungsfähiger zu machen.

Ein neues iTender-Logo, entworfen von Nick Thiele, wurde hinzugefügt. Es gibt dem Produkt eine frische Optik und unterstreicht die Qualität sowie die Professionalität des Produkts.

In Version 2 wurde die Software bis zu 20% schneller gemacht. Diese Optimierung ermöglicht es, das Produkt noch schneller und effizienter zu nutzen.

Features wie Hotspot wurden vorübergehend pausiert, um sich auf die wesentlichen Features zu konzentrieren. Diese Entscheidung ermöglicht es, sich auf die Kernfunktionalitäten des Produkts zu konzentrieren und die Benutzererfahrung zu verbessern.

Ein weiteres wichtiges Feature, das geplant ist, ist ein Säuberungsprogramm. Dieses Feature wird dazu beitragen, das Produkt längerfristig zu erhalten und die Lebensdauer des Produkts zu verlängern.

Im Setup wurde das Einmessen komplett überarbeitet. Wo es vorher kompliziert war, ist es jetzt ein einfacher Tastenklick und nimmt nur ungefähr ein bis zwei Minuten in Anspruch. Diese Änderung erleichtert die Verwendung des Produkts und ermöglicht es, Zeit zu sparen.

Falls keine Sensorik (wie z.B. die Wägezelle) für den Behälter (Container) zur Verfügung steht, wird eine manuelle Zählung durchgeführt, um einen ungefähren Füllstand zu erhalten. Diese Änderung ermöglicht es, das Produkt auch in Situationen zu verwenden, in denen keine Sensorik vorhanden ist.

Insgesamt hat das Versionsupdate von v1 auf v2 dazu beigetragen, das iTender-Produkt zu optimieren und die Benutzererfahrung zu verbessern. Diese Neuerungen und Optimierungen ermöglichen es, das Produkt noch flexibler, leistungsfähiger und benutzerfreundlicher zu machen.

Programmierung / Software

Die Software wurde von Tobias Hopp entwickelt.
Die Software unterliegt dem privaten Copyright Schutz § 69a Abs. 3 Satz 1 UrhG.
Jegliche publikation, bearbeitung, manipulation und verbreiten wird rechtlich verfolgt.
Die Rechte an den folgenden Inhalten hat alleine die natürliche Person Tobias Hopp, geb. 02.05.2003.

Programmiersprache & Bibliotheken

Als Programmiersprache haben wir TypeScript verwendet.
TypeScript ist eine Abwandlung von JavaScript, welche aber strikte Typen hat.
Typen sind in Programmiersprachen eigenschaften von Variablen. Eine Variable kann eine Zeichenkette (sogenannten String) enthalten, aber auch eine Nummer (integer) sein.
Wenn Typengleichheit besteht, kann eine Variable (beispielsweise x) nur einmal definiert werden und behält dann den Typ bei. Wenn man beispielsweise x = 5 beschreibt, dann kann x nicht mehr eine Zeichenkette oder gar nichts werden.
Typensicherheit ist gerade in größeren Projekten von nöten, da so garantiert werden kann, welcher Entwickler wo und was bei einer sogenannten Methode (wie eine Funktion/Formel) zurückgibt.
Da JavaScript, von haus aus keine Typensicherheit bietet, verabscheuen es einige.
TypeScript vereint nun die Typensicherheit mit der eigentlich sehr schönen Sprache JavaScript.

TypeScript hat den Vorteil, dass es sehr anpassbar und dynamisch ist. Es gibt bereits viele Bibliotheken um LEDs und GPIO-Pins über den Raspberry Pi anzusteuern. Außerdem lässt sich in wenigen schritten ein kleiner Webserver einrichten, welcher nun quasi das Hauptstück des iTenders ist.
Da es eben so anpassbar ist, konnten wir den kleinen Webserver sehr erweitern und ihn genau zu unseren zwecken Programmieren.
Die Sprache ist außerdem eine Kompilierungs und Interpretierungssprache, ähnlich wie Java, weshalb sie sehr schnell ist und viele Asynchrone-Tasks (Aufgaben im Hintergrund) ausführen kann.

Genau das war uns wichtig, dass der Nutzer nicht darauf warten muss, dass das Programm fertig berechnet hat, sondern direkt weiter die Bedienung fortführen kann.

Für den Server selber haben wir nicht nur natives Type- bzw. JavaScript verwendet, sondern auch Node.
NodeJs ist die Serverseitige programmierung, des eigentlich für das Web entwickelten Javascripts.
Hier lassen sich die eben besagten Bibliotheken installieren und schnell zu einer Lösung programmieren.

Für Bibliotheken (Programmschnipsel anderer Programmierer) benutzen wir den Package Manager Yarn.
Über ihn lassen sich einfach Bibliotheken installieren, kompilieren und verwenden.
Für das kompilieren selber benutzen wir den TSC (Typescript compiler), für das verpacken für die Benutzeroberfläche Webpack.

Für die Datenbank, welche alles Speichert, haben wir uns für MongoDB entschieden.
MongoDB als No-SQL Datenbank arbeitet im Gegensatz zu Datenbanksystemen wie MySQL mit Dokumenten anstatt mit richtigen Tabellen.
Es bestehen keine festen Relationen zu anderen Dokumenten, es gibt auch keine wirklichen Tabellen.
Jegliche Datensätze sind dynamisch, das heißt, es besteht keine feste Datenstruktur.
Das klingt erstmal schlecht, ist aber mit dem richtigen Programm hilfreich.

Ein MongoDB Server verwaltet mehrere logische Datenbanken, die wiederum einen oder mehrere logische Namensräume enthalten, die sogenannten Collections. In einer Collection werden die einzelnen Datensätze, Dokumente genannt, verwaltet.

Durch die Benutzung von BSON als Dokument, lässt sich ohne großen Aufwand ein ganzes selbst erstelltes Paket in der Datebank abspeichern.
MongoDB ist durch die einfachheit auch deutlich schneller und ermöglicht es größere Datensätze mehr im Programmierkontext zu erfassen.
Mit der Bibliothek Mongoose ist es auch möglich das einzige Problem der Typensicherheit in den Griff zu bekommen.
So ist MongoDB nun schnell, Typensicher und bereit für große Mengen an Daten.

Versionen:

• Yarn: 1.22.19
• NodeJS: 18.9.1
• TypeScript: 4.8.4
• WebPack: 5.74.0
• Mongodb/Mongoose: 5.11.97

Statistiken

Stand 17.01.2023:

# Programmiercode
23217 Zeilen
# Zeitaufwand
92 Stunden und 35 Minuten
# Importierte Bibliotheken
29 Stück
# Dateien (Klassen und Objekte)
~90 Dateien

Aufbau

Das Programm des iTenders ist getrennt in 3 Teile

• iTender Basis
  • Die Basis besteht aus der Kommunikation zwischen den Pumpen, LEDs und jeglicher Hardware
  • Außerdem gibt es Timer, automatische Events, Prüfung und aktualisierung von Getränken etc.
  • Sie übernimmt z.B. das Starten vom Getränke-Füllen, stoppen sowie Berechnen von den Zutaten für ein Getränk
  • Dieser Teil arbeitet seh eng mit dem Websocket-Server zusammen, um so auf Events vom Endnutzer zu reagieren.
• iTender Webserver
  • Der Webserver ist einfach ein statischer Webserver welche Dateien „serviert“, die dann von der Oberfläche geladen werden können.
  • Der Client-Browser oder iTender-Display lädt dann diese Seite, erstmal passiert dann noch nichts
• iTender Websocket-Server
  • Der Websocket-Server dient zur eigentlichen Live-Kommunikation zwischen Client und Gerät.
  • Der Server und die Webseite (Endgerät), bauen eine Ende-zu-Ende Verbindung auf
  • Die Kommunikation zwischen Client und Websocket-Server basiert auf JSON (Javascript-Objekt-Notation).
  • Da der Websocket in früheren Client-Versionen anfällig für Fehler beim Übertragen von nicht alphabetischen Zeichen war, wird der gesendete Inhalt noch in Base64-Kodiert.
  • Base64 dient dazu, die Daten binär zu kodieren, um sie auf der Gegenstelle wieder zu entkodieren.
  • Außerdem wird beim übertragen eine Checksumme mitgegeben, um bei Fehlerhaften Paketen ein neues anzufragen.

Programm & Umsetzung

Das Programm ist aufgeteilt in eine Client und eine Server Seite.
Die Serverseite ist wieder geteilt in „Application“ und „WebSocket“.
Die Application ist der eigentliche iTender. Sie übernimmt die ganzen Aufgaben wie das füllen der Getränke, ansteuern der Pumpen und LEDs.
Der sogenannte WebSocket ist für die Kommunikation mit dem Client (Benutzer-Seite) da.
Er kommuniziert mit der Benutzeroberfläche (UI für User Interface) und sendet bzw. empfängt Pakete welche dann die einzelnen Aktionen auf beiden Seiten ausführen.

Alle Kommunikation zwischen dem WebSocket und der UI basieren auf JSON (Javascript Objekt Notation).
Dieses Datenformat ist sehr robust und ermöglicht das einfache verpacken und senden von Datentypen wie Zeichenketten, Wahr/Falsch Werten (Boolische Werte) sowie Nummern, Objekten und Listen.
Damit die Kommunikation ausfallssicher ist, wird das JSON in Base64 umgewandelt.
Base64 ist eine Kodierung welche nur im gesamten wieder umgewandelt werden kann. Mit einzelnen Teilstücken dieser Enkodierung lässt sich nicht auslesen was dort einmal war.
Das ist zum einen eine kleine Sicherheit, aber auch unsere Möglichkeit zu prüfen, ob die Kommunkation gestört ist.
Sollte die Gegenstelle das jeweilige Paket nicht wieder in JSON kodieren können, fordert es das Paket erneut an.
Falls dann immer noch ein Problem besteht wird ein Alarm erstellt, welcher im Fehlerspeicher des iTenders gesichert wird.
Dort kann er vom Support-Team ausgelesen werden bzw. behandelt werden.

Da JSON eine Objekt Notation ist, müssen wir uns hier noch auf ein gemeinsames Protokoll einigen.
Unser Protokoll ist ein selbst gewähltes Event -> Data Prinzip.
Jedes Paket hat somit ein Event an das es geknüpft ist, die Gegenstelle weiß dann damit richtig umzugehen.
Beispiele hierfür sind das Event STATUS oder REQUEST.
Ein STATUS hat wieder einzelne sub-Status, welche den Status des iTenders wiedergeben.
Ein Status ist beispielsweise READY (iTender ist bereit und wartet auf Benutzerinteraktion) oder DOWNLOADING (iTender lädt neue Getränke herunter).
Der Status ist derzeit noch oben links im Rohformat in der UI sichtbar, soll aber früher oder später anders dargestellt werden.
Eine REQUEST hingehen ist nicht wie die anderen „Protokolle“ nur senden und der andere empfängt, sondern ein die Oberfläche kann hier gezielt Daten anfragen und verarbeiten.
Ein Beispiel hierfür ist die Konfiguration welche im Setup-Menü angezeigt wird.
Damit alle Felder bereits ausgefüllt sind, wie der Benutzer sie eben konfiguriert hat, wird eine REQUEST mit dem Typen „CONFIG“ an den WebSocket (iTender Basis) gesendet. Er antwortet dann mit der Konfiguration und die UI kann die Felder ausfüllen.

Um alle Getränke, Zutaten, Jobs und Vorgänge zu speichern, hat der iTender eine Datenbank.
Bei der Datenbank haben wir uns für MongoDB entschieden.

Alle 10 Minuten sowie vor und nach einem Job (Auftrag fürs Mischen) wird ein sogenannter Health-Check durchgeführt.
In ihm wird überprüft ob ein vorheriger Job fehlgschlagen ist und vielleicht fest steckt. Ob der iTender irgendwo Probleme erkennt und ob alle Behälter ausreichend gefüllt sind (Falls vorhanden mit Sensoren).

Bei einer Behälter-Aktualisierung werden erst einmal alle Behälter von der Datenbank abgefragt, welche einen Inhalt gesetzt haben (also eine Zutat für einen Cocktail).
Danach werden alle Getränke abgefragt. Für jeden Cocktail wird nun geprüft ob alle Zutaten in den Behältern zu verfügung stehen.
Wenn dies der Fall ist, wird der Cocktail einer Liste hinzugefügt, welche unter Laufzeit aufrufbar ist und über eine Request von der UI abgefragt werden kann.

Für die Aktualisierung der Getränke aus der Cloud wird auch JSON benutzt.
Hier wird eine Abfrage an den Cloud-Server gestellt, falls eine Internetverbindung gefunden wurde.
Der Cloudserver antwortet hier, falls erfolgreich, mit einer Liste aller Zutaten und Getränke.
Der iTender geht dann die lokalen Getränke und Zutaten durch und schaut ob er den Eintrag auch auf der Server-Version finden kann. Falls das nicht der Fall sein sollte wird das Element aus dem lokalen Speicher entfernt.

Danach geht die Applikation die Cloud-Elemente durch. Jeweils wird geprüft ob das Element bereits existiert und Änderungen vorliegen.
Für das Prüfen von Änderungen am Thumbnail (Vorschaubild des Getränks) sorgt eine Prüfsumme (Checksum).
Wir benutzen hier den HASH-256 Algorithmus, welcher einen eindeutigen Prüfschlüssel für einen bestimmten Inhalt erstellt. Passt dieser nicht, fordert der iTender das Thumbnail erneut von der Cloud an und speichert dieses lokal.

Da wir andere Schriftarten verwenden, müssen diese auch irgendwie geladen werden.
Anfangs haben wir die Schriftarten über den von Tobias H. bereitgestellten Font-Server geladen.
Da im späteren Anwendungsfall aber nicht immer eine Internetverbindung bereitsteht, können wir keine Schriftarten von Cloud-Services laden. Somit sind alle Schriftarten nun lokal heruntergeladen und werden auch dementsprechend lokal geladen.

Damit es später auch möglich ist, den iTender von einem anderen Gerät aus zu steuern, ist der Webserver auch über andere Geräte im Netzwerk erreichbar.
Das lässt sich im Setup anfangs über die „Remote-Zugriff“ Option erlauben.
Falls aktiviert kann einfach auf die IP-Adresse des Raspberry Pis zugegriffen werden.
Die Verbindung wird dann allerdings der Haupt-Instanz getrennt.
Diese Vorkehrung haben wir getroffen um jegliche Fehler mit Doppel-Events zu vermeiden.
Es wäre theoretisch möglich alles auf mehreren Endgeräten anzuzeigen, ist aber nicht das was wir haben wollen.

Für LEDs nutzen wir eine Bibliothek aus NPM (Node Package Manager), welche das „schreiben“ auf die LEDs sehr einfach macht. Hier wird die Farbe je nach Status des iTenders angepasst. Im Ruhezustand (READY) ist sie auf der Ambiente-Farbe, welche man ebenfalls im Setup festlegen kann.

Kommentar des Autors

Das Projekt hat nun ingesamt einiges meiner Zeit in Anspruch genommen.
Jegliche Kopie oder Verbreitung meines Sourcecodes würde nur mir selbst schaden.
Das Projekt ist in seinem selbst Uhrheberrechtlich geschützt und wird es auch bleiben.
Die Idee es zu einem Marktfähigen Produkt zu machen besteht, ist aber nicht ganz ausgedacht.

Da die Programmierung eben so viel Mühen gekostet hat, bzw. kostet, wäre mir wichtig Respektvoll damit umzugehen.

Sensorik, Arduino und Pumpen

HX711 Wägezellen

Wieso?

Die HX711-Wägezelle ist eine digitale Lastzellen-Schnittstelle, die hauptsächlich in Waagen und anderen Anwendungen zur Gewichtsmessung verwendet wird. Sie bietet eine hohe Genauigkeit und Zuverlässigkeit bei der Messung von Lasten. Hier sind einige der Vorteile der Verwendung einer HX711-Wägezelle:

• Hohe Genauigkeit: Die HX711-Wägezelle ist in der Lage, Lasten mit einer Genauigkeit von bis zu 0,1% zu messen. Diese hohe Genauigkeit ermöglicht es, kleine Veränderungen in Lasten schnell und präzise zu erfassen.
• Breite Spannweite: Die HX711-Wägezelle ist in der Lage, Lasten im Bereich von 20 kg bis zu 50 kg zu messen, was für viele Anwendungen ausreichend ist.
• Einfache Schnittstelle: Die HX711-Wägezelle verfügt über eine einfache Schnittstelle, die es ermöglicht, die gemessenen Lasten mit einem Mikrocontroller oder einem Computer zu verarbeiten.
• Niedriger Stromverbrauch: Die HX711-Wägezelle verfügt über einen niedrigen Stromverbrauch, was sie ideal für Anwendungen mit begrenzter Stromversorgung macht.
• Geringer Platzbedarf: Die HX711-Wägezelle ist sehr kompakt und benötigt nur wenig Platz, was sie ideal für Anwendungen mit begrenztem Platzangebot macht.

Beschreibung

Die HX711 Wägezelle ist ein hochpräziser digitale Lastaufnehmer-IC, der entwickelt wurde, um die Lastaufnahme von Wägezellen (Belastungssensoren) zu verbessern. Es ist ein 24-Bit-A/D-Wandler, der speziell für die Verwendung mit Wägezellen entwickelt wurde und eine hohe Genauigkeit und Auflösung bietet.

Die HX711 Wägezelle besteht aus zwei Teilen: dem HX711 IC selbst und dem Wägezellen-Modul. Das Wägezellen-Modul enthält den HX711 IC sowie die nötigen Verstärker, Filter und Schaltungen, um das Signal der Wägezelle zu verarbeiten. Es kann direkt an eine Vielzahl von Wägezellen angeschlossen werden und ermöglicht es so, die Lastaufnahme von Wägezellen zu verbessern.

Der HX711 IC selbst verfügt über zwei Eingänge, die für die Verarbeitung des Signals der Wägezelle verwendet werden. Der DAT-Eingang wird verwendet, um das analoge Signal der Wägezelle zu empfangen, während der CLK-Eingang verwendet wird, um das Signal zu synchronisieren und die Daten auszulesen.
Das Modul kann mit einer Vielzahl von Mikrocontroller-Systemen wie Arduino, Raspberry Pi usw. verwendet werden. Es gibt auch eine Bibliothek, die es ermöglicht, den HX711 IC einfach in die Anwendung zu integrieren und die Daten auszulesen.

Die HX711 Wägezelle bietet eine hohe Genauigkeit und Auflösung und eignet sich daher besonders für Anwendungen, bei denen eine hohe Genauigkeit erforderlich ist, wie z.B. in der Lebensmittelindustrie, der Medizintechnik oder im Laborbereich.

Es ist jedoch wichtig zu beachten, dass die Genauigkeit auch von der Wägezelle selbst und von der Kalibrierung abhängt. Eine regelmäßige Kalibrierung und Überprüfung des Skalierungsfaktors und der Nullpunktlast ist daher erforderlich, um eine hohe Genauigkeit zu gewährleisten.

Ein weiteres wichtiges Thema ist die Umgebungsbedingungen, wie z.B. Temperatur, Feuchtigkeit und Vibrationen können die Genauigkeit beeinflussen, es ist daher empfehlenswert, die Wägezelle in einer stabilen Umgebung zu betreiben und diese Faktoren zu berücksichtigen.

Insgesamt ist die HX711 Wägezelle ein leistungsfähiges und zuverlässiges Werkzeug, um die Lastaufnahme von Wägezellen zu verbessern und ist in vielen Anwendungen einsetzbar, vor allem in denen die hohe Genauigkeit erfordert wird.

In unserem Arduino-Code verwenden wir die Bibliothek Hx711, welche die Kommunikation mittels HX711-Wägezelle deutlich erleichtert.
Einige Funktionen werden nun erklärt:

Die Methode „tare()“ der HX711-Bibliothek wird verwendet, um die Wägezelle auf Null zu setzen. Dies bedeutet, dass die aktuelle Last auf der Wägezelle als Nullpunkt angesehen wird und die Messungen, die danach mit der Methode „get_units(5)“ durchgeführt werden, relativ zu diesem Nullpunkt erfolgen.

Wenn die tare() Methode aufgerufen wird, berechnet das HX711-Modul einen Mittelwert aus einer bestimmten Anzahl von Messungen und speichert diesen als Nullpunkt. Danach werden alle Messungen, die mit der Methode „get_units(5)“ durchgeführt werden, relativ zu diesem Nullpunkt berechnet.

Peristaltikpumpen

Wieso?

Peristaltikpumpen sind eine Art von Pumpe, die auf der natürlichen Wellenbewegung des menschlichen Körpers basiert. Sie sind besonders nützlich für Anwendungen, bei denen ein präziser Flüssigkeitsfluss und eine geringe Verunreinigung von entscheidender Bedeutung sind. Im Folgenden werden einige der Vorteile von Peristaltikpumpen und mögliche Nachteile beschrieben.

Einer der größten Vorteile von Peristaltikpumpen ist ihre Fähigkeit, Flüssigkeiten präzise und kontinuierlich zu dosieren. Da die Pumpe durch den Druck des Schlauchs betrieben wird, ist sie in der Lage, sehr kleine Flüssigkeitsmengen zu fördern, was sie ideal für Anwendungen wie die Medizintechnik, die Analytik oder die Pharmazie macht.

Peristaltikpumpen sind auch besonders gut geeignet für Anwendungen, bei denen eine geringe Verunreinigung erforderlich ist. Da die Flüssigkeit nicht mit beweglichen Teilen in Kontakt kommt, ist die Gefahr von Verunreinigungen oder Abnutzung geringer als bei anderen Arten von Pumpen.

Ein weiterer Vorteil von Peristaltikpumpen ist ihre Fähigkeit, aggressive oder viskose Medien zu fördern. Da die Flüssigkeit nur durch den Schlauch befördert wird, kann die Pumpe auch Medien mit hohem Schwebstoffgehalt oder hoher Viskosität problemlos handhaben. Dies macht sie ideal für Anwendungen wie die Chemie- oder Lebensmittelindustrie.

Peristaltikpumpen sind auch sehr zuverlässig und langlebig, da sie keine beweglichen Teile haben und somit weniger anfällig für Verschleiß und Ausfälle sind. Sie sind einfach zu warten und zu reparieren, was die Gesamtbetriebskosten senkt.

Ein möglicher Nachteil von Peristaltikpumpen ist, dass sie eine höhere Anschaffungskosten haben können als andere Arten von Pumpen. Jedoch ist es zu berücksichtigen, dass die längere Lebensdauer und die geringeren Wartungskosten diesen höheren Anschaffungspreis auf lange Sicht ausgleichen können. Ein weiterer Nachteil kann sein, dass sie nicht geeignet sind für Anwendungen mit sehr hohen Drücken oder sehr hohen Temperaturen.

In Zusammenfassung bieten Peristaltikpumpen eine präzise und kontinuierliche Dosierung von Flüssigkeiten, eine geringe Verunreinigung, die Fähigkeit, aggressive oder viskose Medien zu fördern, Zuverlässigkeit und Langlebigkeit, und sind einfach zu warten und zu reparieren. Obwohl sie höhere Anschaffungskosten haben können, sind sie auf lange Sicht eine kosteneffiziente Wahl für bestimmte Anwendungen.

Ultrasonic Sensor

Wieso nicht?

Es gibt mehrere Gründe, warum es nicht sinnvoll ist, einen Ultraschall-Sensor wie den HC-SR04 in einem Getränkespender wie dem iTender zu verwenden. Einer der größten Nachteile ist die niedrige Skalierbarkeit des Sensors. Da der Ultraschall-Sensor auf einer bestimmten Distanz basiert, funktioniert er nur innerhalb einer begrenzten Reichweite. Dies bedeutet, dass er nicht in der Lage ist, genaue Messungen von Behältern zu erhalten, die sich weiter entfernt befinden.

Ein weiterer Nachteil ist die ungenaue und unzuverlässige Ergebnisse, die der Sensor liefert. Der Ultraschall-Sensor ist anfällig für Fehler, die durch Hindernisse oder Reflektionen verursacht werden. Dies führt dazu, dass der Sensor ungenaue Messungen liefert, die nicht zuverlässig sind.

Ein weiteres Problem ist, dass der Sensor immer einmalig eingemessen werden muss, damit er ordnungsgemäß funktioniert. Dies bedeutet, dass jedes Mal, wenn ein neuer Behälter hinzugefügt wird, der Sensor erneut eingemessen werden muss, um sicherzustellen, dass die Messungen korrekt sind. Dies kann Zeit und Ressourcen verschwenden.

Schließlich ist der Ultraschall-Sensor nicht dynamisch genug, um mit anderen Behältern im iTender-System zu arbeiten. Da der Sensor auf eine bestimmte Distanz basiert, funktioniert er nicht gut, wenn mehrere Behälter im System vorhanden sind. Dies kann zu Fehlern führen, wenn der Sensor versucht, die Füllstände von mehreren Behältern gleichzeitig zu messen.

Zusammenfassend lässt sich sagen, dass der Ultraschall-Sensor HC-SR04 für den Einsatz in einem Getränkespender wie dem iTender nicht die beste Wahl ist. Aufgrund seiner niedrigen Skalierbarkeit, ungenauen Ergebnissen, der Notwendigkeit der Einmessung und der Unfähigkeit, dynamisch mit anderen Behältern im System zu arbeiten, ist es wahrscheinlich besser, eine andere Technologie zu verwenden.

Wir haben uns anfänglich für den Ultraschall-Sensor entschieden. Er sollte über dem Glas hängen und den Abstand zum gefüllten Messen.
Leider treten dabei einige Nachteile und Probleme auf, die wir bis dato nicht bedacht haben.
Unter anderem muss vor jedem wechseln eines Behälters (größenwechsel) eine neue Einmessung gestartet werden.
Diese Einmessung muss bei den Wägezellen beispielsweise nur alle paar Tage/Wochen ausgeführt werden.