TIA S7-1200 Amperestunden Zähler

digidax

Level-2
Beiträge
42
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich möchte mit einer S7-1200 einen Ah-Zähler realisieren. Am analog In (0-10V) werde ich einen Messumformer anklemmen, der die max. 100A von einem einen 60mV Shunt umwandelt, also 100 A = 10 V an der SPS.

Den AI0 dann normalisieren und skalieren, dass ich den realen Stromwert habe.

Ich würde mit dem TP aller 10 ms einen Impuls erzeugen, der den aktuellen Stromwert mittels ADD aufaddiert: Strom1 = Strom1 + aktueller Stromwert
und die ausgeführten Additionen zählt. Nach 100 Additionen ist also eine Sekunde (100x10 ms = 1000 ms = 1s) vergangen. Nun würde ich den Strom1 Wert durch 100 teilen, das wäre dann der Mittelwert über eine Sekunde, also As. Dieses Ergebnis über die Variable Strom2 aufaddieren: Strom2 = Strom2 + Strom1/100 und Strom1 auf 0 setzen und wieder 100mal zählen lassen.
Der Ah Wert ergibt sich aus Strom2 (As) / 3600.

Wäre das so richtig oder gäbe es einen anderen Ansatz?

lg Frank
 
  • Sind der verwendete Analogeingang der S7-1200 und der Meßumformer schnell genug, um alle 10ms einen neuen Wandlerwert zu liefern? Ich würde vermuten, daß Abtasten alle 100ms oder 50ms reicht.
  • Impulserzeugung mit TP, TON oder ähnliches ist nicht gut, weil Zeit-Ungenauigkeiten durch Timer-Abfrage/Restart im OB1 addieren sich! (TP 10ms: in 1s kommen weniger als 100 Pulse)
    Besser: einen der CPU-Taktmerker (z.B. 10Hz) als Zeittakt + Flankenerkennung benutzen, oder die Abtastung in einem Weckalarm-OB (z.B. alle 100ms) machen.
  • ich würde nicht vor-addieren und alle 1s die gesammelten As übernehmen, sondern jeden Meßwert sofort beim Abtastpuls durch die Abtastfrequenz teilen und auf Strom1 (REAL) addieren
  • Wegen der begrenzten Auflösung von REAL/LREAL würde ich die As als ganze As zählen: immer wenn beim zyklischen zu-addieren zu Strom1 ein Wert > 1.0 zusammengekommen ist, dann: Strom1 := Strom1 - 1.0, Strom2 = Strom2 + 1;
    Strom1 : REAL oder LREAL; Strom2 : DINT; Wie groß kann der Wert in Strom2 werden?
  • Die Zählvariablen in einem globalen DB anlegen, der voraussichtlich nie geändert werden muß. Auf keinen Fall als Instanzvariable eines FB anlegen, weil Dir TIA sonst irgendwann/öfters bei Programmänderungen die Aktualwerte löschen/initialisieren will. Falls Du für den As-Zähler einen FB oder FC schreibst, dann die Zählvariablen per INOUT an den Baustein geben.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
  • [...]immer wenn beim zyklischen zu-addieren zu Strom1 ein Wert > 1.0 zusammengekommen ist, dann: Strom1 := Strom1 - 1.0, Strom2 = Strom2 + 1;
Besser ganz allgemein (falls der Wert auch >= 2.0 werden kann) immer so rechnen:
Code:
  rMesswert : REAL;  [COLOR="#008000"]//oder LREAL[/COLOR]
  Strom1_ganz : INT; [COLOR="#008000"]//oder DINT[/COLOR]
  Strom1 : REAL;     [COLOR="#008000"]//oder LREAL[/COLOR]
  Strom2 : DINT;
END_VAR

Strom1 := rMesswert / 100.0 + Strom1; [COLOR="#008000"]//bei Aufruf alle 10ms (100Hz)[/COLOR]
Strom1_ganz := TRUNC(Strom1);
[COLOR="#008000"]//IF Strom1_ganz <> 0 THEN //kann IF, funktioniert aber auch ohne IF bei Strom1_ganz = 0[/COLOR]
  Strom1 := Strom1 - INT_TO_REAL(Strom1_ganz);
  Strom2 := Strom2 + Strom1_ganz;
