Uhrzeit- und Pausensteuerung Beckhoff

Zuviel Werbung?
-> Hier kostenlos registrieren
// Die Berechnung des Datums für die Zeitumstellung des aktuellen Jahres ist Abhängig vom Vorjahr -> "GVL.stSystemTime.wYear -1"
Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.

Es ist ungünstig, die Systemuhr zu verstellen. Denn dann muß man sich zusätzlich zuverlässig merken ob schon umgestellt wurde und weitere Umstellungen unterdrücken. Üblicherweise läßt man die Systemuhr einfach immer in Winterzeit (oder noch besser: in UTC) laufen und rechnet dann die Systemzeit in die aktuell richtige Lokalzeit um (je nach Zeitpunkt 0 oder 1 oder 2 Stunden addieren).
Wenn man die Systemuhr mit einem NTP-Server synchronisieren will, dann muß bzw. wird sogar die Systemuhr immer in UTC laufen. Zusätzliches Verstellen der Systemuhr hat dann keinen Bestand und wird immer wieder rückgängig gemacht.

Harald
 
Du holst dir die Minuten aus dem Struct der Systemzeit, warum nicht auch die Stunden? Windows kennt von Kindesbeinen an die Zeitumstellung, da braucht man sich eigentlich nicht drum kümmern.
Deine Minutenpulse kannst du immer schicken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig???
Sie ist vom aktuellen Jahr abhängig (und damit "indirekt" natürlich auch vom Vorjahr).
Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
Mein Ansatz, müsste ich auf irgendwelche Hilfen vom "SystemFunktionen" verzichten, wäre genau durch den WochenTag Sonntag inspiriert, nämlich einen speziellen, den OsterSonntag. Dafür gibt es Formeln/Lösungswege - habe ich vor Jahrenden schonmal in Excel durchexerziert, habe die Lösung aber jetzt nicht parat *). Auf dem Umwege über OsterSonntag dürfte sich relativ leicht das Datum des letzten Sonntags im März und Oktober ermitteln lassen.
Ich vermute mal, dass die Formeln entweder zur Ermittlung des Wochentages bzw. zur Ermittlung des OsterSonntags vielleicht irgendwo "aktuelle JahresZahl minus eins" enthalten.
Deine Minutenpulse kannst du immer schicken.
Das hatten wir eigentlich schon geklärt, dass nur "fast immer" richtig ist. Aber nicht in der Stunde, nach der die Uhr 1 Stunde zurückgestellt werden soll.

PS:
*) Doch, in einem geordneten Haushalt geht nix verloren. Konnte die VBA-Routine tatsächlich wiederfinden:
Code:
Function Ostern(ByVal Jahr As Integer) As Date
    Dim ZR1, ZR2, ZR3, ZR4, ZR5, ZR6, ZR7 As Integer
    ZR1 = Jahr Mod 19 + 1: ZR2 = Int(Jahr / 100) + 1
    ZR3 = Int(3 * ZR2 / 4) - 12: ZR4 = Int((8 * ZR2 + 5) / 25) - 5
    ZR5 = Int(5 * Jahr / 4) - ZR3 - 10: ZR6 = (11 * ZR1 + 20 + ZR4 - ZR3) Mod 30
    If (ZR6 = 25 And ZR1 > 11) Or ZR6 = 24 Then ZR6 = ZR6 + 1
    ZR7 = 44 - ZR6
    If ZR7 < 21 Then ZR7 = ZR7 + 30
      ZR7 = ZR7 + 7
    ZR7 = ZR7 - (ZR5 + ZR7) Mod 7
    If ZR7 <= 31 Then
      Ostern = DateSerial(Jahr, 3, ZR7)
    Else
      Ostern = DateSerial(Jahr, 4, ZR7 - 31)
    End If
End Function
 
Zuletzt bearbeitet:
Hmm, der Ostersonntag liegt meistens nach dem letzten Sonntag im März, manchmal aber auch davor - und trotzdem kann man vom Ostersonntag ausgehend den letzten Sonntag im März berechnen??? :unsure:

