OBC-Kette verliert Wert bei Switch Reset

[Quietschboy]

Hi!
da ist man sich manchmal seiner Sache so gut wie sicher, und dann sowas!
Ich dachte bisher, daß die Speicher in Core Switch-Reset-proof sind. Aber neee...

Hier in dem einfachen Beispiel sollte bei einem Switch Reset auf beiden Ausgängen eine 1 ausgespuckt werden, wenn vorher ein Button gedrückt und somit das Latch mit 1 befüllt wurde.
Aber nur Ausgang B schickt tatsächlich die 1 raus. Bei A ist es 0.

OBC verliert Wert bei Switch Reset.jpg

Hier im zweiten, leicht variierten Beispiel funktionierts wieder wie geplant:

OBC verliert Wert bei Switch Reset2 - funzt.jpg

Hat dazu noch jemand Worte???
Mark

[MvKeinen]

habs mal getestet und die obere schaltung funktioniert nur wenn der debugmode aktiviert ist. damit hatte ich auch schon schwierigkeiten. Man baut stundenlang rum mit aktiviertem debugmode und merkt dann dass ohne alles irgendwie anders initialisiert wird. Leider kann ich mehr dazu nicht sagen, würde aber auch gern mehr wissen.

dann hab ich das mal so verkabelt:

obc.jpg

und hier scheint es unabhängig von Debugmode zu funktionieren.

ist das Problem vielleicht die Abfolge der Initialisierung innerhalb vs. ausserhalb der corezelle?
kann es sein, dass die obc speicer ihre werte zwar verlieren aber während des initvorgangs dann wieder bekommen und in der oberen Lösung der Zeitpunkt der Wetreausgabe vor dem Wiederbeschreiben erfolgt?

[Quietschboy]

Hi MvKeinen,
ich vermute inzwischen einen Bug bei der Compilierung. Es könnte doch sein, daß das WRITE als Master in der OBC Kette vom Compiler als ein totes Ende angesehen wird und somit gar nicht vorhanden ist.
Ist ein READ der Master funktioniert es nämlich! Sei es als Dummy oder wie in der Z-1 Struktur.
Aber wie die funktionierende Struktur im zweiten Bild meines ersten Post und deine Struktur zeigen, kann man diese Aussage so alleine auch nicht stehen lassen.
Sehr kurios, das Ganze...irgendwie unübersichtlich...

OBC verliert Wert bei Switch Reset2.jpg

[herw]

Hi MvKeinen,
ich vermute inzwischen einen Bug bei der Compilierung. Es könnte doch sein, daß das WRITE als Master in der OBC Kette vom Compiler als ein totes Ende angesehen wird und somit gar nicht vorhanden ist.
Ist ein READ der Master funktioniert es nämlich! Sei es als Dummy oder wie in der Z-1 Struktur.
Aber wie die funktionierende Struktur im zweiten Bild meines ersten Post und deine Struktur zeigen, kann man diese Aussage so alleine auch nicht stehen lassen.
Sehr kurios, das Ganze...irgendwie unübersichtlich...

OBC verliert Wert bei Switch Reset2.jpg

Ich hoffe, ihr nutzt die neueste Version von REAKTOR (5.8.0).
Ich habe zwar noch nicht in die Struktur geschaut, aber die Bilder lassen mich vermuten, dass es sich um einen wohl bekannten (kaum beachteten) und von unserem Mitglied Gerald List (krümelmonster, cookiemonster) schon vor Jahren gefunden Bug „WhatTheHell” handelt. Der ist angeblich beseitigt seit R5.7.1, aber manchmal schleichen sich alte bugs wieder ein.
Ich muss mal im JIRA (das ist die NI-Plattform für beta-Tester) nachschauen, was dazu geschrieben wurde. Falls dies ein neuer bug sein sollte, dann melde ich den weiter. Das wird mit großem Interesse aufgenommen. Übrigens tauchten deartige Initialisierungsbugs nur bei ganz bestimmten Zahlen (integer-Zahlen) auf. Testet also mal mit anderen Konstantenzahlen wie 0.5, 2, 3 etc. Das war damals sehr verzwickt. Damals zickte nur die 1 !!

ciao herw

[MvKeinen]

Reaktor 5.8 hier.

[Quietschboy]

