Telegramme auf den Bus bei Systemstart

[pio]

Der besagte Code sollte dies allerdings nicht machen, oder?

Das ist genau mein Problem. Ich verstehe nicht, warum mein Code den EibPC in eine Endlos-Rebootschleife getrieben hat.

OK, mein Programm ist (ein bisschen) länger, dürfte aber bei weitem noch nicht an den Umfang eines echten Automation-Freaks herankommen. (Auslastung EibPC 3.88%).
Und ich habe bis jetzt noch kein systematisches Reduzieren ausprobiert.

... wenn ich Zeit finde, probiere ich mal meinen oben gezeigten Minimalcode aus .....

[SteffiEnertex]

Dein EibPC wurde durch die eval-Funktion zum Neustart getrieben.

" Wenn man nıcht aufpasst, kann das zum Zumuellen des Buesses bis nıcht mehr ansprechbar (bzw. Neustart) bedeuten."

Auszug aus Deinem Code:
[highlight=epc]
if eval(after(systemstart(),20000u64)) then {

...

...

if chtime(06,30,00) then {

write("EG Wohnen Jalou Position-2/1/104"u08,vJalouPosEGWohnen);

write("EG Essen Jalou Position-2/1/105"u08,vJalouPosEGEssen);

write("EG Terrasse Jalou Position-2/1/106"u08,vJalouPosEGTerrasse);

write("EG Wohnen Lamelle Position-2/2/104"u08,cLamellenAUF);

write("EG Essen Lamelle Position-2/2/105"u08,cLamellenAUF);

write("EG Terrasse Lamelle Position-2/2/106"u08,cLamellenAUF)

} endif;
...
...
} endif

[/highlight]


führt dazu, dass in jedem Zyklus die Abfrage chtime (06,30,00) ausgewertet wird.
Ist es jetzt nach 6:30h werden die write-Anweisungen immer wieder ausgeführt. Theoretisch bis 00:00h; nur leider packt das der EibPC nicht so lange und startet sich vorher neu.

[saft6luck]

Dein EibPC wurde durch die eval-Funktion zum Neustart getrieben.

" Wenn man nıcht aufpasst, kann das zum Zumuellen des Buesses bis nıcht mehr ansprechbar (bzw. Neustart) bedeuten."

Puh, ich glaube die Gefahr von eval() ist nun bekannt. Den Bus zumüllen kann man aber auch ohne eval() mit Leichtigkeit!

[highlight=epc]
if eval(after(systemstart(),20000u64)) then {
...
if chtime(06,30,00) then {
write("EG Wohnen Jalou Position-2/1/104"u08,vJalouPosEGWohnen);
...
} endif;
...
} endif
[/highlight]

führt dazu, dass in jedem Zyklus die Abfrage chtime (06,30,00) ausgewertet wird.
Ist es jetzt nach 6:30h werden die write-Anweisungen immer wieder ausgeführt. Theoretisch bis 00:00h; nur leider packt das der EibPC nicht so lange und startet sich vorher neu.

Ist wieder so ein Validierungsschema Ding.

Beispiel:
[highlight=epc]
start = AUS
if ( after( start, 1u64 ) ) then {
start = start XOR EIN;
if chtime(06,30,00) then {
write("EG Wohnen Jalou Position-2/1/104"u08,vJalouPosEGWohnen)
} endif
} endif
if ( start == AUS ) then start = EIN endif
[/highlight]

Enthält kein eval() und macht den gleichen Unfug.

Das Problem ist hier ein inkonsequentes Validierungsschema: chtime() wird nur zu einem bestimmten Zeitpunkt EIN und bleibt es dann (also nur ein change() und dann konstant bzw. ein 2. beim Zurücksetzen), innerhalb eines if-then wird es aber auch ohne Trigger immer wieder ausgewertet.

Will man das Programm also entsprechend mit eval() um eine Ausführungsebene 'tiefer legen' muss man das Validierungsschema explizit fordern:
[highlight=epc]
if eval(after(systemstart(),20000u64)) then {
...
if change( chtime(06,30,00) ) and( chtime(06,30,00) == EIN ) then {
write("EG Wohnen Jalou Position-2/1/104"u08,vJalouPosEGWohnen);
...
} endif;
...
} endif
[/highlight]

