Core-Cell In/Out ports verschieben?

[Eventmanager]

Kann man problemlos in ner Core-Cell die Ports vershchieben?
Hab die Erfahrung das das Core-Macros kritisch sein kann, deshalb lass ich es dort. Für die höchste Ebene, also die Cell, hab ich dergleichen noch nicht feststellen müssen. Aber vielleicht waren dass nur zufällig nur Ports wo Reihenfolge/Init keine Rolle spielt, deshalb zur Sicherheit nochmal nachgefragt. Spielt für die Cell die Anordnung der Ports irgendeine Rolle, wird bspw. von oben nach unten initialisiert obwohl es "draussen" anders ist?

[herw]

Kann man problemlos in ner Core-Cell die Ports vershchieben?
Hab die Erfahrung das das Core-Macros kritisch sein kann, deshalb lass ich es dort. Für die höchste Ebene, also die Cell, hab ich dergleichen noch nicht feststellen müssen. Aber vielleicht waren dass nur zufällig nur Ports wo Reihenfolge/Init keine Rolle spielt, deshalb zur Sicherheit nochmal nachgefragt. Spielt für die Cell die Anordnung der Ports irgendeine Rolle, wird bspw. von oben nach unten initialisiert obwohl es "draussen" anders ist?

ja - Spezialgebiet von Mark (Initialisierungen); der meldet sich bestimmt bis heute Abend
Für Otto Normalverbraucher wohl nur in ganz besonderen Fällen wichtig. Aber ich glaube, da kommt niemand außer Mark drauf. Beim core ACEW zum Beispiel muss die Feedback-Schleife ganz oben und ganz unten sein.

[Eventmanager]

Werd nicht ganz schlau aus der Antwort. Formuliere nochmal anders.

Port-Verschieben in der core-CELL (also oberste ebene) kritisch oder nicht?

Bis ich den ACEW Core nutze ist es wohl noch ein Stück Weg;-)
Apropos: Gibts eigentlich irgendeinen Grund, nicht ausschliesslichlich die wireless Variante des ACEW(prim) zu nutzen? Bei Bedarf kann ich doch die Ports auf reguläre Kabel switchen?
Hat die Send-Version irgendwelche Nachteile, wenn ich temporär Ports als Kabelversion nutze? Immerhin muss das ganze ja den switcher/router durchlaufen, bevor es am eigentlichen Watcher ankommt.
Irgendwelche kritischen Geschichten bekannt, die aufgrund dessen auftreten KÖNNTEN, oder ist das unter allen Umständen auszuschliessen?
Bequemer/flexibler ist die dynamische Kabel/Send-Variante ja ausserordentlich.

[herw]

Werd nicht ganz schlau aus der Antwort. Formuliere nochmal anders.

Port-Verschieben in der core-CELL (also oberste ebene) kritisch oder nicht?

Das ist wie gesagt Mark's Spezialgebiet; ich als Anwender vom ACEW (core) muss lediglich beachten, dass die Rückkoppelungen zum eigentlichen (primary-) ACEW richtig eingebaut werden. Bei den Ausgängen ist die Reihenfolge wichtig (von oben nach unten), quasi ein Order und so benutze ich es auch zum Teil, wenn ich Event-Nachrichten auf einem Bus versende. Mark ist wie gesagt der absolute Experte in diesen Dingen, aber zur glaube ich noch im Urlaub, aber, wie ich weiß, sehr REAKTOR-aktiv.

Bis ich den ACEW Core nutze ist es wohl noch ein Stück Weg;-)

Auf keinen Fall warten; der ACEW ist ein absolutes Muss beim Entwickeln von ensembles, sowohl in Primary als auch in core. Ohne ihn gäbe es modular framework nicht.

Apropos: Gibts eigentlich irgendeinen Grund, nicht ausschliesslichlich die wireless Variante des ACEW(prim) zu nutzen? Bei Bedarf kann ich doch die Ports auf reguläre Kabel switchen?
Hat die Send-Version irgendwelche Nachteile, wenn ich temporär Ports als Kabelversion nutze? Immerhin muss das ganze ja den switcher/router durchlaufen, bevor es am eigentlichen Watcher ankommt.
Irgendwelche kritischen Geschichten bekannt, die aufgrund dessen auftreten KÖNNTEN, oder ist das unter allen Umständen auszuschliessen?
Bequemer/flexibler ist die dynamische Kabel/Send-Variante ja ausserordentlich.

Ich denke nicht.
Falls Mark bis heute Abend hier nicht antwortet, mail ich ihm

[Quietschboy]

Kann man problemlos in ner Core-Cell die Ports vershchieben?
Hab die Erfahrung das das Core-Macros kritisch sein kann, deshalb lass ich es dort. Für die höchste Ebene, also die Cell, hab ich dergleichen noch nicht feststellen müssen. Aber vielleicht waren dass nur zufällig nur Ports wo Reihenfolge/Init keine Rolle spielt, deshalb zur Sicherheit nochmal nachgefragt. Spielt für die Cell die Anordnung der Ports irgendeine Rolle, wird bspw. von oben nach unten initialisiert obwohl es "draussen" anders ist?

