Step 7 Frage zum Erstabfragebit

sunny22

Level-2
Beiträge
259
Reaktionspunkte
52
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

ich hätt mal eine Verständnisfrage zum Erstabfragebit
Folgender Code
Code:
      U     M      0.0
      U     M      0.1
      =     M      0.2
      SPA   m1
      U     M      0.3
      U     M      0.4
m1:   U     M      0.5
      =     M      0.6
Warum ist die Anweisung hinter m1 keine Erstabfrage?
- ist nur M0.5 = 1, bleibt M0.6 = 0
- sind M0.0, M0.1 und M0.5 = 1, wird M0.6 = 1

Grüße Oliver
 
Warum ist die Anweisung hinter m1 keine Erstabfrage?
- ist nur M0.5 = 1, bleibt M0.6 = 0
- sind M0.0, M0.1 und M0.5 = 1, wird M0.6 = 1
Für mein Verständnis ist U M 0.5 definitiv eine ErstAbfrage.
= M 0.2 sorgt dafür, dass die nächste durchlaufene Abfrage zur ErstAbfrage wird und SPA ändert daran nichts. SPB statt SPA würde zwar das aktuelle VKE auf 1 setzen, aber das hätte keine Auswirkung, da nicht = oder R oder S folgt, sondern die besagte ErstAbfrage.
Anders wäre es nur, wenn die Zeile = M 0.2 fehlen würde. Dann wäre Deine Beobachtung nachzuvollziehen.
Nimmt M 0.6 tatsächlich die von Dir beschriebenen Zustände an oder gaukelt Dir die Anzeige dies "nur" vor?

PS:
Wird das Label m1: noch von einer anderen ProgrammStelle aus angesprungen?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
"Erstabfrage": wenn das Erstabfragebit /ER = 0 ist dann wird der Status des Operanden der Verknüpfungsoperation direkt in das VKE geladen und nicht mit dem bisherigen VKE verknüpft (egal ob die Verknüpfung U O X ... heißt).

"Erstabfrage" ist nur die ERSTE Verknüpfungsoperation nach einer Operation, die das Erstabfragebit /ER auf 0 setzt (z.B. = S R). Bei Dir: die erste Verknüpfung nach dem "= M0.2"
Wenn mit SPA zu m1 gesprungen wird, dann ist "U M0.5" eine Erstabfrage. Wenn nicht gesprungen wird, dann ist "U M0.3" die Erstabfrage, und "U M0.5" verknüpft mit dem VKE von "U M0.3 + U M0.4"

Merke: Nie in eine Verknüpfung hinein springen! (wenn man nicht ganz genau weiß was man tut und der AWL-Code noch einfach verstehbar bleiben soll)

siehe: Hilfe zu AWL > Index > "Statuswort" > "/ER Erstabfragebit (Statuswort, Bit 0)"
Jede Verknüpfungsoperation fragt den Signalzustand des /ER-Bits und des angesprochenen Kontakts ab.
  • Ist der Signalzustand des /ER-Bits gleich "1", dann verknüpft eine Operation das Ergebnis ihrer Signalzustandsabfrage am von ihr angesprochenen Kontakt mit dem seit der Erstabfrage gebildeten VKE und speichert das Ergebnis im VKE-Bit.
  • Ist der Signalzustand des /ER-Bits gleich "0", dann beginnt die Verknüpfungskette mit einer Erstabfrage.
Mit Zuordnung eines Wertes (S, R, =) oder mit einer VKE-abhängigen Sprungoperation endet die Verknüpfungskette und das /ER-Bit wird auf "0" gesetzt.

Harald
 
Moin Harald,
haben wir beide also keine Erklärung für das Phänomen?
Ich glaube mich zu erinnern, dass zu S5-Zeiten beim Beobachten der Anweisungen tatsächlich Irreführendes angezeigt wurde bzw. werden konnte, wenn ein Teil der Anweisungen übersprungen wurde.
Die CPU hat's aber immer richtig ausgeführt, da sie keinerlei Veranlassung hatte, die übersprungenen Anweisungen in irgendeiner Form zu berücksichtigen.
Ich vermute deshalb, dass auch hier die AnzeigeFunktion Unsinn anzeigt.
Das könnte man aber testen, indem man anderweitig den Zustand von M 0.6 beobachtet.
Oder, indem man die unnützen/überflüssigen Anweisungen
SPA m1
U M 0.3
U M 0.4
löscht.
Gruss, Heinileini
 
