TIA S7-1200 Amperestunden Zähler

Zuviel Werbung?
-> Hier kostenlos registrieren
Moin, Danke für die Infos.
Die CPU Firmware ist aktuell. Daran sollte es nicht liegen.
In TIA V15.1 hat Siemens im SCL/AWL-Compiler was an RUNTIME gefummelt, allerdings laut Liesmich nur an der Syntaxprüfung, ob am Parameter MEM auch wirklich eine Variable vom Datentyp LREAL verwendet ist (also unsere Variable t_last).

Ich glaube, man müsste mal den Siemens Support fragen, ob da jetzt ein Bug bei RUNTIME ist. Kann noch jemand dieses komische Verhalten mit einer S7-1500-CPU testen?

Macht es einen Unterschied, ob der FB INTEGRATE optimierten oder Standard-Bausteinzugriff hat? Vielleicht ist da ein Fehler bei der Übergabe der LREAL-Variable an den Parameter MEM?
Wenn man nur die Anweisung RUNTIME in FUP oder KOP aufruft mit zwei LREAL-Variablen, wird dann an MEM ein normaler Gleitkommawert angezeigt? so wie hier:
Beispiel 1: Laufzeitmessung mit der Anweisung "RUNTIME" für die S7-1200/S7-1500
Wenn man RUNTIME in SCL nicht mit lokalen Variablen des IDB aufruft, sondern mit globalen LREAL-Variablen (aus DB oder Merker) funktioniert es dann richtig?

TheLevel schrieb:
Die Info an den Beinchen des RUNTIME-Bausteins sagen auf beiden Seiten LReal, LWord
Zum Vergrößern anklicken....
Hast Du vielleicht davon ein kleines Bildchen? Ich meine, LWord dürfte im Umfeld von RUNTIME nicht auftauchen (vielleicht ist es auch nur einer der sehr vielen Fehler in der TIA Hilfe...).


@digidax
Sorry, daß es hier jetzt nicht mehr direkt um Deinen Amperestunden-Zähler geht, sondern um diverse Siemens-Bugs ... sollten wir einen neuen Thread aufmachen?

Harald
 
PN/DP schrieb:
Macht es einen Unterschied, ob der FB INTEGRATE optimierten oder Standard-Bausteinzugriff hat? Vielleicht ist da ein Fehler bei der Übergabe der LREAL-Variable an den Parameter MEM?
Wenn man nur die Anweisung RUNTIME in FUP oder KOP aufruft mit zwei LREAL-Variablen, wird dann an MEM ein normaler Gleitkommawert angezeigt? so wie hier:
Beispiel 1: Laufzeitmessung mit der Anweisung "RUNTIME" für die S7-1200/S7-1500
Wenn man RUNTIME in SCL nicht mit lokalen Variablen des IDB aufruft, sondern mit globalen LREAL-Variablen (aus DB oder Merker) funktioniert es dann richtig?
Zum Vergrößern anklicken....
Optimiert oder nicht optimiert spielt keine Rolle, mit Merkern hatte ich ja davor schon getestet und geht auch nicht, hatte ich ja schon erwähnt.

PN/DP schrieb:
Hast Du vielleicht davon ein kleines Bildchen? Ich meine, LWord dürfte im Umfeld von RUNTIME nicht auftauchen (vielleicht ist es auch nur einer der sehr vielen Fehler in der TIA Hilfe...).
Zum Vergrößern anklicken....
Test_runtime_2.png

Im SCL-Aufruf steht nur LReal. Das LWord taucht nur in FUP auf.
 
Diskutiert ruhig weiter, hat ja was damit zu tun. Ich habe jetzt im OB1 den INTEGRATE FB eingefügt, cycle1 ist mit "first scan" belegt, X hat den konstanten Wert 10.0 zugewiesen.
Weiterhin ein DIV, welches Y durch 3600 dividiert (also aus As werden Ah).

Ich habe es gestartet und dann hat es hochgezählt, nach 30 min hätte ich einen Wert von 5 Ah erwartet. Nachdem von Euch empfohlenen Kaffe holen stehen nun 9,4 Ah zu Buche, innerhalb von weniger als 3 min, die ich am Kaffeautomat war. Y Wert ist 33830.37586260...

Hab jetzt ein Meeting, probier unter Beobachtung des INTEGRATE_DB dann noch mal die Werte.

1000 Dank für die äußert professionelle Hilfe, mein Ticket bei Siemens is bislang unbeantwortet.

Mein System:
S7-1200 1214C DC/DC/DC
6ES7 214-1AG40-0XB0
Firmware V 4.1
TIA V15 Update 4
 
