Kommunikation per UART - Versionsgeschichte

Peter Vogginger am 13. Februar 2026 um 18:38 Uhr

2026-02-13T18:38:50Z

← Nächstältere Version		Version vom 13. Februar 2026, 20:38 Uhr
Zeile 6:		Zeile 6:
	einmal das Setzen eines Bits auf 1 und das Löschen eines Bits. Letzteres meint das Setzen eines		einmal das Setzen eines Bits auf 1 und das Löschen eines Bits. Letzteres meint das Setzen eines
	Bits auf 0.		Bits auf 0.
			=== set_bit ===
	Zum Setzen einzelner Bits (siehe linke Grafik in der Abbildung 4) wird zunächst aus dem Bitindex		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 <<		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		bit_index). Durch eine OR-Verknüpfung des Bytes mit dieser Maske wird das betreffende Bit
	zuverlässig auf den Wert 1 gesetzt.		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		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		invertiert und das Byte anschließend mit einer AND-Verknüpfung verarbeitet. Dadurch wird das
Zeile 17:		Zeile 17:
	gewünschte Bit, alle anderen Bits im Byte bleiben unverändert.		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		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		entsprechende Byte um den Bitindex nach rechts verschoben und anschließend mit 1 maskiert
Zeile 23:		Zeile 24:
	Setter und Getter verwendet.		Setter und Getter verwendet.

	Beim Schreiben von Bytes (siehe vierte Grafik von links in der Abbildung 4) wird der Integerwert		=== 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		im Big-Endian-Format in zwei Bytes umgewandelt und an der vorgesehenen Position im
	Bytearray gespeichert.		Bytearray gespeichert.
Zeile 33:		Zeile 39:
	dieselbe Endianess verwenden, sonst entstehen falsche Werte.		dieselbe Endianess verwenden, sonst entstehen falsche Werte.

			=== get_bytes ===
	Das Auslesen von Bytes (siehe rechte Grafik in der Abbildung 4) erfolgt durch Entnehmen von		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		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		dasselbe Format Big-Endian verwenden, wird der Messwert exakt so zurückgegeben, wie er
	zuvor gespeichert wurde.		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. <br />		Die genannten fünf Funktionen werden in die Datei utils.py geschrieben. Diese Datei wird auf jeder Platine hinterlegt. <br />
	Beispielaufruf: utils.set_bytes(token, ort, wert)		Beispielaufruf: utils.set_bytes(token, ort, wert)

	[[Datei:Setter Getter.png\|thumb\|1000px\|gerahmt\|zentriert\|alternativtext=Funktionsablauf Setter und Getter, (c) Peter Vogginger\|Funktionsablauf Setter und Getter, (c) Peter Vogginger]]		[[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<br>Espressomaschinen-Kommunikations-Ring Timing =		= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =

Peter Vogginger: /* Peter Vogginger, 18.12.2025 Setter und Getter für Bits und Bytes */

2026-01-08T13:41:23Z

Peter Vogginger, 18.12.2025 Setter und Getter für Bits und Bytes

← Nächstältere Version		Version vom 8. Januar 2026, 15:41 Uhr
Zeile 1:		Zeile 1:
	= Peter Vogginger, 18.12.2025<br> Setter und Getter für Bits und Bytes =		= Peter Vogginger, 18.12.2025<br> Setter und Getter für Bits und Bytes =
	~~Dokumentation Setter / Getter~~
	Beim Arbeiten mit binären Daten ist der Einsatz von Setter- und Getter-Funktionen sinnvoll, da		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		sie den Code übersichtlicher machen und Fehler durch direkte Bit- oder Bytemanipulation

Peter Vogginger am 8. Januar 2026 um 13:40 Uhr

2026-01-08T13:40:41Z

← Nächstältere Version		Version vom 8. Januar 2026, 15:40 Uhr
Zeile 41:		Zeile 41:
	Die genannten fünf Funktionen werden in die Datei utils.py geschrieben. Diese Datei wird auf jeder Platine hinterlegt. <br />		Die genannten fünf Funktionen werden in die Datei utils.py geschrieben. Diese Datei wird auf jeder Platine hinterlegt. <br />
	Beispielaufruf: utils.set_bytes(token, ort, wert)		Beispielaufruf: utils.set_bytes(token, ort, wert)

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

	= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =		= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =

Peter Vogginger am 18. Dezember 2025 um 13:22 Uhr

2025-12-18T13:22:03Z

← Nächstältere Version		Version vom 18. Dezember 2025, 15:22 Uhr
Zeile 1:		Zeile 1:
			= Peter Vogginger, 18.12.2025<br> Setter und Getter für Bits und Bytes =
			Dokumentation Setter / Getter
			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.

			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.

			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.

			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.

			Beim Schreiben von Bytes (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.

			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.

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

	= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =		= Armin Rohnen, 13.12.2025<br>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]]		[[Datei:20251213 EKR-Timing.png\|thumb\|1000px\|gerahmt\|zentriert\|alternativtext=EKR Timing Diagramm, (c) Armin Rohnen\|EKR Timing Diagramm, (c) Armin Rohnen]]

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

2025-12-13T14:19:27Z

Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing

← Nächstältere Version		Version vom 13. Dezember 2025, 16:19 Uhr
Zeile 5:		Zeile 5:
	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.		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.		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.		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.		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<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =		= Armin Rohnen, 30.11.2025<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =

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

2025-12-13T14:15:29Z

Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing

← Nächstältere Version		Version vom 13. Dezember 2025, 16:15 Uhr
Zeile 9:		Zeile 9:
	Da eine Summenrechenzeit von 5,8 ms sehr knapp ist, ist zu prüfen, ob der Betrieb in maximaler ADC-Abtastrat emöglich ist.		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.		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<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =		= Armin Rohnen, 30.11.2025<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =

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

2025-12-13T14:11:34Z

Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing

← Nächstältere Version		Version vom 13. Dezember 2025, 16:11 Uhr
Zeile 1:		Zeile 1:
	= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =		= Armin Rohnen, 13.12.2025<br>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]]		[[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~~.		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.		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<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =		= Armin Rohnen, 30.11.2025<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =

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

2025-12-13T13:52:57Z

Armin Rohnen, 13.12.2025Espressomaschinen-Kommunikations-Ring Timing

← Nächstältere Version		Version vom 13. Dezember 2025, 15:52 Uhr
Zeile 1:		Zeile 1:
	= Armin Rohnen, 13.12.2025<br>Espressomaschinen-Kommunikations-Ring Timing =		= Armin Rohnen, 13.12.2025<br>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]]		[[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<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =		= Armin Rohnen, 30.11.2025<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =

Armin Rohnen am 13. Dezember 2025 um 13:41 Uhr

2025-12-13T13:41:30Z

← Nächstältere Version		Version vom 13. Dezember 2025, 15:41 Uhr
Zeile 1:		Zeile 1:
			= Armin Rohnen, 13.12.2025<br>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<br> Kommunikationsstart und kontinuierliches Sendendes Token im ADC Takt der Messwertplatine =		= Armin Rohnen, 30.11.2025<br> 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.		Ü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.

Armin Rohnen: /* Token Definition */

2025-12-12T08:25:29Z

Token Definition

← Nächstältere Version		Version vom 12. Dezember 2025, 10:25 Uhr
Zeile 481:		Zeile 481:
	\|		\|
	\|4		\|4
	\|Befüllungsflag		\|Boilerbefüllung (Befüllungsflag)
	\|0/1		\|0/1
	\|True = Boilerbefüllung aktiv		\|True = Boilerbefüllung aktiv