Harald
 
Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
Mit der angewendeten Formel und dem aktuellen Jahr berechne ich mir den Tag (27., 28.,...) für die Zeitumstellung des darauffolgenden Jahres. Demnach nutze ich das Vorjahr um den Tag der Zeitumstellung für das aktuelle Jahr zu berechnen. Deswegen auch Aktuelles Jahr -1.
Es ist ungünstig, die Systemuhr zu verstellen.
Kann natürlich sein, dass ich gerade gewaltig auf dem Schlauch stehe, aber eigentlich verstelle ich die Systemzeit gar nicht, sondern filtere mir nur daraus das aktuelle Jahr um die Daten für die Zeitumstellungen zu ermitteln. Diese vergleiche ich mit der Systemzeit und reagiere je nach Umstellung entsprechend.
Du holst dir die Minuten aus dem Struct der Systemzeit, warum nicht auch die Stunden? Windows kennt von Kindesbeinen an die Zeitumstellung, da braucht man sich eigentlich nicht drum kümmern.
Da ich nur Minutenimpulse benötige sind für mich die Stunden doch uninteressant, oder sehe ich das falsch?
Das hatten wir eigentlich schon geklärt, dass nur "fast immer" richtig ist. Aber nicht in der Stunde, nach der die Uhr 1 Stunde zurückgestellt werden soll.
Genau.


Vielen lieben Dank für eure Unterstützung.
Gruß
Michi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmm, der Ostersonntag liegt meistens nach dem letzten Sonntag im März, manchmal aber auch davor - und trotzdem kann man vom Ostersonntag ausgehend den letzten Sonntag im März berechnen??? :unsure:
Ja, sicher. Und solange sowohl der OsterSonntag als auch der letzte Sonntag im März nach dem potenziellen Störer (Schaltag, 29. Februar) stattfinden, muss man sich nicht einmal um das Thema SchaltJahr kümmern - das tut schon die Berechnung des OsterSonntags! ;)

Nachtrag:
Code:
dws = OsterSo + INT((31_Mrz - OsterSo) / 7) * 7 ' WxlTag (Winter->Sommer)

dsw = OsterSo + INT((31_Okt - OsterSo) / 7) * 7 ' WxlTag (Sommer->Winter)

' Wobei ...
' OsterSo : Datum des OsterSonntags im aktuellen Jahr (s. 'PS' in Beitrag #23)
' 31_Mrz  : Datum des 31. Mrz im aktuellen Jahr
' 31_Okt  : Datum des 31. Okt im aktuellen Jahr

' Gilt auch für das 'PS' in Beitrag #23:
' In SCL und ST dürfte das INT überflüssig sein, da ein INT-Ergebnis einer Division immer nur ab- und nie aufgerundet wird.
' Aber: Vorsicht, der Compiler könnte/dürfte die Division durch 7 mit der anschliessenden Multiplikation mit 7 "zusammenfassen" (= schlabbern)!
' Vorsichtshalber das DivisionsErgebnis einer INT-HilfsVariable zuweisen und mit dieser HilfsVariable weiterrechnen.
 
Zuletzt bearbeitet:
Die Minuten ticken doch sowohl in der Stunde vor der Zeitumstellung, als auch danach. Wenn sich der Wert der Stunde alle 60 Minuten ändert, kannst du ihn übernehmen. Zum Zeitpunkt der Zeitumstellung im März ändert sich der Wert der Stunde von 1 auf 3 -> 1:59 ..3:00, und im Oktober schaltet die Uhr von 2:59 auf 2:00, also ändert sich dort der Wert der Stunde nicht.
Wenn du also immer dann, wenn die Minute auf 00 steht, den Stundenwert übernimmst, hast du nie ein Problem mit der Zeitumstellung und du kannst diesen Wert auch an alle nachgeordneten Clients weitergeben.
Nochmal: Solange die Systemzeit korrekt ist, brauchst du dir um die Zeitumstellung in TwinCat keine Sorgen machen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
Mit der angewendeten Formel und dem aktuellen Jahr berechne ich mir den Tag (27., 28.,...) für die Zeitumstellung des darauffolgenden Jahres. Demnach nutze ich das Vorjahr um den Tag der Zeitumstellung für das aktuelle Jahr zu berechnen. Deswegen auch Aktuelles Jahr -1.
Ich glaube nicht, daß in der Formel der Ausdruck "Jahr - 1" das Vorjahr meint, sondern einfach für die Verschiebung des Ergebnisses der Division und des (0-basierten) MOD um 1 Tag nötig ist. Genauso, wie wenn man ein 0-basiertes Array [0..30] für jeden Tag eines Monats hat und den Index in das Array aus "Tag - 1" berechnet. Da meint "Tag - 1" auch nicht "Gestern" oder einen Tag des Vormonats.


