Technische Beeinflussbarkeit der Geschmacksache Kaffee - Benutzerbeiträge [de]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-26T08:50:48Z

Armin Rohnen: /* Maschinensimulator */

<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Sommersemester 2026 =
Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich.

Die Programmierung der Mikrocontroller erfolgt in MicroPython und die übergeordnete Steuerung ist eine MATLAB®-APP mit einem Prozessschaubild. Die Grundfunktionalität dieses Vorgehensweise ist in der Quellenliste unter [40] (MATLAB® meets MicroPython) beschrieben.

Das Projekt wurde bereits durch eine Projektgruppe bearbeitet und hat einen Projektstand, der jedoch noch nicht die gesamte erforderliche Steuerungsfunktionalität umfasst.

Es wird angestrebt eine Steuerung auf Basis eines Nucleo STM32H743ZI2 zu erstellen. Dies würde die aktuell drei Steuerungsplatinen und Mikrocontroller auf einen reduzieren. Kommunikation wäre dann lediglich zum Displaycontroller erforderlich.

= Aufgabenanalyse =
==UART-Kommunikation==
Es soll eine Stern-Topologie implementiert werden, welche die UART-Kommunikation
zu einem separaten Display-Controller, dem Maschinensimulator und der Wartungs-
App herstellt. Dabei sind Sende- und Empfangs-Token f¨ ur das Display, die Wartungs-App und den Maschinensimulator einzuf¨ uhren. Es gilt dabei, den Umfang und Takt der
neuen Token festzulegen.

==Mehrkernnutzung und/oder Multitasking==

Es gibt bestimmte Vorgänge, welche regelmäßig zur Unterbrechung des Pro-
grammablaufs führen. Es gilt, diese Vorgänge zu identifizieren und umzuleiten,
damit diese den Programmablauf nicht mehr unterbrechen. Die Möglichkeit
der Mehrkernnutzung fällt dabei aus, da der STM32H753ZI nur über einen
M7-Kern verfügt. Dank der Hardware-Unterstützung DMA sowie der Nutzung
der uasyncio-Library besteht die Möglichkeit, die Vorgänge umzuleiten. Somit
können die Unterbrechungen des Programmablaufs reduziert werden.

== Maschinensimulator ==
Die Hauptaufgabe des Maschinensimulators ist die Nachbildung aller Sensordaten der Kaffeemaschine. Dies ermöglicht die Programmentwicklung der Steuerungselektronik ohne die reale Hardware. Die für die Simulation benötigte Hardware ist bereits rudimentär vorhanden, muss aber für einen zuverlässigen und störungsfreien Betrieb optimiert werden. Zudem muss für die Umsetzung der Durchflusssimulation noch eine entsprechende Hardware-Modellierung erfolgen. Softwareseitig ist der Python-Code für die Datengenerierung größtenteils fertiggestellt [Quelle: Wiki ToDo Maschinensimulator - Funktionsnutzung]. Es fehlen aktuell noch die Flowmetersimulation sowie die Aufheizsimulation, welche für die Validierung der Druck- und Temperaturregelung benötigt wird. Die vom Maschinensimulator gelieferten Temperatur- und Druckwerte müssen validiert werden. Dabei wird soll ein bereits bekannter Messfehler bei den Temperaturwerten durch die Anpassung der Einstellwerte behoben werden. Für den Programmablauf des Simulators wird eine MATLAB®-App entwickelt, die parallel zum Ablauf des STM32 arbeitet. Für die UART-Kommunikation in der Sterntopologie zwischen dem Maschinensimulator und dem STM32 müssen zudem spezifische Sende- und Empfangs- Token implementiert sowie deren Taktung und Datenumfang definiert werden. Zusätzlich wird ein Gateway als Kommunikationsschnittstelle zwischen dem Maschinensimulator und der Wartungs-App implementiert. Des Weiteren muss während der Ausarbeitung des Maschinensimulators eine Projektfortschrittsdokumentation erfolgen. Die Ausarbeitung erfolgt in einem ein- bis zweiwöchigen Turnus.

== Füllstandsregler ==
Die Füllstandsregelung erkennt den Füllstand über eine Kurzschlussdetektion. Liegt kein
Kurzschluss vor, wird dies als zu niedriger Füllstand interpretiert und der Boilerdruckregler
zur Vermeidung von Trockenheizen gesperrt. Beim Erreichen des Sollfüllstands erfolgt eine
gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches Ein- und
Ausschalten der Regelung zu vermeiden. Da die in der MATLAB®-GUI realisierte Boiler Füllstandsregelung aus [114] bereits in einem ersten Stand in MicroPython übertragen
wurde, liegt der Fokus hier auf der Validierung am Maschinensimulator sowie der
Abstimmung mit den Schnittstellenpartnern.

== Boilerdruckregelung ==
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung aus [114], die auf
einem PD-Regler basiert, vollständig zu übertragen, sodass die Regelung unabhängig von der
externen PC-Umgebung arbeitet.

== Mischtemperaturregler ==
Der Mischtemperaturregler nach [114] dient zur Regelung der Kaffee- und
Teewassertemperatur und wird als PID-Regler für das Mischventil umgesetzt. Die Stellgröße
ist dabei die Verstellung des Mischventils. Der Temperatursollwert wird aus dem jeweils
aktiven Rezept vorgegeben. Da die Regelung vom aktuellen Durchfluss abhängt, wird eine
Kaskadenstruktur verwendet. In dieser Struktur arbeitet der Durchflussregler als innerer,
schneller Regelkreis, während der Mischtemperaturregler den äußeren Regelkreis bildet und
die Ergebnisse des inneren Kreises berücksichtigt. Daraus ergibt sich ein besonderes
Augenmerk auf das Testen des Zusammenspiels der beiden Regler anhand des
Maschinensimulators, um das Ziel – die Implementierung dieser Kaskadenregelung auf dem
STM32 – zu erreichen.

== Durchflussregler ==
Ein Durchflussregler, der in MATLAB® gemäß [114] vorliegt, wird als PID-Regler in
MicroPython umgesetzt. Durch die Anpassung der Pumpendrehzahl über einen
Spannungssollwert von 0–5 V kann ein konstanter oder ein profildefinierter Volumenstrom
entsprechend der Sollwertvorgabe realisiert werden. Als innerer Regelkreis liefert er
kontinuierlich Durchflusswerte an den Mischtemperaturregler. Daraus ergibt sich der Fokus
auf der Implementierung und dem Test des Reglers sowie auf der Validierung seines
Zusammenspiels mit dem übergeordneten Mischtemperaturregler im Maschinensimulator,
um die Integration auf dem STM32 sicherzustellen.

== Startprozedur ==
Das Ziel ist es, eine Startprozedur zu definieren. Beim Einschalten der Stromversorgung starten die Prozessoren der Maschine. Ohne eine festgelegte Ablauflogik würden die einzelnen Systemteile jedoch unkoordiniert anlaufen. Daraus ergibt sich der technische Bedarf, eine eindeutige Reihenfolge für den Start festzulegen und die zugehörigen Ausgaben auf dem Display so zu definieren, dass der Startprozess nachvollziehbar verfolgt werden kann.

Dafür müssen zunächst die relevanten Inhalte der Startprozedur identifiziert werden. Außerdem sind die beteiligten Schnittstellen zu erkennen und die Reihenfolge der einzelnen Startschritte so festzulegen, dass ein geordneter und technisch sinnvoller Maschinenstart möglich ist.

== Display ==
Ziel ist eine kompakte und benutzerfreundliche Displaylösung, die sich nahtlos in das Gesamtsystem integriert. Das Display mit Touchfunktion dient als Schnittstelle zur Interaktion zwischen Bediener und Maschine. Messwerte müssen strukturiert darzustellen sowie die Auswahl von Funktionen wie Kaffeerezepten, Teewasser- oder Dampfbezug zu ermöglichen. Zusätzlich übernimmt das Display die Visualisierung der Startprozedur, relevanter Betriebszustände und der Sicherheitsfunktionen.

Zunächst werden die benötigten Funktionalitäten analysiert und definiert, darunter Messwertanzeige, Benutzerführung und Sicherheitsmeldungen. Parallel dazu werden drei unterschiedliche Displaytypen (rundes Display, LCD2 und 1,69Display) auf ihre Eignung hin untersucht, um anschließend die, am besten passende, Variante auszuwählen. Die MCU der Displayplatine erhält die benötigten Informationen über die UART-Kommunikation aus dem System und muss in die bestehende Gesamtarchitektur integriert werden. Der Vertikalhebel dient zur Vorgabe von Sollwerten, während die beiden Anschlagtaster die Funktionen Kaffeebezug und Flush beziehungsweise Reinigung auslösen. Diese Bedienelemente sind mit der Displayplatine zu verbinden, damit das Display die zugehörigen Informationen und Zustände für den Benutzer darstellen kann.

== STM32 ==
Als Haupt-MCU soll ein STM32H753ZI-Controller verwendet werden. Es soll sichergestellt
werden, dass die vorinstallierten Steckerleisten CN7 bis CN10 ausreichend Pins für
Definition der benötigten UART-, ADC-, DAC- und GPIO-Pins aufweisen. 
Die Boilerdruck-, die Wassertemperatur-, die Durchfluss- und die Füllstandsregelung des
Boilers müssen implementiert werden. Es soll ebenfalls eine UART-Kommunikation für ein
Touch-Display, einen Maschinensimulator sowie eine Möglichkeit zum Anschließen einer
Wartungs-App programmiert werden. Um einen geordneten Ablauf der einzelnen
Komponenten bei Inbetriebnahme der Maschine zu gewährleisten, soll eine Startprozedur
programmiert werden

== Wartungs - APP ==
Es müssen der Inhalt des Wartungs-Token definiert werden, ein GUI-Layout erstellt werden, ein Kommunikationsaufbau mit dem Maschinensimulator hergestellt werden, die Darstellung der Messwerte, eine manuelle Startprozedur, das Schalten von Magnetventilen, die Einstellung von Sollwertvorgaben (Boilerdruck, Bezugswassertemperatur, Durchfluss) und manuellen Stellwerten für das PWM-Heizelement, die Pumpenansteuerung und die Stellung des Dosierventils sowie die Messwertspeicherung und das Logging programmiert werden. Die App ist bis zu einem funktionsfähigen Prototypen erforderlich.

= Leistungsvereinbarung =

== Startprozedur ==
Es wird eine definierte und nachvollziehbare Startprozedur für die Maschine erarbeitet. Das Ergebnis umfasst eine festgelegte Reihenfolge der Startschritte, die Berücksichtigung der relevanten Schnittstellen sowie ein Konzept für die Ausgaben auf dem Display, damit der Startprozess strukturiert abläuft und für den Benutzer verfolgbar ist.

== Maschinensimulator ==
Das Ziel dieser Arbeit ist die Entwicklung eines voll funktionsfähigen Maschinensimulators, der das Testen der auf den STM32 zu verlagernden Regelkreisen ermöglicht. Hierfür werden physikalische Größen wie Temperatur und Druck simuliert und über die Digital- Potentiometer MCP4151 als elektrische Signale an die Steuerungselektronik ausgegeben. Der Maschinensimulator wird in einer MATLAB®-App implementiert, sodass der Maschinensimulators parallel zu einer weiteern MCU an einem PC betrieben werden kann. Die App soll sowohl den Betrieb des Simulators als solches als auch die Nutzung als Wartungs-App ermöglichen.

== Wartungs - APP ==
Die aktuelle MATLAB®-GUI soll in eine komfortable Bedienoberfläche für Wartungs- und Einstellarbeiten überführt werden. Bei aktivierter Wartungs-App sollen sämtliche Tastenfunktionen und die Vertikalhebelfunktion nutzbar sein und zudem alle Aktoren (Magnetventile, Pumpenleistung und Schrittmotorverstellungen) über diese App angesteuert werden können. Des Weiteren soll die bisherige Visualisierung der Messwerte und Schaltzustände erhalten bleiben. Dies allerdings mit einer geringeren Aktualisierungsrate, da vier Aktualisierungen pro Sekunde als ausreichend angesehen werden.

==UART-Kommunikation==
Um die spezifischen Daten von dem STM32H7 auf das Display zu übertragen, sowie
Steuerbefehle des Displays für den STM32H7, wird ein neue UART-Schnittstelle mit Display-Token eingeführt. Ebenfalls wird eine UART-Kommunikation mit entsprechendem Token für
Maschinensimulator und der Wartungs-App implementiert. Dabei soll ein Gateway den
Zugriff für die Wartungs-App integriert werden.

==Multitasking==
Die direkte Hardware-Unterstützung über DMA gestaltet sich schwierig in MicroPython, da
sie von MicroPython automatisch verwendet wird (bspw. bei Buffern) und nur über
Registeraccess direkt ausgeführt werden kann. Daher wird die Nutzung der uasyncio-Library
bevorzugt, welche die Vorgänge, die den Programmablauf verzögern, umleitet. Dadurch soll
das Programm reibungsfreier ablaufen.

==STM32H7==
Die bestehenden Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung,
Mischtemperaturregelung und Durchflussregelung werden von den drei Microcontroller auf
den STM32H7 verlagert. Ebenfalls erfolgt die Migration der Messwerterfassung aller
verbauten Sensoren auf die neue STM32H7-Plattform. 
Zusätzlich wird eine UART-Kommunikation implementiert, die die Anbindung des Displays,
eines Maschinensimulators sowie für den Zugriff durch eine externe Wartungs-App über
einem Gateway ermöglicht. 
Um einen geordneten Ablauf der einzelnen Komponenten bei Inbetriebnahme der Maschine
zu gewährleisten, wird eine Startprozedur programmiert. 
Die Hardware-Umsetzung wird von LfbA Armin Rohnen übernommen.

== Display ==
Es wird eine geeignete Displaylösung ausgewählt und in das Gesamtsystem integriert. Das Ergebnis umfasst die Darstellung relevanter Messwerte, Betriebszustände, Sicherheitsmeldungen und der Startprozedur sowie die Einbindung der Bedienfunktionen über Touch, Vertikalhebel und Anschlagtaster.

== Vertikalhebel ==
Der Vertikalhebel wird als Bedienelement technisch und funktional in das System integriert. Das Ergebnis umfasst die Erfassung und Verarbeitung der Hebelstellung als Sollwertvorgabe für den Durchflussregler, die Einbindung der Anschlagtaster als zusätzliche Bedienfunktionen sowie die Anzeige der relevanten Informationen auf dem Display.

== Verlagerung der Regler Syntax ==
Ziel dieser Arbeit ist die vollständige Übertragung der in MATLAB® implementierten Regelalgorithmen aus [114] in MicroPython sowie deren Vorbereitung für die Implementierung auf einer STM32‑MCU. Die Umsetzung erfolgt entlang der bestehenden Reglerstruktur: Füllstandsregler, Boilerdruckregelung, Mischtemperaturregler und Durchflussregler.

= Besprechungsprotokolle und weitere Unterlagen =
* [[:Datei:20260214 Abschlusspraesentation.pdf|Übergabepräsentation Vorgänger]]
* [[:Datei:20260326 Projektstart.pdf|Aktueller Projektstand]]
* [[Projektstart 26.03.2026]]
* [[Projektrücksprache 02.04.2026]]
* [[Projektrücksprache 09.04.2026]]
* [[Projektrücksprache 17.04.2026]]
* [[Projektrücksprache 24.04.2026]]
* [[Projektrücksprache 08.05.2026]]
* [[Projektrücksprache 15.05.2026]]
* [[Projektrücksprache 22.05.2026]]
* [[Projektrücksprache 29.05.2026]]
* [[Projektrücksprache 05.06.2026]]
* [[Projektrücksprache 12.06.2026]]
* [[Projektrücksprache 19.06.2026]]
* [[Projektrücksprache 03.07.2026]]
* [[Projektrücksprache 10.07.2026]]
* [[Abschlusspräsentation 24.07.2026]]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-26T08:48:02Z

Armin Rohnen: /* Besprechungsprotokolle und weitere Unterlagen */

<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Sommersemester 2026 =
Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich.

Die Programmierung der Mikrocontroller erfolgt in MicroPython und die übergeordnete Steuerung ist eine MATLAB®-APP mit einem Prozessschaubild. Die Grundfunktionalität dieses Vorgehensweise ist in der Quellenliste unter [40] (MATLAB® meets MicroPython) beschrieben.

Das Projekt wurde bereits durch eine Projektgruppe bearbeitet und hat einen Projektstand, der jedoch noch nicht die gesamte erforderliche Steuerungsfunktionalität umfasst.

Es wird angestrebt eine Steuerung auf Basis eines Nucleo STM32H743ZI2 zu erstellen. Dies würde die aktuell drei Steuerungsplatinen und Mikrocontroller auf einen reduzieren. Kommunikation wäre dann lediglich zum Displaycontroller erforderlich.

= Aufgabenanalyse =
==UART-Kommunikation==
Es soll eine Stern-Topologie implementiert werden, welche die UART-Kommunikation
zu einem separaten Display-Controller, dem Maschinensimulator und der Wartungs-
App herstellt. Dabei sind Sende- und Empfangs-Token f¨ ur das Display, die Wartungs-App und den Maschinensimulator einzuf¨ uhren. Es gilt dabei, den Umfang und Takt der
neuen Token festzulegen.

==Mehrkernnutzung und/oder Multitasking==

Es gibt bestimmte Vorgänge, welche regelmäßig zur Unterbrechung des Pro-
grammablaufs führen. Es gilt, diese Vorgänge zu identifizieren und umzuleiten,
damit diese den Programmablauf nicht mehr unterbrechen. Die Möglichkeit
der Mehrkernnutzung fällt dabei aus, da der STM32H753ZI nur über einen
M7-Kern verfügt. Dank der Hardware-Unterstützung DMA sowie der Nutzung
der uasyncio-Library besteht die Möglichkeit, die Vorgänge umzuleiten. Somit
können die Unterbrechungen des Programmablaufs reduziert werden.

== Maschinensimulator ==
Die Hauptaufgabe des Maschinensimulators ist die Nachbildung aller Sensordaten der

Kaffeemaschine. Dies ermöglicht die Programmentwicklung der Steuerungselektronik ohne

die reale Hardware. Die für die Simulation benötigte Hardware ist bereits rudimentär

vorhanden, muss aber für einen zuverlässigen und störungsfreien Betrieb optimiert werden.

Zudem muss für die Umsetzung der Durchflusssimulation noch eine entsprechende

Hardware-Modellierung erfolgen. Softwareseitig ist der Python-Code für die

Datengenerierung größtenteils fertiggestellt [Quelle: Wiki ToDo Maschinensimulator -

Funktionsnutzung]. Es fehlen aktuell noch die Flowmetersimulation sowie die

Aufheizsimulation, welche für die Validierung der Druck- und Temperaturregelung benötigt

wird. Die vom Maschinensimulator gelieferten Temperatur- und Druckwerte müssen

validiert werden. Dabei wird soll ein bereits bekannter Messfehler bei den

Temperaturwerten durch die Anpassung der Einstellwerte behoben werden. Für den

Programmablauf des Simulators wird eine MATLAB®-App entwickelt, die parallel zum Ablauf

des STM32 arbeitet. Für die UART-Kommunikation in der Sterntopologie zwischen dem

Maschinensimulator und dem STM32 müssen zudem spezifische Sende- und Empfangs-

Token implementiert sowie deren Taktung und Datenumfang definiert werden. Zusätzlich

wird ein Gateway als Kommunikationsschnittstelle zwischen dem Maschinensimulator und

der Wartungs-App implementiert. Des Weiteren muss während der Ausarbeitung des

Maschinensimulators eine Projektfortschrittsdokumentation erfolgen. Die Ausarbeitung

erfolgt in einem ein- bis zweiwöchigen Turnus.

== Füllstandsregler ==
Die Füllstandsregelung erkennt den Füllstand über eine Kurzschlussdetektion. Liegt kein
Kurzschluss vor, wird dies als zu niedriger Füllstand interpretiert und der Boilerdruckregler
zur Vermeidung von Trockenheizen gesperrt. Beim Erreichen des Sollfüllstands erfolgt eine
gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches Ein- und
Ausschalten der Regelung zu vermeiden. Da die in der MATLAB®-GUI realisierte Boiler Füllstandsregelung aus [114] bereits in einem ersten Stand in MicroPython übertragen
wurde, liegt der Fokus hier auf der Validierung am Maschinensimulator sowie der
Abstimmung mit den Schnittstellenpartnern.

== Boilerdruckregelung ==
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung aus [114], die auf
einem PD-Regler basiert, vollständig zu übertragen, sodass die Regelung unabhängig von der
externen PC-Umgebung arbeitet.

== Mischtemperaturregler ==
Der Mischtemperaturregler nach [114] dient zur Regelung der Kaffee- und
Teewassertemperatur und wird als PID-Regler für das Mischventil umgesetzt. Die Stellgröße
ist dabei die Verstellung des Mischventils. Der Temperatursollwert wird aus dem jeweils
aktiven Rezept vorgegeben. Da die Regelung vom aktuellen Durchfluss abhängt, wird eine
Kaskadenstruktur verwendet. In dieser Struktur arbeitet der Durchflussregler als innerer,
schneller Regelkreis, während der Mischtemperaturregler den äußeren Regelkreis bildet und
die Ergebnisse des inneren Kreises berücksichtigt. Daraus ergibt sich ein besonderes
Augenmerk auf das Testen des Zusammenspiels der beiden Regler anhand des
Maschinensimulators, um das Ziel – die Implementierung dieser Kaskadenregelung auf dem
STM32 – zu erreichen.

== Durchflussregler ==
Ein Durchflussregler, der in MATLAB® gemäß [114] vorliegt, wird als PID-Regler in
MicroPython umgesetzt. Durch die Anpassung der Pumpendrehzahl über einen
Spannungssollwert von 0–5 V kann ein konstanter oder ein profildefinierter Volumenstrom
entsprechend der Sollwertvorgabe realisiert werden. Als innerer Regelkreis liefert er
kontinuierlich Durchflusswerte an den Mischtemperaturregler. Daraus ergibt sich der Fokus
auf der Implementierung und dem Test des Reglers sowie auf der Validierung seines
Zusammenspiels mit dem übergeordneten Mischtemperaturregler im Maschinensimulator,
um die Integration auf dem STM32 sicherzustellen.

== Startprozedur ==
Das Ziel ist es, eine Startprozedur zu definieren. Beim Einschalten der Stromversorgung starten die Prozessoren der Maschine. Ohne eine festgelegte Ablauflogik würden die einzelnen Systemteile jedoch unkoordiniert anlaufen. Daraus ergibt sich der technische Bedarf, eine eindeutige Reihenfolge für den Start festzulegen und die zugehörigen Ausgaben auf dem Display so zu definieren, dass der Startprozess nachvollziehbar verfolgt werden kann.

Dafür müssen zunächst die relevanten Inhalte der Startprozedur identifiziert werden. Außerdem sind die beteiligten Schnittstellen zu erkennen und die Reihenfolge der einzelnen Startschritte so festzulegen, dass ein geordneter und technisch sinnvoller Maschinenstart möglich ist.

== Display ==
Ziel ist eine kompakte und benutzerfreundliche Displaylösung, die sich nahtlos in das Gesamtsystem integriert. Das Display mit Touchfunktion dient als Schnittstelle zur Interaktion zwischen Bediener und Maschine. Messwerte müssen strukturiert darzustellen sowie die Auswahl von Funktionen wie Kaffeerezepten, Teewasser- oder Dampfbezug zu ermöglichen. Zusätzlich übernimmt das Display die Visualisierung der Startprozedur, relevanter Betriebszustände und der Sicherheitsfunktionen.

Zunächst werden die benötigten Funktionalitäten analysiert und definiert, darunter Messwertanzeige, Benutzerführung und Sicherheitsmeldungen. Parallel dazu werden drei unterschiedliche Displaytypen (rundes Display, LCD2 und 1,69Display) auf ihre Eignung hin untersucht, um anschließend die, am besten passende, Variante auszuwählen. Die MCU der Displayplatine erhält die benötigten Informationen über die UART-Kommunikation aus dem System und muss in die bestehende Gesamtarchitektur integriert werden. Der Vertikalhebel dient zur Vorgabe von Sollwerten, während die beiden Anschlagtaster die Funktionen Kaffeebezug und Flush beziehungsweise Reinigung auslösen. Diese Bedienelemente sind mit der Displayplatine zu verbinden, damit das Display die zugehörigen Informationen und Zustände für den Benutzer darstellen kann.

== STM32 ==
Als Haupt-MCU soll ein STM32H753ZI-Controller verwendet werden. Es soll sichergestellt
werden, dass die vorinstallierten Steckerleisten CN7 bis CN10 ausreichend Pins für
Definition der benötigten UART-, ADC-, DAC- und GPIO-Pins aufweisen. 
Die Boilerdruck-, die Wassertemperatur-, die Durchfluss- und die Füllstandsregelung des
Boilers müssen implementiert werden. Es soll ebenfalls eine UART-Kommunikation für ein
Touch-Display, einen Maschinensimulator sowie eine Möglichkeit zum Anschließen einer
Wartungs-App programmiert werden. Um einen geordneten Ablauf der einzelnen
Komponenten bei Inbetriebnahme der Maschine zu gewährleisten, soll eine Startprozedur
programmiert werden

== Wartungs - APP ==
Es müssen der Inhalt des Wartungs-Token definiert werden, ein GUI-Layout erstellt werden, ein Kommunikationsaufbau mit dem Maschinensimulator hergestellt werden, die Darstellung der Messwerte, eine manuelle Startprozedur, das Schalten von Magnetventilen, die Einstellung von Sollwertvorgaben (Boilerdruck, Bezugswassertemperatur, Durchfluss) und manuellen Stellwerten für das PWM-Heizelement, die Pumpenansteuerung und die Stellung des Dosierventils sowie die Messwertspeicherung und das Logging programmiert werden. Die App ist bis zu einem funktionsfähigen Prototypen erforderlich.

= Leistungsvereinbarung =