Heinrich, Danke für die Nachfrage. Ich habe nicht beachtet daß mit SPA ja immer gesprungen wird. :oops: In dem Fall ist "U M0.5" IMMER eine Erstabfrage und M0.6 müsste immer den Zustand des M0.5 annehmen.

Mögliche Erklärung für das beschriebene Verhalten:
- Fehler im gezeigten Programm: ist das SPA vielleicht ein SPB?
- Firmware-Fehler der CPU: welche SPS-CPU ist das mit genau welcher Firmware-Version?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Erst mal Danke für die Atworten.
Das Programm ist ein Beispiel um das Phänomen zu zeigen. Es steht so wie abgebildet im OB1 einer CPU. Beobachtet werden die Merker über eine Variablentabelle.
In dem Fall ist "U M0.5" IMMER eine Erstabfrage
Der Meinung war ich auch da = M0.2 das EA Bit eigentlich löscht.
Das Verhalten ist aber wie beschrieben. Die CPU macht nach dem Sprung keine Erstabfrage sondern verknüpft weiter.
CPU ist eine 6ES7 315-2AF01-0AB0 AS4
Auf einer 6ES7 315-2AG10-0BA0 AS7 zeigt sich aber das selbe Verhalten.
Es scheint also kein Bug sondern ein Feature zu sein. Die Frage ist nur welches?
 
Es scheint also kein Bug sondern ein Feature zu sein. Die Frage ist nur welches?
Anscheinend will Siemens seinen Anwendern ein schlagendes Argument liefern, um endlich "freiwillig" Abschied von AWL zu nehmen? :ROFLMAO:
Ich kann und will es nicht glauben und tippe weiterhin auf ein Fatamorgana-Phänomen irgendeiner Art ...
Sollte die CPU wirklich das tun, was laut Anzeige scheinbar(?) passiert, gehört sie bzw. ihre FW in die Tonne getreten! :???:
 
...ein Fatamorgana-Phänomen...
Um der Sache weiter auf den Grund zu gehen und eventuell falsche Anzeigen in der Onlineansicht auszuschließen hab ich es jetzt mit echten IO Baugruppen getestet.
Selbes Ergebnis.
Sollte die CPU wirklich das tun, was laut Anzeige scheinbar(?) passiert, gehört sie bzw. ihre FW in die Tonne getreten!
und wenn das jede 300er CPU so macht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Verhalten ist aber wie beschrieben. Die CPU macht nach dem Sprung keine Erstabfrage sondern verknüpft weiter.
CPU ist eine 6ES7 315-2AF01-0AB0 AS4
Auf einer 6ES7 315-2AG10-0BA0 AS7 zeigt sich aber das selbe Verhalten.
Um der Sache weiter auf den Grund zu gehen und eventuell falsche Anzeigen in der Onlineansicht auszuschließen hab ich es jetzt mit echten IO Baugruppen getestet.
Selbes Ergebnis.

und wenn das jede 300er CPU so macht?
Hast Du mit PLCSIM getestet? Mit welcher Step7-Version programmierst Du?
Das macht ganz bestimmt nicht jede S7-300 so.
(Ich habe allerdings eine 314-6CF02 die tatsächlich an einer Programmstelle bei = nicht das Erstabfragebit löscht, eine identische CPU macht es aber richtig.)
Ich habe diverse 315-2AG10, da kann ich heute abend mal testen.

Tipp: Verteile mal die Merkeradressen auf verschiedene Bytes und teste. Ich meine, es gab da mal einen Firmwarefehler beim Verknüpfen, wenn alle Operanden aus dem selben Byte sind.

Harald
 