eigentlich verstelle ich die Systemzeit gar nicht
OK, ich hatte den Code nur oberflächlich überflogen und fälschlicherweise angenommen, daß da die Uhr verstellt wird. Vor allem, weil beim Rückstellen zur Winterzeit etwas extra für 1 Stunde unterdrückt wird, was bei Berechnung aus einer nicht verstellten Uhr eigentlich nicht nötig sein sollte.

Harald
 
Vielen Dank für euer Feedback. Ich werde versuchen den Code anzupassen und zu verbessern.

Vielleicht ist es dennoch sinnvoll meine Gedankengänge noch einmal kurz aufzuführen:

Minutenimpulse:
  • Mithilfe des von Beckhoff gestellten Funktionsbausteins FB_LocalSystemTime (Link) hole ich mir die lokale Windows-Systemzeit
  • Aus dieser filtere ich die Minuten heraus und vergleiche die "aktuellen" Minuten mit den "alten" Minuten. Daraus ergeben sich die benötigten Minutenimpulse für die Uhren
Zeitumstellung:
  • Berechnung des Datums der Zeitumstellung für das aktuelle Jahr
  • Vergleich des berechneten Datums mit der Systemzeit. Salopp gesagt: Damit die Uhren wissen, wann eine Zeitumstellung stattfindet
  • Je nach Umstellung werden entweder zusätzlich 60 Impulse an die Uhren weitergegeben (W -> S) oder das Weitergeben der Minutenimpulse für eine Stunde unterbunden (S -> W)

Gruß
Michi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
im Falle eines Stromausfalls sollen die Uhren nachgetaktet werden. Dazu muss man natürlich wissen wie lange ein Stromausfall vorlag. Wie geht man mit diesem Problem am Besten um?
Ich habe mir dazu folgende Gedanken gemacht:
  • Ich speichere die Systemzeit persistent in einer Variable ab
  • Nach dem Stromausfall und dem Neustart wird diese dann mit der aktuellen Systemzeit verglichen
  • Aus der sich ergebenden Differenz werden die fehlenden Impulse berechnet und in eine Variable gespeichert
  • Diese werden dann über einen Abwärtszähler abgefrühstückt
Geht der Grundgedanke schon in die richtige Richtung oder wird dies in der Regel anders umgesetzt?

Wie kann die konkrete Uhrzeit und das Datum unmittelbar nach dem Neustart aus der Systemzeit entnommen werden? Die Uhr läuft nun mal weiter, wodurch auch die Differenz ständig größer wird.
Ein weiteres Problem womit ich zu kämpfen habe, ist das Konvertieren vom Format Date and Time zum Word für den Zähler des CTD. Ergibt es eventuell mehr Sinn, das in eine anderes Format zu überführen?

Vorab vielen Dank.

Gruß
Michi
 
