[Hinweis] KB 4.6.6. Break-Definition nicht ganz richtig, oder?

[Robosoc]

@Robert_Mini

Ich glaube die Break-Definition in 4.6.6 ist nicht ganz richtig:

Ich meine verstanden zu haben, dass Break die weitere Ausführung nur abbricht, solange ein "True"-Wert auf einem der gewählten Eingänge anliegt. Es spielt dabei keine Rolle, ob der Wert die Logik getriggert hat (so kann der aktuelle Text interpretiert werden) oder ob der Wert schon länger anliegt oder nur mit u=update aufgenommen wurde.

Aktuelle Definition:
BREAK:
Dies ist ein spezielles Modul, das die weitere Ausführung einer (Custom-) Logikzelle abbricht, sobald ein Wert auf einem der Eingänge eintrifft. Beim Abbruch wird kein Ausgang mehr beschrieben, der nach der Break Definition gesetzt wird! Ausgänge deren Variable vor dem Erreichen des Breaks gesetzt wird, werden jedoch weiterhin gesendet.

[Robert_Mini]

Danke für den Hinweis!

Hab's grad leicht angepasst - bitte nochmal lesen.

Danke und Lg
Robert

[S. Kolbinger]

Hallo zusammen,

Das ist so nicht ganz korrekt.

BREAK:
Dies ist ein spezielles Modul, das die weitere Ausführung einer (Custom-) Logikzelle abbricht, sobald ein "True" auf einem der Break-Eingänge eintrifft (von einem Eingang der Logikzelle oder einer Variablen, die innerhalb der Logik berechnet wird). Beim Abbruch wird kein Ausgang mehr beschrieben, der nach der Break Definition gesetzt wird! Ausgänge deren Variable vor dem Erreichen des Breaks gesetzt wird, werden jedoch weiterhin gesendet.

Richtig ist:

BREAK:
Dies ist ein spezielles Modul, das die weitere Ausführung einer (Custom-) Logikzelle abbricht, sobald ein "True" auf einem der Break-Eingänge anliegt (von einem Eingang der Logikzelle oder einer Variablen, die innerhalb der Logik berechnet wird). Beim Abbruch werden keine nachfolgenden Module mehr berechnet/ausgeführt. Kein Ausgang wird gesendet, auch nicht die Ausgänge, deren Variable vor dem Erreichen des Breaks gesetzt wurden.

[Robosoc]

Code: Alles auswählen

Kein Ausgang wird gesendet, auch nicht die Ausgänge, deren Variable vor dem Erreichen des Breaks gesetzt wurden.

Oh, das war mir dann auch nicht klar. Und ist es auch immer noch nicht.
Heißt das, dass die Ausgänge doch erst einmal nur vorgelegt werden und am Ende der Logikbearbeitung geprüft wird, welcher Ausgang tatsächlich wie gesendet wird (in Abhängigkeit von a c t ct )?

Wenn ein Ausgang also mehrfach innerhalb einer Logik geändert wird (z.b. weil schlecht programmiert wurde), dann wird immer nur der letzte Zustand tatsächlich gesendet?

[S. Kolbinger]

Oh, das war mir dann auch nicht klar. Und ist es auch immer noch nicht.
Heißt das, dass die Ausgänge doch erst einmal nur vorgelegt werden und am Ende der Logikbearbeitung geprüft wird, welcher Ausgang tatsächlich wie gesendet wird (in Abhängigkeit von a c t ct )?

... genauso war es ursprünglich gedacht.

Wenn ein Ausgang also mehrfach innerhalb einer Logik geändert wird (z.b. weil schlecht programmiert wurde), dann wird immer nur der letzte Zustand tatsächlich gesendet?

... ob "schlecht programmiert" oder "genauso beabsichtigt" möchte ich nicht entscheiden.
Aber so gibt es einem mehr Freiheiten bei der Erstellung der Logiken.
Frei nach dem Motto: "Abgerechnet wird zum Schluss" (zumindest bei den Ausgängen )

[Robosoc]

Ja, verstanden. Das macht mir das Leben bei einigen Logiken an denen ich gerade arbeite sogar echt einfacher. Danke und sorry.

[Robert_Mini]

Jetzt sollte es klar sein!

Das heißt, die Auswertung am Ende von C, CT etc. wird übersprungen und nichts gesendet.
Wenn in einer Logik vor Break Variablen geändert wurden und bei der nächsten Ausführung zurück geändert werden, wird dann die Variable wieder als unchanged behandelt (heißt wo wird der Vergleichswert für changed gespeichert: auf level-Ebene oder "außen" auf Ebene der Logikzelle)?

Danke
Robert

[Robosoc]

Wenn in einer Logik vor Break Variablen geändert wurden und bei der nächsten Ausführung zurück geändert werden, wird dann die Variable wieder als unchanged behandelt

Gute Frage, das ist schon recht komplex.

Hätte ich jetzt z.B. nicht so verstanden. Ich würde erwarten, dass die Logik das nächst mal eben doch genau den Change erkennt, obwohl das nach den am Ausgang tatsächlichen gesendeten Telegrammen nicht nachvollziehbar wäre. Aber ich bin mir hier jetzt total unsicher. Gut dass Du nachfragst.