[FINR] [RC1.5 V10] Doktor Modus Anzeige nicht nachvollziehbar

[Robosoc]

Ich habe gestern mal wieder Zeit gefunden und eine Logik erstellt, bei der ich gerne wollte, dass die Logik erst ausgeführt wird, Wenn alle drei Eingangswerte definiert sind (i = inhibit...).

Der erste Eingang und der Dritte sind inzwischen über den Bus auch gesetzt, und den Zweiten habe ich selber manuell über den Doktorwert gesetzt, alle Eingängesind ja auch mit einem rötllichen Tion hinterlegt. Aber dennoch werden im Doktormodus die Ergebnisse der Eingangsfunktionen nicht angezeigt. Eingang 1 und 3 müssten eigentlich nach den Schwellwerten true sein!



Mir ist bei dieser Logik aufgefallen, dass es hilfreich wäre zu wissen, ob eine Logik noch nicht ausgeführt wird, weil mindestens ein Eingang noch nicht definiert wurde. Also in dem Fall, dass ein i eines Eingangs noch Wirkung hat. Vielleicht könnte man das in dem Logikzellen-Status berücksichtigen: "OK, waiting for inputs"

Was meint Ihr, soll ich daraus einen FR machen?

[Dragonos2000]

Da bin ich auch schon drüber gefallen, stimmt. Ist auf jeden Fall ein FR wert

[Dragonos2000]

Was Deine ursprüngliche Frage angeht: Das manuelle setzen im Doktormodus zieht nicht, wenn der Eingang auf I steht (war zumindest bei den Releases so, mit denen ich den Rolladenbaustein geschrieben hatte). Wie das mit den Modifikatoren aussieht, wäre mal gezielt auszutesten: sieht bei Dir tatsächlich auch komisch aus

[StefanW]

Ok,

ich habe Stefan gebeten, uns hier aufzuschlauen.

FR für Info im Doktormodus können wir ja dann daraus noch machen.

lg

Stefan

[StefanW]

Hallo Sven,

ich habe mich mit Stefan K besprochen und versuche das nun darzulegen.

Glückwunsch: Du hast ZWEIKOMMAFÜNF Bugs gefunden

.

Ich habe gestern mal wieder Zeit gefunden und eine Logik erstellt, bei der ich gerne wollte, dass die Logik erst ausgeführt wird, Wenn alle drei Eingangswerte definiert sind (i = inhibit...).

Es sind bei Dir ZWEI Eingangsfilter definiert:

1. Triggerfilter: OnChange (das "C" in der Eingangsbox): Das bedeutet, dass erst weitergeleitet wird, wenn es auch einen Change gibt. Die Logik geht hier von dem boolschen "False" als Default aus. Da kann nun tausend Jahre lang ein weiteres "False" gesendet werden. Solange sich der Pegel nicht ändert, gibt es auch keinen Change und damit auch keine Triggerauslösung.
2. Init-Inhibit (das "I" rechts in der Eingangsbox). Dies bedeutet, dass die Triggerung der Berechnung solange - für die gesamte Zelle - unterbunden wird ("Inhibit") bis der betreffende Eingang das erste mal richtig initialisiert wurde.
   
   
   Und hier die BUGs:
   
   "Halber Bug" Nr 1: Die beiden Filter sind derzeit "hintereinander" wirksam. Das ist nicht unbedingt falsch, kann man schon so machen, aber womöglich unerwartet und daher weniger intuitiv erfassbar. Wir werden das mit RC12 (weil war zu knapp für RC11) ändern. Damit wird das "Init-Inhibit" unabhängig vom Eingangsfilter
   
   Bug Nr. 2: Das Schreiben eines Wertes im Doktormodus führt (fälschlicherweise) nicht dazu, dass der Init-Inhibit zurück fällt. Das ist nicht sehr logisch. Weil in so einem Fall die Werteinspeisung für die Simulation keinen Sinn macht.
   
   Bug Nr. 3: Die rosa Wertänderungen nach der Eingangsbox hätten so gar nicht angezeigt werden dürfen, weil der Init-Inhibit eigentlich den Trigger der gesamten Zelle unterbunden hatte. Es ist allerdings auch eine große Herausforderung, alle logischen Details der Zelle in nullkommanix an die Oberfläche zu führen.
   
   ==> Fixed in übernext Release
   
   Hinweis: Du musst nun ein True (derzeit noch vom Bus) auf den Eingang 2 bekommen, damit der OnChange greift und einen Trigger auslöst und der Init-Inhibit abfällt.
   
   lg
   
   Stefan

[Robosoc]

Vielen Dank für die ausfühlichen Erklärungen, das hilft mir sehr, denn ich hatte schon wieder an meinem Verständnis gezweifelt! Mein zweiter Eingang ist glücklicherweise ein Tag-Nacht-Bit und wurde am Folgemorgen ohnehin einmal auf true gesetzt. Die Logik funktioniert nach meinem Gefühl auch einwandfrei.