kleines logik-problem

[herw]

Hmmmmh,
hatte keine Lust, rauszugehen und Materialschaden.
Bin ja eigentlich auch eher Core-Anhänger.
Aber hilft das hier auf PrimaryLevel-Ebene nicht weiter ?

Hallo Gerald, schön von Dir mal wieder etwas zu hören!
Dein primary level Beispiel funktioniert (nicht immer s.nächste post)korrekt.
Ich werde gleich mal versuchen, eine entsprechende Core Cell Struktur zu entwerfen (eigentlich ja Dein Gebiet!)

Sehr (!) interessant an diesem Beispiel ist es, mal (nacheinander oder auch gleichzeitig) hinter allen Logikausgängen den Eventwatcher zu klemmen:
Beispiel: legt man den eventwatcher hinter den ersten AND-Ausgang und bewegt den "Schalter" B mit der Maus, wird man gleich von einem Schwall an events überrascht. Wenn man knobs als Schalter verwendet, sollte man die Maus-Auflösung auf 2 setzen.

@Gerald, kannst Du nochmals hier deinen Audio-Core-Event-Watcher vorstellen und die Idee der Audio-Event-Ausgänge erläutern?

ciao herw

[herw]

Dieses Beispiel ist genial, um die Problematik von primary level aufzuzeigen.
Ich habe mal ein "neues" ensemble genommen. Öffnet dies bitte einmal!
Keine Änderung zu sehen? Genau! dieselbe Struktur! Stellt beide Regler auf 1. Das richtige Ergebnis 1 wird angezeigt. Nun schaltet das ensemble aus und wieder an. Regelt beide Regler auf 0. Das Resultat 1 wird angezeigt-
falsche Ergebnisse? JAAAA!


Warum? Schaut man in den Debug-Modus, so ergeben beide Strukturen dieselbe (!) event-Order!
Nur der Entwickler weiß es. Ein schwerer "Bug", den man nicht ohne Neukonstruktion der Struktur beseitigen kann.
Gerald hat die Logik richtig konstruiert und dabei natürlich die Struktur unbewusst in der "richtigen" Reihenfolge angeordnet.
Trotzdem funktioniert sie nicht.

Die Lösung kann man nur anhand des event-watchers (EW) erkunden: Also Ausgang des Oder-Moduls an den Eingang 1 des EW und den Ausgang des nachfolgenden Routers an den Eingang 2 des EW.
Vergleicht man nun in beiden Ensembles die Reihenfolge der ankommenden Events wird man eine deutlichen Unterschied in den herausgegebenen Events erleben.
Die Ursache ist meine Verdrahtung: ich habe die Verbindungen der AND-Ausgänge und die Verbindungen zum Router bewusst in der Reihenfolge von unten nach oben vorgenommen. Alles ist anders und niemand kann es ohne eine solche Analyse entdecken.

D.h. dieses "kleine" Logik-Problem kann jetzt zu einem grundsätzlichen Disput über korrekte Eventverarbeitung ausarten. Für die aktiven Ensemble-Gestalter unter uns ist das eine Katastrophe. Keine kritische Struktur ist ohne Wissen über die Verdrahtungsreihenfolge nachvollziehbar.

ciao herw

[herw]

LOB an CORE.
Wie schön einfach es in CORE geht, beweist das folgende Lösungs-Ensemble:



alles klappt, wie man es sich vorstellt.
Wie funktioniert es?
Der Hauptsignalweg ist die UND-Verbindung. Sie liefert bei A=B=0 bzw. A=B=1 die richtigen Ergebnisse 0 bzw. 1.
Die beide Fälle für A=1, B=0 bzw. A=0, B=1 werden über die XOR-Logik erkannt, mit Hilfe des NOT-Operators dagegen die Fälle von Gleichheit. Der Router lässt also nur bei Gleichheit einen Event durch.

Wer noch mit der Modulzahl knausern will, kann das NOT-Modul wegfallen lassen und den unteren Eingang des Routers mit dem Ausgang verbinden.

ciao herw

leider hatte ich ein falsches file hochgeladen; jetzt liegt hier das richtige

[helmsklamm]

danke an die beiden coremonster

zwar funzt meine lösung in meinem speziellen fall (bei anderen triggerabgriff), aber n universelles 2komponenten-3bedingungen-logikmacro zu haben, is natürlich schön.

zum reihenfolge-prob: ich les (translate) mir erstmal den event-initalization-txt, scheint ja in manchen fällen essentiel zu sein. aber gut zu hören, das das in core vglw. simple zu händeln ist.

[krümelmonster]

Gerald hat die Logik richtig konstruiert und dabei natürlich die Struktur unbewusst in der "richtigen" Reihenfolge angeordnet.
Trotzdem funktioniert sie nicht.

Zunächst einmal - sie funktioniert einwandfrei !
Sonst hätte ich sie auch nicht gepostet