== Startprozedur ==
Es wird eine definierte und nachvollziehbare Startprozedur für die Maschine erarbeitet. Das Ergebnis umfasst eine festgelegte Reihenfolge der Startschritte, die Berücksichtigung der relevanten Schnittstellen sowie ein Konzept für die Ausgaben auf dem Display, damit der Startprozess strukturiert abläuft und für den Benutzer verfolgbar ist.

== Maschinensimulator ==
Das Ziel dieser Arbeit ist die Entwicklung eines voll funktionsfähigen Maschinensimulators,

der das Testen der auf den STM32 zu verlagernden Regelkreisen ermöglicht. Hierfür werden

physikalische Größen wie Temperatur und Druck simuliert und über die Digital-

Potentiometer MCP4151 als elektrische Signale an die Steuerungselektronik ausgegeben.

Der Maschinensimulator wird in einer MATLAB®-App implementiert, sodass ein

Programmablauf des Maschinensimulators parallel zum Hauptprogramm (main.py)

ablaufen kann. Die App soll sowohl den Betrieb des Simulators als solches als auch die

Nutzung als Wartungs-App ermöglichen.

== Wartungs - APP ==
Die aktuelle MATLAB®-GUI soll in eine komfortable Bedienoberfläche für Wartungs- und Einstellarbeiten überführt werden. Bei aktivierter Wartungs-App sollen sämtliche Tastenfunktionen und die Vertikalhebelfunktion nutzbar sein und zudem alle Aktoren (Magnetventile, Pumpenleistung und Schrittmotorverstellungen) über diese App angesteuert werden können. Des Weiteren soll die bisherige Visualisierung der Messwerte und Schaltzustände erhalten bleiben. Dies allerdings mit einer geringeren Aktualisierungsrate, da vier Aktualisierungen pro Sekunde als ausreichend angesehen werden.

==UART-Kommunikation==
Um die spezifischen Daten von dem STM32H7 auf das Display zu übertragen, sowie
Steuerbefehle des Displays für den STM32H7, wird ein neue UART-Schnittstelle mit Display-Token eingeführt. Ebenfalls wird eine UART-Kommunikation mit entsprechendem Token für
Maschinensimulator und der Wartungs-App implementiert. Dabei soll ein Gateway den
Zugriff für die Wartungs-App integriert werden.

==Multitasking==
Die direkte Hardware-Unterstützung über DMA gestaltet sich schwierig in MicroPython, da
sie von MicroPython automatisch verwendet wird (bspw. bei Buffern) und nur über
Registeraccess direkt ausgeführt werden kann. Daher wird die Nutzung der uasyncio-Library
bevorzugt, welche die Vorgänge, die den Programmablauf verzögern, umleitet. Dadurch soll
das Programm reibungsfreier ablaufen.

==STM32H7==
Die bestehenden Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung,
Mischtemperaturregelung und Durchflussregelung werden von den drei Microcontroller auf
den STM32H7 verlagert. Ebenfalls erfolgt die Migration der Messwerterfassung aller
verbauten Sensoren auf die neue STM32H7-Plattform. 
Zusätzlich wird eine UART-Kommunikation implementiert, die die Anbindung des Displays,
eines Maschinensimulators sowie für den Zugriff durch eine externe Wartungs-App über
einem Gateway ermöglicht. 
Um einen geordneten Ablauf der einzelnen Komponenten bei Inbetriebnahme der Maschine
zu gewährleisten, wird eine Startprozedur programmiert. 
Die Hardware-Umsetzung wird von LfbA Armin Rohnen übernommen.

== Display ==
Es wird eine geeignete Displaylösung ausgewählt und in das Gesamtsystem integriert. Das Ergebnis umfasst die Darstellung relevanter Messwerte, Betriebszustände, Sicherheitsmeldungen und der Startprozedur sowie die Einbindung der Bedienfunktionen über Touch, Vertikalhebel und Anschlagtaster.

== Vertikalhebel ==
Der Vertikalhebel wird als Bedienelement technisch und funktional in das System integriert. Das Ergebnis umfasst die Erfassung und Verarbeitung der Hebelstellung als Sollwertvorgabe für den Durchflussregler, die Einbindung der Anschlagtaster als zusätzliche Bedienfunktionen sowie die Anzeige der relevanten Informationen auf dem Display.

== Verlagerung der Regler Syntax ==
Ziel dieser Arbeit ist die vollständige Übertragung der in MATLAB® implementierten Regelalgorithmen aus [114] in MicroPython sowie deren Vorbereitung für die Implementierung auf einer STM32‑MCU. Die Umsetzung erfolgt entlang der bestehenden Reglerstruktur: Füllstandsregler, Boilerdruckregelung, Mischtemperaturregler und Durchflussregler.

= Besprechungsprotokolle und weitere Unterlagen =
* [[:Datei:20260214 Abschlusspraesentation.pdf|Übergabepräsentation Vorgänger]]
* [[:Datei:20260326 Projektstart.pdf|Aktueller Projektstand]]
* [[Projektstart 26.03.2026]]
* [[Projektrücksprache 02.04.2026]]
* [[Projektrücksprache 09.04.2026]]
* [[Projektrücksprache 17.04.2026]]
* [[Projektrücksprache 24.04.2026]]
* [[Projektrücksprache 08.05.2026]]
* [[Projektrücksprache 15.05.2026]]
* [[Projektrücksprache 22.05.2026]]
* [[Projektrücksprache 29.05.2026]]
* [[Projektrücksprache 05.06.2026]]
* [[Projektrücksprache 12.06.2026]]
* [[Projektrücksprache 19.06.2026]]
* [[Projektrücksprache 03.07.2026]]
* [[Projektrücksprache 10.07.2026]]
* [[Abschlusspräsentation 24.07.2026]]

Glasboilermaschine

2026-04-25T09:35:07Z

Armin Rohnen: /* Kerneigenschaften und Gleichheit zwischen den unterschiedlichen Maschinentypen */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/b0d68a04d4d54f498c331933d33efebf" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Die Glasboilermaschine - MMM Style =

[[Datei:20230226 Glasboilermaschine Stand Feb2023.png|thumb|750px|gerahmt|zentriert|alternativtext=Armin Rohnen, Glasboilermaschine|Armin Rohnen, Glasboilermaschine]]

== Projektstatus ==
Durch eine Idee auf World of Coffee 2018 in Amsterdam (WOC18) wurde 2018 damit begonnen zu forschen, ob Borosilikat-Glas als Material für den Wasserboiler einer Siebträger-Espressomaschine verwendet werden kann. 
Durch die spezifischen Material-Eigenschaften wie Hitzebeständigkeit, Geschmacksneutralität und den guten Isolationseigenschaften, die Borosilikat-Glas in doppelwandiger Ausführung mit sich bringt, erschien es als Fertigungsmaterial für den Boiler besonders geeignet zu sein. Trotzdem ist die Verwendung dieses Materials in der Industrie bei den etablierten Herstellen bis jetzt gänzlich unbekannt. Boiler handelsüblicher Maschinen werden meist aus Stahl gefertigt und sind im Gehäuse der jeweiligen Maschine versteckt. 
Bei einem Boiler aus Borosilikat-Glas kann der Nutzer, sofern die freie Einsehbarkeit des Boilers gewährleistet ist, den Erhitzungsvorgang des Wassers von Anfang bis Ende miterleben. Das Sprudeln des Wassers während des Betriebs des Boilers sehen zu können ist eine absolute Neuheit, die in Kombination mit der Ästhetik und den Materialeigenschaften des Borosilikat-Glases seinesgleichen sucht. 
Erste Versuche mit einem behelfsmäßigen Versuchsaufbau zeigten, dass Borosilikat-Glas in der Realität tatsächlich als Material für den Boiler geeignet ist und mehrere Vorteile gegenüber dem herkömmlichen Stahl mit sich bringt. 
Daraufhin wurde beschlossen, das Konzept des Borosilikat-Glasboilers weiterzuverfolgen und ein Entwicklungsprojekt für eine eigene Siebträger-Espressomaschine zu starten, die mithilfe studentischer Projekt- und Abschlussarbeiten an der Fakultät 03 der Hochschule München konzipiert werden soll. 
Mit dem Versuchsaufbau des ersten Borosilikatboilers wurden erste Befeuerungen des Boilers vorgenommen. Für den Versuchsaufbau waren einige Änderungen an der Konstruktion des Borosilikatboilers erforderlich. Es wurde insbesondere auf die Verspannung durch Verschraubung verzichtet. Stattdessen wurde ein Federmechanismus eingeführt, der den Boilerdruck aufnimmt und für ausreichend Druck auf dem Dichtungssystem sorgt.

Als problematisch habe sich die vielen Durchführungen dargestellt.

Da das Glas nicht direkt auf einer metallischen Oberfläche verspannt werden darf, ist eine PTFE-Einlage definiert worden. Dies stellt im Deckel kein Problem dar. Da dort keine weiteren Durchführungen vom Boilerinneren in das Boileräußere erforderlich sind. Im Boden stellt sich die flächendeckende PTFE-Einlage als problematisch dar. Für jedes Bauteil, welches durch den Boilerboden durchgeführt wird, musste eine Dichthülse konstruiert werden. Dies führt zu Dichtheitsproblemen und mehrt die Produktionskosten.

Bestätigt wurde die Vorgehensweise für die Versuchsaufbauten der labortechnischen Espressomaschine ein Steuerungskonzept auf Basis eines Raspberry Pi zu verwenden. Erweitert mit GPIO-Expandershield, AD-Wandler-Shield und einer Softwarekombination aus Python-Skripten und MATLAB®-GUI lassen sich die Mess-, Steuerungs- und Regelungsaufgaben praxisorientiert und relativ zügig programmieren.

Erste Tests der SSR-Insel konnten ebenso durchgeführt werden. Hier konnte das Grundkonzept bestätigt werden. Es sind jedoch noch Verbesserungen im Schaltungsdesign erforderlich. Eine Vibrationspumpe kann mit dieser SSR-Schaltung nicht angesteuert werden.

Auf Basis der bis 2021 durchgeführten Grundlagenuntersuchungen wurde das Konzept der 1 (und 2) - Zylinder - Glasboilermaschine definiert.

In [23] wurde eine Borosilikatglas-Espressomaschine konstruiert bei lediglich der Boiler und der Brühturm sich sichtbar oberhalb der Arbeitsplatte befinden. Boiler und Brühturm können nahezu beliebig zueinander positioniert werden. Alle anderen benötigten Baugruppen befinden sich unterhalb der Arbeitsplatte im nicht direkt sichtbaren Bereich. Dieses Konzept wurde nochmals überarbeitet und es kam zu dem nun auf diesen Seiten präsentierten Design.

Um ein optisch ansprechendes Design für eine neue Generation der Espressomaschinen zu ermöglichen, wurde bereits im Zuge [17] Maschine mit einem Boiler aus Borosilikatglas entworfen. Hierbei besteht der Boiler aus zwei Borosilikatglaszylindern, die den Erwärmungsprozess des Wassers im Boiler für den Anwender sichtbar machen. Bei der Erwärmung des Wassers im Boiler wird kein starker Innendruck aufgebaut. Diese Druckkraft wird durch eine Verspannung zwischen Boiler und Boilerdeckel aufgenommen, wobei zu beachten ist, dass dieser Verspannmechanismus ebenfalls eine Längenänderung aufgrund von Erwärmung zu erfassen hat. In der vorangegangenen Arbeit wurde hierfür eine Stabverspannung zwischen den beiden Borosilikatglaszylindern vorgesehen. Da diese jedoch die Sicht auf das Innere des Boilers einschränkt und gleichzeitig das optisch einwandfreie Gesamtbild für den Anwender stört, soll dieser Verspannmechanismus neu entworfen werden.

Des Weiteren ist, für eine optisch ansprechende Aufteilung der wesentlichen Komponenten, eine Undertable-Konstruktion der Maschine zu entwickeln. Hierbei sollen lediglich der Borosilikatglasboiler sowie der Brühturm mit den wichtigsten Bedienelementen für den Anwender erkennbar sein. Alle weiteren Komponenten, z.B. die Kabelführung oder die Wasserzuführung und -ableitung, sollen unter der Arbeitsplatte angebracht sein, um den Blick nicht durch nebensächliche Komponenten abzulenken. Zur Optimierung des visuellen Gesamtbildes sollen der Brühturm und die darauf befindlichen Bedienelemente angepasst werden. Es mussten sowohl die Kabel- und Leitungsführungen neugestaltet werden, als auch die dafür notwendigen Elemente zur Befestigung und Platzierung angepasst werden.

Durch eine Kostenreduktion von Boilerdeckel und -boden werden für den Endverbraucher die Anschaffungskosten der Espressomaschine gesenkt, wodurch das Produkt für den Kunden attraktiver wird.

== Einsatz von FDM 3D-Druck für alle Kunststoffteile der Maschine ==
Durch den Einsatz von FDM 3D-Druck in Verbindung mit einem FDA-Zertifizierten Biopolymer als Druckwerkstoff wird die Verwendung von PFAS Kunststoffen erheblich reduziert. Aktuell zählen lediglich die verwendeten PFA-Rohre (eine Weiterentwicklung von PTFE) für die Wasserführung zu den PFAS-Kunststoffen. Da für die Serienfertigung von einer Kleinserie ausgegangen wird, ergibt sich durch den Einsatz des FDM 3D-Drucks eine Reduktion der Fertigungskosten zwischen Faktor 3 und 10. Probleme des 3D-Drucks sind jedoch die Maßhaltigkeit und die Oberflächenqualität.

== Kerneigenschaften und Gleichheit zwischen den unterschiedlichen Maschinentypen ==
Auch die Glasboiler-Siebträger-Espressomaschine basiert auf der Grundanforderung, dass die Parametrierung des Kaffeebezugs (auch Kaffeerezept genannt) von Kaffeebezug zu Kaffeebezug ohne Wartezeiten verändert werden kann. Dies erfordert die Möglichkeit die Temperatur des Kaffeebezugswassers kurzfristig ändern zu können und schließt Elemete in der Wasserführung mit hohen Wärmekapazitäten aus. Gelöst wird diese Problematik durch zwei Maßnahmen:

Verwendung von Werkstoffen niedriger Wärmeleitfähigkeit und niedriger Wärmekapazität in allen Bauteilen welche für die Heißwasserführung benötigt werden
Herstellung der Bezugswassertemperatur über einen Wassermischer, welcher dem heißen Wasser aus dem Boiler kaltes Wasserbeimischt

Dabei wird erheblich Regelungstechnik eingesetzt.

Grundlegend handelt es sich auch bei der Glasboilermaschine um eine Siebträger-Espressomaschine nach dem Grundprinzip des Zweikreisers. Dabei wird in einem Boiler dessen Temperatur so geregelt wird, dass ein definierter Dampfdruck mit Sollwert p = 1300 mbar in einem Bereich zwischen p = 1100 mbar und p = 1500 mbar frei eingestellt werden kann. Der im Boiler befindliche Wärmetasucher (Wasserwendel) ist so ausgelegt, dass im ungünstigsten Fall das direkte Bezugswasser mit mindestens 100 °C bezogen wird. Über ein Dosierventil wird dem direkten Bezugswasser kaltes Wasser beigemischt und es ergibt sich Kaffeebezugswasser bzw. Teewasser im Temperaturbereich zwischen T = 84 °C und T = 98 °C. Der Temperaturabfall zwischen Mischstelle und Brühgruppe wird in der Regelungstechnik mit berücksichtigt.
Mischer, Wasserwendel und zugehörige Sensorik sind Gleichteile in allen Maschinentypen.

Entscheidend für den Kaffeebezug einer Siebträger-Espressomaschine ist die Brühgruppe. Üblich wird diese schwergewichtig aus Messing mit den Eigenschaften hoher Wärmekapazität und hoher Wärmeleitfähigkeit hergestellt. Die bekannteste Brühgruppe dieser Bauart ist die sogenannte E61-Brühgruppe. Diese wurde 1961 erstmalig in der Faema E61 verbaut und seitdem in einigen Details verändert. Sie ist jedoch im Wesentlichen unverändert geblieben. Diese Brühgruppe verfügt über eine Düse für die Durchflussreduktion und eine Wasserkammer, was dazu führt, dass der Druckaufbau und damit der Kaffeebezug ein wenig Zeitverzögert abläuft. Dieser als Preinfusion bezeichnete Vorgang wird bei anderen Brühgruppentypen durch andere technische Lösungen bzw. durch Regelungstechnik realisiert. Nachteil aller Brühgruppen aus dem Werkstoff Messing ist, dass vorgewärmtes Bezugswasser immer die Kerntemperatur der Brühgruppe annehmen wird. Damit ist eine kurzfristige Änderung der Wasserbezugstemperatur nicht möglich.
Ein weiterer Nachteil dieser Bauart ergibt sich durch die freiliegenden Oberflächen der Messingbauteile. Diese wirken dann als Kühlflächen, sind weitestgehend undefiniert und können in den Temperaturregelungen dieser Maschinen nicht berücksichtigt werden, da die wahren Verhältnisse nicht erfasst werden. Steht die Maschine in einem kühlen Raum ergibt sich eine andere Kaffeebezugstemperatur als wenn diese in einem warmen Raum steht. Im Kaffeegeschmack sind jedoch bereits Temperaturdifferenzen von DeltaT = 0,5 °C nachweisbar.
Um hier Temperaturstabilität und schnelle Temperaturwechsel zu ermöglichen besteht der Kern der verwendeten Brühgruppe aus einem Kunststoffbauteil, welches im 3D-Druck hergestellt wird.

Die Brühgruppe bestehend aus Siebträgeraufnahme, Brühgruppeneinsatz, Wasserverteiler, Duschesieb und Brühgruppendichtung ist Gleichteil in allen Maschinentypen.

Diese Brühgruppe trägt die Bezeichnung WOC18-Brühgruppe. Die Benennung geht auf die Umstände ihrer Erfindung zurück. Die Grundidee dazu entstand im Zuge des Besuchs der World of Coffee (WOC) 2018 in Amsterdam.

Die Erfindungsrechte an den, dieser Entwicklung zugrundeliegenden Erfindungen, sind über die Gebrauchsmusteranmeldungen 20 2022 000 154.1 - Energieeffizientes Boilersystem aus doppelwandigem Glas für eine Espressokaffeemaschine und 20 2022 000 156.8 - Brühgruppe und Mischsystem für eine Espressokaffeemaschine mit schnell veränderlicher Brühassertemperatur geschützt.

Gleichteil in allen Maschinentypen ist auch die verwendete elektronsiche Steuerung. Verwendet werden hier handelsübliche Microkontroller welche in der Programmiersprache Micropython programmiert werden können. Für die unterschiedlcihen Aufgabenbereiche der Steuerung werden eigene Prozessoren verwendet. Für die Steuerung wurde ein Entwicklungskonzept entworfen, welches zunächst lediglich die elementar wichtigen Funktionen direkt auf den Microkontrollern ausführt und übergeordnet in einem in MATLAB® programmierten graphischen Userinterface die Entwicklung der Regelungsalgorithmen durchgeführt werden. Diese Vorgehensweise ist Hilfreich, da die operative Durchführung der Entwicklungsarbeit durch Studierende der Hochschule München, Fakultät Maschinenbau, Fahrzeugtechnik, Flugzeugtechnik erfolgt, welche nicht zwingend die Programmierung mit anderen Programmiersprachen beherrschen.

= Dokumente und Arbeiten =
* [[:Datei:20220112_Entwicklung_einer_Siebträger-Espressomaschinemit_Borosilikat-Glasboiler.pptx|Projektpräsentation Stand Januar 2022]]
* Wintersemester 2018/2019: [[Abschlussarbeit Tritschler]]
* Wintersemester 2019/2020: [[Versuche Glasboiler 2020|Projektarbeit Florian Fritz, Sebastian O'Reilly, Tim Kittelmann, Johannes Kastner]]
* Sommersemester 2020: [[Konstruktion Labormaschine 2020|Projektarbeit Tobias Blädel, Til Ahlgrim, Lukas Ankner, Yasin Bolat, Fabian Weber, Florian Michal (Abschnitt 2.1 und 5.2)]]
* Wintersemester 2021/2022: [[Abschlussarbeit Isabell Nuissl 2021|Abschlussarbeit Isabell Nuißl]]
* Felix Kistler, [[Business Case Glasboilermaschine 2022|Business Case Glasboiler-Maschine]], Stand 01.02.2022
* Sommersemester 2022: [[Projektarbeit Mustafa Inaltekin, Luca Simon Kurbjuweit]]
* Sommersemester 2022: [[Abschlussarbeit Erik Reitsam]]
* Sommersemester 2022: [[Design MMM Style "on Table", Forschungsmaster, Felix Kistler]]
* Sommersemester 2022: [[Projektarbeit Felix Kistler]]
* Wintersemester 2022/23: [[Projektarbeit Martin Aspacher, Michael Albrecht, Stefanie Diener]]
* Wintersemester 2023/24: [[Projektarbeit Thomas Neumeier, Edmond Sogor, Florian Wörle|Prototypenbau 1-Zylinder Glasboilermaschine]]
* Wintersemester 2023/24: [[Abschlussarbeit Felix Kistler|Entwicklung 2-Zylinder Glasboilermaschine]]
* Sommersemester 2024: [[Projektarbeit Florian Buchholz, Felix Forster, Michael Richter, Ferdinand Harbauer|Weiterführung Prototypenbau 1-Zylinder Glasboilermaschine]]
* Sommersemester 2024: [[Projektarbeit Amir Braun, Ze Lee, Leonhard Schöner|Entwicklung von Sensoren und Aktoren]]
* Sommersemester 2024: [[Projektarbeit Vivien Denise Hoffmann, Aurelia Zerle, David Kamm|Detailkonstruktionen]]
* Wintersemetser 2024/25 [[Projektarbeit End Bulliqi, Daniel Hellwig, Michael Bischof|Weiterführung der Inbetriebnahme]]
* Wintersemetser 2024/25 [[Projektarbeit Maximilian Beck, Luca Schmid, Andrei Zemba, Vincent Greinecker|Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck]]
* Wintersemetser 2024/25 [[Projektarbeit Martin Bader, Tobias Schumann, Nicolas Linner|Detailentwicklungen für Siebträger Espressomaschinen]]
* Sommersemester 2025 [[Projektarbeit Simon Besl, Matthias Strohmeier, Maximilian Wimmer|Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck]]

= ToDo-Listen Glasboilermaschinen - MMM Style =
== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

== ToDo-Liste 1 Zylinder ==
{| class="wikitable sortable"
|+
|-
! Arbeitspaket !! ToDo !! Wer !! Priorität !! Status !! WV
|-
| Technische Planung || [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Teilenummern_1_Zylinder_Glasboilermaschine Teilenummern 1 Zylinder Glasboilermaschine] || alle || 1 || 90 || laufend
|-
| Konstruktion || [[Style-Global:Tank|Tank]] || || 1 || 70 ||
|-
| Konstruktion || [[Style-1-Zylinder:Abtropfwanne|Abtropfwanne]] || || 1 || 10 ||
|-
| Konstruktion || [[Style-1-Zylinder:Abtropfblech|Abtropfblech]] || || 1 || 10 ||
|-
| Konstruktion || [[Style-Global:Brühgruppenabdeckung|Brühgruppenabdeckung]] || ||1 || 70 ||
|-
| Konstruktion || [[Style-Global:Vertikalhebel|Vertikalhebel]] || ||1 || 70 ||
|-
| Konstruktion || [[Style-Global:Isolierung|Isolierung zwischen den Zylindern]] || || 1 || 10 ||
|-
| Konstruktion || [[Konstruktionsanpassungen der Brühgruppe|Konstruktionsanpassungen der Brühgruppe (labortechnische Espressomaschine)]] || || 1 || 50 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Glasboiler|Glasboiler]] (Prototypenvariante) || || 1 || 90 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Abtropfbereich|Abtropfbereich]] || || 1 || 10 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Mechatronik|Sensoren/Aktoren (Mechatronik)]] || || 1 || 10 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Elektronik|Elektronik, Netzteil, NOT-AUS]] || || 1 || 70 ||
|-
| Inbetriebnahme || [[Systemsoftware|Software (ToDo-Liste: Mechatronische Inbetriebnahme Labormaschine]] || || 1 || 10 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Dichtheit|Dichtheitsprüfung / Undichtigkeiten Boiler]] || || 1 || 30 ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Funktionstest|Funktionstest]] || || 1 || 10 ||
|-
|Inbetriebnahme
|[[Erstellung einer gesamthaften Montageanleitung]]
|
|1
|50
|
|-
| Sensoren und Aktoren || [[AVS Römer SmartFlow Außenzahnradpumpe]] || || || 10 ||
|-
| ZB|| [[Hydraulikplan Style und Labor]] || Armin Rohnen ||1 || 90 ||
|-
| ZB|| [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Die_Glasboilermaschine_-_Style CAD-Daten MMM Style 1-Zylinder] || || || ||
|-
| ZB|| [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Montageanleitun(en)_1_Zylinder_Glasboilermaschine Montageanleitung(en) MMM Style 1-Zylinder] || || || ||
|-
| ZB || [[Style-1-Zylinder:Konstruktionsänderungen|Konstruktionsänderungen, Festigkeitsnachweise, Mängelliste]] || || || ||
|}

== Erledigte bzw. nicht weiter verfolgte ToDo's 1 Zylinder ==
{| class="wikitable sortable"
|+
|-
! Arbeitspaket !! ToDo !! Wer !! Priorität !! Status !! WV
|-
| Konstruktion || [[Style-Global:Verspanndeckel|Verspanndeckel]]|| || || ||
|-
| Konstruktion || [[Style-Global:Brühturm|Brühturm]]|| || || ||
|-
| Konstruktion || [[Style-Global:freitragende Brühgruppe|freitragende Brühgruppe]]|| || || ||
|-
| Konstruktion || [[Style-Global:Dampflanze|Dampflanze]]|| || || ||
|-
| Konstruktion || [[Style-Global:Teewasserlanze|Teewasserlanze]]|| || || ||
|-
| Konstruktion || [[Style-Global:Glasboiler|Glasboiler]]|| || || ||
|-
| Konstruktion || [[Style-1-Zylinder:Unterbau|Unterbau]]|| || || ||
|-
| Konstruktion || [[Style-1-Zylinder:Bodenplatte|Bodenplatte]]|| || || ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Verrohrung und Verkabelung Boilergruppe|Unterbau Verkabelung]]|| || || ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Tanks|Tanks]]|| || || ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Lanzen|Lanzen]]|| || || ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Inbetriebnahme Unterbau|Unterbau Verrohrung]]|| || || ||
|-
| Inbetriebnahme || [[Style-1-Zylinder:Brühturm|Brühturm]]|| || || ||
|-
| Sensoren und Aktoren || [[Alternative Drucksensoren|Alternative Sensoren]]|| || || ||
|-
| Sensoren und Aktoren || [[Sensorkonstruktion|Konstruktion Temperatursensor, Drucksensor und Dosierventil]]|| || || ||
|-
| Sensoren und Aktoren || [[Prüfprozesse|Prüfprozesse für Temperatursensor, Drucksensor und Dosierventil]]|| || || ||
|}

== ToDo-Liste 2 Zylinder ==
[[Datei:20240523 Finale Ansicht-2-Zylinder-Maschine ohne BG.png|thumb|500px|gerahmt|rechts|alternativtext=Felix Kistler, 2-Zylinder-Maschine|Felix Kistler, 2-Zylinder-Maschine]]
{| class="wikitable sortable"
|+
|-
! Arbeitspaket !! ToDo !! Wer !! Priorität !! Status !! WV
|-
| ZB|| [[Hydraulikplan Style 2-Zylinder]] || ||1 || 100 ||
|-
| Technische Planung || [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Teilenummern_2_Zylinder_Glasboilermaschine Teilenummern 2 Zylinder Glasboilermaschine] || alle || 1 || 90 || laufend
|-
|Technische Planung
|[[Maschinenkonzept 2-Zylinder]]
|
|1
|100
|
|-
|Konstruktion
|[[Style-Global:Glasboiler|Glasboiler]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-Global:Tank|Tank]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-Global:Brühturm|Brühturm]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-2-Zylinder:Abtropfwanne|Abtropfwanne]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-1-Zylinder:Lanzen|Lanzen]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-2-Zylinder:Unterbau|Unterbau]]
|Felix Kistler
|1
|90
|
|-
|Konstruktion
|[[Style-1-Zylinder:Bodenplatte|Bodenplatte]]
|Felix Kistler
|1
|90
|
|-
|Technische Planung
|[[Style-2-Zylinder:Kostenkalkulation und Kostenoptimierung|Kostenkalkulation und Kostenoptimierung]]
|Felix Kistler
|1
|90
|
|}

Systemsoftware

2026-04-25T09:03:43Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || Konstantin Rupprecht / Loic Aboufiras|| 1 || 30 ||08.05.2026
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || Konstantin Rupprecht|| 1 || 70 ||08.05.2026
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || Konstantin Rupprecht|| 1 || 10 ||08.05.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Konstantin Rupprecht|| 1 || 70 ||08.05.2026
|-
| [[Integration eines Displays mit Touchfunktion]] || Loic Aboufiras|| 1 || 30 ||08.05.2026
|-
| [[Integration eines Vertikalhebels]] || Loic Aboufiras|| 1 || 30 ||12.06.2026
|-
| [[Maschinensimulator]] || Francis Booth|| 1 || 70 ||08.05.2026
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || Felix Kerner|| 1 || 10 ||08.05.2026
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || Tillmann Haas|| 1 || 30 ||08.05.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine|Verlagerung der Boilerdruckregelung]] || Tillmann Haas|| 1 || 30 ||15.05.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard|Verlagerung des Mischtemperaturreglers]] || Tillmann Haas|| 1 || 10 ||10.06.2026
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard|Verlagerung des Durchflussreglers]] || Tillmann Haas|| 1 || 10 ||08.07.2026
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-19T08:56:50Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || Konstantin Rupprecht / Loic Aboufiras|| 1 || 30 ||24.04.2026
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || Konstantin Rupprecht|| 1 || 70 ||24.04.2026
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || Konstantin Rupprecht|| 1 || 10 ||24.04.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Konstantin Rupprecht|| 1 || 70 ||24.04.2026
|-
| [[Integration eines Displays mit Touchfunktion]] || Loic Aboufiras|| 1 || 30 ||24.04.2026
|-
| [[Integration eines Vertikalhebels]] || Loic Aboufiras|| 1 || 30 ||24.04.2026
|-
| [[Maschinensimulator]] || Francis Booth|| 1 || 70 ||24.04.2026
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || Felix Kerner|| 1 || 10 ||24.04.2026
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || Tillmann Haas|| 1 || 30 ||24.04.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine|Verlagerung der Boilerdruckregelung]] || Tillmann Haas|| 1 || 30 ||24.04.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard|Verlagerung des Mischtemperaturreglers]] || Tillmann Haas|| 1 || 10 ||24.04.2026
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard|Verlagerung des Durchflussreglers]] || Tillmann Haas|| 1 || 10 ||24.04.2026
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-15T14:26:50Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || Konstantin Rupprecht / Loic Aboufiras|| 1 || 30 ||17.04.2026
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || Konstantin Rupprecht|| 1 || 70 ||17.04.2026
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || Konstantin Rupprecht|| 1 || 10 ||17.04.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Konstantin Rupprecht|| 1 || 70 ||17.04.2026
|-
| [[Integration eines Displays mit Touchfunktion]] || Loic Aboufiras|| 1 || 30 ||17.04.2026
|-
| [[Integration eines Vertikalhebels]] || Loic Aboufiras|| 1 || 30 ||17.04.2026
|-
| [[Maschinensimulator]] || Francis Booth|| 1 || 70 ||17.04.2026
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || Felix Kerner|| 1 || 10 ||17.04.2026
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || Tillmann Haas|| 1 || 30 ||17.04.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine|Verlagerung der Boilerdruckregelung]] || Tillmann Haas|| 1 || 30 ||17.04.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard|Verlagerung des Mischtemperaturreglers]] || Tillmann Haas|| 1 || 10 ||17.04.2026
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard|Verlagerung des Durchflussreglers]] || Tillmann Haas|| 1 || 10 ||17.04.2026
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-09T18:03:39Z

Armin Rohnen:

Systemsoftware

2026-04-09T13:07:44Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || || 1 || 30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || || 1 || 10 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || || 1 || 10 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine|Verlagerung der Boilerdruckregelung]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard|Verlagerung des Mischtemperaturreglers]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard|Verlagerung des Durchflussreglers]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-09T13:06:54Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || || 1 || 30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || || 1 || 10 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || || 1 || 10 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-09T08:43:54Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || || 1 || 30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || || 1 || 10 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || || 1 || 10 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-09T08:40:47Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || || 1 || 30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7]] || || 1 || 10 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||

|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-09T08:39:56Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || || 1 || 30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-04-09T08:38:55Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] | |1 |30 ||
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Projektstart 26.03.2026

2026-03-30T07:32:02Z

Armin Rohnen: Die Seite wurde neu angelegt: „=Besprechungsprotokoll – Projektstart 26.03.2026= Ort: Labor für MAschinendynamik, B0273 Datum: 26.03.2026 Teilnehmer: Konstantin Rupprecht, Loic Aboufiras, Francis Booth, Tillmann Haas, Armin Rohnen Moderator: LfbA Armin Rohnen Protokollant: Tillmann Haas Zu Beginn der Besprechung stellten sich alle Teilnehmenden vor und erläuterten ihre jeweilige Motivation für das Projekt. ==Top 1) Zweck der Besprechung== Zweck und Inhalt der Bes…“

=Besprechungsprotokoll – Projektstart 26.03.2026=
Ort: Labor für MAschinendynamik, B0273 
Datum: 26.03.2026 
Teilnehmer: Konstantin Rupprecht, Loic Aboufiras, Francis Booth, Tillmann Haas, Armin Rohnen 
Moderator: LfbA Armin Rohnen
Protokollant: Tillmann Haas

Zu Beginn der Besprechung stellten sich alle Teilnehmenden vor und erläuterten ihre jeweilige Motivation für das Projekt.

==Top 1) Zweck der Besprechung==
Zweck und Inhalt der Besprechung Ziel der Besprechung war es, die organisatorischen Rahmenbedingungen der Projektarbeit zu klären, die Arbeitsweise innerhalb des Teams abzustimmen sowie die Erwartungen an die Durchführung und Dokumentation des Projekts festzulegen.

==Top 2) Projektorganisation==
Projektorganisation und Arbeitsweise Die Projektarbeit ist eigenständig im Team zu organisieren und durchzuführen, wobei ein besonderer Fokus auf der selbstständigen Planung, Umsetzung und kontinuierlichen Abstimmung innerhalb der Gruppe liegt. Die Projekte sollen eigenständig strukturiert und umgesetzt werden, wobei die Aufgabenstellungen eigenverantwortlich interpretiert und in konkrete Arbeitspakete überführt werden müssen. Zudem ist eine gleichmäßige Arbeitsverteilung innerhalb des Teams sicherzustellen. Das zentrale Lernziel besteht darin, die Teamorganisation sowie die eigenverantwortliche Bearbeitung eines Projekts zu entwickeln.

==Top 3) Zeitmanagement==
Zeitmanagement und Wochenplanung Für die Projektarbeit ist ein kontinuierliches und strukturiertes Zeitmanagement erforderlich. Es ist verpflichtend, eine wöchentliche Planung in Form eines Projektplans zu erstellen, die jeweils bis Freitagabend vorliegen muss und sowohl die kommende als auch die darauffolgende Woche berücksichtigt. Dabei wird empfohlen, mehrere zusammenhängende Arbeitsstunden einzuplanen, anstatt die Arbeit auf viele kurze Zeitabschnitte zu verteilen. Ein entsprechendes Template steht in der PowerPoint zur Verfügung, und es ist ein fester Zeitblock pro Woche festzulegen. Ergänzend dazu ist eine wöchentliche Reflexion vorgesehen, in der die vergangene Woche hinsichtlich erreichter und nicht erreichter Ziele betrachtet und die Planung der kommenden Woche angepasst wird. Diese Reflexion kann zu Beginn etwa 30 bis 60 Minuten dauern und mit steigender Routine schneller abgearbeitet werden.

==Top 4) Projektplanung und Dokumentation==
Die Projektplanung soll strukturiert und nachvollziehbar erfolgen. Zur Dokumentation wird ein Wiki verwendet, dessen Inhaltekontinuierlich gepflegt und aktuell gehalten werden müssen. Die zentrale Dokumentation erfolgt über dieses Wiki und wird durch Protokolle ergänzt.

==Top 5) Protokollführung==
Zu jeder Besprechung ist ein Protokoll zu erstellen, das spätestens zwei Tage nach dem Termin an alle Teilnehmenden versendet wird. Zu Beginn jeder neuen Woche sollen die Protokolle der vergangenen Woche von allen bestätigt werden, um Nachvollziehbarkeit und Verbindlichkeit sicherzustellen.

==Top 6) Kommunikation==
Die Kommunikation innerhalb des Teams sowie mit dem Betreuer soll strukturiert erfolgen. Dazu sind klare Kommunikationskanäle festzulegen und eine regelmäßige Abstimmung sicherzustellen. Dabei ist auf eine angemessene und sachliche Tonalität zu achten.

==Top 7) Termine und Meilensteine==
Ein erstes Review-Gespräch ist für die kommende Woche vorgesehen. Zur Terminabstimmung soll bis Montag, den 29.03., um 09:00 Uhr eine E-Mail mit einem Terminvorschlag versendet werden. Der Projektstand wird regelmäßig vorgestellt, und als Ziel wurde festgelegt, die Aufgabenanalyse bis zur Woche nach Ostern abzuschließen.

==Top 8) Inhalte der ersten Projektphase==
In der ersten Projektphase erfolgt die Einarbeitung in relevante Themenbereiche, beispielsweise in Python. Darüber hinaus soll ein grundlegendes Verständnis des Gesamtprojekts im Bereich Mechatronik und Steuerung entwickelt werden, um darauf aufbauend eine geeignete Umsetzungsstrategie abzuleiten.

==Top 9) Anforderungen an die Projektarbeit==
Für eine erfolgreiche Umsetzung des Projekts ist es entscheidend, die Anforderungen vor Beginn der Umsetzung klar zu definieren und verbindliche Ziele festzulegen. Zudem sind Zuverlässigkeit in der Bearbeitung sowie Ehrlichkeit und Transparenz innerhalb des Teams erforderlich. Eine unzureichende Vorbereitung von Besprechungen kann zu Verzögerungen im Projektverlauf führen.

==Top 10) Hinweise zur Teamorganisation==
Meetings sind grundsätzlich vorzubereiten, wozu insbesondere die Erstellung einer Agenda gehört, die spätestens einen Tag vor dem Termin bereitgestellt werden muss. Fehlende Vorbereitung kann den Projektfortschritt negativ beeinflussen und zu Verzögerungen führen.

==Top 11) Besprechung der Projektmodul-„Projektstart“-Folie==
Im Rahmen dieses Tagesordnungspunkts stellte Herr Rohnen ausführlich den aktuellen Projektstand vor. Offene Fragen aus der Gruppe wurden gemeinsam besprochen und geklärt

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-03-30T07:23:50Z

Armin Rohnen:

Mikrocontroller Programmierung in MicroPython WiSe 2025/26

2026-03-25T12:26:15Z

Armin Rohnen:

<htmltag tagname="img" src="https://vg06.met.vgwort.de/na/c62555318b0346218dc23a5ada9f7726" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Wintersemetser 2025/26 =
Für das Projekt der labortechnischen und Glasboiler Espressomaschine soll die vorhandene Master (MATLAB®-App) Client (RPi RP2040 MCUs in MicroPython) Steuerung auf eine autarke Multi-MCU-Steuerung mit mehreren RPi RP2040 und/oder RPi RP2350 mit einer MATLAB®-App als Service-Tool umgestellt werden.

Die Umstellung soll im ersten Schritt über Demonstratoren vorbereitet werden. Die erforderlichen Steuerungsplatinen sind in mehrfacher Ausfertigung vorhanden, so dass Teilaufgaben voneinander unabhängig abgearbeitet werden können.

Die Programmcodes in MicroPython für die Realisierung der Grundfunktionen (Schalten, Messwerte erfassen, Display ansteuern, UART Kommunikation, MATLAB® Kommunikation) sind in MATLAB® meets MicroPython [40] vorhanden. Hierzu wird die zweite (noch nicht veröffentlichte) Ausgabe zur Verfügung gestellt.

Diese Projektarbeit dient der Weiterentwicklung der modularisierten Systemsteuerung im Gesamtprojekt zur Entwicklung der Siebträger-Espressomaschinen.

= Aufgabenanalyse =
== UART Kommunikation zwischen den einzelnen MCUs ==
Die bestehende Kommunikation über die MATLAB®-GUI soll durch ein robustes, ringförmiges UART-System ersetzt werden, bei dem fünf MCUs kontinuierlich einen gemeinsamen Token austauschen. Jede Platine ergänzt oder liest dabei spezifische Daten, während Start-, Standard- und Paniktoken sowie CRC-Prüfsummen für zuverlässigen Betrieb und Fehlererkennung sorgen.

== Mehrkernnutzung und/oder Multitasking ==
Beim Raspberry Pi Pico soll der zweite Prozessorkern genutzt werden, um die MCU-Kommunikation auszulagern und dadurch den Hauptkern für bestehende Steuerungsaufgaben zu entlasten. Dabei sind die Einschränkungen von _thread() sowie Konflikte beim Zugriff auf gemeinsame Peripherie zu berücksichtigen, während uasyncio als alternative kooperative Multitasking-Lösung nur einen Kern nutzen kann.

== Startprozedur ==
Diese wird initialisiert durch die Aktivierung aller vier MCUs und dient der Gewährleistung einer korrekten Kommunikationsstruktur sowie dem sequenziellen Start von Füllstands- und Boilerdruckregelung. Die Betriebsbereitschaft wird signalisiert, sobald der Boilerdruck-Sollwert erreicht wird.

== Füllstandsregelung ==
Ziel ist die vollständige Übertragung der bisher in der MATLAB®-GUI realisierten Boiler-Füllstandsregelung auf die Basisplatine, um eine PC-unabhängige Regelung zu ermöglichen. Die Regelung erkennt den Füllstand über eine Kurzschlussdetektion; liegt kein Kurzschluss vor, wird dies als unzureichender Füllstand interpretiert und der Boilerdruckregler zur Vermeidung von Trockenheizen gesperrt. Bei Erreichen des Sollfüllstands erfolgt eine gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches An- und Abschalten der Regelung vorzubeugen.

== Boilerdruckregelung ==
Dieser PID-Regler wird auf die SSR-Platine übertragen und aktiviert sich aus Sicherheitsgründen erst dann, wenn ein korrekter Wasserstand im Boiler erkannt wurde. Parallel zur Druckhaltung steuert die Regelung die Entschichtungsfunktion, welche aktiv bleibt, bis die Boilertemperatur einen einstellbaren Grenzwert erreicht.

== Mischtemperaturregelung ==
Um die Wassertemperatur für Kaffee und Tee zu steuern, wird ein PID-Regler für das Mischventil auf der Basisplatine implementiert. Dabei wird eine Kaskadenstruktur verwendet, in der die Mischtemperaturregelung den äußeren Kreis bildet und direkt vom inneren Durchflussregelkreis abhängig ist.

== Durchflussregelung ==
Der auf das Basisboard verlagerte PID-Regler sorgt durch Anpassung der Pumpenspannung für einen konstanten Volumenstrom. Als innerer Regelkreis liefert er kontinuierlich Durchflusswerte an den Mischtemperaturregler, um die Temperaturstabilisierung zu gewährleisten

== Maschinensimulator - Hardware ==
Für die Steuerungselektronik besteht die Siebträger Espressomaschine aus Messwerten. Dies sind in der aktuellen Form
* 4 NTC Temperatursensoren mit 10 kOhm
* 2 Druckmesswerte im Spannungsbereich 0,5 bis 4,5 V
* Leitwert und Temperatur des zufließenden Wassers im Spannungsbereich 0 bis 5 V
* Flowmeter mit 39,9 Impulsen je ccm
* 4 Füllstandssensoren über Kurzschlussdetektion

Realisiert werden diese Messwerte über ein digitales Potentiometer MCP4151 mit 10 kOhm, welches über eine SPI-Schnittstelle eingestellt werden kann. Damit werden die 4 NTC Temperatursensoren und über die Spannungsteilerfunktion des Bauelements werden die Druckmesswerte, der Leitwert und die Temperatur des zufließenden Wassers simuliert.

Die Kurzschlusserzeugung der Füllstandssensoren werden mit einem digitalen Analogschalter (DG411) realisiert und das Flowmetersignal wird über eine Transistorfolgeschaltung erzeugt.

Die Schaltung benötigt eine MCU mit mindestens 17 für Kommunikation und Elektronikansteuerung verfügbaren PINs. Hierzu ist eine Raspberry Pi Pico MCU vorgesehen.

== Maschinensimulator - Hardware ==
Auf der MCU selbst ist zwingend die SPI-Kommunikation zu den digitalen Potentiometer mit insgesamt 8 verschiedenen Chipselect erforderlich. Die digitalen Analogschalter benötigen lediglich ein PIN mit Digoutfunktion während das Flowmetersignal als PWM-Signal mit variabler Frequenz realisiert wird. Für die variable Frequenz kann über die Anweisung PWM.freq([Frequenz]) eingestellt werden.

Die Einstellwerte für das digitale Potentiometer sollten für die 4 NTC Temperatursensoren als Temperaturwerte eingegeben werden. Aus dem Eingabewert wird und über die Beachtung der nichtlinearen Kennlinie der NTCs sowie dem nichtlinearen Zusammenhang aus Einstellwert und Widerstandswert der Einstellwert des jeweiligen digitalen Potentiometers. Die normierten Kennlinien der NTCs liegen vor. Eventuell lassen sich darüber die erforderlichen Einstellwerte ermitteln.

Auch die Einstellwerte für die Simulation der Druckmesswerte sollten in bar für den Brühgruppendruck bzw. in mbar für den Boilerdruck erfolgen. Auch hier muss die nichtlinearität des digitalen Potentiometers berücksichtigt werden.

Es erscheint sinnvoll, dass der Maschinensimulator in den Kommunikationsring eingebunden wird. Aus dem Token kann der Sollwert für die Pumpensteuerung entnommen werden, welches wiederum für die Generierung des Flowmetersignals verwendet werden kann. Ebenso können aus dem Token die Heizleistungen entnommen werden, was für die Temperatursignale sowei Boilerdrucksignal verwendet werden könnte.

Für die einfachere Bedienung und um die Anzahl der benötigten PCs zu minimieren ist eine MATLAB®-GUI nützlich. In dieser sollten die simulierten Signale per numerischer Eingabe, Schalter oder Slider einstellbar sein. ebenso sollten darin Umschaltungen möglich sein, so dass die simulierten Signale in Abhängigkeit der Pumpensteuerung und Heizleistung erzeugt werden. Auch denkbar wären die generierung von Messwerten über bekannte Messwertverläufe von gemessenen Kaffeebezügen.

= Leistungsvereinbarung =
== Kommunikation ==
Es wird eine Kommunikation zwischen den MCUs (Platinen) der Maschinensteuerung aufgebaut. Dazu wird die auf den einzelnen Platinen herausgeführte UART-Schnittstelle so verbunden, dass ein Kommunikationsring entsteht. Über den Kommunikationsring wird ein als Token bezeichnetes Datenpaket mit allen für den Maschinenbetrieb erforderlichen Messdaten, Stellgrößen, Anforderungen, Einstellparametern und Logging-Informationen im Kreis durchgereicht. Der Token wird so gestaltet, dass dieser dynamisch an spätere Anforderungen (2. Brühgruppe) angepasst werden kann. Der Token wird für eine möglichst kleine Anzahl an Kommunikations-Bytes binär ausgeführt. Es wird eine Definitionstabelle des Tokens im öffentlichen Wiki erstellt. Das Verfahren wird als Espressomaschinen-Kommunikations-Ring (EKR) bezeichnet.

== Mehrkernnutzung ==
Es wird versucht, über die MicroPython-Funktionalität „_thread“ die Kommunikation von den anderweitigen Prozessaufgaben auf allen MCUs zu trennen und auf den zweiten Prozessorkern zu verlagern.

== Verlagerung der Regelkreise ==
Die aktuell über die MATLAB®-GUI ausgeführten Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung, Mischtemperaturregelung und Durchflussregelung werden auf die dafür prädestinierten MCUs verlagert. Die Reglercodes dazu sind im Prinzip in MATLAB® vorhanden, müssen aber an das MCU-Umfeld und die Programmiersprache MicroPython angepasst werden. Funktionstest der Regler an einer realen Hardware sind nicht möglich, da diese soweit noch nicht vorhanden ist. Ziel ist die vollständige Implementierung der Reglerlogik in MicroPython einschließlich Schnittstellenanpassung und Variablenmanagement. Die Funktionsprüfung erfolgt auf Codeebene sowie über simulierte Testfälle.

Für den Ablauf zwischen Einschalten der Maschine und Betriebsbereitschaft zum Kaffeebezug, im Weiteren Betriebsbereitschaft zum Dampfbezug, wird eine Startprozedur definiert und soweit es die vorhandene Hardware zulässt getestet.

== Maschinensimulator ==
Zur Überprüfung des MCU-Verbunds, der implementierten Reglerlogik sowie der Startprozedur ohne vorhandene reale Maschinenhardware wird ein Maschinensimulator eingesetzt.

Die Hardware für den Maschinensimulator wird bereitgestellt. Der Maschinensimulator generiert die Widerstandswerte der NTC-Temperatursensoren sowie die Spannungswerte der analogen Sensoren im Bereich von 0,5 V bis 4,5 V. Die Füllstandssensoren werden über Kurzschlussschalter simuliert, der Durchflusssensor über eine getaktete Transistorfolgeschaltung mit PWM-Ansteuerung. Zur Nachbildung der Temperatursensoren, Drucksensoren, Füllstandssensoren, Leitwert- und Durchflusssignale werden geeignete bereits festgelegte elektronische Komponenten verwendet. Die Ansteuerung der einzelnen Signalerzeuger ist dabei offen zu gestalten und kann im Verlauf der Implementierung festgelegt werden.

Der Maschinensimulator wird in den bestehenden Kommunikationsring integriert. Dadurch können Sollwerte und Systemparameter aus dem Token ausgelesen und zur Erzeugung der simulierten Sensorsignale genutzt werden.

= Besprechungsprotokolle =
* [[Projektstart 09.10.2025]]
* [[Projektrücksprache 15.10.2025]]
* [[Projektrücksprache 23.10.2025]]
* [[Projektrücksprache 30.10.2025]]
* [[Projektrücksprache 06.11.2025]]
* [[Projektrücksprache 13.11.2025]]
* [[Projektrücksprache 20.11.2025]]
* [[Projektrücksprache 27.11.2025]]
* [[Projektrücksprache 04.12.2025]]
* [[Projektrücksprache 11.12.2025]]
* [[Projektrücksprache 18.12.2025]]
* [[Projektrücksprache 15.01.2026]]
* [[Projektrücksprache 05.02.2026]]

= Abschlusspräsentation =
[[:Datei:20260214 Abschlusspraesentation.pdf|Mikrocontroller Programmierung in MicroPython]]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-03-25T12:25:49Z

Armin Rohnen:

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-03-25T12:25:11Z

Armin Rohnen:

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-03-25T12:24:24Z

Armin Rohnen: Die Seite wurde neu angelegt: „<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag> hochkant=2.5 = Mikrocontroller Programmierung in MicroPython Sommersemester 2026 = Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich. Die Programmierung der Mikrocont…“

Datei:20260326 Projektstart.pdf

2026-03-25T12:22:15Z

Armin Rohnen:

Armin Rohnen, aktueller Projektstand

Systemsoftware

2026-03-25T12:09:05Z

Armin Rohnen: /* Projektdokumentationen und Beschreibungen */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Startprozedur]]
|
|1
|30
|
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Evaluation STM32H7

2026-03-25T11:34:40Z

Armin Rohnen: /* Armin Rohnen, 22.03.2026 Problembeschreibung */

= Armin Rohnen, 22.03.2026 Problembeschreibung=
Die aktelle Steuerungselektronik besteht aus den drei Platinen (und Mikrocontrollern) Basisplatine, Messplatine und SSR-Platine. Hinzu kommt noch mindestens eine weitere Platine in Verbindung mit dem Display und ggf. eine weitere zur Kommunikation über WLAN oder Bluetooth. Dies ergibt mindestens 4 Mikrocontroller im Gesamtsystem, welche kontinuierlich über UART miteinander Daten austauschen. Darunter auch zeit- und sicherheitsrelevante Informationen.

== Warum sind es so viele Mikroconroller ==
Zu Beginn der Steuerungsentwicklung ergab sich aufgrund der Corona-Krise das Problem, dass Mikrocontroller-Board schwer verfügbar waren. In diesem Zeitraum ist mit dem Raspberry Pi Pico (RP2040) ein kostengünstiger und sehr gut verfügbarer Mikrocontroller in den Markt gebracht worden. Mit dieser MCU entwickelte sich auch die Idee die Steuerung mit MicroPython zu programmieren. Der Nachteil des RP2040 ist jedoch seine Baugröße, er verfügt über relativ wenige PINs und hat keinen programmierbaren DAC (digital analog converter) zur Sollsignalgenerierung. Im Zuge der Steuerungsentwicklung hat sich zudem herausgestellt, dass für die Spannungsmessung der Sensorsignale (Drücke und Temperaturen) eine 16Bit-Auflösung benötigt wird, um die angestrebte Genauigkeit erreichen zu können.

== Alternativen ==
Gerade die Problematik mit der erforderlichen Auflösung von 16Bit für die Spannungsmessung der Druck- und Temperatursignale führt auf die STM32H7-MCU. Diese ist als NUCLEO STM32H753ZI relativ gut im Markt verfügbar. Allerdings gibt es hierzu kein evaluiertes MicroPython-Derivat.

Von einer weiteren Variante, dem NUCLEO STM32H743ZI2-Board sind im Labor 3 Stück verfügbar. Der Unterschied zwischen STM32H743ZI2 und STM32H753ZI ist die Krypto-Unterstützung im H753, welche gänzlich nicht benötigt wird. Darüber hinaus sind beide Boards PIN-gleich und grundsätzlich sollte das vorhandene 16Bit-ADC optimierte MicroPython-Derivat des STM32H743ZI2 auch auf dem STM32H753ZI funktionieren. Nur gesichert ist dies allerdings nicht. Das wäre zu überprüfen.

Allerdings würden für den aktuell anstehenden Bedarf an mximal 3 Systemsteuerungen, die vorhandenen drei STM32H743ZI2-Boards ausreichen.

== Was zu tun ist ==
* Lauffähigkeit des 16Bit-ADC optimierten MicroPython-Derivat des STM32H743ZI2 auf dem STM32H753ZI
* Nutzbare ADC-PINs
* Nutzbare UART PINs
* Nutzbare PWM-Pins bzw. MicroPython-Algorithmus für 8 Hz PWM-Signal mit 0 bis 100% einstellbaren Tastverhältnis
* Nutzbare Dig-Out-PINs
* Nutzbare Dig-In-PINs

Die Überprüfung der PINs soll sich auf die bereits bestückten Kontaktleisten CN7, CN8, CN9 und CN10 beschränken. Nur wenn diese für die Anforderungen der Steuerungselektronik nicht ausreichen, darf auf die im Default unbestückten Kontaktleisten CN11 und CN12 ausgewichen werden.

Verlagerung der Boilerdruckregelung auf die Messplatine

2026-03-25T10:09:30Z

Armin Rohnen: /* Philipp Schiebel, 13.11.2025 - Aufgabenanalyse */

= Philipp Schiebel, 13.11.2025 - Aufgabenanalyse=
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung auf Basis eines PD-Reglers vollständig auf die Messplatine zu übertragen, sodass die Regelung unabhängig von der externen PC-Umgebung arbeitet.

==Systemstart und Aktivierung==
Der Boilerdruckregler ist aktiv, sobald ein gültiger Füllstand des Boilers erkannt wurde. Wird über die Kurzschlussdetektion ein negativer Füllstand erfasst, bleibt der Regler deaktiviert, um Trockenheizen zu verhindern.
Die Regelung wird beim Einschalten der Maschine automatisch initialisiert.

==Betriebslogik und Zustände==
Darf nur aktiv sein bei kurschlussdetektiertem Füllstand des Boilers. Solange die Boilertemperatur kleiner als eine einstellbare Abschalttemperatur ist, erfolgt zusätzlich die Boilerentschichtung. Dabei wird die Pumpe angesteuert und die Magnetventile für die Entschichtung geschaltet. Beim Erreichen der einstellbaren Temperaturgrenze erfolgt die Abschaltung in umgekehrter Reihenfolge. (Solange die Entschichtung aktiv ist oder die Temperatur unter der Abschalttemperatur liegt, bleiben die Funktionssteuerungen verriegelt.)

Die Boilerdruckregelung bleibt grundsätzlich dauerhaft aktiv und wird nur im Fehlerfall oder bei unzureichendem Füllstand deaktiviert. Nach Erreichen eines Boilerdrucksollwerts ist die Betriebsbereitschaft erreicht. Anschließend erfolgt bei Bedarf eine Nachregelung.

==Kommunikation==
Die SSR-Platine erzeugt das PWM-Signal lokal. Messdaten, wie Temperatur oder Druck und der PWM-Stellwert werden über den Token mit den anderen MCUs ausgetauscht.

==Glasboiler 2-Zylinder==
Für den Betrieb einer Glasboiler 2-Zylinder Maschine muss der Boilerdruckregler angepasst werden, um beide Boiler parallel aufzuheizen und dabei möglichst geringe Temperaturunterschiede entstehen lassen. Der schneller aufheizbare Boiler folgt in der Temperatur dem druckgeregelten, langsamer aufheizbaren Boiler.

= Armin Rohnen, 11.04.2024 =
Bei kurzschlussdetektierten Füllstand des Boilers darf die Boilerdruckregelung aktiv sein. Solange die Boilertemperatur kleiner 95 °C ist, erfolgt zusätzlich die Boilerentschichtung. Zur Aktivierung der Boilerentschichtung wird die Pumpensteuerspannung auf 2500 mV eingestellt und die Magnetventile für die Entschichtung geschaltet. Bei Erreichen der Boilertemperatur von 95 °C erfolgt die Abschaltung in umgekehrter Reihenfolge.

Ab Boilertemperatur 105 °C kann der Kaffee- bzw. Teewasserbezug freigegeben werden. Die Boilerdruckregelung erfolgt für einen Sollwert aus der MATLAB®-GUI. Dieser ist im Nennwert 1350 mbar und ist im Bereich von 1000 mbar bis 1500 mbar veränderlich. Nach [114] wird für die Boilerdruckregelung ein PID-Regler verwendet. Stellgröße ist ein PWM-Signal zwischen 0 und 100 % generiert. Beim geöffneten Dampfhahn wird der Sollwert pB,soll um 200 mbar nach unten korrigiert. Damit wird ein unnötiges Aufheizen des Boilers unterbunden. Der Stellwert des PWM-Signals wird an die SSR-Platine übermittelt.

Die Boilerdruckregelung soll wie beschrieben auf die Messplatine verlagert werden. Das PWM-Signal für die Steuerung des Heizelements wird dabei auf der Messplatine erzeugt und über die Verdrahtung an die SSR-Platine weiter geleitet. Dabei muss das System zwischen Aufheizen und Normal-Regelung unterscheiden. In der Aufheizphase bis Boilertemperatur 105 °C müssen die Funktionssteuerungen deaktiviert bleiben.

Auf dem Basisboard muss mit der Entschichtung durch Umpumpen eine weitere Funktionalität eingeführt werden. Die Entschichtung ist lediglich während der Aufheizphase aktiviert, solange die Boilertemperatur < 95 °C ist. Die aktive Entschichtung oder Boilertemperatur < 95 °C verriegelt die Funktionssteuerung.

Die Boilerdruckregelung ist dauerhaft aktiv und wird lediglich durch die negative Kurzschkussdetektion des Boilerfüllstands zeitweilig deaktiviert.

Evaluation STM32H7

2026-03-22T16:47:59Z

Armin Rohnen: Die Seite wurde neu angelegt: „= Armin Rohnen, 22.03.2026 Problembeschreibung= Die aktelle Steuerungselektronik besteht aus den drei Platinen (und Mikrocontrollern) Basisplatine, Messplatine und SSR-Platine. Hinzu kommt noch mindestens eine weitere Platine in Verbindung mit dem Diasplay und ggf. eine weitere zur Kommunikation über WLAN oder Bluetooth. Dies ergibt mindestens 4 Mikrocontroller im Gesamtsystem, welche kontinuierlich über UART miteinander Daten austauschen. Darunter…“

= Armin Rohnen, 22.03.2026 Problembeschreibung=
Die aktelle Steuerungselektronik besteht aus den drei Platinen (und Mikrocontrollern) Basisplatine, Messplatine und SSR-Platine. Hinzu kommt noch mindestens eine weitere Platine in Verbindung mit dem Diasplay und ggf. eine weitere zur Kommunikation über WLAN oder Bluetooth. Dies ergibt mindestens 4 Mikrocontroller im Gesamtsystem, welche kontinuierlich über UART miteinander Daten austauschen. Darunter auch zeit- und sicherheitsrelevante Informationen.

== Warum sind es so viele Mikroconroller ==
Zu Beginn der Steuerungsentwicklung ergab sich aufgrund der Corona-Krise das Problem, dass Mikrocontroller-Board schwer verfügbar waren. In diesem Zeitraum ist mit dem Raspberry Pi Pico (RP2040) ein kostengünstiger und sehr gut verfügbarer Mikrocontroller in den Markt gebracht worden. Mit dieser MCU entwickelte sich auch die Idee die Steuerung mit MicroPython zu programmieren. Der Nachteil des RP2040 ist jedoch seine Baugröße, er verfügt über relativ wenige PINs und hat keinen programmierbaren DAC (digital analog converter) zur Sollsignalgenerierung. Im Zuge der Steuerungsentwicklung hat sich zudem herausgestellt, dass für die Spannungsmessung der Sensorsignale (Drücke und Temperaturen) eine 16Bit-Auflösung benötigt wird, um die angestrebte Genauigkeit erreichen zu können.

== Alternativen ==
Gerade die Problematik mit der erforderlichen Auflösung von 16Bit für die Spannungsmessung der Druck- und Temperatursignale führt auf die STM32H7-MCU. Diese ist als NUCLEO STM32H753ZI relativ gut im Markt verfügbar. Allerdings gibt es hierzu kein evaluiertes MicroPython-Derivat.

Von einer weiteren Variante, dem NUCLEO STM32H743ZI2-Board sind im Labor 3 Stück verfügbar. Der Unterschied zwischen STM32H743ZI2 und STM32H753ZI ist die Krypto-Unterstützung im H753, welche gänzlich nicht benötigt wird. Darüber hinaus sind beide Boards PIN-gleich und grundsätzlich sollte das vorhandene 16Bit-ADC optimierte MicroPython-Derivat des STM32H743ZI2 auch auf dem STM32H753ZI funktionieren. Nur gesichert ist dies allerdings nicht. Das wäre zu überprüfen.

Allerdings würden für den aktuell anstehenden Bedarf an mximal 3 Systemsteuerungen, die vorhandenen drei STM32H743ZI2-Boards ausreichen.

== Was zu tun ist ==
* Lauffähigkeit des 16Bit-ADC optimierten MicroPython-Derivat des STM32H743ZI2 auf dem STM32H753ZI
* Nutzbare ADC-PINs
* Nutzbare UART PINs
* Nutzbare PWM-Pins bzw. MicroPython-Algorithmus für 8 Hz PWM-Signal mit 0 bis 100% einstellbaren Tastverhältnis
* Nutzbare Dig-Out-PINs
* Nutzbare Dig-In-PINs

Die Überprüfung der PINs soll sich auf die bereits bestückten Kontaktleisten CN7, CN8, CN9 und CN10 beschränken. Nur wenn diese für die Anforderungen der Steuerungselektronik nicht ausreichen, darf auf die im Default unbestückten Kontaktleisten CN11 und CN12 ausgewichen werden.

Systemsoftware

2026-03-22T16:20:46Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Startprozedur]]
|
|1
|30
|
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || || 1 || 70 ||
|-
| [[Evaluation STM32H7]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Integration eines Displays mit Touchfunktion

2026-03-22T16:19:00Z

Armin Rohnen: /* Armin Rohnen, 22.03.2026Displayauswahl */

= Armin Rohnen, 22.03.2026 Displayauswahl=
Als mögliche Display wurden neu definiert: 
Waveshare RP2350-Touch-LCD-2.1 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-2.1 Waveshare-Wiki]) 
Waveshare RP2350-Touch-LCD-2 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-2 Waveshare Wiki]) 
Waveshare RP2350-Touch-LCD-1.69 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-1.69 Waveshare Wiki]) 

Alle drei Displays zeichnet aus, dass diese bereits mit einem RP2350-Mikrocontroller-Board versehen sind und daher wie Raspberry Pi Pico 2 behandelt werden können. Zu allen drei Displays gibt es im jeweiligen Wiki Beispielcode für die auf dem board verbauten Sensoren und eben das Display. Einige PINs des RP2350 sind auf Stecker oder Lötpads gelegt, so dass noch etwas Peripherie angeschlossen werden kann. Das lässt immer die UART-Kommunikation zu und es ermöglicht den Vertikalhebel (Spannungsmessung) sowie die beiden mechanischen Tasten anzuschließen.

Allerdings kann das RP2350-Touch-LCD-2.1 Display nicht in MicroPython programmiert werden. Für den darin verwendeten Display-Chip gibt es aktuell keine MicroPython-Library. Allerdings ist ein sehr ausführlicher Democode in C vorhanden.

Bis Juli 2026 soll eine fundierte und finale Entscheidung erarbeitet werden, welches Display weiter verfolgt wird.

= Jeremias Kögl, 12.11.2025 Aufgabenanalyse=
Das Touchdisplay (Adafruit 2478, 240×320 Pixel, SPI-Protokoll) wird zusammen mit einem Raspberry Pi Pico W als lokales HMI (Human-Machine-Interface) betrieben; beide
Komponenten werden als „Display“ bezeichnet.
Das Display:
* initialisiert die Kommunikation im MCU-Verbund
* visualisiert Prozessdaten während des Brühens, der Aufheizphase und der Bereitschaftsphase
* Gibt einen Log aus
* verwaltet Kaffeerezepte
* stellt die Verbindung zur MATLAB®®-Wartungsapp her

Beim Einschalten initialisiert das Display die Kommunikation im MCU-Verbund und die SPI-Schnittstelle, kalibriert die Touchoberfläche und initialisiert die Kommunikation mit den Verbundmodulen durch Senden eines Initialisierungstokens. Die Initialisierung ist erst abgeschlossen, wenn der Token wieder an das Display zurückgekehrt ist. Es lädt anschließend die vier lokal gespeicherten Rezepte und signalisiert die Brühbereitschaft.

Während des Bezugs zeigt das Display in (quasi) Echtzeit neben der Zeit auch Durchfluss, Druck oder Temperatur an. Soll-/Ist-Kurven machen Abweichungen sichtbar. Grenzwerte
sollen Fehlbedienungen vermeiden. Für die Bedienung sind große Touch-Ziele zu verwenden. Es sind Maßnahmen zu treffen, um eine flüssige Darstellung zu gewährleisten und die Touch-Latenz zu minimieren.

Zur Erhöhung der Benutzerfreundlichkeit und Wiederholungssicherheit soll die Möglichkeit bestehen, Rezepte zu speichern. Jedes Rezept umfasst Zielwerte für alle einstellbaren Prozessparameter (Menge In [g], Menge Out [ml oder g], Bezugszeit, Preinfusionszeit und Bezugstemperatur). Nutzer:innen wählen ein Rezept, passen Parameter per Vertikalhebel bzw. numerischer Eingabe an und können Varianten speichern. Sicherheitsrelevante Aktionen (z. B. Überschreiben eines Rezepts) erfordern eine Bestätigung. Die Oberfläche bietet klare Navigationsbereiche, z.B.: Schnellstart (Bezug mit Standardrezept, erfolgt über die hintere Taste am Vertikalhebel), Start (Rezeptwahl), Details (Parameter), Live (Brühvorgang), Service (MATLAB®/Diagnose), Umschaltung auf Handhebelmaschine.

Das Display dient auch als Verbindung zur MATLAB®-App (USB-Schnittstelle). In dieser soll ein tieferer Einblick in den Brühprozess möglich sein, somit muss das Display nicht nur alle relevanten Daten an die App übermitteln, sondern auch imstande sein, Eingaben von der App zu verarbeiten.

= Armin Rohnen, 03.02.2025 =
Es wurde eine Festlegung bezüglich des Display getroffen.
Als Display wird ein adafruit 2478 Display mit resistiver Touchfunktion verwendet. Das Display verfügt über eine weitere MCU. Hier ist ein Raspberry Pi Pico W vorgesehen. Display-Gehäuse und Platinenbefestigung für die Glasboilermaschine sind im Bereich der Brühgruppenabdeckung inzwischen konstruiert und liegen als Musterteile vor.

Die Entscheidung wird als final angesehen. Der zu erwartende Änderungsumfang für die Elektronik umfasst nicht diesen Bereich.

= Armin Rohnen, 11.04.2024 =
Ein Display mit Touchfunktion wird zur Visualisierung und als Tastenersatz angestrebt. Das Display enthält entweder selbst eine MCU oder ist an einer weiteren MCU angeschlossen. Bei einer weiteren MCU bestünde die Möglichkeit eine WLAN-Funktionalität einzuführen. Ein lokalerWebserver auf der Maschine führt zu verbesserter Konektivität sowie zur Erleichterung von Änderungen der Tastenbelegungen und der Profilverwaltung.

Die Display-MCU wertet den Token aus und verändert diesen im Falle von Tastenaktivität. Ggf. würde die Display-MCU den Spannungswert des Vertikalhebels erfassen.

Integration eines Displays mit Touchfunktion

2026-03-22T16:13:22Z

Armin Rohnen:

= Armin Rohnen, 22.03.2026 Displayauswahl=
Als mögliche Display wurden neu definiert: 
Waveshare RP2350-Touch-LCD-2.1 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-2.1 Waveshare-Wiki]) 
Waveshare RP2350-Touch-LCD-2 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-2 Waveshare Wiki]) 
Waveshare RP2350-Touch-LCD-1.69 ([https://www.waveshare.com/wiki/RP2350-Touch-LCD-1.69 Waveshare Wiki]) 

Alle drei Display zeichnet aus, dass diese bereits mit einem RP2350-Mikrocontroller-Board versehen sind und daher wie Raspberry Pi Pico 2 behandelt werden können. Zu allen drei Displays gibt es im jeweiligen Wiki Beispielcode für die auf dem board verbauten Sensoren und eben das Display. EInige PINs des RP2350 sind auf Stecker oder Lötpads gelegt, so dass noch etwas Peripherie angeschlossen werden kann. Das lässt immer die UART-Kommunikation zu und es ermöglicht den Vertikalhebel (Spannungsmessung) sowie die beiden mechanischen Tasten anzuschließen.

Allerdings kann das RP2350-Touch-LCD-2.1 Display nicht in MicroPython programmiert werden. Für den darin verwendeten Display-Chip gibt es aktuell keine MicroPython-Library. Allerdings ist ein sehr ausführlicher Democode in C vorhanden.

Bis Juli 2026 soll eine findierte und finale Entscheidung erarbeitet werden, welches Display weiter verfolgt wird.

= Jeremias Kögl, 12.11.2025 Aufgabenanalyse=
Das Touchdisplay (Adafruit 2478, 240×320 Pixel, SPI-Protokoll) wird zusammen mit einem Raspberry Pi Pico W als lokales HMI (Human-Machine-Interface) betrieben; beide
Komponenten werden als „Display“ bezeichnet.
Das Display:
* initialisiert die Kommunikation im MCU-Verbund
* visualisiert Prozessdaten während des Brühens, der Aufheizphase und der Bereitschaftsphase
* Gibt einen Log aus
* verwaltet Kaffeerezepte
* stellt die Verbindung zur MATLAB®®-Wartungsapp her

Beim Einschalten initialisiert das Display die Kommunikation im MCU-Verbund und die SPI-Schnittstelle, kalibriert die Touchoberfläche und initialisiert die Kommunikation mit den Verbundmodulen durch Senden eines Initialisierungstokens. Die Initialisierung ist erst abgeschlossen, wenn der Token wieder an das Display zurückgekehrt ist. Es lädt anschließend die vier lokal gespeicherten Rezepte und signalisiert die Brühbereitschaft.

Während des Bezugs zeigt das Display in (quasi) Echtzeit neben der Zeit auch Durchfluss, Druck oder Temperatur an. Soll-/Ist-Kurven machen Abweichungen sichtbar. Grenzwerte
sollen Fehlbedienungen vermeiden. Für die Bedienung sind große Touch-Ziele zu verwenden. Es sind Maßnahmen zu treffen, um eine flüssige Darstellung zu gewährleisten und die Touch-Latenz zu minimieren.

Zur Erhöhung der Benutzerfreundlichkeit und Wiederholungssicherheit soll die Möglichkeit bestehen, Rezepte zu speichern. Jedes Rezept umfasst Zielwerte für alle einstellbaren Prozessparameter (Menge In [g], Menge Out [ml oder g], Bezugszeit, Preinfusionszeit und Bezugstemperatur). Nutzer:innen wählen ein Rezept, passen Parameter per Vertikalhebel bzw. numerischer Eingabe an und können Varianten speichern. Sicherheitsrelevante Aktionen (z. B. Überschreiben eines Rezepts) erfordern eine Bestätigung. Die Oberfläche bietet klare Navigationsbereiche, z.B.: Schnellstart (Bezug mit Standardrezept, erfolgt über die hintere Taste am Vertikalhebel), Start (Rezeptwahl), Details (Parameter), Live (Brühvorgang), Service (MATLAB®/Diagnose), Umschaltung auf Handhebelmaschine.

Das Display dient auch als Verbindung zur MATLAB®-App (USB-Schnittstelle). In dieser soll ein tieferer Einblick in den Brühprozess möglich sein, somit muss das Display nicht nur alle relevanten Daten an die App übermitteln, sondern auch imstande sein, Eingaben von der App zu verarbeiten.

= Armin Rohnen, 03.02.2025 =
Es wurde eine Festlegung bezüglich des Display getroffen.
Als Display wird ein adafruit 2478 Display mit resistiver Touchfunktion verwendet. Das Display verfügt über eine weitere MCU. Hier ist ein Raspberry Pi Pico W vorgesehen. Display-Gehäuse und Platinenbefestigung für die Glasboilermaschine sind im Bereich der Brühgruppenabdeckung inzwischen konstruiert und liegen als Musterteile vor.

Die Entscheidung wird als final angesehen. Der zu erwartende Änderungsumfang für die Elektronik umfasst nicht diesen Bereich.

= Armin Rohnen, 11.04.2024 =
Ein Display mit Touchfunktion wird zur Visualisierung und als Tastenersatz angestrebt. Das Display enthält entweder selbst eine MCU oder ist an einer weiteren MCU angeschlossen. Bei einer weiteren MCU bestünde die Möglichkeit eine WLAN-Funktionalität einzuführen. Ein lokalerWebserver auf der Maschine führt zu verbesserter Konektivität sowie zur Erleichterung von Änderungen der Tastenbelegungen und der Profilverwaltung.

Die Display-MCU wertet den Token aus und verändert diesen im Falle von Tastenaktivität. Ggf. würde die Display-MCU den Spannungswert des Vertikalhebels erfassen.

Systemsoftware

2026-03-22T14:54:54Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Startprozedur]]
|
|1
|30
|
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || alle|| 1 || 70 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Systemsoftware

2026-02-14T15:02:55Z

Armin Rohnen: /* ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || || 1 || 70 ||
|-
| [[Mehrkernnutzung und/oder Multitasking]] || || 1 || 70 ||
|-
| [[Startprozedur]]
|
|1
|30
|
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || || 1 || 30 ||
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || || 1 || 30 ||
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || alle|| 1 || 70 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Mikrocontroller Programmierung in MicroPython WiSe 2025/26

2026-02-14T14:26:22Z

Armin Rohnen: /* Besprechungsprotokolle */

<htmltag tagname="img" src="https://vg06.met.vgwort.de/na/c62555318b0346218dc23a5ada9f7726" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Wintersemetser 2025/26 =
Für das Projekt der labortechnischen und Glasboiler Espressomaschine soll die vorhandene Master (MATLAB®-App) Client (RPi RP2040 MCUs in MicroPython) Steuerung auf eine autarke Multi-MCU-Steuerung mit mehreren RPi RP2040 und/oder RPi RP2350 mit einer MATLAB®-App als Service-Tool umgestellt werden.

Die Umstellung soll im ersten Schritt über Demonstratoren vorbereitet werden. Die erforderlichen Steuerungsplatinen sind in mehrfacher Ausfertigung vorhanden, so dass Teilaufgaben voneinander unabhängig abgearbeitet werden können.

Die Programmcodes in MicroPython für die Realisierung der Grundfunktionen (Schalten, Messwerte erfassen, Display ansteuern, UART Kommunikation, MATLAB® Kommunikation) sind in MATLAB® meets MicroPython [40] vorhanden. Hierzu wird die zweite (noch nicht veröffentlichte) Ausgabe zur Verfügung gestellt.

Diese Projektarbeit dient der Weiterentwicklung der modularisierten Systemsteuerung im Gesamtprojekt zur Entwicklung der Siebträger-Espressomaschinen.

= Aufgabenanalyse =
== UART Kommunikation zwischen den einzelnen MCUs ==
Die bestehende Kommunikation über die MATLAB®-GUI soll durch ein robustes, ringförmiges UART-System ersetzt werden, bei dem fünf MCUs kontinuierlich einen gemeinsamen Token austauschen. Jede Platine ergänzt oder liest dabei spezifische Daten, während Start-, Standard- und Paniktoken sowie CRC-Prüfsummen für zuverlässigen Betrieb und Fehlererkennung sorgen.

== Mehrkernnutzung und/oder Multitasking ==
Beim Raspberry Pi Pico soll der zweite Prozessorkern genutzt werden, um die MCU-Kommunikation auszulagern und dadurch den Hauptkern für bestehende Steuerungsaufgaben zu entlasten. Dabei sind die Einschränkungen von _thread() sowie Konflikte beim Zugriff auf gemeinsame Peripherie zu berücksichtigen, während uasyncio als alternative kooperative Multitasking-Lösung nur einen Kern nutzen kann.

== Startprozedur ==
Diese wird initialisiert durch die Aktivierung aller vier MCUs und dient der Gewährleistung einer korrekten Kommunikationsstruktur sowie dem sequenziellen Start von Füllstands- und Boilerdruckregelung. Die Betriebsbereitschaft wird signalisiert, sobald der Boilerdruck-Sollwert erreicht wird.

== Füllstandsregelung ==
Ziel ist die vollständige Übertragung der bisher in der MATLAB®-GUI realisierten Boiler-Füllstandsregelung auf die Basisplatine, um eine PC-unabhängige Regelung zu ermöglichen. Die Regelung erkennt den Füllstand über eine Kurzschlussdetektion; liegt kein Kurzschluss vor, wird dies als unzureichender Füllstand interpretiert und der Boilerdruckregler zur Vermeidung von Trockenheizen gesperrt. Bei Erreichen des Sollfüllstands erfolgt eine gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches An- und Abschalten der Regelung vorzubeugen.

== Boilerdruckregelung ==
Dieser PID-Regler wird auf die SSR-Platine übertragen und aktiviert sich aus Sicherheitsgründen erst dann, wenn ein korrekter Wasserstand im Boiler erkannt wurde. Parallel zur Druckhaltung steuert die Regelung die Entschichtungsfunktion, welche aktiv bleibt, bis die Boilertemperatur einen einstellbaren Grenzwert erreicht.

== Mischtemperaturregelung ==
Um die Wassertemperatur für Kaffee und Tee zu steuern, wird ein PID-Regler für das Mischventil auf der Basisplatine implementiert. Dabei wird eine Kaskadenstruktur verwendet, in der die Mischtemperaturregelung den äußeren Kreis bildet und direkt vom inneren Durchflussregelkreis abhängig ist.

== Durchflussregelung ==
Der auf das Basisboard verlagerte PID-Regler sorgt durch Anpassung der Pumpenspannung für einen konstanten Volumenstrom. Als innerer Regelkreis liefert er kontinuierlich Durchflusswerte an den Mischtemperaturregler, um die Temperaturstabilisierung zu gewährleisten

== Maschinensimulator - Hardware ==
Für die Steuerungselektronik besteht die Siebträger Espressomaschine aus Messwerten. Dies sind in der aktuellen Form
* 4 NTC Temperatursensoren mit 10 kOhm
* 2 Druckmesswerte im Spannungsbereich 0,5 bis 4,5 V
* Leitwert und Temperatur des zufließenden Wassers im Spannungsbereich 0 bis 5 V
* Flowmeter mit 39,9 Impulsen je ccm
* 4 Füllstandssensoren über Kurzschlussdetektion

Realisiert werden diese Messwerte über ein digitales Potentiometer MCP4151 mit 10 kOhm, welches über eine SPI-Schnittstelle eingestellt werden kann. Damit werden die 4 NTC Temperatursensoren und über die Spannungsteilerfunktion des Bauelements werden die Druckmesswerte, der Leitwert und die Temperatur des zufließenden Wassers simuliert.

Die Kurzschlusserzeugung der Füllstandssensoren werden mit einem digitalen Analogschalter (DG411) realisiert und das Flowmetersignal wird über eine Transistorfolgeschaltung erzeugt.

Die Schaltung benötigt eine MCU mit mindestens 17 für Kommunikation und Elektronikansteuerung verfügbaren PINs. Hierzu ist eine Raspberry Pi Pico MCU vorgesehen.

== Maschinensimulator - Hardware ==
Auf der MCU selbst ist zwingend die SPI-Kommunikation zu den digitalen Potentiometer mit insgesamt 8 verschiedenen Chipselect erforderlich. Die digitalen Analogschalter benötigen lediglich ein PIN mit Digoutfunktion während das Flowmetersignal als PWM-Signal mit variabler Frequenz realisiert wird. Für die variable Frequenz kann über die Anweisung PWM.freq([Frequenz]) eingestellt werden.

Die Einstellwerte für das digitale Potentiometer sollten für die 4 NTC Temperatursensoren als Temperaturwerte eingegeben werden. Aus dem Eingabewert wird und über die Beachtung der nichtlinearen Kennlinie der NTCs sowie dem nichtlinearen Zusammenhang aus Einstellwert und Widerstandswert der Einstellwert des jeweiligen digitalen Potentiometers. Die normierten Kennlinien der NTCs liegen vor. Eventuell lassen sich darüber die erforderlichen Einstellwerte ermitteln.

Auch die Einstellwerte für die Simulation der Druckmesswerte sollten in bar für den Brühgruppendruck bzw. in mbar für den Boilerdruck erfolgen. Auch hier muss die nichtlinearität des digitalen Potentiometers berücksichtigt werden.

Es erscheint sinnvoll, dass der Maschinensimulator in den Kommunikationsring eingebunden wird. Aus dem Token kann der Sollwert für die Pumpensteuerung entnommen werden, welches wiederum für die Generierung des Flowmetersignals verwendet werden kann. Ebenso können aus dem Token die Heizleistungen entnommen werden, was für die Temperatursignale sowei Boilerdrucksignal verwendet werden könnte.

Für die einfachere Bedienung und um die Anzahl der benötigten PCs zu minimieren ist eine MATLAB®-GUI nützlich. In dieser sollten die simulierten Signale per numerischer Eingabe, Schalter oder Slider einstellbar sein. ebenso sollten darin Umschaltungen möglich sein, so dass die simulierten Signale in Abhängigkeit der Pumpensteuerung und Heizleistung erzeugt werden. Auch denkbar wären die generierung von Messwerten über bekannte Messwertverläufe von gemessenen Kaffeebezügen.

= Leistungsvereinbarung =
== Kommunikation ==
Es wird eine Kommunikation zwischen den MCUs (Platinen) der Maschinensteuerung aufgebaut. Dazu wird die auf den einzelnen Platinen herausgeführte UART-Schnittstelle so verbunden, dass ein Kommunikationsring entsteht. Über den Kommunikationsring wird ein als Token bezeichnetes Datenpaket mit allen für den Maschinenbetrieb erforderlichen Messdaten, Stellgrößen, Anforderungen, Einstellparametern und Logging-Informationen im Kreis durchgereicht. Der Token wird so gestaltet, dass dieser dynamisch an spätere Anforderungen (2. Brühgruppe) angepasst werden kann. Der Token wird für eine möglichst kleine Anzahl an Kommunikations-Bytes binär ausgeführt. Es wird eine Definitionstabelle des Tokens im öffentlichen Wiki erstellt. Das Verfahren wird als Espressomaschinen-Kommunikations-Ring (EKR) bezeichnet.

== Mehrkernnutzung ==
Es wird versucht, über die MicroPython-Funktionalität „_thread“ die Kommunikation von den anderweitigen Prozessaufgaben auf allen MCUs zu trennen und auf den zweiten Prozessorkern zu verlagern.

== Verlagerung der Regelkreise ==
Die aktuell über die MATLAB®-GUI ausgeführten Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung, Mischtemperaturregelung und Durchflussregelung werden auf die dafür prädestinierten MCUs verlagert. Die Reglercodes dazu sind im Prinzip in MATLAB® vorhanden, müssen aber an das MCU-Umfeld und die Programmiersprache MicroPython angepasst werden. Funktionstest der Regler an einer realen Hardware sind nicht möglich, da diese soweit noch nicht vorhanden ist. Ziel ist die vollständige Implementierung der Reglerlogik in MicroPython einschließlich Schnittstellenanpassung und Variablenmanagement. Die Funktionsprüfung erfolgt auf Codeebene sowie über simulierte Testfälle.

Für den Ablauf zwischen Einschalten der Maschine und Betriebsbereitschaft zum Kaffeebezug, im Weiteren Betriebsbereitschaft zum Dampfbezug, wird eine Startprozedur definiert und soweit es die vorhandene Hardware zulässt getestet.

== Maschinensimulator ==
Zur Überprüfung des MCU-Verbunds, der implementierten Reglerlogik sowie der Startprozedur ohne vorhandene reale Maschinenhardware wird ein Maschinensimulator eingesetzt.

Die Hardware für den Maschinensimulator wird bereitgestellt. Der Maschinensimulator generiert die Widerstandswerte der NTC-Temperatursensoren sowie die Spannungswerte der analogen Sensoren im Bereich von 0,5 V bis 4,5 V. Die Füllstandssensoren werden über Kurzschlussschalter simuliert, der Durchflusssensor über eine getaktete Transistorfolgeschaltung mit PWM-Ansteuerung. Zur Nachbildung der Temperatursensoren, Drucksensoren, Füllstandssensoren, Leitwert- und Durchflusssignale werden geeignete bereits festgelegte elektronische Komponenten verwendet. Die Ansteuerung der einzelnen Signalerzeuger ist dabei offen zu gestalten und kann im Verlauf der Implementierung festgelegt werden.

Der Maschinensimulator wird in den bestehenden Kommunikationsring integriert. Dadurch können Sollwerte und Systemparameter aus dem Token ausgelesen und zur Erzeugung der simulierten Sensorsignale genutzt werden.

= Besprechungsprotokolle =
* [[Projektstart 09.10.2025]]
* [[Projektrücksprache 15.10.2025]]
* [[Projektrücksprache 23.10.2025]]
* [[Projektrücksprache 30.10.2025]]
* [[Projektrücksprache 06.11.2025]]
* [[Projektrücksprache 13.11.2025]]
* [[Projektrücksprache 20.11.2025]]
* [[Projektrücksprache 27.11.2025]]
* [[Projektrücksprache 04.12.2025]]
* [[Projektrücksprache 11.12.2025]]
* [[Projektrücksprache 18.12.2025]]
* [[Projektrücksprache 15.01.2026]]
* [[Projektrücksprache 05.02.2026]]

= Abschlusspräsentation =
[[Datei:20260214 Abschlusspraesentation.pdf|Mikrocontroller Programmierung in MicroPython]]

Technische Beeinflussbarkeit der Geschmacksache Kaffee:Literatur

2026-02-14T14:25:24Z

Armin Rohnen: /* Quellenverzeichnis */

<htmltag tagname="img" src="https://vg05.met.vgwort.de/na/44b0bd294def495a8e21154f37810b84" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Quellenverzeichnis =
Quellen und Dokumente

Bei den hier gelisteten Dokumenten und Quellen handelt es sich um Dokumentationen der durchgeführten Projekt- und Abschlussarbeiten, Statusberichte sowie um Fachliteratur.

Für das Projekt "Technische Beeinflussbarkeit der Geschmacksache Kaffee" wird über diese Seite ein einheitliches Literaturverzeichnis geführt, welches bei Bedarf erweitert wird.In den jeweiligen Dokumentationen entfällt das sonst übliche Literaturverzeichnis

# Kilian Stach, [[Abschlussarbeit Stach|Entwicklung einer labortechnischen Mehrkreis- und Mehrkessel-Espressomaschine]], Bachelor-Thesis, 2018
# Rawad Alshikh, Frank Hadwiger, Timo Sieber, [[Inbetriebnahme 2018|Inbetriebnahme der Labor-Espressomaschine]], Projektarbeit, 2018
# Johann Siegl, Schaltungstechnik- Analog und gemischt analog/digital, 2. Auflage Springer Berlin Heidelberg New York, 2005
# Matthias Kretzschmar, Joshua Bauske, Christoph Binder, [[Simulation 2018|Simulationsmodell einer Siebträger Kaffeemaschine]], Projektarbeit, 2018
# Marc Arendt, [[Abschlussarbeit Arendt|Neukonstruktion einer Kaffeemaschinenbrühgruppe]], Bachelorarbeit 2018 (Konstruktion der ersten Variante einer kalten Brühgruppe)
# Fabian Deiser, Felix Müller, Stefan Sellmaier, Johannes Amann, [[Inbetriebnahme 2019|Inbetriebnahme und Vorbereitung zur Erprobung der kalten Brühgruppe für eine labortechnische Espressomaschine]], Projektarbeit 2019
# Tobias Tritschler, [[Abschlussarbeit Tritschler|Konstruktion zweier Druckbehälter für eine hochwertige Siebträgermaschine]], Bachelorarbeit 2019
# Sebastian O’Reilly, Florian Fritz, Tim Kittelmann, Johannes Kastner, [[Versuche Glasboiler 2020|Versuchsaufbau und Versuchsdurchführung an einem Borosilikatdampfboiler]], Projektarbeit 2020
# Sebastian Bitzinger, Lorenz Fricke, Marinus Winhart, [[Kalte E61 2019|Konstruktion einer kalten Brühgruppe nach dem E61 Prinzip]], Projektarbeit 2019
# Andreas Boeck, Ludwig Laurent, Marcel Seibold, [[Projektarbeit Kraftmessung 2019|Kraftmessung in Z-Richtung]], Projektarbeit 2019
# Melissa Schütz, Moritz Albrecht, Vladyslav Sosnytskyi, [[Projektarbeit Konstruktionen 2020|Konstruktion von vier Siebträger-Espressomaschinen]], Projektarbeit 2020
# Erich Weidler, Armin Rohnen, [[Erfindungsmeldung 2019|Erfindung Espressomaschine mit kalter Brühgruppe]], Erfindungsmeldung 2019
# Armin Rohnen, Hydraulikplan mit Entschichtung, 2019 (ungültig, neuer Stand [64])
# VERORDNUNG (EU) Nr. 801/2013 Festlegung von Ökodesign- Anforderungen an den Stromverbrauch elektrischer und elektronischer Haushalts- und Bürogeräte
# Formelsammlung und Berechnungsprogramme Anlagenbau, gesehen am 22.03.2020
# Vorrichtung zum erwärmen eines Trinkgefässes, Patentschrift EP 1 878 369 A1, Anmeldetag 14.07.2006
# Tobias Blädel, Til Ahlgrim, Lukas Ankner, Yasin Bolat, Fabian Weber, Florian Michal, [[Konstruktion Labormaschine 2020|Konstruktion einer Siebträger-Espressomaschine]], Projektarbeit 2020
# Tolga Acar, Antonia Huber, Karim Ragab, Kerstin Seitz, [[Konstruktion Brühgruppe 2020|Konstruktion der Brühgruppen und zugehöriger Siebträger für den 3D-Druck]], Projektarbeit 2021
# Fabian Weber, [[Abschlussarbeit Weber|Mechatronische Entwicklung und Inbetriebnahme einer labortechnischen Espressomaschine]], Bachelorarbeit 2021
# Florian Johann Michal, [[Abschlussarbeit Michal|Entwicklung und Inbetriebnahme des hydraulischen Aufbaus einer labortechnischen Espressomaschine]], Bachelorarbeit 2021
# Felix Müller, [[Abschlussarbeit Felix Müller|Entwicklung zweier Temperaturregelungen (Folgeregelung) mithilfe von Python und MATLAB®]], Abschlussarbeit 2020
# Armin Rohnen, Konzept: Modulare Systemelektronik für Siebträger Espressomaschinen, 2021 (ungültiges Dokument)
# Ludwig Ackermann, Lucas Kolbinger, Marko Kurtusic, Isabell Nuißl, Matthias Rieseberg, Melanie Schuster, Edon Shala, [[Projektarbeit Glasboiler 2021|Espressomaschine mit Borosilikatglasboiler]], Projektarbeit 2021
# Sebastian Czernin, Jonas Pytlik, Michael Zanziger, [[Projektarbeit Mess-System 2021|Mess-System zur Ermittlung der Betriebsparameter von Espressomaschinen]], Projektarbeit 2021
# Korbinia Ass, Valentin Sachmann, Simon Schmetz, [[Projektarbeit Pumpenprüfstand 2021|Entwicklung eines Kalibriersystems für Druck- und Temperatursensoren]], Projektarbeit 2021
# Anna Gutenberger, Yasin Mahan, Michael Spießl, Artur Tomczak, [[Projektarbeit Bedienkonzept 2021|Entwicklung eines Bedienkonzeptes für eine Espressomaschine und Simulation der Bedienung mit MATLAB® App Designer]] (Bedienungsanleitung, Funktionsliste), Projektarbeit 2021
# Andreas Goclik, Armin Rohnen, Konzept Kaffee-Maschine, 2021 (nicht öffentliches Dokument)
# Fabian Sinn, Manuel Menrath, Niklas Vonderschnitt, [[Inbetriebnahme Labormaschine 2021|Weiterführung Inbetriebnahmelabortechnische Espressomaschine, Neukonstruktion von Heizelementen und Wasserwendel]], Projektarbeit 2021
# Janina Schulz, Simon Nantschev, Tomislav Marjanovic, Josef Hanswold, Konstruktion einer 1,8 Liter Siebträger-Espressomaschine mit kalter Brühgruppe, Projektarbeit 2021 (nicht öffentliches Dokument)
# Patricia Viebke, Tamiem Sediq, Andreas Turbanisch, [[Inbetriebnahme Mess-System 2021|Inbetriebnahme Mess-System zur Bestimmung von Durchflussraten, Druck und Temperaturverläufen von Siebträger-Espressomaschinen]], Projektarbeit 2021
# Armin Rohnen, [[Konzept Elektronik Entwicklung 2021|Erforschung eines Arbeitsablaufs für die Entwicklung integrierter elektronischer Systeme anhand des Beispiels einer Siebträger-Espressomaschine]], 2021
# La Marzocco, Patentschrift, Weighing Device for an Espresso Coffee Machine
# La Marzocco, Patentschrift, Machine for preparing a beverage withrepeatable characteristics
# La Marzocco, Patentschrift, Espresso Coffee Machine with adjustment of the dispensing pressure an method for adjusting the dispensing pressure of an Espresso Coffee Machine
# Stephan Hase, [[Praktikum Inbetriebnahme Pumpenprüfstand 2021|Inbetriebnahme des Pumpenprüfstands]], Praxissemester Sommersemester 2021
# La Marzocco, Patentschrift WÄGEVORRICHTUNG FÜR EINE ESPRESSOKAFFEEMASCHINE UND ESPRESSOKAFFEEMASCHINE MIT EINER SOLCHEN VORRICHTUNG, EP 2 701 563 B1, 2015 (ab Seite 6 deutsche Beschreibung der Patentansprüche)
# Armin Rohnen, Hydraulikplan 1,8 Liter Kaffeemaschine, Stand: 20.04.2022 (nicht öffentliches Dokument)
# Grobübersicht Projekt Kaffeemaschine (Projektflyer) (nicht öffentliches Dokument)
# Marktüberblick Siebträger-Kaffeemaschinen (nicht öffentliches Dokument)
# Armin Rohnen, MATLAB® meets MicroPython, Springer Fachmedien Wiesbaden, ISBN 978-3-658-39948-1, 2022
# Armin Rohnen, [[Schnittstelle MATLAB MicroPython 2021|STM32F411 nucleo - MATLAB® Schnittstelle]], Stand November 2021
# Wittel et. al., Roloff/Matek, Maschinenelemente, Normung, Berechnung, Gestaltung, 24., überarbeitete und erweiterte Auflage, Springer Vieweg, 2019
# Felix Kistler, [[Projektarbeit Glasboilermaschine 2021|Entwicklung einer Siebträger-Espressomaschine mit Borosilikat-Glasboiler]], Januar 2021
# Isabell Nuißl, Konstruktion, [[Abschlussarbeit Isabell Nuissl 2021|Nachrechnung und Montage des Borosilikatglasboilers der Espressomaschine Style]], Abschlussarbeit 2021
# Armin Rohnen, Hydraulikplan Borosilikatgals-Espressomaschine MMM - Style, (ungültig, neuer Stand [64])
# Phillip Crone, Espressomaschinen sind die neuen Autos, Süddeutsche Zeitung Online, 21. Januar 2022
# Bosche, [https://www.bosche.eu/waagenkomponenten/waegezellen/plattform-waegezellen/plattform-waegezellen-h10a Test Certificate Bosche H10A Wägezellen], 11.12.2012
# Villeroy und Boch, Villeroy und Boch: Tassen und Becher, 25.10.2021
# Aluminiumklebebänder, Aluminiumklebebänder, Februar 2022
# Gregor Mietzsch, Marvin Baumgartner, [[Projektarbeit Wägetechnik 2022|Konzeptentwicklung der Wägetechnik für eine Siebträgerespressomaschine]], Projektarbeit 2022
# Matthias Rieseberg, Inbetriebnahme mit Montageanleitung der 1,8 – Liter Kaffeemaschine, Abschlussarbeit 2022 (nicht öffentliches Dokument)
# Daniele Fecondo, Philipp Wieland, Sebastian Intra, [[Projektarbeit Inbetriebnahme Labormaschine 2022|Inbetriebnahme einer labortechnischen Kaffeemaschine]], Projektarbeit, 2022
# Nermin Arbi, Alexander Egger, Michael Urbin, [[FMEA Labormaschine 2020|FMEA Labortechnische Espressomaschine]], Modularbeit 2020
# Eric Hübner, Semih Kum, [[Projektarbeit Inbetriebnahme Pumpenprüfstand 2022|Abschlussbericht zur Projektarbeit Inbetriebnahme Pumpenprüfstand]], Projektarbeit, 2022
# Patricia Viebke, [[Abschlussarbeit Patricia Viebke 2022|Inbetriebnahme eines Messsystems zur Aufnahme von Betriebsparametern bei Siebträger Espressomaschinen mit und ohne E61 Brühgruppe]], Abschlussarbeit, 2022
# Felix Kistler, [[Projektarbeit innovative Komponenten 2022|Qualifikation innovativer Komponenten einer Siebträger-Espressomaschine]], Projektarbeit, 2022
# Armin Rohnen, Hydraulikplan Style, Stand 08.04.2022 (ungültig, neuer Stand [64])
# Daniele Fecondo, Philipp Wieland, Sebastian Intra, [[Montageanleitung Labormaschine 2022|Montageanleitung labortechnische Espressomaschine]], Stand 15.02.2022
# Florian Christ, Philipp Seeholzer, Timo Mehlbeer, Stefan Weiderer, Projektdokumentation Detailkonstruktionen 1,8 Liter Kaffeemaschine , 2022 (nicht öffentliches Dokument)
# Armin Rohnen, Hydraulikplan Labor, Stand 08.04.2022 (ungültig, neuer Stand [64])
# [https://www.gemu-group.com/fileadmin/user_upload/DownloadSupport/Wissensportal/GEM%C3%9C_Dampfdrucktabelle_de.pdf Dampfdrucktabelle der Fa. GEMÜ Gebr. Müller Apparatebau GmbH & Co. KG]
# Johannes Wandinger, Skript Technische Mechanik 2
# Felix Kistler, [[Business Case Glasboilermaschine 2022|Business Case Glasboiler-Maschine]], Stand 01.02.2022
# Armin Rohnen, [[Hydraulikplan Style und Labor|Hydraulikplan Labor und Style]], Stand: 24.11.2023
# FLUID-O-TECH, kein Datum, [https://www.fluidotech.it/site/assets/files/1319/datenblatt_der_einheit_der_serie_fg200-300.pdf PUMPEN-MOTOR EINHEIT SERIE FG200-300-400], Online, Zugriff am 24.07.2022
# Anon., kein Datum, [https://www.chemie.de/lexikon/Liste_der_spezifischen_W%C3%A4rmekapazit%C3%A4ten.html Liste der spezifischen Wärmekapazitäten], Online, Zugriff am 24.07.2022
# Armin Rohnen, ntc_spannungsteiler_mit_interpolation, 2020
# AVS-Römer, 2021, Mess- und Regeltechnik, Online, Zugriff am 24.07.2022
# Digmesa International LTD, kein Datum, [https://www.digmesa.com/de/product-details/flow-sensor-nano_brass/ NANO BRASS], Online, Zugriff am 24.07.2022
# Armin Rohnen, Signalanalyse Pumpe, 2022
# Rowbitt, M., kein Datum, [https://microbit-micropython.readthedocs.io/en/v1.0.1/devguide/repl.html Accessing the REPL], Online, Zugriff am 24.07.2022
# Schnabel, P., kein Datum, [https://www.elektronik-kompendium.de/sites/com/0310301.htm Serielle Schnittstelle (RS232 / V.24 / COM)], Online, Zugriff am 24.07.2022
# The MathWorks®, kein Datum, [https://de.mathworks.com/help/instrument/serialport.writeline.html writeline], Online, Zugriff am 24.07.2022
# BARESTA® Experten Team, kein Datum, [https://www.baresta.com/bar-baresta/der-perfekte-espresso Der perfekte Espresso - Die perfekte Zubereitung - Checkliste - Ursachen], Online, Zugriff am 24.07.2022
# Heinz, M., Horst, S., Rainer, F. und Klaus, W., 2019. Einführung in die Regelungstechnik (12. Auflage). München: Carl Hanser Verlag München.
# Gräber, M., 2021, [https://tlk-energy.de/blog/pid-regler-einstellen PID Regler einstellen in der Praxis], Online, Zugriff am 24.07.2022
# [https://grabcad.com/library/all-gastronorm-containers-1 CAD-Modelle der Gastro-Norm-Behälter], ONLINE
# Faton Brahimi, Alexander Ivanov, Umkonstruktion der Labortechnische Espressomaschine, Projektarbeit, 2022 (ungültiges Dokument)
# Melanie Ostermeier, Markus Hofer, Daniele Fecondo, Dario Opacak, Alexander Hoffmann, Christian Eichholz, Florian Todenhagen, [[FMEA Betriebssoftware 2022|FMEA: Betriebssoftware labortechnische Espressomaschine]], Modularbeit 2022
# Armin Rohnen, [[Teilenummernkonzept]], 2022
# Armin Rohnen, [[Schraubenauslegung Brühgruppe|Schraubenauslegung Angepasste Brühgruppe]], Stand: 30.06.2022
# Felix Kistler, [[Kaffeemaschinen Montag 2022|Abschlusspräsentationen Kaffeemaschinen Montag]], Stand: 07.08.2022
# Erik Reitsam, [[Abschlussarbeit Erik Reitsam|Konstruktion der Komponenten Tank, Bodenplatte und Unterbau der Espressomaschine „Style“]], Abschlussarbeit 2022
# Felix Kistler, [[Brühgruppenversuche 2022|Versuchsprotokoll der Brühgruppenversuche vom 08.06.2022]], Stand: 14.10.2022
# Jan Budnick, [[Abschlussarbeit Jan Budnick|Betriebssoftwareentwicklung mit MATLAB®-MicroPython-Schnittstelle und Verbesserung einer geregelten Zweikreis-Espressomaschine]], Abschlussarbeit, 2022
# Stefan Hase, Hydraulikplan Pumpenprüfstand, 2021 (ungültiges Dokument}
# Stefanie Diener, [[Festigkeitsberechnung Spannhaken 2022|Festigkeitsberechnung Spannhaken]], 2022
# Armin Rohnen, [[Projektstatus 2021|Status der Espressomaschinen-Entwicklung für das Forschungsprojekt der technischen Beeinflussbarkeit der Geschmacksache Kaffee]], Juli 2021
# Armin Rohnen, [[Innovationsvortrag 2022|Innovation, Vortrag am Kaffeemaschinen Montag]], August 2022
# Felix Kistler, [[DOE Kaffeebezugsparameter 2023|Erforschung des Einflusses relevanter Kaffeebezugsparameter auf die Entstehung der Crema bei Siebträger-Espressomaschinen]], Januar 2023
# Florian Wandl, [[Abschlussarbeit Florian Wandl|Lieferantenmanagement und Kostenkalkulator]], Abschlussarbeit, 2023
# Michael Albrecht, Martin Aspacher, Stefanie Diener [[Projektarbeit Maschinenkonstruktionen WiSe 2022|Konstruktionsarbeiten labortechnische Espressomaschine und Glasboilermaschine]], Projektarbeit, 2023
# Axel Georg Steer, [https://cuvillier.de/de/shop/publications/3228 Physikalisch-chemische Parameter des Kaffeegetränkes und Untersuchungen zur Röstkaffee-Extraktion], Dissertation, 2003
# Wilhelm Kleppmann, Versuchsplanung, 10., überarbeitete und erweiterte Auflage, Carl Hanser Verlag, München, 2020
# Patricia Viebke, [[Inbetriebnahme Pumpenprüfstand|Finalisierung der Inbetriebnahme des Pumpenprüfstands]], Projektarbeit, 2023
# Patricia Viebke, [[:Datei:20221229 ModularbeitMSMM PatriciaViebke.pdf|Kalibrierung JoeFrex Waage]], Modularbeit, 2023
# Felix Kistler, [[Projektarbeit Felix Kistler|Entwicklung einer Siebträger-Espressomaschine mit Borosilikat-Glasboiler]], Projektarbeit, 2022
# Felix Kistler, [[:Datei:20230621 Glasboiler-Maschine Schnittstellendefinition neu.pdf|Schnittstellendefinition der angepassten Brühgruppe für Labor- und Glasboilermaschine]], Juni 2023
# Elektronik-Kompedium, [https://www.elektronik-kompendium.de/sites/slt/0411221.htm#:~:text=Ein%20Darlington%2DTransistor%20ist%20im,gro%C3%9Fe%20Last%20steuern%2Fschalten%20soll. Funktion Darlington-Schaltung] ,Online, Zugriff am 24.07.2023
# Deltron AG, [https://wiki.bu.ost.ch/infoportal/_media/hardware/sysp/bauteile/schrittmotor_kurz_erklaert_d.pdf Funktion Schrittmotor] Online, Zugriff am 24.07.2023
# Circuit Diy, [https://www.circuits-diy.com/adjustable-voltage-regulator-circuit-using-lm338/ Funktion LM338] , Online, Zugriff am 28.07.2023
# Robert Hammelrath, MicroPython Classenbibliothek ads1x15, https://github.com/robert-hh/ads1x15, Online, Zugriff am 30.07.2023
# Simon Lorenz Thrainer, Melina Scherf, Madita vom Stein, Hendrik Wegjan, [[:Datei:20230809 Abschlussbericht Systemsoftware.pdf|Weiterentwicklung der Systemsoftware für eine Siebträger Espressomaschine]], Projektarbeit, 2023
# Armin Rohnen, [[:Datei:20230909 Elektronik-Konzeptbeschreibung.pdf|Elektronik-Konzept]], September 2023
# [https://www.mikrocontroller.net/articles/Schmitt-Trigger Funktion Schmitt-Trigger], Online, Zugriff am 25.09.2023
# Elektronik-Kompedium, [https://www.elektronik-kompendium.de/sites/kom/0401111.htm PWM-Signal], Online, Zugriff 25.09.2023
# Elektronik-Kompedium, [https://www.elektronik-kompendium.de/public/schaerer/pullr.htm Funktion Pull-up Widerstand], Online, Zugriff 25.09.2023
# [https://forum.arduino.cc/t/wie-funktioniert-ein-pid-regler-eine-nicht-wissenschaftliche-erklarung/416421 Erklärung PID-Regler], Online, Zugriff 25.09.2023
# Technische Universität Graz, [https://www.tugraz.at/fileadmin/user_upload/Institute/IRT/Skripten/Regelungstechnik_Horn_Juni_2015_.pdf Anti-Windup], Online, Zugriff 25.09.2023
# Microstar Laboratories [https://www.mstarlabs.com/control/znrule.html Auslegung PID-Regler Ziegler Nicholson Methode] , Online, Zugriff 25.09.2023
# [https://developer.mozilla.org/en-US/docs/Glossary/Callback_function Callback Erklärung], Online, Zugriff 27.09.2023
# Patricia Viebke, [[:Datei:2023Oct26_Update_Pumpenpr%C3%BCfstand.pdf|Updates zum Pumpenprüfstand]], Oktober 2023
# [[:Datei:PVDF-Polyvinylidenfluorid.pdf|Datenblatt PVDF]]
# Noureddine Ait Ouhamou, [[:Datei:02363 EMB Ait-Ouhamou Noureddine 2023-10-10.pdf|Umbau der Systemelektronik der Kaffeemaschine und Anpassung der Regelung]], Abschlussarbeit, 2023
# Felix Kistler, [[:Datei:20231129 Konzeptbeschreibung 2-Zylinder-Maschine.pdf|Konzeptbeschreibung 2-Zylinder-Maschine]], 2023
# Dichtelemente arcus GmbH, [[:Datei:Einbauhinweise o-ringe.pdf|Dimensionierung und Auswahl von O-Ringen]]
# Florian Wörle, Edmond Sogor, Thomas Neumeier, [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=20240219_Prototypenbau_1_Zylinder_Glasboiler Prototypenbau 1-Zylinder Glasboiler], Projektarbeit 2024
# Datenblatt Vishay 10 kOhm, 0,3 Sekunden [[:Datei:Ntcle317e4103sba.pdf|Vishay 10 kOhm 0,3 s NTC|Vishay 10 kOhm 0,3 s NTC]]
# [https://awesome-micropython.com/ Linksammlung MicroPython Libraries, Frameworks, Software und Ressourcen]
# Armin Rohnen, Aufgabenbeschreibung labortechnische Espressomaschine, [[:Datei:20240407 Verlagerung Regelkreise.pdf|Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik]], April 2024
# Technisches Datenblatt [[:Datei:Datenblatt Extrudr GreenTecPRO Datenblatt DE.pdf|Extrudr GreenTecPRO]] Filament
# Patricia Viebke, [[:Datei:2024Apr20 Projektarbeit2 PatriciaViebke.pdf|Finalisierung der Inbetriebnahme eines Mess-Systems für die Aufnahme von Parametern an Siebträger Espressomaschinen mit und ohne E61 Brühgruppe]], Projektarbeit 2024
# Markus Mörtl und Christian Schmied, Design for Cost - A Review of Methods, Tools and Research Directions. Journal of the Indian Institute of Science. 95 (4), 379-404, 2015
# Ehrlenspiel et al., Kostengünstig Entwickeln und Konstruieren. Kostenmanagement bei der integrierten Produktentwicklung. 8. Auflage. Springer-Verlag, Berlin, Heidelberg, 2020
# Borja Roman Corrochano, Advancing the Engineering Understanding of Coffee Extraction. Dissertation an der University of Birmingham, 2015
# Parenti et al., Comparison of espresso coffee brewing techniques. Journal of Food Engineering, 121, 112–117, 2014
# Romani et al., Quality of “ Espresso ” coffee: a study performed through Italian coffee shops. In ASIC (Ed.), 20th International Conference on Coffee Science, 521–525, Bangalore, India, 2004
# Andueza et al., Chemical and sensorial characteristics of Espresso coffee as affected by grinding and torrefacto roast. Journal of Agricultural and Food Chemistry, 2003
# Caporaso et al., Neapolitan coffee brew chemical analysis in comparison to espresso, moka and American brews. Food Research International, 2014
# M. Petracco, Beverage preparation: brewing trends for the new millennium. In: Clarke, R., Vitzthum, O. (Eds.), Coffee: Recent Developments. Blackwell Science, Oxford, 2001
# Mestdagh et al: Chapter 15 - The Brew-Extracting for excellence. The craft and science of coffee, Academic Press, 355-380, 2017
# Armin Rohnen, [[:Datei:20211104 SPRIN-D.pdf|Leitfragen Sprunginnovationen - Reduzierung des Energiebedarfs einer Siebträger-Espressomaschine]], eingereicht bei der Bundesagentur für Sprunginnovationen SPRIND, 2020
# Felix Kistler, [[:Datei:20240531 Technische Entwicklung und Kostenoptimierung einer modularen Siebträger-Espressomaschine Felix Kistler.pdf|Technische Entwicklung und Kostenoptimierung einer modularen Siebträger-Espressomaschine]], Abschlussarbeit, 2024
# Kostenfreies Online-Tool zur Erstellung von Hydraulikplänen, Schaltplänen, Logikdiagrammen, etc., https://etools.smc.at/pneudraw
# DIN EN ISO 75-1:2020-06, Kunststoffe - Bestimmung der Wärmeformbeständigkeitstemperatur - Teil 1: Allgemeines Prüfverfahren (ISO 75-1:2020); Deutsche Fassung EN ISO 75-1:2020
# Ausdehnungskoeffizient - https://de.wikipedia.org/wiki/Ausdehnungskoeffizient#Beispiele
# Eigenschaften von PFA - https://www.rct-online.de/de/RctGlossar/detail/id/15
# LOCTITE® EA 9480 Datenblatt - https://datasheets.tdx.henkel.com/LOCTITE-EA-9480-de_DE.pdf
# Using Epoxy to protect NTC Thermistors - https://www.ametherm.com/blog/thermistors/using-epoxy-to-protect-ntc-thermistors/
# Prusament PLA Datenblatt - https://prusament.com/wp-content/uploads/2022/10/PLA_Prusament_TDS_2021_10_DE.pdf
# B&B Sensors - Keramischer Drucksensor - https://shop.bb-sensors.com/Messtechnik-je-Branche/Automotive/Keramischer-Drucksensor.html
# AVS Römer Produktkatalog - https://www.avs-roemer.de/media/service/produktkatalog-broschueren/20221206-avs-r%C3%B6mer_produktkatalog_2022.2_de.pdf
# Wellenkupplungs Adapter - https://www.christians-shop.de/Wellenkupplung-20mm-25NM-6mm-8mm
# 3D Druck von Überhängen - https://www.filamentpreis.de/ueberhaenge-bruecken-schoener-drucken/#:~:text=%C3%9Cberh%C3%A4nge%2520bis%252045%2520Grad%2520schafft,auch%2520noch%2520relativ%2520sauber%2520druckbar
# Datenblatt Schrittmotor SM158-35S - https://www.color-technik.net/wp-content/uploads/2020/10/SM158-35S_PM_RH-Getriebemotor_ct3820.pdf
# Markus Stommel, Marcus Stojek, Wolfgang Korte, FEM zur Berechnung von Kunststoff- und Elastomerbauteilen, 2. Auflage Carl Hanser Verlag GmbH & Co. KG, 2018
# AD-2000-Regelwerk, Beuth, Berlin 2013
# Was ist der Unterschied zwischen Zugfestigkeit und Streckgrenze? - https://provenproductivity.com/de/was-ist-der-unterschied-zwischen-zugfestigkeit-und-streckgrenze/
# Prof. Dr.-Ing. T. Preussler, Festigkeitslehre, Torsion
# Eigenschaften von A4 Edelstahl - https://www.teamedelstahl.de/werkstoffe/1-4401/
# Reibwerte von verschiedenen Materialien - https://www.schweizer-fn.de/stoff/reibwerte/reibwerte.php#sonstiges
# Leonhard Schöner, Ze Lee, Amir Braun, [[:Datei:20240807 Amir Braun Leonhard Schöner Ze Lee Projektbericht-Entwicklung von Sensoren und Aktoren.pdf|Entwicklung von Sensoren und Aktoren für die Die Glasboilermaschine – Style]], Projektarbeit, 2024
# Patricia Viebke, [[:Datei:2024Sep27 Masterarbeit PatriciaViebke.pdf|Vermessung von E61 und nicht-E61 Siebträger Espressomaschinen anhand Auswertung und Gegenüberstellung der erfassten Parameter mittels des entwickelten Mess-Systems]], Abschlussarbeit, 2024
# Florian Buchholz, Felix Forster, Ferdinand Harbauer, [[:Datei:20240725 Abschlusspräsentation Glasboilerespressomaschine SoSe24.pdf|Abschlusspräsentation Prototypenbau Glasboilermaschine]], Projektarbeit, 2024
# P. D. L. Prod. Dr. Langhorst, Skript zur Spanenden Fertigung, 2023
# Wilbur's Finest, '5 Different Types of 3D Build Plates'. Accessed: Nov. 07, 2024. [Online]. Available: https://wilbursfinest.com/blogs/news/5-different-types-of-3d-build-plates
# James Madison, '3D Printer Bed: How to Choose Your Build Plate', Affordable 3D Printing Filaments and Resins. Accessed: Nov. 08, 2024. [Online]. Available: https://www.sunlu.com/en-de/blogs/3d-printing-guide/3d-printer-bed-how-to-choose-your-build-plate-surface
# P3D, 'What is PEI, PEO, PEY, PET, PEX Build Plates? And How to Use it?'. Accessed: Nov. 07, 2024. [Online]. Available: https://p3d.mx/blogs/how-to-3d-print/what-is-pei-peo-pey-pex-pet-build-plates
# 3DSourced, 'The Best 3D Printer Build Plates & Surface For Every Filament'. Accessed: Nov. 07, 2024. [Online]. Available: https://www.3dsourced.com/rigid-ink/build-plate-surface/
# Bambu Lab Wiki, 'Introduction to the Build Plates'. Accessed: Nov. 07, 2024. [Online]. Available: https://wiki.bambulab.com/en/filament-acc/acc/plates
# 3D Maker Engineering, '3D Printer Build Plate Guide'. Accessed: Nov. 08, 2024. [Online]. Available: https://www.3dmakerengineering.com/blogs/3d-printing/3d-printer-build-plate-guide
# All3DP, '3D Printer Bed: How to Choose Your Build Plate/Surface'. Accessed: Nov. 08, 2024. [Online]. Available: https://all3dp.com/2/3d-printer-bed-how-to-choose-the-right-build-plate/
# A. Z. Dwi and H. Syamsudin, 'Manufacturing Fiberglass-Epoxy LSU-03 Aircraft Propeller Using Hand Lay-up and Vacuum Assisted Resin Transfer Moulding (VARTM) Methods', IOP Conf. Ser. Mater. Sci. Eng., vol. 645, no. 1, p. 012018, Oct. 2019, doi: 10.1088/1757-899X/645/1/012018.
# adafruit 2,4" Display with Touch [https://cdn-learn.adafruit.com/downloads/pdf/adafruit-2-4-color-tft-touchscreen-breakout.pdf Handbuch]
#F. Bouchard, M. Soldera, R. Baumann, and A. F. Lasagni, ‘Hierarchical Microtextures Embossed on PET from Laser-Patterned Stamps’, Materials, vol. 14, no. 7, p. 1756, Apr. 2021, doi: 10.3390/ma14071756.
#‘G.W.P. AG - Thermoformen / Vakuumtiefziehen / Warmformen / Kunststofftiefziehen - Tiefziehen von Kunststoff’. Accessed: Dec. 05, 2024. [Online]. Available: https://www.gwp-ag.de/leistungen/serienfertigung/kunststoffverarbeitung/thermoformen/256.Thermoformen--Vakuumtiefziehen
#‘laser_processing_pet_film.pdf’. Accessed: Dec. 05, 2024. [Online]. Available: https://cdn.ulsinc.com/assets/pdf/materials_subordinate/583603b397d4dd52f774230f/laser_processing_pet_film.pdf
#Gloria E. Magarotto, ‘Orca Slicer: Fuzzy Skin – Simply Explained’, All3DP. Accessed: Dec. 10, 2024. [Online]. Available: https://all3dp.com/2/orca-slicer-fuzzy-skin-simply-explained/
#Fuzzy skin | Prusa Knowledge Base’. Accessed: Dec. 10, 2024. [Online]. Available: https://help.prusa3d.com/article/fuzzy-skin_246186
#‘Fuzzy skin’, Bambu Lab Wiki. Accessed: Dec. 10, 2024. [Online]. Available: https://wiki.bambulab.com/en/software/bambu-studio/parameter/fuzzy-skin
#N. Aboulkhair, FDM Polishing 2022|Vapour polishing of fused deposition modelling (FDM) parts: a critical review, International Journal of Advanced Manufacturing Technology, Bd. 122, Nr. 6, S. 1–12, 2022.
#A. Kumar et al., 3D Printing Processes 2023|Post-Production Finishing Processes Utilized in 3D Printing: A Review, Processes, Bd. 12, Nr. 3, S. 595, 2023.
#M. Neumann, PLA Solvents 2023|Mechanical behaviour of post-processed 3D printed PLA parts using polar and non-polar solvents, Polymer Bulletin, Bd. 124, Nr. 3, S. 987–995, 2023.
#J. Prusa, Solvent Smoothing 2023|How to Solvent Smooth 3D Printed FDM Parts, Prusa3D Blog, 2023.
#D. Müller, Dissolving PLA 2023|Which Solvent Works Best for Dissolving PLA?, 3DPrintBeast, 2023.
#J. Novak, Chemical Resistance 2023|Chemical resistance of 3D printing materials, Prusament Blog, 2023.
#R. Singh, Surface Quality FDM 2023|The Surface Quality Improvement Methods for FDM Printed Parts: A Review, Springer Series in Advanced Manufacturing, Bd. 25, S. 223–238, 2023.
#End Bulliqi, Daniel Hellwig, Michael Bischof, [[:Datei:20250213 Prototypenbau Abschlusspraesentation.pdf|Prototypenbau Siebträger-Espressomaschine]], Projektarbeit 2025
#Maximilian Beck, Luca Schmid, Andrei Zemba, Vincent Greinecker, [[:Datei:20250212 Vincent Greinecker Uebergabeprotokoll.pdf|Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck]], Projektarbeit, 2025
#Marin Bader, Nicolas Linner, Tobias Schumann, [[:Datei:20250219 Konstruktionen WiSe2024 25.pdf|Detailentwicklungen Siebträger Espressomaschine]], Projektarbeit, 2025
#Pascal Deppe, Elias Erl, Sebastian Krimmer, [[:Datei:20250702 Abschlusspraesentation Projektmodul Erl Deppe Krimmer.pdf|Konstruktionsarbeiten: Unbeheizte E61 Brühgruppe, Boilerboden, Boilerdeckel, Gehäusekonzept und weitere]], Projektarbeit, 2025
#'Coherent Corp. - Diamond J Serie'. Accessed: Apr. 23, 2025. [Online]. Available: https://www.coherent.com/de/lasers/co2/diamond-j-series
#extrudr GmbH. GreenTEC Pro - Sicherheitsdatenblatt (SDS). Accessed: Apr. 10, 2025. [Online]. Available: https://3dee.at/wp-content/uploads/2024/08/extrudr-greentec-pro-SDS-de.pdf
#Simon Besl, Matthias Strohmeier, Maximilian Wimmer, [[:Datei:20250707 BeslStrohmeierWimmer Abschlusspräsentation Projektmodul.pdf|Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck]], Projektarbeit, 2025
#colortechnik Antriebstechnik GmbH [[:Datei:20260207 SM149-SM155 PM Getriebemotor CT3820.pdf|Getriebe-Schrittmotor SM149-25T / SM155-25L Serie]] (Stand Jan 2026)
#Philipp Schiebel, Peter Vogginger, [[Datei:20260214 Abschlusspraesentation.pdf|Mikrocontroller Programmierung in MicroPython]], Projektarbeit WiSe 2025/26

Datei:20260214 Abschlusspraesentation.pdf

2026-02-14T14:24:26Z

Armin Rohnen:

Abschlusspräsenttaion Schiebel, Vogginger

Systemsoftware

2026-02-12T16:20:54Z

Armin Rohnen:

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || Peter Vogginger|| 1 || 30 || 05.02.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Peter Vogginger|| 1 || 30 ||05.02.2026
|-
| [[Startprozedur]]
|Philipp Schiebel
|1
|30
|
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 30 || 05.02.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || Philipp Schiebel|| 1 || 30 || 05.02.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 10 ||
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 1 || 10 ||
|-
| [[Integration eines Displays mit Touchfunktion]] || || 1 || 30 ||
|-
| [[Integration eines Vertikalhebels]] || || 1 || 30 ||
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI]] || || 1 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|-
| [[Maschinensimulator]] || alle|| 1 || 30 ||05.02.2026
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Projektarbeit Simon Besl, Matthias Strohmeier, Maximilian Wimmer

2026-02-12T16:16:43Z

Armin Rohnen: /* Besprechungsprotokolle */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/01eb38e54a1640e4910af65aa621c0fc" width="1" height="1" alt=""></htmltag>
= Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck =

== Aufgabenanalyse ==

===Lasergravieren von Kunststofffolien Folien zur Druckplattenbeschichtung (Matthias Strohmeier)===
In diesem globalen Arbeitspaket wird die Bearbeitung von (PET-) Folien mittels Lasergravur sowie die anschließende Beschichtung von FDM-3D-Druckplatten mit diesen untersucht. Es werden verschiedene (PET-) Ausgangsfolien ausgewählt, die auf Druckplatten geklebt werden können. Diese dienen als Ausgangsmaterial. 

Zunächst werden verschiedene Laserbearbeitungsverfahren in Verbindung mit PET-
Folien recherchiert. Bei der Laserbearbeitung von Kunststofffolien sind häufig Parameter wie die Wellenlänge des Laserlichts, die Laserleistung oder die Bearbeitungsgeschwindigkeit entscheidend für ein erfolgreiches Beschriftungsergebnis. Diese und möglicherweise weitere Parameter werden recherchiert, sortiert und anschließend getestet. Auch die Form und Komplexität der Gravur kann hierbei eine Rolle spielen und wird untersucht. 
Zusätzlich stellt sich die Frage, wie lange eine solche Textur – beispielsweise eine Nummer oder ein Logo – über eine PET-Folie auf Bauteile aufgedruckt werden kann, bevor die Folie verschleißt. Das gesamte Vorgehen wird im ersten Schritt sorgfältig geplant und vorbereitet, da der Zugang zu einem Laserbeschrifter nicht jederzeit garantiert werden kann. Somit liegt der erste Fokus klar auf der Recherche, Planung und Vorbereitung der Versuche. Als zusätzliche Untersuchung kann das „GreenTec Pro“-Filament der Marke Extrudr auf direkte Lasergravur und -bearbeitung hin untersucht werden. Hierbei werden gedruckte Bauteile mit verschiedenen Laserparametern beschossen und anschließend ausgewertet.

=== Vergleich der Oberflächenqualität bei unterschiedlichen FDM-3D-Druckern (Simon Besl) ===
Im Rahmen dieses Arbeitspakets wird der Einfluss unterschiedlicher FDM-3D-Drucker auf die resultierende Oberflächenqualität von Druckteilen systematisch untersucht. Ziel ist es, Druckergebnisse hinsichtlich ihrer optischen und haptischen Qualität sowie geometrischen Maßhaltigkeit vergleichend zu analysieren.

Dazu wird zunächst ein standardisiertes Testbauteil konstruiert, das gezielt typische Herausforderungen im FDM-Druck integriert – darunter Überhänge über 45°, filigrane Details sowie Flächen zur Bewertung von Textur und Layer-Bildung. Dieses Testobjekt dient als Referenzmodell für alle Druckversuche.

Im Anschluss erfolgt der Druck des Testobjekts auf mehreren 3D-Druckern unterschiedlicher Hersteller unter möglichst einheitlichen Druckparametern. Zusätzlich wird der Einfluss verschiedener Slicer-Programme (z. B. Cura, PrusaSlicer, Orca) analysiert, indem identische Modelle mit jeweils softwaretypischen Standardprofilen gesliced und verglichen werden.

Die gedruckten Bauteile werden in zwei Schritten ausgewertet:

# '''Subjektive Analyse:''' In einem Blindtest beurteilen sowohl Laien als auch Projektteilnehmende die Oberflächenqualität der Druckteile hinsichtlich Gleichmäßigkeit, Schichtlinien und Haptik.
# '''Objektive Analyse:''' Mittels Messmitteln (z. B. Bügelmessschraube) werden Maßhaltigkeit, Detailtreue sowie eventuelle Verzüge dokumentiert und gegenübergestellt.

Als zusätzlicher Untersuchungsaspekt wird bei Bedarf der Einfluss unterschiedlicher Düsendicken auf die Oberflächenqualität und Druckgeschwindigkeit geprüft. Hierzu wird das Testobjekt mit unterschiedlichen Düsendicken gedruckt um zu prüfen, ob eine Steigerung der Druckgeschwindigkeit ohne Einbußen bei der Oberflächengüte möglich ist.

===Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse (Maximilian Wimmer)===
In diesem Arbeitspaket wird die mechanische Belastbarkeit von 3D-gedruckten Bauteilen einer Kaffeemaschine untersucht. Dabei werden sowohl die Eigenschaften unbehandelter Teile als auch ihr Verhalten unter Einflüssen wie Wasser, Temperatur und Chemikalien betrachtet.

Dieses Arbeitspaket baut auf die Projektarbeit von Maximilian Beck, Luca Schmid, Andrei Zemba und Vincent Greinecker auf und knüpft unmittelbar an die im Übergabeprotokoll [179] unter Kapitel 4.2 festgehaltenen Vorgehensmöglichkeiten an.

Zunächst erfolgen Laborversuche wie Zug- und Schlagbiegeprüfungen, um die Ergebnisse mit den Herstellerangaben zu vergleichen und Referenzwerte für spätere Tests zu gewinnen. Anschließend wird die Wasseraufnahme experimentell bestimmt, inklusive der Auswirkungen auf mechanische Eigenschaften und mögliche optische oder geometrische Veränderungen.

Die Temperaturbeständigkeit wird zum einen durch einmaliges Erhitzen der Bauteile und anschließende mechanische Prüfungen ermittelt. Zum anderen untersuchen wir das Verhalten unter thermischen Zyklen, indem die Proben wiederholt in einem Wasserbad aufgeheizt und anschließend abgekühlt werden.

Zudem wird die Beständigkeit gegenüber Chemikalien wie Reinigungs- und Entkalkungsmitteln untersucht, indem Bauteile über längere Zeit in entsprechenden Lösungen gelagert und anschließend analysiert werden.

== Zielvereinbarung ==
Die Zielsetzung des Arbeitspakets "''Lasergravieren von (PET-) Folien zur Druckplattenbeschichtung''" ist es, eine klare Dokumentation über alle relevanten Möglichkeiten und Parameter der Lasergravur von mit PET-Folien beschichteten Druckplatten sowie der direkten Laserbearbeitung von 3D-gedruckten Bauteilen zu erstellen. Die Ergebnisse sollen klar nachvollziehbar und reproduzierbar sein.

Zielsetzung des Arbeitspakets „''Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse auf die Bauteilfestigkeit''“ ist die genaue Analyse der Festigkeitseigenschaften des Kunststoffs GreenTec Pro im Vergleich zu den vom Hersteller angegebenen Werten. Ebenso sollen die Veränderungen der Materialeigenschaften unter typischen Einsatzbedingungen einer Kaffeemaschine, Einwirkung von Wasser, Temperatur und Chemikalien, untersucht werden.

Die Zielsetzung des Arbeitspakets „''Vergleich der Oberflächenqualität bei unterschiedlichen FDM-3D-Druckern''“ liegt in der systematischen Untersuchung des Einflusses verschiedener FDM-Drucker, Slicer-Software und Düsen auf die Maßhaltigkeit, Oberflächenqualität und Detailgenauigkeit von 3D-gedruckten Bauteilen. Dazu wird ein standardisiertes Testmodell entwickelt. Die Ergebnisse werden sowohl subjektiv (z. B. durch Blindtests) als auch objektiv (z. B. Maßanalyse, Verzugsmessung) bewertet. Ziel ist es, verlässliche Aussagen über den Zusammenhang zwischen Drucktechnik und Bauteilqualität zu treffen und diese in die Gesamtbewertung des Projekts einzubinden.

== Besprechungsprotokolle ==
[[FDM-Druck Startgespräch 27.03.2025]] 
[[FDM-Druck Rücksprache 04.04.2025]] 
[[FDM-Druck Rücksprache 25.04.2025]] 
[[FDM-Druck Rücksprache 09.05.2025]] 
[[FDM-Druck Rücksprache 23.05.2025]] 
[[FDM-Druck Rücksprache 06.06.2025]] 
[[FDM-Druck Rücksprache 20.06.2025]] 

== Arbeitspakete ==
=== Status ===
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

=== ToDo-Liste Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck ===

{| class="wikitable sortable"
|+
|-
! Arbeitspaket !! ToDo !! Wer !! Priorität !! Status !! WV
|-
| 1 || [[Drucker|Einfluss unterschiedlicher FDM-Drucker auf die Druckqualität]] || || || ||
|-
| 2 || [[Slicer|Einfluss unterschiedlicher Slicer-Programme auf die Druckqualität]] || || || ||
|-
| 3 || [[Düsendurchmesser|Einfluss unterschiedlicher Düsendurchmesser auf die Druckqualität]] || || || ||
|-
| 4 || [[Festigkeit|Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse auf die Bauteilfestigkeit]] || || || ||
|-
| 4.1 || [[Einfluss von Wasser auf Bauteilfestigkeit]] || || || ||
|-
| 4.2 || [[Einfluss von Temperatur auf Bauteilfestigkeit]] || || || ||
|-
| 4.3 || [[Einfluss von Chemikalien auf Bauteilfestigkeit]] || || || ||
|-
| 5 || [[Laserbeschriftung (PET-) Folien und anschließende Druckplattenbeschichtung (Matthias Strohmeier)]] || || || ||
|-
| 5.1 || [[Laserbeschriftung von Folien bzw. Druckplatten (Matthias Strohmeier)]] || || || ||
|-
| 5.2 || [[Drucken der Bauteile auf zuvor gravierte Druckplatte ("Prägedruck") (Matthias Strohmeier)]] || || || ||
|}

Projektarbeit Simon Besl, Matthias Strohmeier, Maximilian Wimmer

2026-02-12T16:16:27Z

Armin Rohnen: /* ToDo-Liste Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck */

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/01eb38e54a1640e4910af65aa621c0fc" width="1" height="1" alt=""></htmltag>
= Möglichkeiten der Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck =

== Aufgabenanalyse ==

===Lasergravieren von Kunststofffolien Folien zur Druckplattenbeschichtung (Matthias Strohmeier)===
In diesem globalen Arbeitspaket wird die Bearbeitung von (PET-) Folien mittels Lasergravur sowie die anschließende Beschichtung von FDM-3D-Druckplatten mit diesen untersucht. Es werden verschiedene (PET-) Ausgangsfolien ausgewählt, die auf Druckplatten geklebt werden können. Diese dienen als Ausgangsmaterial. 

Zunächst werden verschiedene Laserbearbeitungsverfahren in Verbindung mit PET-
Folien recherchiert. Bei der Laserbearbeitung von Kunststofffolien sind häufig Parameter wie die Wellenlänge des Laserlichts, die Laserleistung oder die Bearbeitungsgeschwindigkeit entscheidend für ein erfolgreiches Beschriftungsergebnis. Diese und möglicherweise weitere Parameter werden recherchiert, sortiert und anschließend getestet. Auch die Form und Komplexität der Gravur kann hierbei eine Rolle spielen und wird untersucht. 
Zusätzlich stellt sich die Frage, wie lange eine solche Textur – beispielsweise eine Nummer oder ein Logo – über eine PET-Folie auf Bauteile aufgedruckt werden kann, bevor die Folie verschleißt. Das gesamte Vorgehen wird im ersten Schritt sorgfältig geplant und vorbereitet, da der Zugang zu einem Laserbeschrifter nicht jederzeit garantiert werden kann. Somit liegt der erste Fokus klar auf der Recherche, Planung und Vorbereitung der Versuche. Als zusätzliche Untersuchung kann das „GreenTec Pro“-Filament der Marke Extrudr auf direkte Lasergravur und -bearbeitung hin untersucht werden. Hierbei werden gedruckte Bauteile mit verschiedenen Laserparametern beschossen und anschließend ausgewertet.

=== Vergleich der Oberflächenqualität bei unterschiedlichen FDM-3D-Druckern (Simon Besl) ===
Im Rahmen dieses Arbeitspakets wird der Einfluss unterschiedlicher FDM-3D-Drucker auf die resultierende Oberflächenqualität von Druckteilen systematisch untersucht. Ziel ist es, Druckergebnisse hinsichtlich ihrer optischen und haptischen Qualität sowie geometrischen Maßhaltigkeit vergleichend zu analysieren.

Dazu wird zunächst ein standardisiertes Testbauteil konstruiert, das gezielt typische Herausforderungen im FDM-Druck integriert – darunter Überhänge über 45°, filigrane Details sowie Flächen zur Bewertung von Textur und Layer-Bildung. Dieses Testobjekt dient als Referenzmodell für alle Druckversuche.

Im Anschluss erfolgt der Druck des Testobjekts auf mehreren 3D-Druckern unterschiedlicher Hersteller unter möglichst einheitlichen Druckparametern. Zusätzlich wird der Einfluss verschiedener Slicer-Programme (z. B. Cura, PrusaSlicer, Orca) analysiert, indem identische Modelle mit jeweils softwaretypischen Standardprofilen gesliced und verglichen werden.

Die gedruckten Bauteile werden in zwei Schritten ausgewertet:

# '''Subjektive Analyse:''' In einem Blindtest beurteilen sowohl Laien als auch Projektteilnehmende die Oberflächenqualität der Druckteile hinsichtlich Gleichmäßigkeit, Schichtlinien und Haptik.
# '''Objektive Analyse:''' Mittels Messmitteln (z. B. Bügelmessschraube) werden Maßhaltigkeit, Detailtreue sowie eventuelle Verzüge dokumentiert und gegenübergestellt.

Als zusätzlicher Untersuchungsaspekt wird bei Bedarf der Einfluss unterschiedlicher Düsendicken auf die Oberflächenqualität und Druckgeschwindigkeit geprüft. Hierzu wird das Testobjekt mit unterschiedlichen Düsendicken gedruckt um zu prüfen, ob eine Steigerung der Druckgeschwindigkeit ohne Einbußen bei der Oberflächengüte möglich ist.

===Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse (Maximilian Wimmer)===
In diesem Arbeitspaket wird die mechanische Belastbarkeit von 3D-gedruckten Bauteilen einer Kaffeemaschine untersucht. Dabei werden sowohl die Eigenschaften unbehandelter Teile als auch ihr Verhalten unter Einflüssen wie Wasser, Temperatur und Chemikalien betrachtet.

Dieses Arbeitspaket baut auf die Projektarbeit von Maximilian Beck, Luca Schmid, Andrei Zemba und Vincent Greinecker auf und knüpft unmittelbar an die im Übergabeprotokoll [179] unter Kapitel 4.2 festgehaltenen Vorgehensmöglichkeiten an.

Zunächst erfolgen Laborversuche wie Zug- und Schlagbiegeprüfungen, um die Ergebnisse mit den Herstellerangaben zu vergleichen und Referenzwerte für spätere Tests zu gewinnen. Anschließend wird die Wasseraufnahme experimentell bestimmt, inklusive der Auswirkungen auf mechanische Eigenschaften und mögliche optische oder geometrische Veränderungen.

Die Temperaturbeständigkeit wird zum einen durch einmaliges Erhitzen der Bauteile und anschließende mechanische Prüfungen ermittelt. Zum anderen untersuchen wir das Verhalten unter thermischen Zyklen, indem die Proben wiederholt in einem Wasserbad aufgeheizt und anschließend abgekühlt werden.

Zudem wird die Beständigkeit gegenüber Chemikalien wie Reinigungs- und Entkalkungsmitteln untersucht, indem Bauteile über längere Zeit in entsprechenden Lösungen gelagert und anschließend analysiert werden.

== Zielvereinbarung ==
Die Zielsetzung des Arbeitspakets "''Lasergravieren von (PET-) Folien zur Druckplattenbeschichtung''" ist es, eine klare Dokumentation über alle relevanten Möglichkeiten und Parameter der Lasergravur von mit PET-Folien beschichteten Druckplatten sowie der direkten Laserbearbeitung von 3D-gedruckten Bauteilen zu erstellen. Die Ergebnisse sollen klar nachvollziehbar und reproduzierbar sein.

Zielsetzung des Arbeitspakets „''Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse auf die Bauteilfestigkeit''“ ist die genaue Analyse der Festigkeitseigenschaften des Kunststoffs GreenTec Pro im Vergleich zu den vom Hersteller angegebenen Werten. Ebenso sollen die Veränderungen der Materialeigenschaften unter typischen Einsatzbedingungen einer Kaffeemaschine, Einwirkung von Wasser, Temperatur und Chemikalien, untersucht werden.

Die Zielsetzung des Arbeitspakets „''Vergleich der Oberflächenqualität bei unterschiedlichen FDM-3D-Druckern''“ liegt in der systematischen Untersuchung des Einflusses verschiedener FDM-Drucker, Slicer-Software und Düsen auf die Maßhaltigkeit, Oberflächenqualität und Detailgenauigkeit von 3D-gedruckten Bauteilen. Dazu wird ein standardisiertes Testmodell entwickelt. Die Ergebnisse werden sowohl subjektiv (z. B. durch Blindtests) als auch objektiv (z. B. Maßanalyse, Verzugsmessung) bewertet. Ziel ist es, verlässliche Aussagen über den Zusammenhang zwischen Drucktechnik und Bauteilqualität zu treffen und diese in die Gesamtbewertung des Projekts einzubinden.

== Besprechungsprotokolle ==
[[FDM-Druck Startgespräch 27.03.2025]] 
[[FDM-Druck Rücksprache 04.04.2025]] 
[[FDM-Druck Rücksprache 25.04.2025]] 
[[FDM-Druck Rücksprache 09.05.2025]] 
[[FDM-Druck Rücksprache 23.05.2025]] 
[[FDM-Druck Rücksprache 06.06.2025]] 
[[FDM-Druck Rücksprache 20.06.2025]] 
[[FDM-Druck Rücksprache 04.07.2025]] 
[[FDM-Druck Abschlusspräsentation 25.07.2025]]

== Arbeitspakete ==
=== Status ===
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

=== ToDo-Liste Oberflächengestaltung und Maßhaltigkeit im FDM 3D-Druck ===

{| class="wikitable sortable"
|+
|-
! Arbeitspaket !! ToDo !! Wer !! Priorität !! Status !! WV
|-
| 1 || [[Drucker|Einfluss unterschiedlicher FDM-Drucker auf die Druckqualität]] || || || ||
|-
| 2 || [[Slicer|Einfluss unterschiedlicher Slicer-Programme auf die Druckqualität]] || || || ||
|-
| 3 || [[Düsendurchmesser|Einfluss unterschiedlicher Düsendurchmesser auf die Druckqualität]] || || || ||
|-
| 4 || [[Festigkeit|Nachweis der Bauteilfestigkeit und Untersuchung der Einflüsse auf die Bauteilfestigkeit]] || || || ||
|-
| 4.1 || [[Einfluss von Wasser auf Bauteilfestigkeit]] || || || ||
|-
| 4.2 || [[Einfluss von Temperatur auf Bauteilfestigkeit]] || || || ||
|-
| 4.3 || [[Einfluss von Chemikalien auf Bauteilfestigkeit]] || || || ||
|-
| 5 || [[Laserbeschriftung (PET-) Folien und anschließende Druckplattenbeschichtung (Matthias Strohmeier)]] || || || ||
|-
| 5.1 || [[Laserbeschriftung von Folien bzw. Druckplatten (Matthias Strohmeier)]] || || || ||
|-
| 5.2 || [[Drucken der Bauteile auf zuvor gravierte Druckplatte ("Prägedruck") (Matthias Strohmeier)]] || || || ||
|}

Technische Beeinflussbarkeit der Geschmacksache Kaffee:Literatur

2026-02-09T07:45:49Z

Armin Rohnen: /* Quellenverzeichnis */

Technische Beeinflussbarkeit der Geschmacksache Kaffee:Literatur

2026-02-09T07:45:11Z

Armin Rohnen:

Datei:20260207 SM149-SM155 PM Getriebemotor CT3820.pdf

2026-02-09T07:44:08Z

Armin Rohnen:

colortechnik Antriebstechnik GmbH Datenblatt

Maschinensimulator

2025-12-18T11:07:51Z

Armin Rohnen: /* Armin Rohnen, 29.10.2025 - Funktionstest MCP4151 (digitaler Widerstand) */

= Armin Rohnen, 29.10.2025 - Funktionstest MCP4151 (digitaler Widerstand) =
Über den Programmcode

def set_poti(ch, value): 
if not 0 <= ch < len(cs): 
raise ValueError('Ungültiger Kanal (0–7)') 
if not 0 <= value <= 255: 
raise ValueError('Wert muss zwischen 0 und 255 liegen') 
 
cs[ch].value(0) 
spi.write(bytearray([CMD_WRITE << 4, value])) 
cs[ch].value(1) 
 
spi = SPI(0, baudrate=400000, sck=Pin(2), mosi=Pin(3), miso=Pin(4)) 
cs = [Pin(pin, Pin.OUT, value=1) for pin in (5, 6, 7, 8, 9, 10, 11, 12)] 

werden die Widerstandswerte für die einzelnen simulierten Sensoren eingestellt. Konkret führt die Anweisung

set_poti(ch, value)

zur Verstellung des Widerstandswertes im MCP4151. Darin ist ch die Kanalnummer (0 bis 7) und value der Digitalwet ( 0 bis 255).

Für die Kanäle 0 bis 3 wird über den Widerstandswert jeweils ein NTC simuliert. Die Abhängigkeit ist jedoch nicht linear.

{| class="wikitable"
|+ Wertetabelle für den simulierten NTC-Widerstand
|-
! Digitalwert !! Widerstand in Ohm
|-
| 0 || 96
|-
| 50 || 1550
|-
| 100 || 3740
|-
| 150 || 5490
|-
| 200 || 7240
|-
| 255 || 9180
|}

Der Zusammenhang zwischen Digitalwert und simulierte Temperatur muss noch ermittelt werden.

Für die Kanäle 4 bis 7 wird der MCP4151 als Spannungsteiler mit einer Speisespannung von 5 V eingesetzt. Dies simuliert einen analogen Sensorwert in einem Spannungsbereich von 0 bis 5 V. Allerdings darf der Spannungsendwert 5 V nicht angesteuert werden, dies würde u. U. zu einem Kurzschluss führen. Der Nutzbare digitale Wertebereich liegt hier zwischen 50 und 250. Damit bleibt auf jeder Seite des Spannungsteilers immer ein Restwiderstand, welcher den Stromfluss hinreichend begrenzt. 
Aufgrund des nichtlinearen Widerstandsverlaufs ergibt sich ein ebenso nichtlinearer Spannungsverlauf.

{| class="wikitable"
|+ Wertetabelle für den simulierten Sensorwert (Spannung)
|-
! Digitalwert !! Spannung in mV
|-
| 50 || 4060
|-
| 100 || 3740
|-
| 150 || 2102
|-
| 200 || 1122
|-
| 255 || 144
|}

Der Zusammenhang zwischen Digitalwert und dem zu simulierenden Sensorwert muss noch ermittelt werden.

= Armin Rohnen, 29.10.2025 - Schaltungsaufbau =
Der Schaltplan für den Maschinensimulator ist soweit erstellt. Inhaltlich fehlt die Transistorfolgeschaltung für die Simulation des Flowmetersignals. 
Aktuell wird die Funktionalität des MCP4151-103E/P getestet. Dabei stellt sich heraus, dass sich der Widerstandswert nicht linear zum Einstellwert verhällt. Im Weiteren wurde festgestellt, dass auf dem Breadboard das erforderliche Durchschleifen der SPI-Schnittstelle nicht funktioniert. Damit ist bereits für die schnelle Übergangslösung eine gelötete Platine erforderlich.

= Armin Rohnen, 19.10.2025 - Konzept des Maschinensimulators =
Für die Steuerungselektronik besteht die Siebträger Espressomaschine aus Messwerten. Dies sind in der aktuellen Form
* 4 NTC Temperatursensoren mit 10 kOhm
* 2 Druckmesswerte im Spannungsbereich 0,5 bis 4,5 V
* Leitwert und Temperatur des zufließenden Wassers im Spannungsbereich 0 bis 5 V
* Flowmeter mit 39,9 Impulsen je ccm
* 4 Füllstandssensoren über Kurzschlussdetektion

Angedacht ist eine Hardware herzustellen, welche diese Messwerte simuliert.

Bei dem Bauelement MCP4151-103E/P handelt es sich um ein digitales 10 kOhm Potentiometer welches als Spannungsteiler eingesetzt werden kann und über SPI programmiert wird. Dieses Bauelement soll dazu dienen den Wiederstandswert der NTCs zu simmulieren und als Spannungsteiler die Druckmesswerte, Leitwert und Wassereingangstemperatur zu generieren.

Der Kurzschluss für die Füllstandssensoren soll über das Bauelement DG 411 DJZ und das Flowmeter über eine Transistorschaltung erzeugt werden.

Als Steuerung ist eine Raspberry Pi Pico MCU vorgesenen die u.U. mit einer übergeordneten MATLAB-GUI bedient werden kann. Für die Widerstandsabhängigen Sensorsimulationen wird eine SPI-Schnittstelle und insgesamt 8 PINs für CS benötigt. Die Kurzschlusserzeugung der Füllstandssensoren erfordert 4 PINs digital I/O und das Flowmetersignal einen PIN mit PWM-Signal.

Es ist zu überlegen, ob der Simulator mit in den Kommunikations-Ring des Systems eingebunden wird.

Der Maschinensimulator wird zunächst auf einem Breadboard realisiert um nach erfolgreichem Test die Schaltung in ein Platinenlayout zu überführen.

Maschinensimulator

2025-12-18T11:07:18Z

Armin Rohnen: /* Armin Rohnen, 29.10.2025 - Funktionstest MCP4151 (digitaler Widerstand) */

= Armin Rohnen, 29.10.2025 - Funktionstest MCP4151 (digitaler Widerstand) =
Über den Programmcode

def set_poti(ch, value): 
if not 0 <= ch < len(cs): 
raise ValueError('Ungültiger Kanal (0–7)') 
if not 0 <= value <= 255: 
raise ValueError('Wert muss zwischen 0 und 255 liegen') 
 
cs[ch].value(0) 
spi.write(bytearray([CMD_WRITE << 4, value])) 
cs[ch].value(1) 
 
spi = SPI(0, baudrate=400000, sck=Pin(2), mosi=Pin(3), miso=Pin(4)) 
cs = [Pin(pin, Pin.OUT, value=1) for pin in (5, 6, 7, 8, 9, 10, 11, 12)] 

werden die Widerstandswerte für die einzelnen simulierten Sensoren eingestellt. Konkret führt die Anweisung

set_poti(ch, value)

zur Verstellung des Widerstandswertes im MCP4151. Darin ist ch die Kanalnummer (0 bis 7) und value der Digitalwet ( 0 bis 255).

Für die Kanäle 0 bis 3 wird über den Widerstandswert jeweils ein NTC simuliert. Die Abhängigkeit ist jedoch nicht linear.

{| class="wikitable"
|+ Wertetabelle für den simulierten NTC-Widerstand
|-
! Digitalwert !! Widerstand in Ohm
|-
| 0 || 96
|-
| 50 || 1550
|-
| 100 || 3740
|-
| 150 || 5490
|-
| 200 || 7240
|-
| 255 || 9180
|}

Der Zusammenhang zwischen Digitalwert und simulierte Temperatur muss noch ermittelt werden.

Für die Kanäle 4 bis 7 wird der MCP4151 als Spannungsteiler mit einer Speisespannung von 5 V eingesetzt. Dies simuliert einen analogen Sensorwert in einem Spannungsbereich von 0 bis 5 V. Allerdings darf der Spannungsendwert 5 V nicht angesteuert werden, dies würde u. U. zu einem Kurzschluss führen. Der Nutzbare digitale Wertebereich liegt hier zwischen 50 und 250. Damit bleibt auf jeder Seite des Spannungsteilers immer ein Restwiderstand, welcher den Stromfluss hinreichend begrenzt. 
Aufgrund des nichtlinearen Widerstandsverlaufs ergibt sich ein ebenso nichtlinearer Spannungsverlauf.

{| class="wikitable"
|+ Wertetabelle für den simulierten Sensorwert (Spannung)
|-
! Digitalwert !! Spannung in mV
|-
| 50 || 4060
|-
| 100 || 3740
|-
| 100 || 3740
|-
| 150 || 2102
|-
| 200 || 1122
|-
| 255 || 144
|}

Der Zusammenhang zwischen Digitalwert und dem zu simulierenden Sensorwert muss noch ermittelt werden.

= Armin Rohnen, 29.10.2025 - Schaltungsaufbau =
Der Schaltplan für den Maschinensimulator ist soweit erstellt. Inhaltlich fehlt die Transistorfolgeschaltung für die Simulation des Flowmetersignals. 
Aktuell wird die Funktionalität des MCP4151-103E/P getestet. Dabei stellt sich heraus, dass sich der Widerstandswert nicht linear zum Einstellwert verhällt. Im Weiteren wurde festgestellt, dass auf dem Breadboard das erforderliche Durchschleifen der SPI-Schnittstelle nicht funktioniert. Damit ist bereits für die schnelle Übergangslösung eine gelötete Platine erforderlich.

= Armin Rohnen, 19.10.2025 - Konzept des Maschinensimulators =
Für die Steuerungselektronik besteht die Siebträger Espressomaschine aus Messwerten. Dies sind in der aktuellen Form
* 4 NTC Temperatursensoren mit 10 kOhm
* 2 Druckmesswerte im Spannungsbereich 0,5 bis 4,5 V
* Leitwert und Temperatur des zufließenden Wassers im Spannungsbereich 0 bis 5 V
* Flowmeter mit 39,9 Impulsen je ccm
* 4 Füllstandssensoren über Kurzschlussdetektion

Angedacht ist eine Hardware herzustellen, welche diese Messwerte simuliert.

Bei dem Bauelement MCP4151-103E/P handelt es sich um ein digitales 10 kOhm Potentiometer welches als Spannungsteiler eingesetzt werden kann und über SPI programmiert wird. Dieses Bauelement soll dazu dienen den Wiederstandswert der NTCs zu simmulieren und als Spannungsteiler die Druckmesswerte, Leitwert und Wassereingangstemperatur zu generieren.

Der Kurzschluss für die Füllstandssensoren soll über das Bauelement DG 411 DJZ und das Flowmeter über eine Transistorschaltung erzeugt werden.

Als Steuerung ist eine Raspberry Pi Pico MCU vorgesenen die u.U. mit einer übergeordneten MATLAB-GUI bedient werden kann. Für die Widerstandsabhängigen Sensorsimulationen wird eine SPI-Schnittstelle und insgesamt 8 PINs für CS benötigt. Die Kurzschlusserzeugung der Füllstandssensoren erfordert 4 PINs digital I/O und das Flowmetersignal einen PIN mit PWM-Signal.

Es ist zu überlegen, ob der Simulator mit in den Kommunikations-Ring des Systems eingebunden wird.

Der Maschinensimulator wird zunächst auf einem Breadboard realisiert um nach erfolgreichem Test die Schaltung in ein Platinenlayout zu überführen.

Kommunikation per UART

2025-12-13T14:19:27Z

Armin Rohnen: /* Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing */

= Armin Rohnen, 13.12.2025 Espressomaschinen-Kommunikations-Ring Timing =
[[Datei:20251213 EKR-Timing.png|thumb|1000px|gerahmt|zentriert|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen|EKR Timing Diagramm, (c) Armin Rohnen]]
Das Timing des Espressomaschinen-Kommunikations-Rings erfolgt durch die Taktung des ADCs der Messwertplatine. Dieser kann mit einer maximalen Abtastrate von 860 SPS (Samples per Second) betrieben werden. Da jeder 1. Messwert verworfen werden muss und insgesamt 8 Messkanäle berücksichtigt werden müssen, beträgt die effektive Abtastrate 53,75 Hz bzw. alle 18,6 ms steht damit ein neuer Messwertdatensatz zur Verfügung und es wird der Token an die Basisplatine (bas) gesendet. Nach aktuellem Stand (12. Dezember 2025) besteht der Token aus 74 Bytes, was 740 Transferbits ergibt und mit der definierten Transferrate von 230.400 Baud eine Übertragungszeit von 3,2 ms erfordert.

Der Kommunikationsring ist mit der Abfolge - Messwertplatine -> Basisplatine -> SSR-Platine -> Displayplatine -> (Maschinensimulator) -> Messwertplatine definiert. Außer auf der Messwertplatine wird jeweils der Token empfangen, danach die erforderlichen Programmcodes ausgeführt und Änderungen am Token vorgenommen um ihn abschließend an die nächste Platine weiter zu senden. Bei Einstellvorgängen des Dosierventils auf der SSR-Platine wird dies so nicht funktionieren, da die Verstellung des Schrittmotors zu lange dauern wird.

Wird die Kommunikation so wie beschrieben separat betrachtet, dann summiert sich die Transferzeit auf 12,8 ms (bzw. 16 ms mit eingebundenen Maschinensimulator) bis dass der dann mit Änderungen versehene Token wieder an der Messwertplatine angekommen ist. Alle 18,6 ms sendet bei höchster Abtastrate die Messwertplatine den Token erneut. Damit keine Informationen verloren gehen, bleiben insgesamt 5,8 ms Rechenzeit für alle im Ring befindlichen Platinen übrig. Die Messwertplatine fügt aus diesem Grund die Messwerte erst direkt vor dem Senden des Tokens darin ein.

Da eine Summenrechenzeit von 5,8 ms sehr knapp ist, ist zu prüfen, ob der Betrieb in maximaler ADC-Abtastrat emöglich ist.

Eine Reduzierung auf die Abtastrate 475 SPS würde den Token-Aktualisierungstakt auf 33,7 ms (29,7 Hz) erhöhen. Da die kummulierte Übertragungszeit mit 12,8 ms gleich bleibt, ergäbe sich dann eine Restrechenzeit von 20,9 ms. Da der aktualisierte Token, in dem die Messwertplatine wieder Änderungen einfügen darf, dann erst nach dem 3. Messwert eintrifft, ist weiterhin eine Zwischenspeicherung der erfassten Messdaten erforderlich.

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Kommunikation per UART

2025-12-13T14:15:29Z

Armin Rohnen: /* Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing */

= Armin Rohnen, 13.12.2025 Espressomaschinen-Kommunikations-Ring Timing =
[[Datei:20251213 EKR-Timing.png|thumb|1000px|gerahmt|zentriert|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen|EKR Timing Diagramm, (c) Armin Rohnen]]
Das Timing des Espressomaschinen-Kommunikations-Rings erfolgt durch die Taktung des ADCs der Messwertplatine. Dieser kann mit einer maximalen Abtastrate von 860 SPS (Samples per Second) betrieben werden. Da jeder 1. Messwert verworfen werden muss und insgesamt 8 Messkanäle berücksichtigt werden müssen, beträgt die effektive Abtastrate 53,75 Hz bzw. alle 18,6 ms steht damit ein neuer Messwertdatensatz zur Verfügung und es wird der Token an die Basisplatine (bas) gesendet. Nach aktuellem Stand (12. Dezember 2025) besteht der Token aus 74 Bytes, was 740 Transferbits ergibt und mit der definierten Transferrate von 230.400 Baud eine Übertragungszeit von 3,2 ms erfordert.

Der Kommunikationsring ist mit der Abfolge - Messwertplatine -> Basisplatine -> SSR-Platine -> Displayplatine -> (Maschinensimulator) -> Messwertplatine definiert. Außer auf der Messwertplatine wird jeweils der Token empfangen, danach die erforderlichen Programmcodes ausgeführt und Änderungen am Token vorgenommen um ihn abschließend an die nächste Platine weiter zu senden. Bei Einstellvorgängen des Dosierventils auf der SSR-Platine wird dies so nicht funktionieren, da die Verstellung des Schrittmotors zu lange dauern wird.

Wird die Kommunikation so wie beschrieben separat betrachtet, dann summiert sich die Transferzeit auf 12,8 ms (bzw. 16 ms mit eingebundenen Maschinensimulator) bis dass der dann mit Änderungen versehene Token wieder an der Messwertplatine angekommen ist. Alle 18,6 ms sendet bei höchster Abtastrate die Messwertplatine den Token erneut. Damit keine Informationen verloren, gehen bleiben insgesamt 5,8 ms Rechenzeit für alle im Ring befindlichen Platinen. Die Messwertplatine fügt aus diesem Grund die Messwerte erst direkt vor dem Senden des Tokens darin ein.

Da eine Summenrechenzeit von 5,8 ms sehr knapp ist, ist zu prüfen, ob der Betrieb in maximaler ADC-Abtastrat emöglich ist.

Eine Reduzierung auf die Abtastrate 475 SPS würde den Token-Aktualisierungstakte auf 33,7 ms (29,7 Hz) erhöhen. Da die kummulierte Übertragungszeit mit 12,8 ms gleich bleibt, ergäbe sich dann eine Restrechenzeit von 20,9 ms. Da der aktualisierte Token, in dem die Messwertplatine wieder Änderungen einfügen darf, erst nach dem 3. Messwert eintrifft, ist dann weiterhin eine Zwischenspeicherung der erfassten Messdaten erforderlich.

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Kommunikation per UART

2025-12-13T14:11:34Z

Armin Rohnen: /* Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing */

= Armin Rohnen, 13.12.2025 Espressomaschinen-Kommunikations-Ring Timing =
[[Datei:20251213 EKR-Timing.png|thumb|1000px|gerahmt|zentriert|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen|EKR Timing Diagramm, (c) Armin Rohnen]]
Das Timing des Espressomaschinen-Kommunikations-Rings erfolgt durch die Taktung des ADCs der Messwertplatine. Dieser kann mit einer maximalen Abtastrate von 860 SPS (Samples per Second) betrieben werden. Da jeder 1. Messwert verworfen werden muss und insgesamt 8 Messkanäle berücksichtigt werden müssen, beträgt die effektive Abtastrate 53,75 Hz bzw. alle 18,6 ms steht damit ein neuer Messwertdatensatz zur Verfügung und es wird der Token an die Basisplatine (bas) gesendet. Nach aktuellem Stand (12. Dezember 2025) besteht der Token aus 74 Bytes, was 740 Transferbits ergibt und mit der definierten Transferrate von 230.400 Baud eine Übertragungszeit von 3,2 ms erfordert.

Der Kommunikationsring ist mit der Abfolge - Messwertplatine -> Basisplatine -> SSR-Platine -> Displayplatine -> (Maschinensimulator) -> Messwertplatine definiert. Außer auf der Messwertplatine wird jeweils der Token empfangen, danach die erforderlichen Programmcodes ausgeführt und Änderungen am Token vorgenommen um ihn abschließend an die nächste Platine weiter zu senden. Bei Einstellvorgängen des Dosierventils auf der SSR-Platine wird dies so nicht funktionieren, da die Verstellung des Schrittmotors zu lange dauern wird.

Wird die Kommunikation so wie beschrieben separat betrachtet, dann summiert sich die Transferzeit auf 12,8 ms (bzw. 16 ms mit eingebundenen Maschinensimulator) bis dass der dann mit Änderungen versehene Token wieder an der Messwertplatine angekommen ist. Alle 18,6 ms sendet bei höchster Abtastrate die Messwertplatine den Token erneut. Damit keine Informationen verloren, gehen bleiben insgesamt 5,8 ms Rechenzeit für alle im Ring befindlichen Platinen. Die Messwertplatine fügt aus diesem Grund die Messwerte erst direkt vor dem Senden des Tokens darin ein.

Da eine Summenrechenzeit von 5,8 ms sehr knapp ist, ist zu prüfen, ob der Betrieb in maximaler ADC-Abtastrat emöglich ist.

Eine Reduzierung auf die Abtastrate 475 SPS würde den Token-Aktualisierungstakte auf 33,7 ms (29,7 Hz) erhöhen. Da die kummulierte Übertragungszeit mit 12,8 ms gleich bleibt, ergäbe sich dann eine Restrechenzeit von 20,9 ms.

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Kommunikation per UART

2025-12-13T13:52:57Z

Armin Rohnen: /* Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing */

= Armin Rohnen, 13.12.2025 Espressomaschinen-Kommunikations-Ring Timing =
[[Datei:20251213 EKR-Timing.png|thumb|1000px|gerahmt|zentriert|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen|EKR Timing Diagramm, (c) Armin Rohnen]]
Das Timing des Espressomaschinen-Kommunikations-Rings erfolgt durch die Taktung des ADCs der Messwertplatine. Dieser kann mit einer maximalen Abtastrate von 860 SPS (Samples per Second) betrieben werden. Da jeder 1. Messwert verworfen werden muss und insgesamt 8 Messkanäle berücksichtigt werden müssen, beträgt die effektive Abtastrate 53,75 Hz bzw. alle 18,6 ms steht damit ein neuer Messwertdatensatz zur Verfügung und es wird der Token an die Basisplatine (bas) gesendet. Nach aktuellem Stand (12. Dezember 2025) besteht der Token aus 74 Bytes, was 740 Transferbits ergibt und mit der definierten Transferrate von 230.400 Baud eine Übertragungszeit von 3,2 ms ergibt.

Der Kommunikationsring ist mit der Abfolge - Messwertplatine -> Basisplatine -> SSR-Platine -> Displayplatine -> (Maschinensimulator) -> Messwertplatine definiert.

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Datei:20251213 EKR-Timing.png

2025-12-13T13:43:29Z

Armin Rohnen: Armin Rohnen lud eine neue Version von Datei:20251213 EKR-Timing.png hoch

Timing Diagramm

Kommunikation per UART

2025-12-13T13:41:30Z

Armin Rohnen:

= Armin Rohnen, 13.12.2025 Espressomaschinen-Kommunikations-Ring Timing =
[[Datei:20251213 EKR-Timing.png|thumb|1000px|gerahmt|zentriert|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen|EKR Timing Diagramm, (c) Armin Rohnen]]

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Datei:20251213 EKR-Timing.png

2025-12-13T13:39:10Z

Armin Rohnen:

Timing Diagramm

Kommunikation per UART

2025-12-12T08:25:29Z

Armin Rohnen: /* Token Definition */

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung (Befüllungsflag)
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Kommunikation per UART

2025-12-12T07:59:08Z

Armin Rohnen: /* Token Definition */

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Befüllungsflag
|0/1
|True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.

Kommunikation per UART

2025-12-12T07:34:06Z

Armin Rohnen: /* Token Definition */

= Armin Rohnen, 30.11.2025 Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =
Über die Messwertplatine wird der Kommunikationsstart realisiert. Damit dies nicht direkt beim Einschalten erfolgt ist der zugehörige Code in der Datei main_mwp.py abgelegt. Wird diese Datei ausgeführt, dann startet die Kommunikation zwischen den Platinen und im Weiteren erfolgt der Maschinenstart.

Aktuell müssen die Variablen UART_TimeOut, token und uart global definiert werden. Werden diese zu einem späteren Zeitpunkt in main.py initialisiert, dann sind diese automatisch global.

Es wird der Initialtoken mit 75-Bytes angelegt und in Byte[0] wird "0x0A" eingetragen. Sollte es sich ergeben, dass die Tokendefinition noch zu weiteren Bytes führt, dann ist dies an den entsprechenden Stellen der main.py auf den Platinen einzutragen.

Im weiteren Ablauf wird die uart-Schnittstelle initialisiert. In der Datei uart_lib.py ist die Klassendefinition des UARTHandler hinterlegt. Diese konfiguriert die uart-Schnittstelle. Im Konstruktor der Klasse ist hinterlegt, dass per UART.IRQ_RXIDLE auf eingehende Daten an der uart-Schnittstelle ragiert wird. Es wird als erstes die Methode _uart_rx_handler aufgerufen, welche sich innerhalb der Klasse befindet. Darin werden lediglich die Daten eingelsen und auf die Methode on_receive weiterverwiesen. Die Methode on_receive ist in allen Realisierungen gleich und prüft auf empfangene Datenlänge und auf das gültige Startzeichen. Danach wird auf die Methode local_receive weitergeleitet.

Die Methode uart.local_receive aus der Klassendefinition wird durch uart.local_receive = mwp_receive_handler mit der in main_mwp.py befindlichen Funktion ersetzt. Da der zu erwartende Token eingegangen ist, wird als erstes die UART-TimeOut-Funktion deaktiviert. Es wird geprüft, ob die Sicherheitsfunktion aufgerufen werden muss oder ob der Token abgearbeitet werden kann. Handelt es sich bei dem empfangenen Token um den ersten Token, werden aktuell das Default-Kaffeerezept und die Betriebsparameter in den Token eingetragen. Es wid eine Byte-Positionsliste erstellt, an die die Messwerte im Token eingetragen werden sollen und es wird der ADS1115 gestartet, welcher danach das Senden des Token takten wird.

In der Datei mwp_messwerte.py ist die Klassendefinition des ADS1115MuxSampler angelegt. Das ist die Umsetzung als Klassendefinition der bisherigen Messdatenerfassung. Der Konstruktor benötigt den Token, eine Positionslsite für die Byte-Nr. der Messwerte im Token (token_pos_list), das UART-Schnittstellenobjekt, die PIN-Nr über den der ADC-IRQ (irq_pin_nr) eingeht und die Kennziffer für die Abtastrate (smple_rate) des ADCs. 
Wenn der ADC gestartet ist, wird nach jedem erfolgten Sampling der Messwert durch die Methode _sample abgeholt. Es wird lediglich jeder zweite Messwert verwendet, da sich in der Wandlung des ersten Messwerts die Umstellung des Multiplexers befindet und der Messwert damit nicht korrekt sein kann. Gültige Messwerte werden als 2 Bytes im Token an der zugehörigen Position abgelegt und danach wird der nächste Messkanal am Multiplexer eingestellt. Ist der achte Messwert erfasst, wird der Token gesendet und die Abarbeitung startet wieder neu.

Damit der Token über die im Verbund befindlichen Platinen durchgereicht wird existiert ein allgemeingültiges main.py und eine allgemeingültige uart_lib.py. In main.py muss die jeweils gültige Länge des Tokens inkl. aller Sonderbyts wie Startzeichen und Checksumme hinterlegt sein, sonst erfolgt keine Weiterleitung des Token. In der uart_lib.py wird aktuell der Token um 0,1 Sekunde verzägert weiter gesendet. Das ist zum Testen über den ADC-TAkt zu löschen.

= Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation =
Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

[[Datei:20251128 Initialisierung MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen|Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen]]

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

[[Datei:20251128 Programmablauf UART IRQ.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen|Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen]]

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen. 
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR. 
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

[[Datei:20251128 Programmablauf ADC IRQ MWP.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen|Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen]]

Jeder eingehende Token am UART-RX der jeweiligen Platine lösst die Abarbeitung über die ISR aus. Solange Token im Umflauf sind, solange werden auf den einzelnen Platinen Funktionsabarbeitungen erfolgen. Getriggert wird das System durch die Abtastrate des ADCs auf der Messwertplatine. Endlosschleifen in "main.py" und/oder den ISR stören diesen Ablauf und dürfen daher nicht verwendet werden. Allerdings sind Endlosschleifen icht erforderlich, da dies über den im Umlauf befindlichen Token erfolgt.

= Peter Vogginger, 10.11.2025 - Aufgabenanalyse =
Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

== Hardware-Aufbau ==
Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

== Messwerte ==
Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

== Token ==
=== Anzahl ===
Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

=== Struktur ===
Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

=== Prüfsumme ===
Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

=== Standardtoken ===
Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

=== Paniktoken ===
Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.
=== Fehlererkennung ===
Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

== Token Definition ==
{| class="wikitable"
|+ Tabelle 1: Tokeninhalt
|-
! Platine !! Byte-Nr !! Bits / Bit-Nr. !! Beschreibung !! Wertebereich !! Anmerkung
|-
|
|0
|8 Bit
|Startzeichen
|
|0x0A - Standardtoken
|-
| rowspan="15" | Messplatine || 1,2 || 16 Bit || Leitwert || 0,2 - 20 S/cm || rowspan="15" | 16 Bit im Token
dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet.

Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine.

Der Tassenwärmer existiert nur 1x je Machine
|-
| 3,4 || 16 Bit || Boilerdruck || 0,5 - 4,5 V / 0 - 4 bar
|-
| 5,6 || 16 Bit || Brühgruppendruck (1. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 7,8 || 16 Bit || Brühgruppendruck (2. BG) || 0,5 - 4,5 / 0 - 12 bar
|-
| 9,10 || 16 Bit || Wassereingangstemperatur
(ersatzweise Leitungsdruck)
|
|-
| 11,12 || 16 Bit || Boiler-NTC (1. BG) || Kennlinie
|-
| 13,14 || 16 Bit || Boiler-NTC (2. BG) || Kennlinie
|-
| 15,16 || 16 Bit || Tassenwärmer-NTC || Kennlinie
|-
| 17,18 || 16 Bit || Mischtemperatur-NTC (1. BG) || Kennlinie
|-
| 19,20 || 16 Bit || Mischtemperatur-NTC (2. BG) || Kennlinie
|-
| 21,22 || 16 Bit || Brühgruppen-NTC (1. BG) || Kennlinie
|-
| 23,24 || 16 Bit || Brühgruppen-NTC (2. BG) || Kennlinie
|-
| 25,26 || 16 Bit || Boilerheizung (Soll, 1. BG) || 8 Hz PWM 0 - 100 %
|-
| 27,28 || 16 Bit || Boilerheizung (Soll, 2. BG) || 8 Hz PWM 0 - 100 %
|-
| 29,20 || 16 Bit || Tassenwärmerheizung (Soll) || 8 Hz PWM 0 - 100 %
|-
| rowspan="2" | SSR-Platine || 31,32 || 16 Bit || Position Schrittmotor Dosierventil 1. BG || 0 - 550 ||
|-
| 33,34 || 16 Bit || Position Schrittmotor Dosierventil 2. BG || 0 - 550 ||
|-
| rowspan="17" | Basisplatine || 35,36 || 16 Bit || Verstellwert Schrittmotor Dosierventil 1. BG || Integer mit Vorzeichen ||
|-
| 37,38 || 16 Bit || Verstellwert Schrittmotor Dosierventil 2. BG || Integer mit Vorzeichen ||
|-
|39,40
|16 Bit
|Pumpensollwert 1. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|41,42
|16 Bit
|Pumpensollwert 2. BG
|0 - 4096
|entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
|-
|43
|8 Bit
|Durchflussrate 1. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|44,45
|16 Bit
|Durchflusscounts 1. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
|46
|8 Bit
|Durchflussrate 2. BG
|0 - 25 ml/s
|Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
|-
|47,48
|16 Bit
|Durchflusscounts 2. BG
|0 - 65535
|je Count 1/39,9 ml, Überlauf muss unterbunden werden
|-
| rowspan="9" |49
|
|Füllstandsbyte
|
| rowspan="9" |Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet
Füllstand Abtropfschale True verhindert Pumpenansteuerung
Füllstand Boiler False verhindert Pumpenansteuerung
|-
| 0 || Füllstand Boiler 1. BG || 0/1
|-
| 1 || Füllstand Boiler 2. BG || 0/1
|-
| 2 || Füllstand Tank Minimum || 0/1
|-
| 3 || Füllstand Tank Maximum || 0/1
|-
| 4 || Füllstand Abtropfschale || 0/1
|-
| 5 || || 0/1
|-
| 6 || || 0/1
|-
| 7 || || 0/1
|-
| || rowspan="9" | 50 || || Magnetventile Byte 1 || || rowspan="9" | Magnetventile Y101 bis Y113 gehören zur 1. BG
Y113 ist der Dampfhahn
Y214 bis Y222 gehören zur 2. BG
|-
| || 0 || Y101 || 0/1
|-
| || 1 || Y102 || 0/1
|-
| || 2 || Y103 || 0/1
|-
| || 3 || Y104 || 0/1
|-
| || 4 || Y105 || 0/1
|-
| || 5 || Y106 || 0/1
|-
| || 6 || Y107 || 0/1
|-
|
|7
|Y108
|0/1
|-
|
| rowspan="9" |51
|
|Magnetventil Byte 2
|
| rowspan="9" |
|-
|
|0
|Y109
|0/1
|-
|
|1
|Y110
|0/1
|-
|
|2
|Y111
|0/1
|-
|
|3
|Y112
|0/1
|-
|
|4
|Y113
|0/1
|-
|
|5
|Y214
|0/1
|-
|
|6
|Y215
|0/1
|-
|
|7
|Y216
|0/1
|-
|
| rowspan="9" |52
|
|Magnetventil Byte 3
|
| rowspan="9" |
|-
|
|0
|Y217
|0/1
|-
|
|1
|Y218
|0/1
|-
|
|2
|Y219
|0/1
|-
|
|3
|Y220
|0/1
|-
|
|4
|Y221
|0/1
|-
|
|5
|Y222
|0/1
|-
|
|6
|
|0/1
|-
|
|7
|
|0/1
|-
|Displayplatine
|53,54
|16
|Bezugswassertemperatur 1. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|55,56
|16
|Bezugswassertemperatur 2. BG
|30 - 98 °C
|Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
|-
|
|57,58
|16
|Bezugsmenge 1. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|59,60
|16
|Bezugsmenge 2. BG
|20 - 300 g bzw. ml
|Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
|-
|
|61,62
|16
|Bezugszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|63,64
|16
|Bezugszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|65,66
|16
|Preinfusionszeit 1. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|67,68
|16
|Preinfusionszeit 2. BG
|0 - 120 Sekunden
|Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
|-
|
|69
|8
|Abschalttemperatur Entschichtung
|90 - 98 °C
|Integerwert in °C
|-
|
|70
|8
|Grenztemperatur
|135 - 150 °C
|Integerwert in °C
|-
|
|71
|8
|Sollwert Boilerdruck
|1100 - 1500 mbar
|Integerwert in 10 mbar, damit Wertebereich 110 bis 150
|-
|
|72
|8
|Stellung Vertikalhebel
|0 - 180 Grad
|Integerwert
|-
|
|
|
|
|
|
|-
|
| rowspan="9" |73
|
|Maschinenstatus Byte 1
|
|
|-
|
|0
|Mischerstatus 1. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|1
|Mischerstatus 2. BG
|0/1
|True = Mischtemperatur erreicht
|-
|
|2
|Entschichtung
|0/1
|True = Entschichtung aktiv
|-
|
|3
|Handhebelmodus
|0/1
|True = aktiv
|-
|
|4
|Rezepteingabe
|0/1
|True = aktiv
|-
|
|5
|Wartungsmodus
|0/1
|True = aktiv
|-
|
|6
|Schrittmotor Dosierventil Flag
|0/1
|True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
|-
|
|7
|
|0/1
|
|-
|
| rowspan="9" |74
|
|Maschinenstatus Byte 2
|
|
|-
|
|0
|Kaffeebezug 1. BG
|0/1
|
|-
|
|1
|Kaffeebezug 1. BG
|0/1
|
|-
|
|2
|Teewasserbezug
|0/1
|
|-
|
|3
|Dampfbezug
|0/1
|Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
|-
|
|4
|Boilerbefüllung
|0/1
|Befüllungsflag, True = Boilerbefüllung aktiv
|-
|
|5
|Aufheizen
|0/1
|True = Aufheizphase, False = Betriebsbereit
|-
|
|6
|Systemstart
|0/1
|True = Systemstart
|-
|
|7
|Sicherheitsfunktion
|0/1
|True = Sicherheitsfunktion aktiv
|}
= Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2 =
Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:
* weniger Elektronik in der Peripherie
* ADCs ausreichend am Board
* DACs ausreichend am Board
* 8 serielle Schnittstellen
* viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

= Armin Rohnen, 16.10.2025 =
Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

= Armin Rohnen, 11.04.2024 =
[[Datei:20250322 Konzept.png|thumb|900px|gerahmt|zentriert|alternativtext=Armin Rohnen, Kommunikationskonzept mit Token|Armin Rohnen, Kommunikationskonzept mit Token]]
Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.