[COLOR="#008000"]//END_IF;[/COLOR]

Harald
 
Vielen Dank Harald für die wertvollen Hinweise. Der Wert für Strom2 wird maximal 300 (Ah) werden.

Folgender Messumformer wird eingesetzt:
https://www.sensorshop24.de/temp-messumformer/norm-bzw-hutschienen-messumformer/norm-bzw-hutschienen-messumformer-fuer-ma-mv-und-v/

kleine Änderung, die 100A werden in 50 mV und über den Umformer in 0-10 V skaliert. Datenblatt hier: https://enda.com/en/automation/converters/standard/ecsc/ecsc.pdf

Wenn die Teile Da sind, werde ich mal die Versuchsschaltung aufbauen.

Vielen Dank für die Hilfe.
Frank
 
Das wird aber nur halbwegs genau wenn sich dein Strom nicht zu schnell ändert. Wenn du da mit größeren Impulsen rechnen musst, wird das so wahrscheinlich ziemlich ungenau.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Stom nimmt innerhalb von 3 Stunden 4 verschiedene Werte an, die SPS regelt dabei den Stom immer auf den Wert, durch soll und ist Vergleich. Werteänderungen werden innerhalb von 3 sek. realisiert. Ein permanentes nachregeln nach erreichen eines neuen Solwertes wird es nicht geben, da sich der Lastwiderstand unerheblich ändert und Schwankungen vernachlässigt werden können.

@winnmann, hättest Du eine andere Idee?
 
Beim Addieren muss man auch bedenken, dass man den Messfehler des Analogwertes jedes Mal mit addiert. Bei hundert Messwerten pro Sekunde hat man dann auch einen hundertfachen Messfehler gegenüber einem einzigen Messwert pro Sekunde. Man muss also ein gutes Mittelmaß finden zwischen Abtastrate und Dynamik.

Die Idee mit dem Vor-Addieren finde ich nicht verkehrt, wobei eine Abtastung von 10ms wohl deutlich zu schnell ist. Das Vor-Addieren würde ich mit LReal realisieren, den eigentlichen Zähler mit Lint, oder was die Steuerung halt hergibt. Beim Übertrag der Gleitpunkt-Summe auf den Zähler, die Zähler-Wertigkeit von der Summe subtrahieren, nicht einfach die Summe auf Null setzen. Ein paar Kommastellen bleiben beim Übertrag von Gleitpunkt auf Ganzzahl immer stehen.

Eine gewisse Dämpfung des Messwertes würde ich hierbei immer empfehlen.

Nachtrag:
Nach weiteren Überlegungen sind meine o.g. Erläuerungen größtenteils Quatsch.
 
Zuletzt bearbeitet:
Nach einen Tipp gestern Abend in der Sauna, werde ich mal diese Möglichkeit (Integralrechnung) probieren:

https://support.industry.siemens.co...ation-für-die-s7-1200-s7-1500-?dti=0&lc=de-WW

In Zeile 20 und 21 wird im SCL gleich der Analogwert auf 0-10 normiert und skaliert, da ich ja 100 A über einen 50 mV Shunt messe, welche dann durch einen Messumformer in 0-10V für die SPS gewandelt werden, würde es doch Sinn machen, gleich in Zeile 21 auf 100 (A) zu skalieren, um die Rundeungsfehler klein zu halten - oder verstehe ich das SCL falsch?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Nach einen Tipp gestern Abend in der Sauna, werde ich mal diese Möglichkeit (Integralrechnung) probieren:

https://support.industry.siemens.co...ation-für-die-s7-1200-s7-1500-?dti=0&lc=de-WW
Das was Du und ich machen wollten, ist ebenfalls eine numerische Integration (Integralrechnung), die allerdings zur Vereinfachung davon ausgeht, daß die Wertekurve bei Wert-Erhöhungen und Wert-Verringerungen paarweise gleich große Krümmungen hat. Unser einfaches Verfahren zerlegt die Kurve in rechteckige Streifen, das Siemens-Beispiel zerlegt die Kurve in trapezförmige Streifen. Ich meine, der Unterschied ist praktisch vernachlässigbar, vereinfacht unsere Implementation aber ungemein.