(Ich habe allerdings eine 314-6CF02 die tatsächlich an einer Programmstelle bei = nicht das Erstabfragebit löscht, eine identische CPU macht es aber richtig.)
...
Tipp: Verteile mal die Merkeradressen auf verschiedene Bytes und teste. Ich meine, es gab da mal einen Firmwarefehler beim Verknüpfen, wenn alle Operanden aus dem selben Byte sind.
Oh Harald! In was für einer verrückten Zeit leben wir!? Das ist doch allein mit Trumpeltier oder Covid19 nicht mehr zu erklären.
Lässt Siemens seine ArbeitsAnweisungen/PflichtenHefte für die Inder per Google übersetzen?
Das ging mir vorhin so durch den Sinn, als ich bei Conrad folgenden Text gelesen habe:
"Ein norMaßer LED-Optoisolator invertiert die Logik eines Signals.
Wir haben einige Transistoren auf dieses kompakte Board geworfen, um die Invertierung zu korrigieren." :ROFLMAO: :p

Es gab mal S5-CPUs, bei denen musste eine ErstVerknüpfung unbedingt ein U oder UN sein. Verwendete man nichtsahnend (oder weil man der Siemens-Doku nicht glauben wollte) O bzw. ON (X und XN waren eh noch nicht erfunden), dann passierte ähnlich verwirrendes Zeug.

Hatte vorhin einen "GeistesBlitz", den ich mir evtl. als Ursache vorstellen könnte: was würde passieren, wenn VOR den vom TE gezeigten Anweisungen eine Klammer geöffnet aber nicht wieder geschlossen wurde? Ich meine 'U(' oder 'O(' oder 'X(' und das abschliessende ')' vergessen, auskommentiert oder sonstwie wegrationalisiert. Oder ein zwischen den Klammern eingefügter SprungBefehl oder ein Sprung zwischen die Klammern? Sind solche Konstrukte überhaupt eingebbar? Bin mangels gegebenen Anlasses nie auf die Idee gekommen, solche Fälle zu testen. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein, PLCSIM hab ich hier nicht auf dem Rechner hab nur am realen Objekt getestet. Step7 ist V5.6
(Ich habe allerdings eine 314-6CF02 die tatsächlich an einer Programmstelle bei = nicht das Erstabfragebit löscht, eine identische CPU macht es aber richtig.)
Erinnert irgendwie an I-Robot "...die Geister in der Maschine..."
...heute abend mal testen.
Da bin ich ja mal gespannt. Vielleicht kannst Du es ja auch mal mit PLCSIM versuchen.
Das mit den Merkerbytes teste ich morgen.
Es gab mal S5-CPUs, bei denen musste eine ErstVerknüpfung unbedingt ein U oder UN sein.
Daran erinnere ich mich auch noch. Das hat uns unser SPSler in der Lehre auch so eingetrichtert.
Was die Klammergeschichte betrifft, würde ich das dann aber schon eher in Richtung Programmierfehler einordnen. Wobei dann auch schon mal komische Sachen passieren dürfen.
Mein Beispiel ist, wenn man sich vielleicht noch eine Sprungmarke vor das U M0.3 denkt, gar nicht sooo abwegig.
 
OMG. Es scheint so, als ob dieser Fehler tatsächlich in (allen?) S7-300 CPU drin ist... :roll:
Sogar in F-CPUs!
S7-400 und PLCSIM verhalten sich so wie es sein soll.

Ich bin noch am testen. Später mehr Infos.

Harald
 
...als ob dieser Fehler...
Nicht Fehler, Feature :ROFLMAO:
Ich denke ich habe die Ursache gefunden.
http://www.kleissler-online.de/Siemens/312C.pdf
Auf Seite 16
Erstabfrage, Bit kann im Anwenderprogramm mit Operation L STW nicht ausgewertet werden, da das Bit zur Programmlaufzeit nicht aktualisiert wird.
Was eine Erstabfrage ist und was nicht wird offenbar schon beim kompilieren festgelegt. Zumindest bei der S7 300.
Da beim oben gezeigten Konstrukt zu dem Zeitpunkt noch nicht klar ist ob U M0.5 eine Erstabfrage ist oder nicht kommt es zu diesem Verhalten.
Für den Compiler ist U M0.3, als Beginn der Kette, die Erstabfrage.
 