In dieser Richtung, einen "Zähler" zu verwenden, hatte ich auch schon tendiert - jedenfalls um die Phänomene beim Wechsel von W->S bzw. S->W aufzufangen bzw. zu "puffern". Ein weiteres Phänomen, nämlich ein StromAusfall - so finde ich - lässt sich gut in dieses Konzept integrieren.
Der Aufwand hierfür beschränkt sich eigentlich darauf, zu ermitteln, wie viele Impulse nachzuliefern sind. Die Abarbeitung der Impulse wäre, dann schon erledigt, weil identisch mit dem Vorstellen der Uhr beim Wechsel W->S.
Das Unterdrücken der Impulse beim Wechsel S->W hatte ich mir so vorgestellt, dass der Zähler im negativen Bereich arbeitet.
D.h., der Zähler wird statt beim "normalen" Minuten-Impuls um 1 erhöht und statt beim Wxl S->W um 61 erhöht zu werden, beim Wxl W->S um 59 vermindert.
Die Auswertung des Zählers und die (Nicht-)Umsetzung in reale Impulse an die Uhren sieht dann so aus:
- ist der Zählerstand <= 0, so passiert nichts
- ist der Zählerstand > 0, so wird 1 Impuls ausgegeben und der Zähler um 1 dekrementiert.
Für den Fall, dass der Zählerstand > 1 ist, muss natürlich dafür gesorgt werden, dass die ImpulsFolge entspechend einem "speziellen" Takt erfolgt.

Allerdings neige ich dazu, weder CTU noch CTD zu verwenden, sondern eine "stinknormale", aber statische INT-Variable.

D&T? Weiss ich nicht. Stelle mir vor, dass die "Datümer" (letzter Sonntag im Mrz und Okt) nicht in jedem Zyklus berechnet werden, aber natürlich ständig zum Vergleich mit dem aktuellen Datum zur Verfügung stehen müssen. Ferner denke ich, dass die Zeit in einer Form zur Verfügung steht, die ein Vielfaches von s oder ms oder µs oder ns darstellt.
Du benötigst
- die Stunde 2 für die Wxl W->S und S->W
- die Minute bei jedem Wxl der Minute
- z.B. einen 0,5 Hz Takt zum Aufholen der "geschlabberten" Minuten-Impulse.
Die Stunden, Minuten und Sekunden lassen sich Leicht per Division und MOD aus z.B. einem Vielfachen von ms isolieren.

So in etwa hatte ich mir das gedacht (noch recht rudimentär, gänzlich ungetestet und ohne StromAusfallBerücksichtigung):
Code:
// Pulse vorbereiten
tbSecond0 := tiSecond = 0 ;
tbHour2 := tiHour = 2 ;
IF sbSecond0Prev OR NOT tbSecond0 THEN
    ; // wenn nicht positive Flanke der Sekunde: nichts tun
ELSIF sbHour2Prev OR NOT tbHour2 THEN
    PulseCounter := PulseCounter + 1 ;  // 1 min vor, normaler Impuls, wenn nicht Beginn der "magischen" Stunde
ELSIF tdateChgWin2Sum = actualDate THEN
    PulseCounter := PulseCounter + 61 ; // 1 min vor und 1 h vor
ELSIF tdateChgSum2Win = actualDate THEN
    PulseCounter := PulseCounter - 59 ; // 1 min vor und 1 h zurück
ELSE
    PulseCounter := PulseCounter + 1 ;  // 1 min vor, normaler Impuls, wenn Beginn der "magische" Stunde, aber kein Wxl-Datum
END_IF ;
sbSecond0Prev := tbSecond0 ; // für FlankenErkennung
sbHour2Prev := tbHour2 ; // für FlankenErkennung

// Pulse ausgeben bzw. unterdrücken
tbClock := ( tiSecond MOD 2 ) = 0 ; // für z.B. tbClock 0,5 Hz

output_pulse := output_pulse AND tbClock ; // Rücksetzen des Ausgabe-Impulses
IF sbClockPrev OR NOT tbClock THEN
    ; // wenn nicht positive Flanke des AusgabeTaktes: nichts tun
ELSIF PulseCounter <= 0 THEN
    ; // wenn ZählerStand <= 0: nichts tun
ELSE                                             
    output_pulse = TRUE ; // wenn Zählerstand > 0: Impuls setzen und Zähler dekrementieren
    PulseCounter := PulseCounter - 1 ;
ENDIF ;
sbClockPrev := tbClock ; // für FlankenErkennung
 