Zuviel Werbung?
-> Hier kostenlos registrieren
digidax schrieb:
mein Ticket bei Siemens is bislang unbeantwortet.
Zum Vergrößern anklicken....

PN/DP schrieb:
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.
Zum Vergrößern anklicken....
Meine Meinung: Vergiss den Siemens-Baustein
Zum Vergrößern anklicken....
Wie wir festgestellt haben rechnet dieser Integrationsbaustein falsch wegen diverser Programmierfehler. Siemens reagierte bisher auch nicht auf meine Fehlermeldung zu dem Beitrag (Beitrag zu alt?). Sollen sich doch ruhig noch weitere Dummies ohne Ahnung den Baustein in ihre Programme einbauen...

Ich habe gerade gefunden, daß es nun einen Integrator-FB in der LGF gibt: Bibliothek mit generellen Funktionen (LGF) für STEP 7 (TIA Portal) und S7-1200 / S7-1500

Du kannst ja mal diesen FB LGF_Integration testen. Weil ich kein TIA V15 habe, kann ich mir den SCL-Quelltext leider nicht ansehen, ob der nun korrekt programmiert ist. Die Beschreibung zum FB LGF_Integration verwendet das selbe Bild wie der Support-Beitrag mit dem fehlerhaften Baustein. (Zumindest hat der LGF Baustein vermutlich den selben Makel, daß er die Uhrzeit der SPS-CPU verwendet.)

Könntest Du bitte von dem FB LGF_Integration eine SCL-Quelle erstellen und hier an einen Beitrag anhängen?
(Baustein in ein Projekt einfügen - Rechtsmausklick > Quelle aus Baustein generieren > "LGF_Integration.scl" - dann die Datei umbenennen zu "LGF_Integration.scl.txt" und hier an einen Beitrag anhängen/hochladen)

Harald
 
Zuletzt bearbeitet:
PN/DP schrieb:
Könntest Du bitte von dem FB LGF_Integration eine SCL-Quelle erstellen und hier an einen Beitrag anhängen?
(Baustein in ein Projekt einfügen - Rechtsmausklick > Quelle aus Baustein generieren > "LGF_Integration.scl" - dann die Datei umbenennen zu "LGF_Integration.scl.txt" und hier an einen Beitrag anhängen/hochladen)

Harald
Zum Vergrößern anklicken....

