Nein! Auch das ist schon WunschDenken. Nicht einmal das passt, weil bereits der vergurkte Wert in #statLastIn draufaddiert wurde anstelle des vorherigen Wertes der normierten/skalierten ProzessVariablen.
FUNCTION_BLOCK INTEGRATE
VAR_INPUT
E : BOOL := TRUE;
X : REAL;
K : REAL := 1.0;
END_VAR
VAR_IN_OUT
Y : REAL;
END_VAR
VAR
X_last : REAL;
init: BOOL;
last: DWORD;
tx: DWORD;
END_VAR
(*read system time *)
tx := T_PLC_MS();
IF NOT init THEN
init := TRUE;
X_last := X;
ELSIF E THEN
Y := (X + X_LAST) * 0.5E-3 * DWORD_TO_REAL(tx-last) * K + Y;
X_last := X;
END_IF;
last := tx;
END_FUNCTION_BLOCKFUNCTION T_PLC_MS : DWORD
VAR CONSTANT
debug : BOOL := 0;
N : INT := 0;
offset : DWORD := 0;
END_VAR
VAR
tx : TIME;
END_VAR
(*
version 1.2 16. nov 2008
programmer hugo
tested by oscat
T_PLC_MS reads the internal PLC timer and return the time, it has the advantage to be able to set a debug mode
and speed up the counter to test the plc timer overrun which occurs every 50 days respectively 25 days at siemens S7
this routine also allows to correct the behavior of s7 where the internal plc counter will not count all 32 bits.
*)
(* @END_DECLARATION := '0' *)
tx := TIME();
T_PLC_MS := TIME_TO_DWORD(Tx);
(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim Überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei Überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)
IF debug THEN
T_PLC_MS := (SHL(T_PLC_MS,N) OR SHL(DWORD#1,N)-1) + OFFSET;
END_IF;
(* revision history
hm 14.9.2007 rev 1.0
original version
hm 12. nov 2007 rev 1.1
added temporaray variable tx because some compilers could not handle time() as an argument
hm 16. nov. 2008 rev 1.2
initialized constants with 0 for compatibility reasons
*)
END_FUNCTIONDas ist die Codesys-Version der Bausteine, die funktionieren so nicht richtig in S7-CPU.
FUNCTION_BLOCK INTEGRATE
TITLE = 'INTEGRATE'
//Das Integral vom Eingangswert X ermitteln mit Trapezregel.
VERSION : '1.0'
AUTHOR : PN_DP
VAR_INPUT
enable : BOOL := FALSE;
cycle1 : BOOL := TRUE; //TRUE im 1.Zyklus CPU STOP/RUN
reset : BOOL := FALSE; //Reset Y:=0.0
X : REAL; //Eingangswert
END_VAR
VAR_IN_OUT
Y : REAL; //Integral
END_VAR
VAR
X_last : REAL;
t_last: TIME;
init_done : BOOL := FALSE; //möglichst nicht remanent, oder im 1.Zyklus CPU STOP/RUN auf 0, oder cycle1 benutzen
END_VAR
VAR_TEMP
t_x : TIME; //System Time jetzt
dt_ms_r : REAL; //Delta t (ms) zu letztem Durchlauf
END_VAR
BEGIN
(* read system time (ms) *)
t_x := TIME_TCK(); //S7-CPU: 0 .. 2.147.483.647 ms mit Überlauf zu 0 (bei RUN/STOP und nach ca. 25 Tagen)
IF reset THEN //Nullen des Integrals
Y := 0.0;
END_IF;
(* im 1. Zyklus CPU STOP/RUN oder neu laden des IDB: nur t_last und X_last merken *)
IF NOT(init_done) OR cycle1 OR reset THEN
init_done := TRUE;
// Y := 0.0; //bei Laden des IDB lieber kein Reset
// X_last := X; //wird sowieso immer gemacht; t_last ebenso
ELSIF enable THEN
(* Delta t (ms, REAL) zu letztem Durchlauf, mit Korrektur bei Überlauf system time *)
dt_ms_r := DINT_TO_REAL(DWORD_TO_DINT( DINT_TO_DWORD(TIME_TO_DINT(t_x - t_last)) AND 16#7FFF_FFFF ));
(* Integrieren mit Trapezregel *)
Y := (X + X_last) * 0.5 * 0.001 * dt_ms_r + Y; //0.001: ms-->s
END_IF;
X_last := X;
t_last := t_x;
END_FUNCTION_BLOCK
(*
// cycle1 im 1. OB1-Zyklus z.B. so (AWL):
L #OB1_SCAN_1
L 3
<>I
= "IDB_INTEGRATE".cycle1
*)
Wie stellt sich Siemens das vor? :roll:FUNCTION_BLOCK "INTEGRATE"
TITLE = 'INTEGRATE'
AUTHOR : PN_DP
VERSION : 1.0
//Das Integral vom Eingangswert X ermitteln mit Trapezregel.
VAR_INPUT
enable : Bool := FALSE;
cycle1 : Bool := TRUE; // TRUE im 1.Zyklus CPU STOP/RUN
reset : Bool := FALSE; // Reset Y:=0.0
X : Real; // Eingangswert
END_VAR
VAR_IN_OUT
Y : LReal; // Integral
END_VAR
VAR
X_last : LReal;
t_last : LReal;
init_done : Bool := FALSE; // möglichst nicht remanent, oder im 1.Zyklus CPU STOP/RUN auf 0, oder cycle1 benutzen
[COLOR="#A52A2A"] Runtime_overflow : UInt; // Test: Zähler RUNTIME()-Überläufe[/COLOR]
[COLOR="#A52A2A"] t_max : LReal; // Test: höchste erreichte RUNTIME()-Startzeit[/COLOR]
END_VAR
VAR_TEMP
dt_s_r : LReal; // Delta t (s) zu letztem Durchlauf
END_VAR
BEGIN
// INTEGRATE für S7-1200/S7-1500, getestet mit PLCSIM V13 SP1 als CPU 1215C Firmware V4.1
(* Zeit (s) seit letztem Aufruf *)
#dt_s_r := RUNTIME(#t_last);
[COLOR="#A52A2A"]IF #t_last > #t_max THEN #t_max := #t_last; END_IF; //Testcode: ca. Überlaufzeitpunkt ermitteln und merken[/COLOR]
IF #dt_s_r < 0.0 THEN //hat RUNTIME() einen Überlauf? kommt alle ca. 1696.725 s ~ 28 Minuten vor (PLCSIM V13 SP1)
#dt_s_r := #dt_s_r + 1696.726; //empirisch ermittelter Korrekturwert 1696.725 s + 1 ms vorsichtshalber
[COLOR="#A52A2A"] #Runtime_overflow := #Runtime_overflow + 1; //Testcode: RUNTIME()-Überlaufzähler[/COLOR]
END_IF;
IF #reset THEN //Nullen des Integrals
#Y := 0.0;
END_IF;
(* im 1. Zyklus CPU STOP/RUN oder neu laden des IDB: nur t_last und X_last merken *)
IF NOT(#init_done) OR #cycle1 OR #reset THEN
#init_done := TRUE;
// Y := 0.0; //bei Laden des IDB lieber kein Reset
// X_last := X; //wird sowieso immer gemacht; t_last ebenso
ELSIF #enable THEN
(* Integrieren mit Trapezregel *)
#Y := (#X + #X_last) * 0.5 * #dt_s_r + #Y;
END_IF;
#X_last := #X;
// cycle1 mit Systemmerker "FirstScan" beschalten
// RUNTIME() hat irgendwann Überlauf (liefert dann <0.0)! System Time für RUNTIME() läuft weiter während CPU STOP!
// TIA V15 SP1 Hilfe sagt schwammig: Die Anweisung "Laufzeitmessung" verwendet einen internen hochfrequenten Zähler
// um die Zeit zu berechnen. Wenn der Zähler überläuft, gibt die Anweisung Werte <= 0.0 zurück. Dies kann für
// S7-1200-CPUs mit Firmware Stand <V4.2 bis zu einmal pro Minute vorkommen. Diese Runtimewerte sind zu ignorieren. (!)
// Mit TIA PLCSIM V13 SP1 empirisch ermittelter Überlaufzeitpunkt (siehe t_max): ca. 1696.725 s
END_FUNCTION_BLOCK
Bei Aufruf in einem Cyclic interrupt kann man am besten kontrollieren, ob er richtig rechnet (und hat mir geholfen bei den Überläufen den Korrekturwert auszurechnen, weil ich da ja weiß welche Zeit rauskommen muß).
Schreib mal ein FALSE oder den Systemmerker "FirstScan" an den FB-Eingang Eingang cycle1 ...
Mist, dann ist das womöglich schlimmstenfalls in jeder CPU und jeder Firmwareversion (und in PLCSIM) anders, und deswegen will Siemens sich nicht festlegen und das Überlauf-Verhalten exakt dokumentieren? "Einfach ignorieren" ist aber auch keine Lösung!
Das Zeitintervall muß man nicht wissen, der FB misst das selber mit RUNTIME (bis auf die (ungelöste) Überlauf-Macke)
Du kannst einen Taktmerker + P-Flanke an enable anlegen, oder den FB in einem "Cyclic Interrupt" alle 100 ms aufrufen, oder ganz einfach im OB1 in jedem Zyklus aufrufen - der FB liefert am Ausgang Y das Integral Einheit_von_X * Sekunden, also z.B. X in Ampere (A) ergibt Y in AmpereSekunden (As)
Ich denke, Du brauchst noch mehr Kaffee. Auch LREAL-Werte kann man miteinander vergleichen und feststellen, ob und welcher Wert der größere ist, wenn sie auch noch so mini-mini-minimal unterschiedlich sind.
Mein V13SP1-PLCSIM für eine S7-1500 CPU läuft auch (noch) nicht über. Weil die S7-1500 die TIME_TCK-Anweisung haben, vermute ich mal, daß RUNTIME bei S7-1500 ebenfalls nach 2147483,647 s (ca. 24,8 Tage) überläuft und der Korrekturwert wäre in dem Fall +2147483,648
Irgendwas läuft bei Dir verkehrt, vielleicht beobachtest Du falsch? t_last sind die Sekunden und Sekundenbruchteile seit Start des System timers und wird als LREAL von RUNTIME() geliefert - wenn da wirklich mal als Gleitpunkt ungültige Werte drin stehen würden, dann könnte man keiner von Siemens vorgefertigten Anweisung/Baustein mehr trauen, besonders nicht den so schlecht dokumentierten ...
Hmm, komisch.
Ja, da gibt es Grenzen, die weiß ich aber nicht genau. Ich meine, ab 1000 Pixel Breite wird zwangsweise auf jpg-Format gewandelt und vielleicht ab 2000 Pixel wird das Bild verkleinert.
TIA V15.1
Die Info an den Beinchen des RUNTIME-Bausteins sagen auf beiden Seiten LReal, LWord
Nein. Ich hatte das Phänomen beim einfachen Aufruf von Runtime mit Merkern an den Beinchen und daraufhin deinen Baustein übernommen. Den IDB gab es vorher nicht.
Ja, so sollte es sein, da bin ich ganz deiner Meinung. Und nein, die 8. Stelle von rechts etwa im 0,5s Takt
Führt in diesem Fall beides zur selben Darstellung. Deswegen hatte ich die Beobachtungstabelle mit in den Screenshot genommen.