Vielen Dank für die ausführliche Erläuterung!
Der Aufwand hierfür beschränkt sich eigentlich darauf, zu ermitteln, wie viele Impulse nachzuliefern sind.
Aber genau hier liegt auch mein Problem. Wie kann man die exakte Uhrzeit unmittelbar nach dem Einschalten festhalten, um die zeitliche Differenz zu ermitteln? Im Grunde muss ich ja wissen wann die Steuerung ausgefallen ist und wann sie wieder gestartet wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Könnte man nicht ab Mitternacht mitzählen, wieviele Minutenimpulse tatsächlich ausgegeben wurden, und mit der aktuellen Uhrzeit vergleichen, wieviele es hätten sein müssen?
Haben Deine Nebenuhren irgendeine Rückmeldung, wo ein oder beide Zeiger stehen?

Harald
 
Wie kann man die exakte Uhrzeit unmittelbar nach dem Einschalten festhalten, um die zeitliche Differenz zu ermitteln?
Du benötigst nicht die "die genaue Uhrzeit unmittelbar nach dem Einschalten", sondern die aktuelle Uhrzeit, zu der Du beginnst, die ImpulsAusgabe wieder aufzunehmen. Und natürlich auch bzw. insbesondere, die aktuelle Uhrzeit und den Zählerstand zu dem Zeitpunkt, zu dem Du den letzten Impuls ausgegeben bzw. unterdrückt hast. Die aktuelle Uhrzeit kannst Du in "aller Ruhe" - wie gewohnt - einlesen.

Tja, das bedeutet eigentlich, dass man jeden Impuls nicht mehr stur aus irgendwelchen Wechseln/Flanken von irgendwelchen Teilen der Uhrzeit ableitet, sondern grundsätzlich jedesmal davon ausgeht, dass die Zeitspanne seit der letzten Ausgabe eines Impulses unbekannt ist und berechnet werden muss. Werde noch ein Bisschen darüber nachdenken. Immerhin könnte ja während des Stromausfalls ein Wechsel von Winter-/Sommerzeit stattgefunden haben und man muss sich deshalb nicht nur die Uhrzeit, sondern auch das Datum des zuletzt ausgegebenen Impulses merken.

Wichtig ist, dass Du die Uhrzeit (und das Datum), die Du Dir bei der Ausgabe des (jeweils) letzten Impulses gemerkt hast, nicht mit "Schrott" überspeicherst, wenn die PLC neu hochfährt.

Die Unsicherheit, die bleibt, ist, ob alle Uhren geschaltet haben, wenn der StromAusfall einsetzte, während Du einen Impuls ausgegeben hast.
Also, war der Impuls, der bei den Uhren angekommen ist, lang genug, um auch bei allen wirksam zu werden. Dagegen weiss ich kein Rezept, wenn es keine Rückmeldungen der Uhren gibt.
 
Haben Deine Nebenuhren irgendeine Rückmeldung, wo ein oder beide Zeiger stehen?
Nein, die Uhren geben leider keine Rückmeldung.

Immerhin könnte ja während des Stromausfalls ein Wechsel von Winter-/Sommerzeit stattgefunden haben und man muss sich deshalb nicht nur die Uhrzeit, sondern auch das Datum des zuletzt ausgegebenen Impulses merken.
Unabhängig vom Wechsel der Sommer-/Winterzeit muss das Datum sowieso einbezogen werden, falls sich der Stromausfall über mehrere Tage erstrecken sollte, oder nicht? Das war zumindest mein Gedanke und der Grund dafür warum ich vom Datentyp Date and Time gesprochen habe.

Gruß
Michi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Unabhängig vom Wechsel der Sommer-/Winterzeit muss das Datum sowieso einbezogen werden, falls sich der Stromausfall über mehrere Tage erstrecken sollte, oder nicht? Das war zumindest mein Gedanke und der Grund dafür warum ich vom Datentyp Date and Time gesprochen habe.
Hmmm, jain. Du musst doch "normalerweise" (wenn kein Wechsel zwischen Sommer- und Winterzeit während des StromAusfalls stattfindet) "nur" den MinutenZeiger und "indirekt" auch den StundenZeiger synchronisieren. Oder haben Deine Uhren auch eine DatumsAnzeige, die über den Minuten-Impuls gesteuert wird?
Uhrzeit und Datum sind zu berücksichtigen wegen der Umstellungen zwischen Sommer- und Winterzeit.
Um die beiden Zeiger (Stunde und Minute) zu synchronisieren, kann Dir egal sein, wie viele (halbe!?) Tage zwischen Beginn und Ende des StromAusfalls vergangen sind.
Du musst nur die Differenz zwischen Soll und Ist der Zeiger ausgleichen und die ist maximal 12 Stunden.
Frage am Rande: die StundenZeiger machen doch pro 24 Stunden 2 Umdrehungen?

Ich würde "intern" doch lieber mit 1 Variablen für das Datum und einer weiteren Variablen für die Zeit arbeiten wollen.
Datum: Anzahl der Tage seit einem bestimmten "Basis"-Datum.
Zeit: Anzahl der Sekunden (oder ms oder µs oder ...) seit 00:00.000..... Uhr.
Damit Datum und Zeit konsistent sind (zueinander passen), würde ich auch aktuelles Datum und aktuelle Zeit in der "gemeinsamen" Form DAT einlesen, diese dann in die 2 genannten Teile aufspalten, einfach, weil ich's übersichtlicher finde.
 
Hmmm, jain. Du musst doch "normalerweise" (wenn kein Wechsel zwischen Sommer- und Winterzeit während des StromAusfalls stattfindet) "nur" den MinutenZeiger und "indirekt" auch den StundenZeiger synchronisieren. Oder haben Deine Uhren auch eine DatumsAnzeige, die über den Minuten-Impuls gesteuert wird?
Uhrzeit und Datum sind zu berücksichtigen wegen der Umstellungen zwischen Sommer- und Winterzeit.
Um die beiden Zeiger (Stunde und Minute) zu synchronisieren, kann Dir egal sein, wie viele (halbe!?) Tage zwischen Beginn und Ende des StromAusfalls vergangen sind.
Ja guck, da hatte ich wohl einen Denkfehler🤔. Nein nein, die Uhren haben keine Datumsanzeige.
Könnte man nicht ab Mitternacht mitzählen, wieviele Minutenimpulse tatsächlich ausgegeben wurden, und mit der aktuellen Uhrzeit vergleichen, wieviele es hätten sein müssen?
Jetzt leuchtet mir auch der Ansatz von PN/DP ein.
Du musst nur die Differenz zwischen Soll und Ist der Zeiger ausgleichen und die ist maximal 12 Stunden.
Frage am Rande: die StundenZeiger machen doch pro 24 Stunden 2 Umdrehungen?
Zur Frage: Genau, 2 Umdrehungen pro 24 Stunden.
 
Könnte man nicht ab Mitternacht mitzählen, wieviele Minutenimpulse tatsächlich ausgegeben wurden, und mit der aktuellen Uhrzeit vergleichen, wieviele es hätten sein müssen?
Ja. Und zwar separat für jede einzelne, angeschlossene Uhr.
Warum so kompliziert? Ich gehe mal davon aus, dass die Synchronität einzelner Uhren verloren gehen kann (z.B. durch einen Defekt) oder von vornherein (noch) nicht gegeben ist. Also für jede Uhr ein eigenes Eingabefeld vorsehen, in dem die tatsächliche, aktuelle Anzeige der jeweiligen Uhr eingegeben werden kann, um jegliche Manipulationen an den Uhren vor Ort zu vermeiden.
Praktisch dürfte es sinnvoll sein, in der Zeitspanne vom Ablesen der ersten Uhr bis zur Eingabe des letzten AnzeigeWertes, die ImpulsAusgabe zumindest für die zu stellenden Uhren, anzuhalten.
Die internen Zähler der Uhren würde ich tatsächlich bei 12 h "überlaufen" lassen, also - wenn man so will - die Minuten-Impulse ab Mitternacht bzw. ab Mittag zählen lassen.
Um die "magische" Stunde (2 Uhr an den Tagen der Wechsel zwischen Sommer- und Winterzeit) richtig zu dekodieren ist ein 24-h-Turnus nur bei der "Master-Uhr" (bei der eingelesenen Zeit) erforderlich, nicht bei den angeschlossenen ZeigerUhren.
 
Zurück
Oben