Verständnisproblem Validierungsschema

[sapler]

Hallo an alle,
habe mir jetzt einen EIBPC2 geleistet und bin gerade dabei, mich damit vertraut zu machen. Beim Thema Validierungsschema habe ich jedoch offene Punkte. Im Handbuch steht folgendes zum Thema innere IF Anweisungen drinnen:
dataurl510928.png
Ein par Seiten weiter unten ist ein Beispiel aufgeführt, was jedoch mein mühsam aufgebautes Verständnisgebilde wieder zum Einsturz bringt:
dataurl510929.png
Hier steht, das „sendudp“ Kommando wird „zweimal“ ausgeführt. Jetzt beginnt jetzt mein Verständnisproblem. Gemäß o.a. Definition ist die innere IF Anweisung nur von der äußeren abhängig. Diese wird doch nur einmalig beim Systemstart ausgeführt, dann nicht mehr. Daher dürfte der ELSE Zweig der inneren IF Anweisung doch gar nicht durchlaufen werden. Habe ich einen Denkfehler?

Eine weitere Frage habe ich zu zum Ablauf der Zyklusverarbeitung. Alle invalidierten Objekte werden gemäß Beschreibung in einem Zyklus abgearbeitet. Wenn jetzt innerhalb des Zyklus weitere Objekte invalide werden, werden diese dann auch innerhalb des gleichen Zyklus abgearbeitet, oder erst im nächsten?

Danke euch und sorry wenn das für viele von euch banal klingen mag, aber als EIBPC Anfänger ist das mein Verständnis sehr wichtig.

[TabSel]

ein else ist immer wie ein separates, negiertes if auf dem selben Level zu verstehen.
im obigen if Zweig wird B auf 2 gesetzt.
der else Zweig ist ein negiertes if, also ein „if b != 1“, auf selbem Level, dessen äußeres if ja prozessiert wird (systemstart)…

[sapler]

Hallo TabSel,
vielen Dank für deine prompte Antwort. Das ist dann natürlich die Erklärung für das Verhalten, und auch die Antwort auf meine zweite Frage.
In diesem Fall wird ein weiteres Programmobjekt innerhalb eines Zyklus des EIBPC invalide und auch innerhalb des gleiches Zyklus abgearbeitet.
Denn im nächsten Zyklus dürfte ja nichts mehr aus der systemstart if Bedingung ausgeführt werden.
Daraus ergibt sich aber für mich die nächste Frage. Dann ist es ja zumindest theoretisch so, dass ständig neue Invalidierungen innerhalb eines Zyklus erzeugt werden können und der EIBPC nie zur Abarbeitung der Queues kommt?

[TabSel]

der innere else Zweig, also das negierte if ist KEIN Programmobjekt! es wird nur nach dem ersten if ausgeführt, weil ein Prozessor halt sequentiell arbeitet

also: das äußere (systemstart) ist invalid und wird prozessiert.
jetzt wird das erste if prozessiert, die Bedingung (b==1) ist wahr, damit wird b=2 gesetzt
dann wird das zweite if prozessiert, die Bedingung (b!=1) ist wahr…

tricky…

[sapler]

dank deiner konstruktiven Anmerkungen komme ich der Sache schon näher. Danke dir!
Das innere else ( gedanklich negierte IF ) ist kein Programmobjekt, aber das "b" auf das sich das innere if bezieht wäre gemäß der u.a. Definition aus dem Handbuch eines, wenn es sich nicht innerhalb der äußeren If Schleife befinden würde.
image.png
D.h. alles innerhalb einer äußeren IF Schleife wird sequentiell abgearbeitet.
Da ist es glaube ich für mich aus Gründen der Lesbarkeit besser wenn möglich auf "else" Anweisungen zu verzichten.

[TabSel]

Wenn es ein äußeres, von b abhängiges if gäbe (z.B. „if change(b) then …“), dann gäbe es ein weiteres Programmobjekt, ja. Dieses würde dann durch die Änderung von b invalidiert werden und im NÄCHSTEN Zyklus validiert, also prozessiert werden…