[pio]

führt dazu, dass in jedem Zyklus die Abfrage chtime (06,30,00) ausgewertet wird.
Ist es jetzt nach 6:30h werden die write-Anweisungen immer wieder ausgeführt.

entspricht genau dem was ich vermutet hatte, was aber NICHT logisch ist. Innerhalb einer if-Abfrage mit eval werden alle anderen if-Abfragen auch bei jedem Zyklus neu ausgewertet, auch wenn das Resultat sich nicht geändert hat ( chtime(6,30,0) ändert sich nicht, egal ob es 7:00h oder 8:00h ist )

[QUOTE=saft6luck;114742]
[highlight=epc]
start = AUS
if ( after( start, 1u64 ) ) then {
start = start XOR EIN;
if chtime(06,30,00) then {
write("EG Wohnen Jalou Position-2/1/104"u08,vJalouPosEGWohnen)
} endif
} endif
if ( start == AUS ) then start = EIN endif
[/highlight]

Hätte ich ebenfalls nicht erwartet, weil ebenfalls NICHT logisch.

Daher folgenden DRINGENDEN Wunsch:
1) Validierungsschema so anpassen, dass es auch innerhalb verschachtelter if-Anweisungen so funktionieren würde, wie man es
erwartet.
2) eval() so anpassen, dass nur das jeweils betroffene if bei jedem Zyklus ausgewertet wird, verschachtelte if ohne eval aber nicht.
3) Um den ganzen Zirkus zu vermeiden, bitte mehrere (beliebig viele, da ja auch beliebig viele Timer verfügbar sind) Sektionen, oder Sektionen der Art:

[EibPC1=0u64]
// wird sofort nach Neustart ausgeführt

[EibPC2=1000u64]
// wird nach einer Sek ausgeführt

[EibPC3=60000u64]
// wird nach einer Min ausgeführt


Ich mach auch gerne eine Abstimmung, falls euch die aktuelle Diskussion (und die Früheren) noch nicht überzeugt hat.

Was meinen denn die Power-User mit mehr als den paar (120) Zeilen, die ich in meinem Programm habe?

[pio]

EVAL ist eine 'teuflische' Sache. Sie unterbricht das Validierungsschema und sorgt dafür, dass bei jedem zyklus die Auswertung der if-Anweısung ausgewertet werden.

Deine Aussage ist so NICHT korrekt, wie wir mittlerweile wissen.
Es muss heissen:
"EVAL ist eine 'teuflische' Sache. Sie unterbricht das Validierungsschema und sorgt dafür, dass bei jedem zyklus die Auswertung der if-Anweısung, in der eval() steht UND alle weiteren if-Anweisungen, die in der eval()-if-Anweisung verschachtelt sind, ausgewertet werden. "


Das ist NICHT logisch, NICHT im Manual beschrieben und NICHT vorhersehbar!

Zu Eurer Entlastung nehme ich jetzt mal an, dass das von Euch auch nicht so vorgesehen war ?!

[saft6luck]

Daher folgenden DRINGENDEN Wunsch:
1) Validierungsschema so anpassen, dass es auch innerhalb verschachtelter if-Anweisungen so funktionieren würde, wie man es
erwartet.

Yep.

"EVAL ist eine 'teuflische' Sache. Sie unterbricht das Validierungsschema und sorgt dafür, dass bei jedem zyklus die Auswertung der if-Anweısung, in der eval() steht UND alle weiteren if-Anweisungen, die in der eval()-if-Anweisung verschachtelt sind, ausgewertet werden. "

So wie ich das verstehe ist es eben keine Besonderheit von eval(), sondern es ist immer so. Keine Ahnung ob das ein Bug oder Feature ist.

Bei verschachtelten if-then tritt es zu Tage, hier z.B mit völlig unabhängigen Bedingungen:

'Wenn die Taste gedrückt wird und es 23:00 Uhr ist ...'