Code: 
FUNCTION_BLOCK "LGF_Integration"{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      value : Real;   // -
      enable : Bool;   // -
      reset : Bool;   // -
   END_VAR


   VAR_OUTPUT 
      integral : Real;   // -
      error : Bool;   // -
      statusID : UInt;   // -
      status : Word;   // -
   END_VAR


   VAR 
      statSysTime {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;   // -
      statLastTime {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;   // -
      statOldValue : Real;   // -
      statIntegral : Real;   // -
      tempValue { ExternalAccessible := 'False'; ExternalVisible := 'False'; ExternalWritable := 'False'} : Real;   // -
      tempDeltaTimeT { ExternalAccessible := 'False'; ExternalVisible := 'False'; ExternalWritable := 'False'} : Time;   // -
      tempDeltaTimeDInt { ExternalAccessible := 'False'; ExternalVisible := 'False'; ExternalWritable := 'False'} : DInt;   // -
      tempDeltaTimeReal { ExternalAccessible := 'False'; ExternalVisible := 'False'; ExternalWritable := 'False'} : Real;   // -
      tempRetval { ExternalAccessible := 'False'; ExternalVisible := 'False'; ExternalWritable := 'False'} : Int;   // -
   END_VAR


   VAR CONSTANT 
      ZERO : Real := 0.0;
      NO_ERROR : Word := 16#0000;   // -
      NO_CURRENT_JOBS : Word := 16#7000;   // -
      ERROR_IN_THIS_BLOCK : UInt := 1;   // error in this block
      ERROR_RD_SYS_T : UInt := 2;   // error in RD_SYS_T
   END_VAR




BEGIN
	//=============================================================================
	// SIEMENS AG
	// (c)Copyright 2017
	//-----------------------------------------------------------------------------
	// Library:       LGF (Library General Functions)
	// Tested with:   CPU1212C DC/DC/DC FW:V4.2
	// Engineering:   TIA Portal V14 Upd 1
	// Restrictions:  -
	// Requirements:  PLC (S7-1200 / S7-1500)
	// Functionality: The input value will be integrated.
	//                
	//-----------------------------------------------------------------------------
	// Change log table:
	// Version  Date        In charge Changes applied
	// 01.00.00 17.02.2017  Siemens Industry Online Support
	//                      First released version
	// 01.00.01 17.08.2018  Siemens Industry Online Support
	//                      Upgrade: TIA V15 Update 2
	//-----------------------------------------------------------------------------
	//=============================================================================
	
	// Initialization
	#error := FALSE;
	#statusID := #NO_ERROR;
	#status := #NO_CURRENT_JOBS;
	
	// Reset 
	IF #reset = true THEN
	  #integral := #ZERO;
	  #statOldValue := #ZERO;
	  #statIntegral := #ZERO;
	  RETURN;
	END_IF;
	
	// Write input value to temp variable
	#tempValue := #value;
	
	// Read system time
	#tempRetval := RD_SYS_T(OUT => #statSysTime);
	
	// Error Handling read system time
	IF (#tempRetval > 1) THEN
	  #error := TRUE;
	  #statusID := #ERROR_RD_SYS_T;
	  #status := INT_TO_WORD(#tempRetval);
	  RETURN;
	END_IF;
	
	// Calculate time difference between last and actual time
	#tempDeltaTimeT := #statSysTime - #statLastTime;
	
	// Convert times difference to REAL
	#tempDeltaTimeDInt := TIME_TO_DINT(#tempDeltaTimeT);
	#tempDeltaTimeReal := DINT_TO_REAL(#tempDeltaTimeDInt);
	
	// Convert in seconds
	#tempDeltaTimeReal := #tempDeltaTimeReal / 1000.0;
	
	// Write actual to last time
	#statLastTime := #statSysTime;
	
	IF NOT #enable = true THEN
	  #statOldValue := #ZERO;
	  RETURN;
	END_IF;
	
	// Add LastScalIn to ScalIn
	#tempValue := #tempValue + #statOldValue;
	
	// Save last input
	#statOldValue := #value;
	
	// Divide in half statScalIn
	#tempValue := #tempValue / 2.0;
	
	// Multiply with Delta Time
	#tempValue := #tempValue * #tempDeltaTimeReal;
	
	// Calculate new integral
	#statIntegral := #statIntegral + #tempValue;
	
	// Write outputs
	#integral := #statIntegral;
	#status := #NO_ERROR;
END_FUNCTION_BLOCK
 
Ach Harald,
wie lange hättest Du gebraucht, um Dir einen eigenen Integrator zu programmieren und wieviel Zeit hast Du jetzt schon damit vergurkt, hinter dem Siemens-Integrator her zu forschen?

Ich glaube, dass Siemens eine Möglichkeit anbietet, die vertane Zeit wieder reinzuholen, gefunden dank Deinem RuntimeLink:
NegativeWarteZeit.jpg
Wartezeiten empfindet man zwar fast immer als negativ, aber wenn man negative WarteZeiten jetzt (oder demnächst, bei künftigen CPUs) auch programmieren kann, ist das doch unglaublich positiv!
Die Wirkungsweise ist zwar nicht beschrieben, aber ich vermute, die in den letzten n µs durchlaufenen Befehle werden aufgerubbelt und die gesparte Zeit dem nächsten PLC-Zyklus gutgeschrieben.
Das kommt allen HochSprachenProgrammierern sehr entgegen, deren Belange Siemens offensichtlich um jeden Preis berücksichtigen will.
Endlich ein WAIT-Befehl für PLC-Programme! Noch dazu die Möglichkeit, vertane Zeiten wieder reinzuholen. Dem Trial-and-Error mit Backtracking steht jetzt nichts mehr im Wege.

Ich bin auch über einen versteckten Tipp von Siemens gestolpert:
BestBeforeDateRuntime.jpg
"Best before date"! Das ist es doch! Programme und Daten mit VerfallsDatum! Soll vermutlich heissen: funktioniert nur bis zum nächsten Update.

Andererseits, Gewährleistung für das korrekte Programmieren kann man ohnehin nicht mehr übernehmen:
OptimierteProgramme.jpg
. . . denn, wenn der Compiler sowieso das tut, was er für besser hält . . .

PS:
Habe gerade #47 gelesen. Das wird ja immer aufregender! Siemens gibt sich sooo viel Mühe (leider!).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Also der Integrator aus der LGF läuft gerade auf einer s7-1200 mit konstant 10.0 am Eingang, enables über einen TP mit einer Länge von 15 Minuten.
Nach Ablauf dessen sollten dann 2,5 AH auf der Uhr stellen. Die SPS hat einen eingerichteten NTP Sync, welche hier in die Suppe spucken könnte da
mit der SysTime integriert wird.
Werden dann nochmal mit deaktivierter Zeitsynchronisation testen.
 
So, Kochkurs mit Harald undHeinileini ergab bei aktiven NTP Sync Intervall von 3600 sec: 2,5 Ah bei 10 A am Eingang.
Das Ganze jetzt nochmal, diesmal den NTP Sync auf 60 sec. gesetzt.
 
Heinileini schrieb:
Habe gerade #47 gelesen. Das wird ja immer aufregender! Siemens gibt sich sooo viel Mühe (leider!).
Zum Vergrößern anklicken....
*ROFL*
Ja, "Die LGF wurde mit dem Programmierstyleguide erstellt." :ROFLMAO:
Sollen jetzt alle Industrie-Programme so infantil aussehen wie der LGF_Integration? ;)

Abgesehen von der Verwendung der SPS-Uhrzeit anstatt dem System timer (die kriegen das wohl selber nicht mit dem verhuntzten RUNTIME hin?) - wieso rechnen die das Integral nicht in LREAL sondern nur in REAL, wo doch S7-1200 und S7-1500 beide LREAL können?

PS: Wozu haben Bausteine eigentlich die Eigenschaft "VERSION", wenn da eh' immer nur 0.1 drin steht?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
PS: Wozu haben Bausteine eigentlich die Eigenschaft "VERSION", wenn da eh' immer nur 0.1 drin steht?
Zum Vergrößern anklicken....
Wenn die Version hochgezählt würde, würde doch jeder eine Verbesserung erwarten!
Aber was will man da noch verbessern? Noch mehr Kommentare? Noch mehr verzweifelte FehlerBehandlungen? Noch mehr "lesbare" Konstanten?
 
PN/DP schrieb:
*ROFL*
PS: Wozu haben Bausteine eigentlich die Eigenschaft "VERSION", wenn da eh' immer nur 0.1 drin steht?
Zum Vergrößern anklicken....

Das sind die Alpha Versionen und wir sind die Beta Tester. :ROFLMAO:

So, NTP Sync auf 60 sec gesetzt, dann wieder 15 min bei 10 A => Ergebnis: 2,5 Ah, passt.
Nun lass ich es mal über 1 Stunde laufen, morgen dann über 3 Stunden, das ist der Zeitrahmen, welcher für mich produktiv wichtig ist.
Dann nochmal statt 10 A konstant mit Analog Eingang vom Gleichrichter.

Den SCL Code könnte man ja bei der Variablendefinition von REAL auf LREAL anpassen?
 
Heinileini schrieb:
Aber was will man da noch verbessern?
Zum Vergrößern anklicken....
Vielleicht mal das Problem und die realisierte Lösung gründlich durchdenken und die kleinen Logikfehler der Lösung beseitigen? Doch das würde Zeit kosten und Zeit kostet Geld.
Naja, gegenüber der ersten veröffentlichten Baustein-Katastrophe rechnet der Baustein nun wenigstens ungefähr richtig. Bei der Genauigkeit darf man eben nicht so penibel sein.

Gibt es eigentlich eine "international übliche" Vorgehensweise beim numerischen Integrieren, daß man bei der ersten Integration ab enable = true nur einen zufällig großen Flächen-Bruchteil zwischen ein bisschen über 0 bis höchstens 50% in das Integral übernimmt?


digidax schrieb:
Den SCL Code könnte man ja bei der Variablendefinition von REAL auf LREAL anpassen?
Zum Vergrößern anklicken....
Ja klar, ich würde aber nicht den Baustein in der LGF-Bibliothek ändern sondern davon abgeleitet einen eigenen verbesserten Baustein entwickeln. Du kannst den FB aus der Bibliothek in ein Projekt einfügen, davon eine SCL-Quelle erzeugen, die SCL-Quelle in Dein eigentliches Projekt einfügen und daraus den Baustein erzeugen. An dem kannst Du dann alles ändern, verbessern und Fehler beseitigen. :cool:
Und wenn Dein Baustein dann viel besser als die Siemens Version ist, dann kannst Du Deinen Baustein auch Siemens anbieten, damit die Allgemeinheit was davon hat, falls Siemens das recht ist ;)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So nach einer Stunde mit NTP Sync aller 60 sec. und 10 A am Eingang x sind 9,9 Ah statt 10 Ah herausgekommen, laut Instanzbaustein 35696 As.
Differenz also 304 As was 0,084 Ah entspricht. hmmmmm, bei 3 Stunden wäre das eine Abweichung von 0,252 Ah. Mal sehen was der Galvaniker meint in Bezug auf seine Schichtdicke.
In die Fehlerrechnung muß dann auch die A/D Ungeneuigkeit, Messumformer Toleranz, Stromshunt usw. mit rein.

Werde morgen mal NTP sync komplett deaktivieren und mal über eine Stunde messen. Kann man den Sync auch vom Programm aus machen, also Nachts, wenn eh nichts läuft, so als Cron Job?
 
PN/DP schrieb:
Gibt es eigentlich eine "international übliche" Vorgehensweise beim numerischen Integrieren, daß man bei der ersten Integration ab enable = true nur einen zufällig großen Flächen-Bruchteil zwischen ein bisschen über 0 bis höchstens 50% in das Integral übernimmt?
Zum Vergrößern anklicken....
Weiss ich nicht. Üblich scheint zu sein, sich keine Gedanken darüber zu machen, zumal das Ergebnis ja eh nur "annähernd" dem Integral entsprechen soll.

Ich glaube dies ist ein Fall, bei dem man sinnvollerweise die Zählung bei 0 beginnen sollte.
Der nullte Aufruf nach enable darf m.E. nur das Ergebnis 0 als frisch gelöschte Summe liefern und (wie bei allen Aufrufen) für den nächsten Aufruf den aktuellen EingangsWert (und ggfs den aktuellen ZeitWert) abspeichern. Der "erste" Aufruf danach kann dann (wie alle folgenden Aufrufe - solange enable nicht unterbrochen wird) getrost die TrapezRegel mit sinnvollen Werten anwenden.
Statt beim nullten Aufruf die Summe zu löschen, könnte es sinnvoll sein, die Summe mit einem vorgegebenen Wert (AufrufParameter z.B. mit dem Wert 0 versorgt) vorzubesetzen. Aber wahrscheinlich würde dies eher zu Missverständnissen und Missbräuchen verleiten, als sinnvoll eingesetzt zu werden.
 
Heinileini schrieb:
Der nullte Aufruf nach enable darf m.E. nur das Ergebnis 0 als frisch gelöschte Summe liefern und (wie bei allen Aufrufen) für den nächsten Aufruf den aktuellen EingangsWert (und ggfs den aktuellen ZeitWert) abspeichern.
Zum Vergrößern anklicken....
Ich meine auch das wäre das korrekte Vorgehen. Wenn man sich das mal aufzeichnet sieht es richtig aus.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der nullte Aufruf nach enable darf m.E. nur das Ergebnis 0 als frisch gelöschte Summe liefern und (wie bei allen Aufrufen) für den nächsten Aufruf den aktuellen EingangsWert (und ggfs den aktuellen ZeitWert) abspeichern.
Zum Vergrößern anklicken....

Vollkommen korrekt, wie lange dauert im Idealfall das erste Zeitintervall? 1 ms?
Man müßte die Logik umdrehen:

In meinem Fall starte ich einen Prozess und integriere dann einen Anlogwert über eine unendlichlange Zeit bis das Integral einen vorgegebenen Wert erreicht, dann ist der Prozess beendet.

Der Integrator FB müsste zuerst gestartet werden, dann ist definitiv der analoge Eingang Null, wenn dann das erste Zeitintervall vorbei ist und damit für das Zweite ein Wert zur Verfügung steht, startet der Integrator FB den eigentlichen Prozess.

Die wäre meines Achtens die korrekte Vorgehensweise, fall am Integratoreingang X ein Wert > Null anliegt. In meinem Fall wäre der Wert aber eh Null, damit unwichtig.

So, Versuch mit deaktivierten NTP und 10 A konstant läuft gerade für eine Stunde, mal sehen wie groß die Abweichung ist.

Nochmal die Frage: läßt sich die Uhr zeitgesteuert aus dem Programm per NTP synchronisieren? z.B. um 3:00 Uhr früh?
 
digidax schrieb:
Nochmal die Frage: läßt sich die Uhr zeitgesteuert aus dem Programm per NTP synchronisieren? z.B. um 3:00 Uhr früh?
Zum Vergrößern anklicken....
Das weiß ich nicht, ich glaube nicht.

Du könntest im LGF_Integration die Uhrzeitverarbeitung entfernen und ihn in einem Cyclic Interrupt z.b. alle 50 ms aufrufen, dann stört die Uhrzeitsynchronisation nicht. #tempDeltaTimeReal ersetze in dem Fall durch die feste Zeit 50 ms (ist 0.05 s):
Code: 
	// Divide in half statScalIn and Multiply with Delta Time (s)
	#tempValue := #tempValue / 2.0 * 0.05; // wird alle 50 ms aufgerufen

Harald
 
So, mit deaktivierter NTP Sync hat er 261 As zu wenig gezählt. Die Uhrzeit scheint also systematisch "nachzugehen".
Ich werde Deinen Vorschlag mal umsetzen und erneut testen.
 
Zurück
Oben