Hi Herw,
danke mal wieder für deine Insider-Infos!
Dieses Phänomen zickt unter 5.6.2 und aber auch unter 5.8.0.
Ich habe dem Button auch mal andere Konstanten als 1 schicken lassen, aber das hilft auch nicht.

Was den WhatTheHell Bug unter 5.8.0 angeht (gerade getestet):
ER IST WEG!!

Bravo NI!!!! Danke und weiter so!!!

http://www.native-instruments.com/forum ... hp?t=36658
(Info: Im WhattheHell Bug sendete ein Latch stets eine 1, obwohl es per Definition bei Initialisierung (und nur dann) mit der Konstante 0 befüllt wurde.)

[herw]

So, ich habe mir die Beispiele angeschaut:

Testumgebung: MacOsX 10.8.3, Reaktor 5.8.0 (R550)

Please use the following as a guideline for a good bug description:
Problem Description: Describe the bug as detailed as necessary and as short as possible.
Reproduction Steps: List the exact steps to produce the bug.
Observed Results: Describe what actually occurred.
Expected Results: Describe what you expected to happen.
----------------
Problembeschreibung: Core Speicher sind nicht switch-reset-sicher
Reproduktionsschritte:
- Lade das Ensemble „OBC verliert ...2”
- Drücke den Trigger-Button (Wert 1)
- Führe einen Switch-Reset durch
Beobachtetes Verhalten: Ausgang A liefert den Wert 0, Ausgang B den Wert 1 des oberen Beispiels.
Erwartetes Verhalten: Beide Ausgänge sollen 1 zeigen (?)
----------------

Nach mehreren Tests, kann ich dieses Verhalten bestätigen:
Befindet man sich außerhalb der CoreCell, dann werden in der Tat 0 und 1 ausgegeben, befindet man sich innerhalb der CoreCell, dann werden zweimal 1 ausgegeben.
Dazu muss man allerdings wissen, dass bei Aktivierung der CoreCell (man befindet sich innerhalb der CoreCell) nur diese neu compiliert wird (frag mich nicht warum).
Dieses für uns User ungewöhnliche Verhalten ist bekannt und nach eingehender Recherche kann ich sagen, dass dies wohl aus programmiertechnischen Gründen notwendig ist bzw. dass eine komplette Re-Compilierung wohl problematisch ist.
Jedenfalls ist es wichtig zu wissen, ob das Verhalten (0 an A und 1 an B) dem Normalfall, also dem Play-Modus entspricht. Ich denke, dass die Ergebnisse der oberen Beispiele begründbar sind. Ich habe mal eine Anfrage an Norbert Nemec gerichtet. Ich finde es gut, dass man mit den unteren drei Beispielen eine gewünschte Initialisierung kontrollieren kann (Lob! - guter Bugreport).

Bitte den Initialisierungsalgorithmus nochmals überprüfen!!

ciao herw

PS: Es gibt noch so einige (bekannte) Bugs im Zusammenhang mit der Initialisierung und dem Interface zwischen primary und core. Deswegen werde ich ja auch nicht müde, immer wieder auf eine grundlegende Reform von REAKTOR zu drängen. Die Diskrepanz zwischen beiden Welten wird immer offenkundiger. Aber ich denke, das dürfte dann auch eine sehr schwerwiegende Entscheidung bei NI sein und ich wette darauf, dass wieder 60-70% aller REAKTOR-user darüber zetern werden und lieber core zur Hölle schicken möchten, gleichzeitig aber jeden Komfort für primary aus der Core-Ebene wünschen.

[herw]

Die Nachfrage hat ergeben, dass es sich in der Tat wohl um einen so genannten re-init-Bug (Quietschboy: switch-reset) des Core-Compilers handelt, der relativ selten auftritt. Er ist bekannt und man arbeitet daran, hat aber noch keine zufrieden stellende Lösung.

ciao herw

[Quietschboy]

Danke Herw!
Ich habe diesen seltenen Bug tatsächlich in der Praxis, genauer gesagt bei der Arbeit am ACEW 2.0, feststellen müssen. Dort konnte ich den Fehler ohne Probleme mit dem o.g. Z-1 umschiffen, was aber nicht immer eine akzeptable Lösung sein kann.

Gruß, Mark

[Quietschboy]

Dieser Bug wurde mit Reaktor 5.9.0 nicht behoben!