Also, das Feature nennt sich "Dynamische Auswertung des ERAB-Bits".
Ob die CPU das kann lässt sich über RDSYSST feststellen SZL 0112 Index 0300 Kennung 0316.
Siehe "System- und Standardfunktionen für S7-300/400"
Die 300er Serie kann es nicht, die 400er kann es.

 
Bei 3 der STW-Bits steht, dass sie mit L STW nicht ausgewertet werden können, da sie zur ProgrammLaufzeit nicht aktualisiert werden: /ER, STA, OR.
Wer will sie denn schon zur ProgrammLaufzeit mit L STW auswerten? Allein die CPU muss sie setzen/rücksetzen und abfragen können, um ordnungsgemäss arbeiten zu können - aber die CPU braucht dafür nicht die Anweisung L STW. Für mich bedeutet das nur, dass - vermutlich aus PerformanceGründen - darauf verzichtet wurde, diese StatusBits bei der Aufbereitung dessen, was der L STW an Informationen liefern kann, zu berücksichtigen. Oder es gibt diese Bits in dieser Form gar nicht mehr, weil ihre Aufgabe jetzt ganz anders gelöst ist?
Kann man denn mit L STW die Bits auswerten, wenn die CPU in Stopp gelaufen ist? Nein, auch nicht, denn Anweisungen (wie z.B. L STW) werden doch nur zur Laufzeit ausgeführt. :ROFLMAO:
Die Formulierung ist irgendwie irreführend.

Siemens hat beim Definieren der S5-AWL-Sprache (S3 habe ich nie kennengelernt - ich fange einfach mal bei S5 an) nicht vorausgesehen, dass Generationen später ein bewährter Interptreter auf einen Compiler umgewürgt werden würde, um zeitgemäss zu erscheinen. Und derjenige, der's realisieren musste, hat nicht verstanden, was für ein "Potenzial" sich hinter dem Begriff ErstVerküpfung verbirgt.
Einigen Herstellern anderer AWL-ähnlicher Sprachen war das Thema ErstVerknüpfung nie geheuer oder zu kompliziert und sie haben deshalb dem Programmierer die Aufgabe auf's Auge gedrückt, per speziellem Operator (load, read, ...) eindeutig festzulegen, dass sie eine ErstVerknüpfung meinen. Das war eine Compiler-freundliche Entscheidung.
Die Siemens-Entscheidung, Aufwärtskompatibilität im weitesten Sinne durchzuboxen, war jedoch nicht Compiler-freundlich. Jetzt haben wir den Schlammassel.
Wie gut, dass es das Wort 'feature' gibt, um damit einen 'bug' umschreiben zu können. :ROFLMAO:

Ein Compiler, der regelwidrige AnweisungensFolgen kommentarlos hinnimmt, weil er sie gar nicht erst als solche erkennt, gehört eigentlich auch in die Tonne getreten ...
Bei "regelwidrig" denke ich an die Regeln des Compilers, unabhängig davon, ob diese noch den Regeln der SprachDefinition entsprechen.

Edit:
Also, das Feature nennt sich "Dynamische Auswertung des ERAB-Bits".
Ob die CPU das kann lässt sich über RDSYSST feststellen SZL 0112 Index 0300 Kennung 0316.
Siehe "System- und Standardfunktionen für S7-300/400"
Die 300er Serie kann es nicht, die 400er kann es.
Ach so macht Siemens das! Ein ausschleichendes bzw. ein ausgeschlichen wordenes Feature wird so getarnt dokumentiert, dass um HimmelsWillen kein niemand nicht ahnt, was gemeint ist und ins offene Messer rennen muss.
Das ERAB-Bit wurde doch geschaffen, um höchstdynamisch ausgewertet zu werden. Ohne dynamische Auswertung macht es keinen Sinn und ist schlichtweg überflüssig ...
Es wird also heimlich und - damit's hoffentlich keiner merkt - scheinbar schrittweise wegrationalisiert?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
OMG. Es scheint so, als ob dieser Fehler tatsächlich in (allen?) S7-300 CPU drin ist... :roll:
Sogar in F-CPUs!
S7-400 und PLCSIM verhalten sich so wie es sein soll.

Ich bin noch am testen. Später mehr Infos.

Harald
Hier ein bild von ein 6ES7315-2AG10-0AB0 V2.6
VKE.JPG

Bei dass der SPA m1 mit SET für die Sprungziel habe ich ein VKE eins bei der m2 ohne die SET ist das VKE 0.
 