Daß dabei ein wenig Glück im Spiel war, ist eine andere Sache und der Grund dafür für mich auch ein neuer.
Danke Herwig, für den Hinweis:

Laut manual dürfte nur die Reihenfolge des Einsetzens von Modulen von Bedeutung für die Verabeitungsreihenfolge sein,
die Reihenfolge des Verdrahtens jedoch nicht.
Ein Entfernen und erneutes Herstellen von Verdrahtungen in anderer Reihenfolge beweist leider das Gegenteil.

Kaum auszudenken, was passiert, wenn die Reaktor-Initialisierungsregeln wieder einmal geändert werden sollten und ein funktionierendes Macro mit einem Mal nicht mehr das tut, was es vorher getan hat.

Da erfreut man sich doch lieber der Core-Variante, die nicht nur viel eleganter ausschaut, sondern wahrscheinlich auch noch CPU-sparsamer sein wird ( denke ich mir zumindest ).

Eigentlich ging es mir auch nur darum zu zeigen, daß dieses Problem auch auf PrimaryLevel ohne riesigen Aufwand zu lösen ist, q.e.d.

Viele Grüsse, Gerald.

[krümelmonster]

Meine Güte,
Herwig, Du hast wirklich recht.
Das ist eine wirkliche Katastrophe.
Bzw. eine schwere Unterlassung im manual.
Nein, eher eine Katastrophe.
Ohoh, worauf kann man sich denn noch verlassen ?

Viele Grüsse, Gerald.

[helmsklamm]

Ohoh, worauf kann man sich denn noch verlassen ?

auf herw!

[herw]

Also meiner Ansicht nach ist das eine Erwähnung im NI-Reaktorforum wert, so daß auch Kollegen, die der deutschen Sprache nicht mächtig sind, vorgewarnt sind.
Die PrimaryLevel-Lösung arbeitet ja nun wirklich zuverlässig. Man stelle sich nur vor, das Ganze wäre ein wenig komplexer, es käme noch eine weitere Bedingung dazu, man löst alle Verkabelungen, aktualisiert sie in anderer Reihenfolge und - es läuft nichts mehr.
Nein, ich denke mir, daß dies nicht dem Instinkt überlassen bleiben darf.
Da reicht es auch nicht aus, bessere Mittel zur Diagnose zu haben.
Da das nicht wenigstens im manual erwähnt ist, ist es einfach ein schwerer Fehler...

Ok - eigentlich wollte ich ja im NI-Forum bis zum Erscheinen von mindestens vier Major-Updates in diesem Jahr nichts mehr schreiben, aber dies ist in der Tat ein Super-GAU.
Ich habe das Beispiel nochmals ausgearbeitet und ins englische Forum gestellt SUPERGAU. Bitte unterstützt mich bei der notwendigen Diskussion. Ich habe NI darüber informiert und hoffe, dass diese post nicht wieder zensiert wird.

ciao herw

[herw]

Das Auftreten des SUPERGAUs liegt wie richtig beschrieben in der Einfügereihenfolge der Kabel begründet. Im Handbuch findet man hierzu eine kleine Bemerkung (Reaktor Handbuch S. 191 2. Abschnitt):
"Wenn ein Event-Pfad sich in verschiedene Zweige auffächert und für korrekte Funktion eine bestimmte Reihenfolge der Eventbearbeitung eingehalten werden muss, sollten Sie das Modul Order benutzen."
Genau dies muss hier beachtet werden. Vom OR-Modul verzweigt sich der Weg in den Pos-Eingang des folgenden Routers und den Signaleingang.
Schließt man (wie gewöhnlich) den Pos-Eingang zuerst an und dann den Signaleingang, funktioniert alles wie gewünscht; schließt man aber den Signaleingang zuerst an und dann den Pos-Eingang, dann wird alles falsch.
Das heißt, damit für den User völlige Klarheit herrscht, muss man dem Router ein Order Modul voranstellen:

Damit braucht man, um diese Falle auszumerzen, in Geralds Struktur sicherheitshalber drei zusätzlich Order-Module. Dan funktioniert die Struktur immer, egal, in welcher Reihenfolge man sie verdrahtet.

gearde noch gerettet!

trotzdem bestärkt mich dies darin, in Zukunft möglichst nur noch CORE zu benutzen, wenn es um Eventverarbeitung geht.

ciao herw

[helmsklamm]

also heisst das fazit mit dem order-modul DARF man die strippen in "falscher" reihenfolge ziehen.
deshalb gab mir der eventwatcher dieses omionöse direkt-trigger trotzdem als letztankommendes event, obwohl die anderen laut debug erst viel später kommen müssten, weil ich dieses kabel zuletzt verbunden hatte. tsttsts.
welchen zweck hat denn der debug-modus nun eigentlich? nur für die erstinitialisierung nach neustart oder nach snapwechsel oder was?