Ich hatte bislang angenommen, dass der 1-Minuten-Zeitraum stets vom letzten Eingangswert zurückgerechnet wird. Das frühere Testsignal war daher durch die Triggerperiode von 8 s auch so konstruiert, dass innerhalb des Zyklus kein Eingangswert genau auf eine Minutengrenze fallen konnte, bzw. der längste Abstand innerhalb einer Minute vor dem letzten Signal 56 Sekunden betrug (7*8) und das nächstfrühere Signal 64 Sekunden vor dem letzten Signal lag.
Nun ist mir die Vermutung gekommen, dass der Minutenzeitraum dasselbe Minutenraster wie die Systemzeit hat. Um daraus möglicherweise enstehende Abtastprobleme testweise auszuschließen, habe ich das Testsignal so modifiziert, dass ein neuer Wert niemals auf eine Minutengrenze der Systemzeit fällt. Außerdem habe ich die Signalwerte so modifiziert, dass die Werte für den Mittelwert stets maximal zwei Nachkommastellen haben.
Das modifizierte Testsignal wird nun erzeugt, indem das Zeitmodul alle 6 Sekunden triggert (also genau 10/min), das Skript für die Signalerzeugung aber noch mit 3 Sekunden Verzögerung ausgeführt wird, d.h. bei 3,9,15,21, ..., 57, ..., 117 Sekunden.
Code: Alles auswählen
object o = dom.GetObject("Test:1").DPByHssDP("SET_STATE");
object o1 = dom.GetObject("Test:1").DPByHssDP("STATE");
real rVal;
integer iLT = ((localtime.ToInteger() % 84600) % 120) / 6;
if (iLT == 5) {rVal = 0.555;}
else {rVal = 1.005+iLT.ToFloat()/100.0;}
! WriteLine(iLT);
! WriteLine(rVal);
o.State(rVal);
! WriteLine(o1.State());
object oLogit = dom.GetObject("CUxD.CUX2801001:1.LOGIT");
oLogit.State("Wrapper"#";"#rVal);
Das Ergebnis im Log-File sieht dann so aus: Dementsprechend habe ich die Analyse mittels Excel (Tabelle1_4) ebenfalls angepasst. Nun stimmt (mit Verschiebung) alles exakt überein:
VG,
Peter