Ich habe gestern ca. 17 verschiedene S7-300-CPUs und drei S7-400-CPUs getestet. Bei allen S7-300-CPUs ist die U-Verknüpfung nach dem Sprung keine Erstabfrage! Bei S7-400 und PLCSIM ist es eine Erstabfrage - die verhalten sich "richtig" gemäß AWL-Dokumentation.

Das scheint tatsächlich eine Systemeigenschaft der S7-300 zu sein. Doch warum hat Siemens das jahrzehntelang nicht deutlich dokumentiert und selbst in S7-300-CPU-spezifischen Dokumentationen (wie den Operationslisten der CPUs) den Sachverhalt falsch dargestellt? Oder kennt jemand eine Stelle, wo Siemens auf diesen essentiellen Unterschied der S7-300 entgegen der AWL-Dokumentation hinweist?
In den Operationslisten der S7-300-CPUs schreibt Siemens ausdrücklich, daß z.B. die Operationen = S R das Erstabfragebit /ER auf 0 setzen, und daß alle Verknüpfungsoperationen vom /ER abhängen, und daß der Sprung SPA das /ER nicht beeinflußt. Das ist so offensichtlich falsch. Der knappe Hinweis, daß das Erstabfrage-Bit zur Programmlaufzeit nicht aktualisiert wird, ist ja wohl keine Dokumentation daß alle Erklärungen bezüglich Erstabfragebit im selben Dokument (und in der AWL-Beschreibung) nicht gelten.

Es scheint mir so, als ob die S7-300 tatsächlich gar kein Erstabfragebit hat bzw. nicht verwendet, sondern eine besondere Erstverknüpfungs-Anweisung hat oder (nur) die erste Verknüpfungsanweisung besonders gekennzeichnet wird. (und der AWL-zu-MC7-Übersetzer ist auch nicht besonders schlau und merkt nicht daß der Code zwischen SPA und m1 nie ausgeführt wird und deshalb "U M2.5" die Erstabfrage sein muß)
In dem Bild von Joop #18 sieht man zwar im Statuswort Bit 0 (eine Simulation?) das Erstabfragebit /ER, man sieht aber auch daß es bei m2 gar nicht beachtet wurde.

Es ist schon ziemlich überraschend daß ein nicht ausgeführter Code beeinflusst wie Code dahinter funktioniert, allein durch sein Vorhandensein:
Code:
      U     M 2.0
      U     M 2.1
      =     M 2.2
      SPA   m1

[COLOR="#0000FF"]      U     M 2.3  //wird nicht ausgeführt[/COLOR]
[COLOR="#0000FF"]      U     M 2.4  //wird nicht ausgeführt[/COLOR]

m1:   U     M 2.5  //bei S7-300 keine Erstabfrage! sondern Weiterverknüpfung von "= M2.2"
      =     M 2.6
Code:
      U     M 2.0
      U     M 2.1
      =     M 2.2
      SPA   m1

[COLOR="#0000FF"]      U     M 2.3  //wird nicht ausgeführt[/COLOR]
[COLOR="#0000FF"]      U     M 2.4  //wird nicht ausgeführt[/COLOR]
      [COLOR="#FF0000"]SET[/COLOR]          [COLOR="#0000FF"]//wird nicht ausgeführt[/COLOR]

m1:   U     M 2.5  //nun ist es eine Erstabfrage
      =     M 2.6
Code:
      U     M 2.0
      U     M      2.1
      =     M      2.2
      SPA   m1

m1:   U     M 2.5  //nun ist es eine Erstabfrage
      =     M 2.6
Wie ich schon in #3 schrieb "Merke: Nie in eine Verknüpfung hinein springen!" - dann spielt dieses besondere Verhalten der S7-300 keine Rolle.

Die Beschreibungen von TIA bzgl. Statuswort und Erstabfragebit kann man vergessen. Da steht noch weniger als in der Step7 classic AWL-Beschreibung ... Es wird allgemein kein Unterschied zwischen S7-300 und S7-400 gemacht, lediglich bei "L STW" steht ein knapper Hinweis
Die Steuerungen der S7-300 Baureihe (außer S7-318 ) laden die Statusbits /ER, STA und OR nicht in den Akkumulator 1. Diese Stellen werden mit "0" beschrieben.


