PARTIALS FRAMEWORK (multiplexing)

[herw]

Beispiel 2: einfacher Eventblock (Teil 8)

alles ist erlaubt

EventBlock7.ens

Da nun der Eventblock mit Zeitgleichheit in der CoreCell ankommt, können wir nun beliebig die Daten ändern.

Beispiel 2-24.jpg

Hier mal ein Beispiel, wie man die Daten shiftet:

Beispiel 2-25.jpg

alles erlaubt - alles super einfach

[herw]

Beispiel 3: Eventblock und EventTable (Teil 1)

Da wir ja schon im fortgeschrittenen Stadium sind, kann ich mir viele Erklärungen sparen, da das Wesentliche in den obigen Posts bereits angesprochen wurde.
Wir wollen in diesem Beispiel das Ein- und Auslesen von Daten einer EventTable mit Hilfe eines Eventblocks durchführen.

Einlesen einer EventTable: die schmutzige Lösung

EventBlock8.ens

Beispiel 3-1.jpg

Warum schmutzige Lösung? Naja schaut man sich die nächste Abbildung an und vergleicht mit meinen Kommentaren weiter oben, dann ist klar, dass ich eine Verschachtelung der Datenelemente nicht mag: wenn schon Block, dann auch richtig Block.

Beispiel 3-2.jpg

An der Funktionstüchtigkeit ist nichts zu mäkeln, aber die Durchführung ist nicht so klar.
Wie funktoniert's: nun, die Daten kommen ja schon in der richtigen Reihenfolge, wir müssen nur noch den passenden Index herausfiltern.
Da wir die Daten nicht mit receive_synchronous empfangen, werden sie einzeln „abgearbeitet”.
Den port flag müssen wir natürlich unberücksichtigt lassen, da dieser ja nicht mit abgespeichert werden soll, der Index beginnt also eigentlich mit 1, daher müssen wir um 1 reduzieren.

Beispiel 3-3.jpg

[herw]

Beispiel 3: Eventblock und EventTable (Teil 2)

Einlesen einer EventTable: die saubere Lösung

EventBlock9.ens

Beispiel 3-4.jpg

Ich habe das Makro send_( [], $) aus dem send_synchronous abgeleitet. Zusätzlich zu den Daten werden vorweg jeweils die Indices gesendet.

Beispiel 3-5.jpg

Das Ausfiltern der relevanten Daten hängt nun von der Iteration ab; die Indices 0 und 1 sind hier unwichtig. Ich gehe jetzt hier nicht darauf ein, da die Iterationen noch mal ein extra Thema sein werden.

Beispiel 3-6.jpg

Nun das Ergebnis ist doch wohl eindeutig sauberer:

Beispiel 3-7.jpg

immer eins nach dem anderen.

Ich hoffe, man erkennt schon, wie schnell man zu eigenen Lösungen kommt, wenn man die Vorgaben des frameworks zum Multiplexing konsequent benutzt.

ciao herw

[herw]

Beispiel 3: Eventblock und EventTable (Teil 3)

Auslesen einer EventTable

EventBlock10.ens

Ich habe zunächst eine Clienttabelle erzeugt, da man ja in der Regel die EventTable dezentral lesen möchte. Natürlich kann man das Konstrukt auch auf dieselbe EventTable anwenden. Zu beachten sind die Verknüpfungen der drei Module.

Beispiel 3-8.jpg