Wie programmieren Sie in STEP 7 (TIA Portal) die numerische Integration für die S7-1200/S7-1500?
Verwenden Sie zur näherungsweisen Flächenbestimmung den FB "Integration", bei dem die Summierung der Flächenelemente in einem SCL-Programm kontinuierlich berechnet wird.
Meine Meinung: Vergiss den Siemens-Baustein, der ist noch meilenweit von einer zuverlässigen Verwendbarkeit in Industrieanlagen entfernt. Der Integrationsbaustein ist ein Beispiel, wie man mit viel Rechenaufwand eine Funktion zur Verfügung stellt für Programmierer die nicht wissen was sie tun - programmiert von einem Programmierer der ebenfalls nicht weiß was er tut. Der Baustein macht für mich den Eindruck als ob er von einem Praktikant/Hochschulabsolvent ohne praktische Erfahrung geschrieben wurde. Ganz offensichtlich hat sich bei Siemens niemand mit Ahnung den Baustein angesehen. Der Baustein macht so ziemlich alles verkehrt was man verkehrt machen kann ... außerdem ist ca. die Hälfte der spärlichen Kommentare/Hinweise falsch.

PS: typisch für heutige Anwendungs-Idioten: anstatt direkt den SCL-Quelltext des Bausteins zu zeigen, wird er in einen Megabyte-großen Download verpackt, der nur mit einem speziellen Programm geöffnet werden kann. Könnte man den Quelltext direkt lesen, dann könnte man sich den Download sparen.