[highlight=epc]
if "Tastendruck" then
if chtime(23,00,00) then
blah
endif
endif
[/highlight]

Das Validierungsschema prüft hier nur noch auf chtime(23,00,00) == EIN, der Change wird nicht mehr beachtet. Das ist zwar inkonsequent aber für die Hausfrau schlüssig.
Eigentlich müsste nach der Logik ja auch:

[highlight=epc]
if chtime(23,00,00) then
if "Tastendruck" then
blah
endif
endif
[/highlight]

funktionieren, jedoch wird jetzt das Change beachtet und dass jemand exakt um 23:00 auf die Taste drückt ist sehr unwahrscheinlich, aber was passiert um 23:00 wenn jemand bereits gedrückt hatte?

Wenn man immer explizit auf change (oder event) und den Wert prüft, wird die Sache etwas verständlicher, finde ich und dann macht das eval plötzlich richtig Sinn:

[highlight=epc]
if change( "Tastendruck" ) and ( "Tastendruck" == EIN ) then
if eval( chtime(23,00,00) == TRUE ) then
blah
endif
endif
[/highlight]

Das kann ich dann auch problemlos umstellen.

[salixer]

Hallo,
nur mal kurz:

'Wenn die Taste gedrückt wird und es 23:00 Uhr ist ...'

sollte bei chtime eher 'Wenn die Taste gedrückt wird und es nach 23:00 Uhr ist ...' heißen. Das war bei den Codebeispielen auch die Intention denk ich. Und eigentlich steht in dem Satz auch schon drin, wie ich es am einfachsten programmieren würde:

[highlight=epc]
if "Tastendruck" and chtime(23,00,00) then {
blah
} endif
[/highlight]

Ich muss dann aber erstmal alle deine Beispiele durchtesten um mehr zu sagen.

[enertegus]

D
"EVAL ist eine 'teuflische' Sache. Sie unterbricht das Validierungsschema und sorgt dafür, dass bei jedem zyklus die Auswertung der if-Anweısung, in der eval() steht UND alle weiteren if-Anweisungen, die in der eval()-if-Anweisung verschachtelt sind, ausgewertet werden. "

Das macht jede If-Anweisung schon immer so:
[highlight=epc]
if Taste then
if Irgendwas
endif
[/highlight]Wenn nun Taste auf 1b01 wechselt und Irgendwas auf 1b01 steht, so wird die innere Schleife ausgeführt. Schon immer.

[enertegus]

entspricht genau dem was ich vermutet hatte, was aber NICHT logisch ist.
Was meinen denn die Power-User mit mehr als den paar (120) Zeilen, die ich in meinem Programm habe?

Ich habe mittlerweile 15% hier zuhause und habe kein Eval benutzt.
Ich sehe das nicht als unlogisch an. Um die Diskussionen mit dem Eval bzw. dem Valdierungsschema zu beenden, haben wir diese Funktion eingebaut. Wegen mir kann die ja jeder nutzten, aber ich möchte im Forum hier jedem soweit unterstützen, dass wir mit dem Programm zufrieden wären - ist also nur als Hilfestellung nicht als Sendungsbewusstsein zu verstehen.

[pio]

Das macht jede If-Anweisung schon immer so:
[highlight=epc]
if Taste then
if Irgendwas
endif
[/highlight]Wenn nun Taste auf 1b01 wechselt und Irgendwas auf 1b01 steht, so wird die innere Schleife ausgeführt. Schon immer.

Ich zitiere aus dem HandbuchEibPC-15.odt, 2010-07-22, und ich kann keinen, aber auch gar keinen Hinweis auf dieses Verhalten finden. Hab ich vielleicht was übersehen?

Seite 108:
Für die Abfragebedingung der if-Anweisung gilt das Valdierungschema, wie es auf der folgenden Seite 109 für Variablen beschrieben ist. Dies bedeutet, dass eine if-Anweisung nur (einmal) ausgewertet wird, wenn die Abfragebedingung sich ändert. Wenn a den Wert 23u08 annimmt, so wird einmal der then-Zweig ausgeführt. Im darauf folgende Zyklus, wenn a sich nicht ändert, wird auch die if-Funktion nicht erneut ausgeführt.