Was haben wir? Fünf Daten, die in einer EventTable abgespeichert sind. Sie werden über den Leseindex Rx und den Lesetrigger R abgerufen.
Was wollen wir? Einen Eventblock, der einen Identifier id, die Anzahl # der folgenden Daten, einen port_flag or und die eigentlichen fünf Daten, also insgesamt acht Daten besitzt.
Wir erzeugen durch den Trigger Lies eine Schleife mit dem Datenbereich [-3,4]. Die negativen Parameter erzeugen den Kopf (header {h}) des Eventblocks, also (id,#,or), die anderen rufen über einen Indexbus {i} die Daten aus der Tabelle ab. Da alles sequentiell abläuft, werden die Daten als Eventblock gesendet.

Beispiel 3-9.jpg

Wie viele Daten letztlich abgerufen werden sollen, wird über den Parameter DX der EventTable ermittelt. D.h. das Beispiel ist für beliebig große EventTables gedacht. Denkbar wäre hier auch der Abruf von Teilbereichen, wenn man bei der Ausgabe der Indices eine Rechenoperation anwendet.
Gelb umrandet ist der Bereich des headers. Es passiert dort nicht viel, interessant ist vielleicht die Berechnung des port_flags or. Das erkläre ich mal nicht, sondern gebe das als Mathematikaufgabe zur Binärrechnung.
Die Parameterwerte 0 bis 4 werden nach außen der EventTable zugeführt, wo sie den Lesevorgang auslösen.

Beispiel 3-10.jpg

Kleine Bemerkung zur EventTable: damit beim Duplizieren der Table auch wirklich eine ClientTable entsteht, muss man die erste Table zunächst abspeichern (irgendeinen Namen). Dadurch ist sie quasi im Ensemble angemeldet und damit verknüpft. Die gerade abgespeicherte Tabelle kann man auf seinem Compi übrigens wieder löschen. Wenn man die Tabelle nun dupliziert, laufen diese synchron. D.h. jede Änderung in der ersten Tabelle bewirkt auch eine im client und umgekehrt. In diesem Ensemble ist nur die erste Tabelle sichtbar.

Ich habe beim Abspeichern des Ensembles die Tabelle in den Draw-Modus gestellt. D.h. man kann auch von Hand die Werte ändern und über Lies auslesen.
Der Sende-Knopf überschreibt wieder.

ciao herw

[MvKeinen]

danke, herw wie immer für die klaren Ausführungen. Da hab ich erstmal ne Menge zu verarbeiten.

Wenn ich aber so frech sein dürfte und einen kleinen Wunsch für irgendwann äußern dürfte, dann wäre ein Kapitel über die Terminologie des Partial Frameworks interessant. Also Namensgebung der Ein- und Ausgänge und deren Bedeutung. Ich mach mir da gerade selber ein paar verallgemeinerte Notizen, bin mir aber sicher dass diese "löchrig" sind.

aber erstmal viel spass im Urlaub und danke nochmal

[herw]

danke, herw wie immer für die klaren Ausführungen. Da hab ich erstmal ne Menge zu verarbeiten.

Wenn ich aber so frech sein dürfte und einen kleinen Wunsch für irgendwann äußern dürfte, dann wäre ein Kapitel über die Terminologie des Partial Frameworks interessant. Also Namensgebung der Ein- und Ausgänge und deren Bedeutung. Ich mach mir da gerade selber ein paar verallgemeinerte Notizen, bin mir aber sicher dass diese "löchrig" sind.

aber erstmal viel spass im Urlaub und danke nochmal

steht aber alles in obigen posts

hier eine kleine Auswahl

id = identifier des Events oder Eventblocks
# = Anzahl der folgenden Daten eines Blocks
[] = Index des aktuellen Datenwerts eines Blocks beginnend mit 0
$ = Datenwert
or = port flag zum synchronen Senden und Empfangen
+- und -+ = Verbindung zum chain Iterator
! = Trigger
{b} = Datenbus
id? = Abfragewert auf Gleichheit mit dem identifier das Datenblocks, kann auch ein boolscher Wert sein, wenn man die Abfrage selbst gestalten möchte.

Anfänglich gefielen mir die Bezeichnungen auch nicht, aber man gewöhnt sich daran. Ein Umbenennnen nach persönlichen Geschmack ist in einer allgemeinen Diskussion oder beim Austausch von neuen Makros nicht sinnvoll.