LBS 19000100 Betriebsstundenzähler

[WagoKlemme]

Hallo Michael,

könntest Du bitte - bei Gelegenheit - mal diesen LBS unter die Lupe nehmen. Er funktioniert, aber beim Triggern (speichern des iKOs) mit E2 gibt es leichte "Irritationen".
Der E2 wird getriggert mit folgendem Ergebnis:

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
[TR]
[TD]2016-09-26 22:00:00[/TD]
 			[TD]262038[/TD]
 			[TD]INTERN[/TD]
 			[TD] [/TD]
 			[TD]-[/TD]
 			[TD]1316[/TD]
 			[TD]Steckdose Maxi PC Betriebsstunden mit Minuten und Sekunden[/TD]
 			[TD]675:29:28[/TD]
 		[/TR]
[/TABLE]
[TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
[TR]
[TD]2016-09-26 23:00:00[/TD]
 			[TD]290905[/TD]
 			[TD]INTERN[/TD]
 			[TD] [/TD]
 			[TD]-[/TD]
 			[TD]1316[/TD]
 			[TD]Steckdose Maxi PC Betriebsstunden mit Minuten und Sekunden[/TD]
 			[TD]678:47:40[/TD]
 		[/TR]
[/TABLE]
[TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
[TR]
[TD]2016-09-27 11:00:00[/TD]
 			[TD]183254[/TD]
 			[TD]INTERN[/TD]
 			[TD] [/TD]
 			[TD]-[/TD]
 			[TD]1316[/TD]
 			[TD]Steckdose Maxi PC Betriebsstunden mit Minuten und Sekunden[/TD]
 			[TD]718:42:16[/TD]
 		[/TR]
[/TABLE]

Screenshot - 27_09.png









E4 habe ich *räusper* dazugefummelt, damit er keine Resourcen klaut wenn das Gerät aus ist (if ($E[4]['value']==1) über alles). Dürfte aber mit dem o.g. Problem nichts zu tun haben, da er dieses Verhalten schon vorher hatte.

[wintermute]

Huh, der frisst auch noch Ressourcen?
Ich schau mir das an und melde mich!

[WagoKlemme]

Huh, der frisst auch noch Ressourcen?

Bei Inaktivität sprich Gerät läuft gar nicht - ja. Er wird ja jede halbe Stunde sinnlos getriggert.
OT:
Vielleicht liegt mein "Spardrang" daran, dass seit März bei mir alles (Logik und Visu) über Edomi läuft und durch das ständige dazubauen Performanceeinbußen spürbar da sind. NACH der Projektaktivierung brauche ich inzwischen fast 3 Minuten bis er über den "Logikberg" ist und das ohne irgendwelche IP Geschichten. Mein Server ist zu 99,9% offline. 1268 KOs, 1380 LBS, 72 Visuseiten.

Danke Dir.

[wintermute]

3 Minuten ist mal ne Ansage
Aber den halbstuendigen Aufruf nehme ich fuer mich dann trotzdem so hin
Den Rest guck ich mir an!

gruesse :: Michael

[gaert]

Die 3 Minuten dürften wohl eher dem Initscan geschuldet sein - bei 1268 KOs und vermutlich 50% mit Initscan-Option...

[starwarsfan]

Hallo miteinander

NACH der Projektaktivierung brauche ich inzwischen fast 3 Minuten bis er über den "Logikberg" ist und das ohne irgendwelche IP Geschichten. Mein Server ist zu 99,9% offline. 1268 KOs, 1380 LBS, 72 Visuseiten.

Das ist bei mir vom Volumen her ähnlich aber ich spüre keinerlei Performance-Einbussen. Hätte jetzt die gleiche Vermutung geäussert wie Christian: Viele Initscan. Bist Du sicher, dass Du dort nicht GAs abfragst, welche das entsprechende Flag nicht gesetzt haben bzw. wo eben keiner drauf antwortet?

[WagoKlemme]

gaert
Ja es sind geschätzt 400 mit Initscan, damit gehe ich sehr sparsam um. Nur die wirklich Notwendigen.
Ich sehe allerdings auch an der Visu, dass er Stück für Stück die Logik umgesetzt aufs Bild bringt.

starwarsfan
Wenn ich GAs abfrage deren Flags nicht gesetzt sind kommt doch eine Fehlermeldung, oder ?
Fehlermeldungen sind allerdings SEHR selten und von der Art InitScan (3 GAs / 5 Abfragen / 25 Checks)
Manchmal, dann wieder nicht, diese Fehlermeldungen und das erst seit ca. 2 Monaten, vorher nie.
Mein Xoro scheint mit der Visu auch zunehmend ein Problem mit seinem Cache zu bekommen. Seitenwechsel werden schon Monat für Monat und Zubau merklich träger.
Am PC ist es noch flüssig wie am ersten Tag.

wintermute
So vernachlässigbar sehe ich das nicht, wenn man das über alle LBS betrachtet. Kleinvieh macht auch Mist.
Na dann warte ich mal bis Du soweit bist. Schätze mal bei Dir steuert immer noch was Anderes (HS?) als Edomi dein Haus.
Dieses "Feintuning" über die ganze Logik hat die CPU Auslastung immerhin um ca. 2% gesenkt auf momentan 0.8-2.2%. Dafür kann ich dann wieder was an Logik dazubauen.
Ausserdem so "ticke" ich halt. Ich laufe auch jedem einzelnen Watt nach. Lohnt sich nicht aber macht Spaß.
Liegt vielleicht am Alter/Generation.

[gaert]

Meine Logik besteht z.Z. aus >2000 LBS Tendenz stark steigend... Latenzen kann ich keine feststellen (zumindest nicht spürbar). Allerdings versuche ich natürlich auch meine Logiken halbwegs "intelligent" umzusetzen, sprich: sparsam. Beispiel: Ein LBS, der 20 Ausgänge setzt, führt letztlich 20 DB-Operationen diesbezüglich durch. Wenn ich aber nur z.B. A1 und A2 benötigen würde, wäre der LBS für mich "raus" Ich würde den Burschen dann entsprechend modifizieren...

[WagoKlemme]

Nur um keinen falschen Eindruck zu erwecken. Ich bin top zufrieden. Nein, mehr als das...

Logiken halbwegs "intelligent" umzusetzen, sprich: sparsam.

Genau um das ging es mir oben. Freut mich nicht alleine zu sein.

[wintermute]

Ich hab grad mal (wirklich nur mal) fluechtig druebergeguckt.... sicher, dass der Baustein selber dafuer verantwortlich ist, dass er jede halbe Stunde neu gestartet wird? o\

[WagoKlemme]

Ich soll/muss doch die Betriebsstunden regelmässig in ein remanentes iKO sichern, sonst gibts doch Lücken z.B. bei der Projektaktivierung. Der LBS schreibt es sonst nicht raus ins iKO. Das macht er nur bei E2=1.
Das Problem oben ist, dass er die Stunden nicht richtig zählt. Ausser dein Tag hat z.B. 42 h. Schau mal links Datum und Uhrzeit und rechts die Stunden. Das kann nicht sein.
Oder reden wir komplett aneinander vorbei.

Edit:
Ich habe jetzt auch mal reingeschaut. Eigentlich sollte jede Wirkleistungsänderung auch ein Schreiben ($E1['refresh'] ) auf das iKO auslösen.
Das tut es aber nicht, zumindest nicht mit der Live-Ansicht. Mache ich allerdings auf E2 einen Refresh dann tuts, auch mit der Live-Ansicht.
Stand bei mir und Workaround zu dem Punkt "Baustein neugestartet".
Unabhängig davon zählt er dann nicht richtig - der Zähler läuft der realen Zeit davon.
Im o.g. Log sieht man um 22.00 Uhr 675h und am nächsten Tag um 11Uhr 718h. Obwohl E1=0 (und E4=0=Baustein deaktiviert) war, von 01:00-10:44 am Folgetag.

Edit2: Nach 1 3/4h Beobachtung: Gestartet mit 695:00:00 um 20.00Uhr bin ich jetzt um 21.39Uhr bei 700:39:04.

[wintermute]

Ja, wie gesagt, das mit der verschrobenen Zeit schau ich mir noch an. Leider grad nicht allzuviel Zeit wegen GaLa-Bau und so
gaert Und bzgl der 30 Minuten und weil ich ja weiss, dass Christian hier mitliest
Ein KO das beim regulaeren Shutdown von Edomi auf 1 gesetzt wird (und dann gibts ja noch diese 3s Karenzzeit oder so) waer ne prima Sache. Damit koennte man Probleme mit remanent zu speichernden Sachen deutlich sauberer loesen....

[panzaeron]

Ein KO das beim regulaeren Shutdown von Edomi auf 1 gesetzt wird (und dann gibts ja noch diese 3s Karenzzeit oder so) waer ne prima Sache. Damit koennte man Probleme mit remanent zu speichernden Sachen deutlich sauberer loesen....

Noch besser wäre es, wenn ich innerhalb des LBS abfragen könnte, ob EDOMI sich noch innerhalb der Startphase befindet. Dann benötigt man keinen extra Eingang...

[gaert]

Das SysKO wird unmittelbar nach dem Initscan/Initsend auf 0 gesetzt, dann erfolgt die LBS-Initialisierung und wenn diese durch ist, wird das KO auf 1 gesetzt. Der Haken an der Sache: Das KO kannst Du im LBS nicht "abfragen" Es muss also so oder so auf einen Eingang gelegt werden.

Aber Du kannst die Funktion getSysInfo(1) verwenden - diese liefert u.a. diese Werte:
1=Initialisierungsphase
2=Bereit

[wintermute]

Und bzgl des "Shutdown-KOs"?