Port-Verschieben in der core-CELL (also oberste ebene) kritisch oder nicht?

Die Anordnung von Ausgangsports in Core Macros ist völlig wurscht.
Aber bei den Ausgängen von Core Cells kann das in der Tat eine Rolle spielen. Für simultane Events an den Out-Ports gilt die Top->Down Regel mit der sie an die Primary Struktur übergeben und dort eben nacheinander jeweils bis zu ihrem Ende verarbeitet werden.
Das einfachste Beispiel ist das "Core Order". Ein Event wird simultan an beide Ausgänge (oder mehr, wenn man möchte) gesendet:

Core Order.JPG

Das Core Order hat den Vorteil, dass es für den simultanen Init-Zeitpunkt im Gegensatz zum Primary Order Module ohne Verzögerung arbeitet. Beim Primary Order wird bei Init ja nur der erste Outport unverzögert durchgereicht, die restlichen Ports erst post-Init abgefeuert. Das kann hier und da mal hinderlich sein, ist aber ziemlich selten dass man ein Core Order benötigt. Für Multiplexing sind die post-Init Outports des Primary Order sogar Pflicht.

Für die Eingänge der (R6) Core Cell gibt es bei Re-Init, nicht bei Init, auch eine Top->Down Order. Das habe ich im NI Forum im Thread "R6 Initialization" schon ziemlich ausführlich beschrieben.

Zum Wireless ACEW:
Ich habe bei länger dauernden Baustellen auch immmer den Wireless ACEW im Einsatz. Dazu mache ich mir meist Macros mit 4er-Päckchen Sends, die ich dort wo ich sie benötige platziere und meist auch lasse, denn irgendwann kommt man ja zurück in dieses Macro um weitere Untersuchungen zu machen. Die Sends benenne ich dementsprechend eindeutig.
Der Hauptgrund, warum es den "normalen" ACEW auch noch gibt, ist, dass die Receive Module im Wireless ACEW möglicherweise im Ensemble bereits vorhandene Send-Receive Verknüpfungen durcheinanderbringen können.
Aber da ist Herwig der Spezialist, was das angeht. Ich erinnere mich noch, dass das Send-Receive System in seinem vorletzten Modular äußerst fragil war und ein Wireless ACEW oder andere zusätzlichen Send-Receive Verbindungen das System gekillt hätten.

Ansonsten hat die "normale" ACEW Variante längere Beschriftungsfelder...
und, wichtiger, du kannst Audiostreams in den Primary ACEW leiten indem du den entsprechenden Inport auf Audio umstellst. Mit dem Wireless ACEW ist das mit seinem "Source select" Vorbau nicht ganz so einfach, es sei denn man überbrückt ihn einfach.

Gruß, Mark

[Quietschboy]

Noch ein anderes lebendes Beispiel, wo die Core Order eine Rolle spielt:

core order beispiel.JPG

Hinter einem Iterationsmodul folgt eine Core Cell die einen Router über den Ausgang G (Gate) ansteuert.
Beim Start der Iteration wird das Gate nicht vom Ausgang G des Iterationsmodul selbst bestimmt, sondern ein Wert G muss in der Core Cell anhand des ersten Iterationsevent auf "Iter" bestimmt werden.
Nun ist es aber wichtig, dass der Router gestellt wird, bevor das erste Iterationsevent die Core Cell verlässt.
Deswegen musste ich hier die Ports "Iter" und "G" vertauschen. Hier die Core Cell von Innen:

core order beispiel 2.JPG

Ich hoffe, dir wird es jetzt klar...

[Eventmanager]

Danke Herw, vor allem Danke Mark, namentlich das 2te Beispiel macht die Sache klar. Also Faustregel: Finger weg von funzenden CELL!!!! Ports, auch wenns für die Prim-Structure dann mitunter deutlich mehr kreuz und quer Kabel bedeutet. Im Bus-System (also diesem neuen core-MUX-Ding) bin ich noch nicht richtig drin, aber schonmal vorneweg, spielt hier die Reihenfolge ne Rolle (is ja auch ein core-MACRO, ein sehr spezielles zwar, aber immerhin doch ein MACRO, und nach deiner obigen Aussage wurscht, wo hier die Ports liegen), oder kann ich schalten und walten, wie ich will?

###
Jo, ein sauber benanntes Sendto-ACEW-Macro hab ich mir auch schon gebastelt Macht es deutlich schneller und übersichtlicher. Insbesondere inside Stack-Macros ist ja mit dem Kabel-ACEW nur sehr umständlich zu arbeiten...
Und erneut nochmal ein riesiges Dankeschön für dieses enorm-wichtige Tool.