Gleichzeitigkeit und Reihenfolge in CORE
Verfasst: 14. Januar 2007, 09:53
Die Überarbeitung des Panels erweist sich als äußerst fruchtbar. Ich verfolge den gesamten Signalwegs der Adressenzuweisung und Panelpositionen an die Kabelgrafik. Da die einzelnen Busse eine festgelegte Reihenfolge in ihrer Werteübertragung haben, muss ich nur darauf achten, dass ein entsprechender Trigger dies über den gesamten Signalweg synchronisiert.
Durch konsquentes Umstellen auf Core-Makros konnte ich dabei viele in Prim-Level erforderliche Order-Val-Elemente ersetzen bzw. ganz wegfallen lassen.
Die Umstellung von relativen Panel-Koordinaten (Grobrasterung) auf Pixelkoordinaten des Multidisplays schafft ebenfalls viel einfachere Operationen. Interessant dabei ist, wie unterschiedlich man durch den Begriff Gleichzeitigkeit (im Core-Level) denken muss (besser: kann).
Ein Beispiel: Ich habe auf dem Panel ein Wire gelöscht. Das ist grafisch nichts anderes als die Transparenz des Wires auf 100% zu setzen. Die Adresse der zuletzt benutzten Ausgangsbuchse ist immer noch aktuell.
Rechtsklicke ich auf irgendeine Eingangsbuchse, dann wird diese Adresse korrekterweise benutzt (wenn ich nicht einen anderen Ausgang benutzen möchte).
Beim Neustart merkte ich nun, dass (nur beim erstenmal) diese Ausgangskoordinaten aber auf 0 initialisiert waren, somit ein Wire in der oberen linken Ecke startet; In der alten Version mit Primary Level ist mir das gar nicht aufgefallen.
Kein Beinbruch, da man dies ja durch nochmalige Ausgangsauswahl sofort korrigieren kann. Aber das interessante war, die Ursache herauszufinden: es lag nur an einer Intialisierungsreihenfolge beim Starten des Progamms. Das Vertauschen der Reihenfolge der Ausgänge E, X1, Y1, X2, Y2 zu X1, Y1, X2, Y2, E schafft hier teilweise Abhilfe; zusätzlich musste ich allerdings im weiteren Verlauf snap-Module für X1 und Y1 einbauen, damit die Initialisierung korrekt erfolgt. CoreCells leiten gleichzeitige Events ins primary level über die Ausgänge von oben nach unten ab.
Letztendlich habe ich aber die Lösung nochmals geändert, so dass ich den 1-Event (gelber Rahmen) des Rechtsklick-Gates als Trigger (hier X2,Y2) und den 0-Event (grüner Rahmen) des Rechtsklick-Gates für die Eingangsadresse E benutze:
Durch konsquentes Umstellen auf Core-Makros konnte ich dabei viele in Prim-Level erforderliche Order-Val-Elemente ersetzen bzw. ganz wegfallen lassen.
Die Umstellung von relativen Panel-Koordinaten (Grobrasterung) auf Pixelkoordinaten des Multidisplays schafft ebenfalls viel einfachere Operationen. Interessant dabei ist, wie unterschiedlich man durch den Begriff Gleichzeitigkeit (im Core-Level) denken muss (besser: kann).
Ein Beispiel: Ich habe auf dem Panel ein Wire gelöscht. Das ist grafisch nichts anderes als die Transparenz des Wires auf 100% zu setzen. Die Adresse der zuletzt benutzten Ausgangsbuchse ist immer noch aktuell.
Rechtsklicke ich auf irgendeine Eingangsbuchse, dann wird diese Adresse korrekterweise benutzt (wenn ich nicht einen anderen Ausgang benutzen möchte).
Beim Neustart merkte ich nun, dass (nur beim erstenmal) diese Ausgangskoordinaten aber auf 0 initialisiert waren, somit ein Wire in der oberen linken Ecke startet; In der alten Version mit Primary Level ist mir das gar nicht aufgefallen.
Kein Beinbruch, da man dies ja durch nochmalige Ausgangsauswahl sofort korrigieren kann. Aber das interessante war, die Ursache herauszufinden: es lag nur an einer Intialisierungsreihenfolge beim Starten des Progamms. Das Vertauschen der Reihenfolge der Ausgänge E, X1, Y1, X2, Y2 zu X1, Y1, X2, Y2, E schafft hier teilweise Abhilfe; zusätzlich musste ich allerdings im weiteren Verlauf snap-Module für X1 und Y1 einbauen, damit die Initialisierung korrekt erfolgt. CoreCells leiten gleichzeitige Events ins primary level über die Ausgänge von oben nach unten ab.
Letztendlich habe ich aber die Lösung nochmals geändert, so dass ich den 1-Event (gelber Rahmen) des Rechtsklick-Gates als Trigger (hier X2,Y2) und den 0-Event (grüner Rahmen) des Rechtsklick-Gates für die Eingangsadresse E benutze: