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

Kommunikation per UART

2026-02-13T18:38:50Z

Peter Vogginger:

= Peter Vogginger, 18.12.2025 Setter und Getter für Bits und Bytes =
Beim Arbeiten mit binären Daten ist der Einsatz von Setter- und Getter-Funktionen sinnvoll, da
sie den Code übersichtlicher machen und Fehler durch direkte Bit- oder Bytemanipulation
vermeiden. Ein Setter verändert einen Wert in einem Bytearray, während ein Getter einen
bestehenden Wert ausliest. Der Setter wird bei Bits in Form von zwei Funktionen beschrieben,
einmal das Setzen eines Bits auf 1 und das Löschen eines Bits. Letzteres meint das Setzen eines
Bits auf 0.
=== set_bit ===
Zum Setzen einzelner Bits (siehe linke Grafik in der Abbildung 4) wird zunächst aus dem Bitindex
eine Bitmaske erzeugt, indem der Wert 1 entsprechend nach links verschoben wird (1 <<
bit_index). Durch eine OR-Verknüpfung des Bytes mit dieser Maske wird das betreffende Bit
zuverlässig auf den Wert 1 gesetzt.
=== clear_bit ===
Zum Löschen eines Bits (siehe zweite Grafik von links in der Abbildung 4) wird dieselbe Maske
invertiert und das Byte anschließend mit einer AND-Verknüpfung verarbeitet. Dadurch wird das
Zielbit sicher auf den Wert 0 gesetzt. Beide Operationen verändern ausschließlich das
gewünschte Bit, alle anderen Bits im Byte bleiben unverändert.

=== get_bit ===
Das Auslesen eines Bits (siehe mittlere Grafik in der Abbildung 4) erfolgt, indem das
entsprechende Byte um den Bitindex nach rechts verschoben und anschließend mit 1 maskiert
wird. Auf diese Weise wird das Zielbit isoliert und als Wert 0 oder 1 zurückgegeben.
Für die Verarbeitung ganzer Messwerte, die aus ein oder zwei Bytes bestehen, werden ebenfalls
Setter und Getter verwendet.

=== sync_bit ===
Das Synchronisieren eines Bits (siehe linke Grafik in Abbildung 5) erfolgt, indem zunächst das entsprechende Bit aus dem Token ausgelesen und mit dem gemessenen Zustand verglichen wird. Stimmen beide Werte nicht überein, wird das Bit im Token entsprechend dem gemessenen Zustand gesetzt oder gelöscht. Ist der Wert bereits identisch, erfolgt keine Änderung.
Auf diese Weise wird sichergestellt, dass der im Token gespeicherte Zustand jederzeit dem realen Messwert entspricht, ohne unnötige Schreibzugriffe durchzuführen.

=== set_bytes ===
Beim Schreiben von Bytes in den Token (siehe vierte Grafik von links in der Abbildung 4) wird der Integerwert
im Big-Endian-Format in zwei Bytes umgewandelt und an der vorgesehenen Position im
Bytearray gespeichert.

Big-Endian-Format bedeutet, dass bei mehrbyteigen Werten das höherwertige Byte (MSB) zuerst
gespeichert oder übertragen wird, gefolgt vom niederwertigen Byte (LSB). Im Gegensatz dazu
gibt es noch das Format Little-Endian. Hierbei ist die Reihenfolge genau umgekehrt, das
niederwertiges Byte wird zuerst übertragen. Entscheidend ist, dass Sender und Empfänger
dieselbe Endianess verwenden, sonst entstehen falsche Werte.

=== get_bytes ===
Das Auslesen von Bytes (siehe rechte Grafik in der Abbildung 4) erfolgt durch Entnehmen von
einem (oder zwei Bytes) und deren Rückwandlung in einen Integer. Da beide Funktionen
dasselbe Format Big-Endian verwenden, wird der Messwert exakt so zurückgegeben, wie er
zuvor gespeichert wurde.

=== get_signed_bytes ===
Das Auslesen eines vorzeichenbehafteten 16-Bit-Wertes (siehe mittlere Grafik in der Abbildung 5) erfolgt, indem zunächst zwei aufeinanderfolgende Bytes aus dem Token entnommen und zu einem 16-Bit-Ganzzahlwert zusammengesetzt werden. Hierzu wird das höherwertige Byte um acht Bit nach links verschoben und anschließend mit dem niederwertigen Byte logisch verknüpft.

Anschließend wird geprüft, ob das höchstwertige Bit (Bit 15) gesetzt ist. Dieses Bit stellt im Zweierkomplement das Vorzeichenbit dar. Ist es gesetzt, wird vom berechneten Wert 2^16 (0x10000) subtrahiert, um die korrekte negative Ganzzahl zu erhalten.
Auf diese Weise wird ein im Token gespeicherter 16-Bit-Wert unabhängig von seiner internen Byte-Darstellung korrekt als signed Integer interpretiert. Dieser aufwendige Code ist nötig, da in MicroPython die Anweisung int.from_bytes(two_bytes, 'big') keinen zusätzlichen Parameter signed hat. Dies gilt auch für den folgenden Getter.

===set_signed_bytes ===
Das Speichern eines vorzeichenbehafteten 16-Bit-Wertes (siehe rechte Grafik in der Abbildung 5) erfolgt durch Zerlegung des Integerwertes in zwei einzelne Bytes. Hierzu wird zunächst das höherwertige Byte ermittelt, indem der Wert um acht Bit nach rechts verschoben wird. Durch anschließendes Maskieren mit 0xFF werden ausschließlich die unteren acht Bit übernommen. Dieses Byte wird an der angegebenen Startposition im Token gespeichert.
Anschließend wird das niederwertige Byte bestimmt, indem der Wert direkt mit 0xFF maskiert wird. Auch hier werden nur die unteren acht Bit berücksichtigt. Dieses Byte wird an der darauffolgenden Position im Token abgelegt.

Die genannten fünf Funktionen werden in die Datei utils.py geschrieben. Diese Datei wird auf jeder Platine hinterlegt. 
Beispielaufruf: utils.set_bytes(token, ort, wert)

[[Datei:Setter Getter.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abbildung 4: Funktionsablauf Setter und Getter Teil 1, (c) Peter Vogginger|Abbildung 4: Funktionsablauf Setter und Getter Teil 1, (c) Peter Vogginger]]

[[Datei:20260213 Flussdiagramm Setter Getter 2.png|thumb|1000px|gerahmt|zentriert|alternativtext=Abbildung 5: Funktionsablauf Setter und Getter Teil 2, (c) Peter Vogginger|Abbildung 5: Funktionsablauf Setter und Getter Teil 2, (c) Peter Vogginger]]

= 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.

Systemsoftware

2026-02-03T17:08:27Z

Peter Vogginger: /* 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: 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 - 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: 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-01-27T13:05:53Z

Peter Vogginger: /* 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: 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 - 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 || 29.01.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Peter Vogginger|| 1 || 30 ||05.02.2026
|-
| [[Startprozedur]]
|Philipp Schiebel
|1
|30
|22.01.2026
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 30 || 15.01.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine]] || Philipp Schiebel|| 1 || 30 || 22.01.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 10 || 29.01.2026
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard]] || Philipp Schiebel|| 1 || 10 || 29.01.2026
|-
| [[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 ||15.01.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: 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 ||
|-
| || || || ||
|}

Mehrkernnutzung und/oder Multitasking

2026-01-15T13:06:49Z

Peter Vogginger:

2025-10-19T09:26:41Z

Peter Vogginger: /* Peter Vogginger, xx.10.2025 - NUCLEO_H743ZI2 */

= 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.

== Definition der Token ==

{| class="wikitable"
|+ Text der Überschrift
|-
! Byte !! Token 1 !! Token 2 !! Token 3 !! Token 4
!Token 5
!Token 6
|-
| 0 || Messwerttoken BG 1 || Stelllgrößentoken BG 1 || Messwerttoken BG 2 || Stelllgrößentoken BG 2
|Messwerttoken BG 3
|Stelllgrößentoken BG 3
|-
| 1 (Highbyte) || Leitwert || Magnetventil 9-16 || ||
|
|
|-
| 2 (Lowbyte) || Leitwert || Magnetventil 1-8 || ||
|
|
|-
| 3 (Highbyte) || Boilerdruck || Sollwert Flowrate || ||
|
|
|-
| 4 (Lowbyte) || Boilerdruck || Sollwert Flowrate || ||
|
|
|-
| 5 (Highbyte) || Brühgruppendruck || Stellwert Pumpe || ||
|
|
|-
| 6 (Lowbyte) || Brühgruppendruck || Stellwert Pumpe || ||
|
|
|-
| 7 (Highbyte) || Leitungsdruck || Mischer T-Soll || ||
|
|
|-
| 8 (Lowbyte) || Leitungsdruck || Mischer T-Soll || ||
|
|
|-
| 9 (Highbyte) || T-Boiler || Stellwert Dosierventil || ||
|
|
|-
| 10 (Lowbyte) || T-Boiler || Stellwert Dosierventil || ||
|
|
|-
| 11 (Highbyte) || T-Tassen || Sollwert Boilerdruck || ||
|
|
|-
| 12 (Lowbyte) || T-Tassen || Sollwert Boilerdruck || ||
|
|
|-
| 13 (Highbyte) || T-Mischer || Stellwert Heizung || ||
|
|
|-
| 14 (Lowbyte) || T-Mischer || Stellwert Heizung || ||
|
|
|-
| 15 (Highbyte) || T-Brühgruppe || Sollwert Tassenwärmer || ||
|
|
|-
| 16 (Lowbyte) || T-Brühgruppe || Sollwert Tassenwärmer || ||
|
|
|-
| 17 (Highbyte) || inc. Flowmeter || Stellwert Tassenwärmer || ||
|
|
|-
| 18 (Lowbyte) || inc. Flowmeter || Stellwert Tassenwärmer || ||
|
|
|-
| 19 (Highbyte) || Flowrate || || ||
|
|
|-
| 20 (Lowbyte) || Flowrate || || ||
|
|
|-
| 21 (Highbyte) || || || ||
|
|
|-
| 22 (Lowbyte) || || || ||
|
|
|-
| 23 (Highbyte) || || || ||
|
|
|-
| 24 (Lowbyte) || || || ||
|
|
|-
| 25 (Highbyte) || || || ||
|
|
|-
| 26 (Lowbyte) || || || ||
|
|
|-
|27 (Highbyte)
|
|
|
|
|
|
|-
|28 (Lowbyte)
|
|
|
|
|
|
|-
|29 (Highbyte)
|
|
|
|
|
|
|-
|30 (Lowbyte)
|
|
|
|
|
|
|-
|31 (Highbyte)
|
|
|
|
|
|
|-
|(Lowbyte)
|
|
|
|
|
|
|}