Nachtrag 15.02.2019: der fehlerhafte FB "Integration" wurde nun aus der genannten Siemens FAQ entfernt und durch einen Verweis auf die Bibliothek mit generellen Funktionen (LGF) für STEP 7 (TIA Portal) ersetzt. Die LGF enthält einen verbesserten Integrator-Baustein "LGF_Integration", der z.Z. zwar auch noch nicht ganz fehlerfrei ist (siehe ab #46), nun aber im wesentlichen richtig rechnet. Vielleicht läßt sich Siemens noch ein zweites Mal überzeugen, daß auch der "LGF_Integration" noch nicht das Wahre ist und überarbeitet den Baustein nach meinen Hinweisen :cool: ;)

Warnung: Bitte den hier angehängten FB "Integration" nicht in SPS-Projekten verwenden. Er dient nur noch zur Dokumentation, damit man die hier nachfolgende Diskussion über die Fehler nachvollziehen kann. (siehe z.B. #18 und #20)

Harald
 

Anhänge

  • 42469594_FB_Integration.scl.txt
    3 KB · Aufrufe: 12
Zuletzt bearbeitet:
Hab ja die 13er Version installiert, die ist 1,1 MB groß und dann kommen 30 Zeilen SCL raus, also 99% Overhead. Musste auch etwas schmunzeln.

Danke für deine Erklärung, dabei ist mir noch eine Idee gekommen. Die Stromregelung der Anlage erfolgt über einen Trafo mit Schleifabgriff, die Position des Abgreifers wird über einen Stellmotor (den ich auch mit steuern muss) realisiert. Dieser läuft immer mit konstanter Geschwindikeit - wenn er läuft. Die tatsächliche Stromänderung ist also immer linear mit konstanten Anstieg, damit kann ich problemlos mit rechteckigen Streifen arbeiten, die sinnvolle Breite (Delta t) kann ich aus dem zu erwartenden Anstieg der Kurve während der Änderung der Stromstärke ermitteln und somit auch in der Fehlerrechnung den Anteil dieder Integration sinnvoll bewerten.

Dankeschön.
 
Code:
  rMesswert : REAL;  [COLOR=#008000]//oder LREAL[/COLOR]
  Strom1_ganz : INT; [COLOR=#008000]//oder DINT[/COLOR]
  Strom1 : REAL;     [COLOR=#008000]//oder LREAL[/COLOR]
  Strom2 : DINT;
END_VAR

Strom1 := rMesswert / 100.0 + Strom1; [COLOR=#008000]//bei Aufruf alle 10ms (100Hz)[/COLOR]
Strom1_ganz := TRUNC(Strom1);
[COLOR=#008000]//IF Strom1_ganz <> 0 THEN //kann IF, funktioniert aber auch ohne IF bei Strom1_ganz = 0[/COLOR]
  Strom1 := Strom1 - INT_TO_REAL(Strom1_ganz);
  Strom2 := Strom2 + Strom1_ganz;
[COLOR=#008000]//END_IF;[/COLOR]

Da ja der "analog In" bei 10V einen Wert von 27648 liefert, ist es sinnvoll / performanter diesen direkt an unseren Integrator FB zu geben oder vorher auf 100 (A) zu skalieren?
Die Zählvariablen werden in einer globalen DB abgelegt. Warum soll der Zählvert per InOut und nicht per Input im OB an deb FB übergeben werden?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist IMMER sinnvoll beim Arbeiten mit Werten diese auf eine sinnvolle Maßeinheit zu skalieren.
Ob ich in deinem Fall allerdings REAL und Ampere wählen würde oder möglicherweise besser DINT und Milliampere ist so eine Frage (der Genauigkeit) - das mußt du für dich ausprobieren.

Gruß
Larry
 
Da ja der "analog In" bei 10V einen Wert von 27648 liefert, ist es sinnvoll / performanter diesen direkt an unseren Integrator FB zu geben oder vorher auf 100 (A) zu skalieren?
Das kann man für einen speziellen Fall ausprobieren, ob der Integrator mit Ganzzahl einen kleinen Tick genauer wird (vermutlich nur, wenn für den Vorzähler vor dem Übertrag mehr als 7 Ziffern zusammenkommen, dann könnte man aber auch LREAL verwenden). Für die Entscheidung, wann der "Vorzähler" einen Übertrag zum Hauptzähler liefert, muß man sowieso einmal die Skalierung machen (dann ist es für die Performance mit heutigen S7-CPUs egal ob vor oder hinter dem Integrator) oder mit "krummen" "Magic" Ganzzahl-Grenzwerten arbeiten (was schlechter lesbar und schlechter wartbar ist). Ich meine, es ist besser und verständlicher und fehlerfreier, möglichst durchgängig mit den skalierten technischen Einheiten zu hantieren als mit den AD-Wandler-Rohwerten. Wenn man mit den technischen Einheiten hantiert, dann kann man auch ganz einfach die Beträge von mehreren/verschiedenen/umschaltbaren Wandlern mit dem selben Integrator verarbeiten.

Die Zählvariablen werden in einer globalen DB abgelegt. Warum soll der Zählvert per InOut und nicht per Input im OB an deb FB übergeben werden?
Weil auf die Zählvariablen Werte addiert werden: der FB muß den aktuellen Wert vor der Addition wissen (lesen, IN) und das Ergebnis wieder auf die Variable speichern (schreiben, OUT). Genau dafür ist IN_OUT vorgesehen. Auf Input-Variablen schreibt man nicht, und es würde sowieso nur funktionieren wenn die Input-Variable per Referenz übergeben wird.

Harald
 
Wie programmieren Sie in STEP 7 (TIA Portal) die numerische Integration für die S7-1200/S7-1500?
Verwenden Sie zur näherungsweisen Flächenbestimmung den FB "Integration", bei dem die Summierung der Flächenelemente in einem SCL-Programm kontinuierlich berechnet wird.
Meine Meinung: Vergiss den Siemens-Baustein [...]
Hat mal jemand den SCL-Quelltext des TIA-V15-Projektes? Ist der genau wie im V13-Projekt oder wurden da die Fehler bereinigt?

Z.B. Entgegen der Theorie/Beschreibung rechnet das Programm nicht mit der linken und der rechten Trapezhöhe, sondern mit der vorher berechneten (linken) Fläche und der neuen Trapezhöhe, da passen schon die phys. Einheiten nicht zusammen, z.B.: Integral[Vs] := Integral[Vs] + (altwert[Vs] + neuwert[V])/2 * tdiff;
Und weitere Unzulänglichkeiten wie: die erste Fläche geht nur zur Hälfte ein, Verwendung der PLC-Uhrzeit, ...
Im Anhang ein Bild wie der FB bei Aufrufzeit von 1 Sekunde tatsächlich "integriert". :roll:

Harald
 

Anhänge

  • 42469594_S7-1200_Integration_tatsächlich.png
    42469594_S7-1200_Integration_tatsächlich.png
    3,6 KB · Aufrufe: 33
  • 42469594_S7-1200_Integration_Theorie.png
    42469594_S7-1200_Integration_Theorie.png
    2,6 KB · Aufrufe: 36
Die Installation von V15 ging dann doch schnell, hat nur etwas über 6 Stunden gedauert....

Hier das SCL aus der V15 Lib:

Code:
//Der Eingangswert am Eingang "in" wird mit Hilfe des FB "Integration" integriert.
//Am Parameter "out" des FBs erfolgt die Ausgabe des Integralwertes und wird remanent gehalten.
// - "reset" setzt den Ausgabewert des Integrationsbausteins zurück.
// - "enable" startet die Integralberechnung und ist remanent zu wählen, wenn die Integration nach einem Spannungsausfall fortgesetzt werden soll.
// - das Ausgangsbit "error" signalisiert die fehlende Aktivierung oder Beschaltung des Systemmerkerbyte. Ist das "Error"-Bit nur für einen Zyklus aktiv, trat eine Spannungswiederkehr während der Integration auf.
//*******************************************************************************************************************************************************************************************************************
//The input value "in" will be integrated by the FB "Integration".
//The output value of the "Integration" is the parameter "out" and is retentive and holds the integrated value.
// - "reset" resets the integrated output value "out".
// - "enable" starts the integral calculation and must be retentive if the integration should continue after a power failure.
// - the output bit "error" signals that the system memory byte is disabled or not connected (when glowing). Is active for one cycle only, it signals a power up while integration.
                                       
IF #reset = true THEN
     #out := 0.0;
     #statLastIn := 0.0;
     #statIntegral := 0.0;
     RETURN;
END_IF;
                                       
#tempAux := NORM_X(MIN := 0, VALUE := #in, MAX := 27648);
#statIn := SCALE_X(MIN := 0.0, VALUE := #tempAux, MAX := 10.0);
                                       
#tempRv1:= RD_SYS_T(OUT=>#statActualTime);

#tempDeltaTimeT:= T_DIFF(IN1:=#statActualTime, IN2:=#statlastTime);
#tempDeltaTimeDI:= TIME_TO_DINT(#tempDeltaTimeT);

#tempDeltaTime:= DINT_TO_LREAL(#tempDeltaTimeDI);
#tempDeltaTime := #tempDeltaTime / 1000.0;
#statlastTime := #statActualTime;

IF NOT #enable = true THEN
    #statLastIn := 0.0;
    RETURN;
END_IF;

#statIn := #statIn + #statLastIn;
#statIn := #statIn / 2.0;
#statIn := #statIn * #tempDeltaTime;
#statIntegral := #statIntegral + #statIn;
#out:= #statIntegral;

#statLastIn := #statIn;
 
Zuletzt bearbeitet:
Meines Erachtens ist das Intergrieren in den Siemens-Beispielen prinzipiell richtig. Es wird der aktuelle Prozesswert mit dem Prozesswert des vorherigen Zyklus addiert. Diese Summe wird durch 2 geteilt (Trapezregel) und mit der Abtastzeit multipliziert. Daraus ergibt sich eine Fläche, welche zum Integral aufaddiert wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
. . . Es wird der aktuelle Prozesswert mit dem Prozesswert des vorherigen Zyklus addiert. . .
Eben nicht! Da hat Harald vollkommen Recht.
Code:
. . . 
#statIn := #statIn + #statLastIn;
#statIn := #statIn / 2.0;
#statIn := #statIn * #tempDeltaTime;
#statIntegral := #statIntegral + #statIn;
#out:= #statIntegral;
#statLastIn := #statIn;

Denn zu guter letzt steht #statLastIn := #statIn und zu diesem ZeitPunkt hat #statIn schon lange nicht mehr DIE Bedeutung, die es mal hatte und die gemeint sein dürfte. Es müsste z.B. heissen:
Code:
. . . 
[FONT=courier new]#Irgendwas := #statIn + #statLastIn;
#[COLOR=#222222]Irgendwas[/COLOR] := #[COLOR=#222222]Irgendwas[/COLOR] / 2.0;
#[COLOR=#222222]Irgendwas[/COLOR] := #[COLOR=#222222]Irgendwas[/COLOR] * #tempDeltaTime;
#statIntegral := #statIntegral + #[COLOR=#222222]Irgendwas[/COLOR];
#out:= #statIntegral;
#statLastIn := #statIn;[/FONT]

 
Der größte Fehler des Bausteins steckt hier
Code:
#statIn := #statIn / 2.0;             [COLOR="#008000"]//ab hier enthält statIn die mittlere Höhe des Trapez[/COLOR]
[COLOR="#0000FF"]#statIn := #statIn * #tempDeltaTime;[/COLOR]  [COLOR="#008000"]//ab hier enthält statIn die Fläche[/COLOR]
#statIntegral := #statIntegral + [COLOR="#0000FF"]#statIn[/COLOR];
...
#statLastIn := [COLOR="#FF0000"]#statIn[/COLOR]; [COLOR="#008000"]//hier soll sich statLastIn den aktuellen Meßwert merken, es ist aber die Fläche[/COLOR]
Da hätte man dem Baustein lieber noch eine Variable mehr spendieren sollen.

"Gut gemeint" ist wohl auch der Fehler "#statLastIn := 0.0" wenn enable = false ist
(btw.: Wer formuliert sowas: "IF NOT #enable = true THEN" ???)

Für das V15 Projekt hat man den V13-Quellcode nochmal angefasst (kosmetische Änderungen der Variablennamen der Stat- und Temp-Variablen), es hat sich aber offensichtlich wieder niemand gefunden, der den Baustein mal länger als eine Minute testet, ob er denn auch das tut was er soll...
(sind die Fehler in fast 3 Jahren niemandem aufgefallen? Sind die Anwender so doof oder verwendet niemand den Baustein?)

Dabei ist ein kurzer Test doch so einfach zu realisieren:
- den FB-Eingang "in" fest mit 27648 (für 10 V) beschalten und 10s lang "enable" aktivieren
- da muß dann 10 V * 10 s = 100 Vs rauskommen, egal in welchen Zeitabständen man den Integrierer aufruft

Tatsächlich kommt aber raus (PLCSIM, Aufrufe in "Cyclic interrupt OB30"), ich habe es jeweils 3x gemacht:
Code:
  10 Aufrufe alle 1000ms : 89.999775390625    Soll: 100.0
                           90.009765625
                           89.991162109375

1000 Aufrufe alle 10ms   : 50.2458775131216   Soll: 100.0
                           50.2510037625305
                           50.2458876837445
Erstaunlich wie ungenau/schwankend der Baustein rechnet trotz LREAL - weil die verwendete Uhrzeit (RD_SYS_T) nur 1ms Auflösung hat, versaut sie die Berechnung. Besser ist, die Zeit aus der Berechnung völlig rauszulassen und stattdessen den Integrierer in konstanten Zeitabständen in einem "Cyclic interrupt" aufzurufen. (Siemens gibt nirgends den Hinweis, daß für diesen Baustein die SPS-Uhr nicht verstellt/synchronisiert werden darf)

Warnt das TIA V15 eigentlich beim Übersetzen, daß dem FB-Out "error" nie etwas zugewiesen wird? (dabei hat man doch extra eine sooo schöne Erklärung in zwei Sprachen formuliert, was der Ausgang angeblich signalisiert...)

Nicht richtig durchdacht sind die Hinweise, was an dem Baustein remanent sein sollte. (in der V13-Bibliothek zum Download ist allerdings gar nichts remanent) Sehr wertvoll ist auch die Idee, die Integration über einen CPU-Spannungsausfall hinweg fortzusetzen...

Harald
 

Anhänge

  • 42469594_S7-1200_Integration_Theorie.png
    42469594_S7-1200_Integration_Theorie.png
    2,6 KB · Aufrufe: 22
  • 42469594_S7-1200_Integration_tatsächlich_10ms.png
    42469594_S7-1200_Integration_tatsächlich_10ms.png
    5,4 KB · Aufrufe: 23
  • 42469594_S7-1200_Integration_tatsächlich_1s.png
    42469594_S7-1200_Integration_tatsächlich_1s.png
    5 KB · Aufrufe: 22
  • 42469594_S7-1200_Integration_tatsächlich_2s.png
    42469594_S7-1200_Integration_tatsächlich_2s.png
    5,3 KB · Aufrufe: 22
Zurück
Oben