Seite 109:
Der Enertex® EibPC verarbeitet nur sich ändernde Ausdrücke und merkt sich dabei den letzten Zustand, der über eine Gruppenadresse gesendet wurde. Das Abbilden der Zustände der eingegangen Telegramme und Variablen bezeichnen wir als Validierungsschema. Es macht die Anwendung und Programmierung einfach und intuitiv, solange man Verschachtelungen von if-Anweisungen vermeidet.

[saft6luck]

sollte bei chtime eher 'Wenn die Taste gedrückt wird und es nach 23:00 Uhr ist ...' heißen. Das war bei den Codebeispielen auch die Intention denk ich.

Yep, eigentlich 'schon 23 Uhr'

Und eigentlich steht in dem Satz auch schon drin, wie ich es am einfachsten programmieren würde:

Mir ging es ganz bestimmt nicht darum, zu zeigen, wie man es am einfachsten programmieren sollte, sondern eben was falsch läuft.

[saft6luck]

Das macht jede If-Anweisung schon immer so:

Sehr konsequent! Zuerst auf eval() schießen und dann war es ja schon immer so.

Ich habe mittlerweile 15% hier zuhause und habe kein Eval benutzt.
Ich sehe das nicht als unlogisch an. Um die Diskussionen mit dem Eval bzw. dem Validierungsschema zu beenden, haben wir diese Funktion eingebaut. Wegen mir kann die ja jeder nutzten, aber ich möchte im Forum hier jedem soweit unterstützen, dass wir mit dem Programm zufrieden wären - ist also nur als Hilfestellung nicht als Sendungsbewusstsein zu verstehen.

Es geht aber nicht mehr um eval()! Auch wenn es schon immer so war, war dieses inkonsequente Anwenden des Validierungsschemas wahrscheinlich ein Grund für die Forderung nach eval(). So manches Problem wird jetzt erklärbar.

Auch für mich bleibt diese Ausnahme unlogisch!

[Tessi]

Zu Eurer Entlastung nehme ich jetzt mal an, dass das von Euch auch nicht so vorgesehen war ?!

Doch, weil z.B. die write-Funktion auch nur dann schreibt, wenn sie vorher invalid wird.
Damit also

if Ereignis then write(irgendwas irgendwohin) endif

auch tatsächlich was sendet muß der Code im then-Zweig invalid gemacht werden. Das wird dann "konsequent" auf alles angewendet.
Bug oder Feature? Weder noch, es ist eine Eigenheit der Implementierung der Auswertung für die Entscheidung, wann etwas gesendet werden soll.
Macht einfache Logik einfach und aufwendige Logik entweder extrem aufgeblasen (weil ich jegliche Verschachtelung auflösen und "flach" machen muß - gibt partiell gigantische Ausdrücke für das if) oder zum Lotteriespiel - mal sehen, was die Validierung da mal wieder draus macht - falls ich das je herausbekomme und der EPC sich nicht gleich in Resets flüchtet.

Mein (vielleicht ganz persönliches) Problem ist, das ich trotz der ganzen Erklärungen hier mich immer noch außer Stande sehe, bei verschachtelten Bedingungen vorherzusagen, was der EPC daraus machen wird - und wenn er den Bus flutet bis er mit einem internen Überlauf in einen Reset getrieben wird, kann ich nicht einmal mehr per Debugger etwas finden...
Dann ist Code-Analyse angesagt - und genau dafür reichen mir die Angaben immer noch nicht.

Ärgerlich fände ich jetzt, wenn eine eindeutigere Beschreibung (z.B. Diagramme, die genau zeigen, wann, wie und in welcher Reihenfolge der EPC den Code auswertet) daran scheitern, das dadurch vermeintlich oder tatsächlich zu viele "Betriebsgeheimnisse" offensichtlich werden könnten oder würden - eine Antwort im Thread "In der Tiefe: Validierungskonzept"

Nun ich wollte nicht den FW-Code und unsere internen Dinge allzusehr ausbreiten.

deutete so etwas an...