Also, das Feature nennt sich "Dynamische Auswertung des ERAB-Bits".
Ob die CPU das kann lässt sich über RDSYSST feststellen SZL 0112 Index 0300 Kennung 0316.
Siehe "System- und Standardfunktionen für S7-300/400"
Die 300er Serie kann es nicht, die 400er kann es.
Wie bist Du darauf gekommen? Hattest Du einen Hinweis von Siemens?


Anhang: diese CPUs habe ich getestet. Bei allen ist die U-Verknüpfung nach dem Sprung keine Erstabfrage!
Code:
151-8AB01 V3.2.10 IM151-8 PN/DP
313-5BE01 V2.0.10 313C
314-5AE03 V1.1.0  314IFM
314-6CF00 V1.0.3  314C-2 DP
314-6CH04 V3.3.17 314C-2 DP
314-1AE04 V1.2.0  314
314-1AF10 V2.0.11 314
314-1AF11 V2.0.11 314
314-1AG14 V3.0.3  314
315-2AF03 V1.2.0  315-2 DP
315-2AG10 V2.0.11 315-2 DP
315-2AG10 V2.0.12 315-2 DP
315-2AG10 V2.6.11 315-2 DP
315-2AH14 V3.3.16 315-2 DP
315-2EH13 V2.6.0  315-2 PN/DP
316-2AG00 V1.2.1  316-2 DP
318-3FL01 V3.2.7  319F-3 PN/DP
C7-CPUs habe ich keine getestet, doch vermutlich verhalten die sich ebenfalls so.

Eine CPU 318-2 habe ich noch nicht getestet, da habe ich keine mit Fernzugriff. Die verhält sich normalerweise wie eine S7-400, in der Operationsliste wird bzgl. Erstabfragebit auf keinen Unterschied zu anderen S7-300 hingewiesen. Man müsste mal testen, ob der "CPU 318 Migration Check" solche Anweisungsfolgen als problematisch ausgibt.

Nachtrag:
318-2AJ00 V3.0.1 318-2
Die 318-2 verhält sich wie vermutet anders als andere S7-300 - bei der 318-2 funktioniert die Erstabfrage korrekt wie bei S7-400.
Der "CPU 318 Migration Check" weiß daß sich S7-300-CPUs bei der Erstabfrage anders verhalten als die 318-2. Sprünge in eine Verknüpfungskette werden beanstandet:
Achten Sie bei Programmen für die S7-300-CPUs darauf, dass bei Sprungoperationen das Sprungziel immer der Beginn einer Verknüpfungskette ist (muss nicht bei der CPU 318-2 sein). Das Sprungziel darf sich nicht innerhalb einer Verknüpfungskette befinden.

Harald
 

Anhänge

  • 315-2AG10_2.0.11.png
    315-2AG10_2.0.11.png
    4,8 KB · Aufrufe: 12
  • VKE.JPG
    VKE.JPG
    37 KB · Aufrufe: 15
Zuletzt bearbeitet:
Ich habe gestern ca. 17 verschiedene S7-300-CPUs und drei S7-400-CPUs getestet. Bei allen S7-300-CPUs ist die U-Verknüpfung nach dem Sprung keine Erstabfrage! Bei S7-400 und PLCSIM ist es eine Erstabfrage - die verhalten sich "richtig" gemäß AWL-Dokumentation.

Das scheint tatsächlich eine Systemeigenschaft der S7-300 zu sein. Doch warum hat Siemens das jahrzehntelang nicht deutlich dokumentiert und selbst in S7-300-CPU-spezifischen Dokumentationen (wie den Operationslisten der CPUs) den Sachverhalt falsch dargestellt? Oder kennt jemand eine Stelle, wo Siemens auf diesen essentiellen Unterschied der S7-300 entgegen der AWL-Dokumentation hinweist?

Im SCL-Compiler ist diese Eigentschaft berücksichtigt. Dort wird nach Sprüngen und vor Abfragen CLR gesetzt. Das reicht mir auch. Wer im Jahr 2020 nach Christus AWL benutzt, ist selber schuld und ihm ist vermutlich auch nicht mehr zu helfen, um das mal klar zu formulieren.
 
Zurück
Oben