Seite 1 von 1
KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 12:01 pm
von 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.
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 8:09 pm
von Robert_Mini
Danke für den Hinweis!
Hab's grad leicht angepasst - bitte nochmal lesen.
Danke und Lg
Robert
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 10:00 pm
von 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.
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 10:15 pm
von 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?
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 10:24 pm
von S. Kolbinger
Robosoc hat geschrieben: ↑Di Nov 05, 2019 10:15 pm
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.
Robosoc hat geschrieben: ↑Di Nov 05, 2019 10:15 pm
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

)
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Di Nov 05, 2019 10:25 pm
von Robosoc
Ja, verstanden. Das macht mir das Leben bei einigen Logiken an denen ich gerade arbeite sogar echt einfacher. Danke und sorry.
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Mi Nov 06, 2019 7:26 am
von 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
Re: KB 4.6.6. Break-Definition nicht ganz richtig, oder?
Verfasst: Mi Nov 06, 2019 8:47 am
von Robosoc
Robert_Mini hat geschrieben: ↑Mi Nov 06, 2019 7:26 am
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.