LBS(Sammlung) Squeeze

[wintermute]

Sooo...
Aktuelle Versionen der Bausteine sind im Portal zu finden, da koennten einige (neue sowie alte) Bugs drin sein - es hat sich konzeptionell einiges geaendert. Die Versionen lauten 0.4 fuer den Server (19000200@0.4), 0.2 fuer den Client (19000201@0.2) und 0.3 fuer den Kommando LBS (19000202@0.3).

Grundlegend behoben wurden die beiden konzeptionellen Probleme von d (zwei Client LBS an denselben Ausgang eines Kommando LBS zu haengen) und jonofe (zwei Eingaenge eines Kommando LBS "gleichzeitig" zu triggern).

(Falls es interessiert: Letzteres Problem kam dadurch zustande, dass innerhalb eines LBS-Durchlaufes ein Ausgang nur einmal gesetzt werden darf/kann und dadurch der "erste" Trigger verloren ging - das liess sich dadurch beheben, dass der LBS die Kommandos sammelt, verkettet und dann "in einem Schub" auf den Ausgang legt.
Ersteres Problem war etwas tiefer verbuddelt und hatte wohl mit der Kommunikation zwischen LBS- und EXEC-Teil innerhalb eines einzelnen Bausteins zu tun (hier innerhalb des Server LBS), das konnte ich durch Verwendung einer Pipe in den Griff bekommen.)

Die beiden oben geschilderten Bugs sollten also behoben sein, zumindest in meinen Testlogiken sah es bisher gut aus.

gruss :: Michael

[gaert]

Nicht unbedingt, denn:
- die "Wartezeit" ist dynamisch (passt sich dem aktuellen Bedarf an)
- während des Wartens könnten ja (theoretisch) andere Bausteine den gleichen Eingang (über weitere LBS) setzen. Ausgänge sind wie gesagt eigentlich Eingänge anderer Bausteine...

Die Chancen steigen natürlich, wenn man wartet Und das ist natürlich auch alles sehr konstruiert, was ich schreibe - in der Praxis sieht das mit Deinem LBS sicher nicht so dramatisch aus, da Du vermutlich nicht mit weiteren Logiken an den Ausgängen rechnen musst.

[wintermute]

Tut mir leid Aber das ist nunmal das Konzept eines LBS (verhält sich beim HS übrigens ähnlich).

Ist ja erstmal keine Sache, muss man halt gucken wie man das dann anderweitig auf die Reihe bekommt...
Zum Verstaendnis: bzgl derselben Problematik (also denselben Ausgang in einem EXEC mehrfach schnell "toggeln") schriebst Du "Glueckssache"
Oder anders formuliert: wenn man zwischen den Wechseln einen Durchgang der globalen Logikengine abwartet (also global_logicWaitMax), dann muesste eigentlich alles korrekt ankommen, oder?

gruesse :: Michael

[gaert]

Tut mir leid Aber das ist nunmal das Konzept eines LBS (verhält sich beim HS übrigens ähnlich).

[wintermute]

Ein LBS ist so konzipiert (und auch zu implementieren), dass bei jedem einzelnen Aufruf genau 1 eindeutiges "Ergebnis" resultiert. Das Ergebnis kann natürlich mehrere Ausgänge setzen - aber nach dem Durchlauf werden die "Ausgänge" erst alle zusammen verarbeitet.

Ja, genau das hatte ich befuerchtet...

Ich muss dann mal in mich gehen und mir ueberlegen ob ich das i-wie anders loesen kann, aber konkret faellt mir dazu erstmal nix ein.
Bis auf weiteres ruht die Entwicklung der Squeeze-Bausteine dann erstmal.

gruesse :: Michael

[gaert]

Der EXEC-Teil arbeitet naturgemäß asynchron, also völlig losgelöst von der Logikengine. Daran ist nix zu rütteln, denn das wäre im Detail zu "unsicher" (der EXEC-Teil nimmt nicht(!) an der "Verkettung" von Bausteinen teil, sondern darf halt mal dazwischenfunken).

Zu Deiner anderen Frage:
Man kann nicht 2 Ausgänge mit einem Eingang verbinden... Da gehört immer ein LBS dazwischen - und von diesem hängt natürlich auch das Verhalten ab

Könnte ich den LBS irgendwie dazu bringen für jeden geänderten Eingang erneut durchzulaufen?

Puh... Naja, mal abgesehen von irgendwelchen Verzögerungs-Bausteinen am Eingang (irgendwie unsauber) bleibt hier nur eine eigene Implementierung mit Variablen etc... Vielleicht wäre es an dieser Stelle sinnvoller, das Design Deines LBS zu überdenken (und an das EDOMI-Logikkonzept anzupassen).


Nochmals zum besseren Verständnis:
Ein LBS ist so konzipiert (und auch zu implementieren), dass bei jedem einzelnen Aufruf genau 1 eindeutiges "Ergebnis" resultiert. Das Ergebnis kann natürlich mehrere Ausgänge setzen - aber nach dem Durchlauf werden die "Ausgänge" erst alle zusammen verarbeitet.

[jonofe]

wäre es nicht sinvoller jedes Beschreiben eines Ausgangs in einer Queue zu puffern und somit auf jeden Fall abzuarbeiten? Das wäre aus meiner Sicht zumindest die deterministischere Lösung. Man wüsste somit zumindest dass jedes "Senden eines KO's" (Setzen eines Ausgangs) abgearbeitet wird. Ich verstehe dass die Reihenfolge dann nicht deterministisch ist, aber das ist auch okay.

Zusätzliche Frage dazu:
Was würde denn passieren wenn ich statt einem Ausgang mehrmals in einem LBS Durchlauf einen Wert zuzuweisen, mehere Ausgänge hätte, jedem einen Wert im Zuge des LBS Durchlaufs zuordnen würde und alle Ausgänge demselben Eingang eines andere LB zuordnen würde. Würden dann alle Werte sequentiell abgearbeitet?
Konkret: in einem Durchlauf werden die squeeze-Kommandos "play 0" und "power 0" generiert. jedes wird auf einen separaten Ausgang gelegt, dieser aber mit demselben Eingang am SqueezServer LBS verbunden. Werden dann beide Befehle abgearbeitet?

Wenn nein, wie würde man das Problem lösen?
Könnte ich den LBS irgendwie dazu bringen für jeden geänderten Eingang erneut durchzulaufen? Bsp. Eingang 1 und 2 haben sich geändert. LBS läuft einmal durch und arbeitet den Wechsel von Eingang 1 ab. Außerdem wird festgestellt, dass sich Eingang 2 auch geändert hat, also müsste er dafür nochmal getriggert werden. Geht das irgendwie?

[gaert]

Im EXEC-Teil ist es quasi Glückssache, da asynchron. Der Ausgang wird natürlich immer gesetzt, sobald man die Funktion aufruft - aber man kann nicht vorhersagen, wann genau darauf reagiert wird: Es werden in Wirklichkeit nämlich keine Ausgänge gesetzt (die gibt es garnicht), sondern die Eingänge, die mit den Ausgängen verbunden sind. Wenn also im EXEC ein Ausgang gesetzt wird und "unmittelbar" danach der Ziel-Eingang von einem anderen LBS gesetzt wird, gewinnt u.U. der andere LBS.

EXEC-LBS sind also eher für spezielle Dinge wie... naja, ist ja bekannt... geeignet. Eher weniger für typische Logikaufgaben. In den meisten Fällen spielt das aber vermutlich keine Rolle.

[wintermute]

Wenn Du also einen Ausgang mehrfach während eines "Durchlaufs" setzt, wird natürlich nur der letzte Wert berücksichtigt.

Ja, so hatte ich das gemeint.
Passiert das auch um EXEC-Teil? Vermutlich nicht, denn sonst taete ein Daemon ja prinzipiell nicht funktionieren, richtig?
Also koennte man das Verhalten umgehen, indem man aus dem "konventionellen" LBS eine EXEC-Variante macht?

gruesse :: Michael

[gaert]

Das Setzen eines Wertes an einem Ausgang wird sofort erledigt, sobald die Funktion aufgerufen wird. Eine Queue gibt es durchaus, allerdings nicht innerhalb EINES Aufrufs des Bausteins! Der Baustein wird ja (hier mal abgesehen von Timern etc.) immer dann aufgerufen, wenn an einem oder mehreren Eingängen etwas passiert. Dies entspricht quasi genau einem Durchlauf des Bausteins (also der Hauptfunktion im LBS-Teil). Auch wenn mehrere(!) Eingänge quasi gleichzeitig refreshed werden, wird der Baustein nur einmal aufgerufen - sonst würde schnell ein ziemliches Chaos entstehen

Wenn Du also einen Ausgang mehrfach während eines "Durchlaufs" setzt, wird natürlich nur der letzte Wert berücksichtigt. Die Logik-Verkettung simuliert schließlich keine elektronische Schaltung Natürlich wäre es prinzipiell auch möglich, dass bei JEDEM Setzen eines Ausgangs ein entsprechendes Event getriggert wird - aber dann wird's u.U. sehr schnell sehr "rekursiv"...

Das Prinzip ist also:
1. irgendwas kommt rein (Eingänge)
2. dies wird verarbeitet (1 Durchlauf)
3. irgendwas kommt raus (Ausgänge)

[jonofe]

Nee nee Da wird nix verschluckt... Allerdings betrifft dies nur den LBS-Teil - der EXEC-Teil läuft ja quasi asynchron vor sich hin.

Und wichtig in diesem Kontext: Vor 1.20 (oder war's 1.21?) könnte tatsächlich etwas verschluckt werden, wenn die KOs schnell hintereinander eintreffen. Aber dies habe ich korrigiert in der aktuellen Version, bzw. in 1.20/1.21

Es ging in meinem Fall nicht um zu schnell eintreffende KO's, sondern darum, wenn dasselbe KO an mehreren Eingänge eintrifft und ein LBS Durchlauf aufgrund der implementierten Logik denselben Ausgang in diesem Durchlauf zweimal mit unterschiedlichen Werten belegt. Dann scheint nur das letzte Setzen des Ausgangs berücksichtigt zu werden. Es ist also die Frage ob SetLogicLinkAusgang() Aufrufe gequeued werden oder ob am Ende des LBS Durchlaufs geschaut wird, welchen Zustand sie haben und dann damit die weitere Logik getriggert wird. Im Moment sieht es eher nach letzterem Verhalten aus.

[gaert]

Nee nee Da wird nix verschluckt... Allerdings betrifft dies nur den LBS-Teil - der EXEC-Teil läuft ja quasi asynchron vor sich hin.

Und wichtig in diesem Kontext: Vor 1.20 (oder war's 1.21?) könnte tatsächlich etwas verschluckt werden, wenn die KOs schnell hintereinander eintreffen. Aber dies habe ich korrigiert in der aktuellen Version, bzw. in 1.20/1.21

[rdeckard]

Danke für die Tests!
Schade, jetzt wo es eigentlich schon richtig gut laufen würde. Aber ich hoffe, Christian wird da schon noch eine Lösung finden.

[wintermute]

Sooo... nachgebaut, getestet, stümmt...
Das mit den verzögerten Aktualisierungen zumindest, wieso das mit dem stop passiert weiss ich noch nicht - so weit hab ich mich nicht getraut

Problem ist, dass Edomi scheinbar KO Wechsel verwirft wenn diese "quasi-parallel" oder zumindest sehr sehr schnell nacheinander auftreten, aehnlich dem Problem, das André weiter oben ausgefuehrt hat (ich glaube nicht aehnlich, sondern sogar identisch).
In deinem konkreten Fall ist es jetzt so, dass 2 Client LBS quasi "zeitgleich" in dasselbe KO schreiben, in den allermeisten Faellen kommt aber nur einer davon wirklich durch, wenn man die LBS einzeln debugged, kann man das gut sehen (so sieht das zB bei dem nachgebauten Szenario von Dir aus):

016-03-05 23:46:31 --- LBS19000201(34:15:9e:8e:de:22): sending player command '34:15:9e:8e:de:22 mixer volume 50'
016-03-05 23:46:31 --- LBS19000201(00:88:65:3e:2b:34): sending player command '00:88:65:3e:2b:34 mixer volume 50'
016-03-05 23:46:32 --- LBS19000200(127): Received external command: 00:88:65:3e:2b:34 mixer volume 50
016-03-05 23:46:32 --- LBS19000200(127): Sending '00:88:65:3e:2b:34 mixer volume 50'

Also: zwei unterschiedliche LBS (die 201er) schreiben quasi zur selben Zeit in dasselbe KO und wer zuletzt kommt, behaelt da die Oberhand (in obigem Beispiel wird also nur das letzte Kommando tatsaechlich zum Server LBS transportiert).
Anders gesagt: scheinbar arbeitet Edomi da nicht sobald sich der Status eines KOs aendert (also nicht ereignis-getriggert), sondern arbeitet eine Schleife ab und nimmt die Werte die zu dem Zeitpunkt grad in den KOs stehen (Christian, bitte entschuldige wenn das inkorrekt ist, aber so scheint mir das grad).

Kurzum: weiss ich jetzt nicht, was ich dagegen machen soll... an bestimmten Stellen zu warten hilft vielleicht, kann aber auch nicht der Stein der Weisen sein. Vielleicht hilft es auch, den Client LBS als EXEC-Variante auszulegen, denn da schien es mir bisher zumindest so, dass auch schnelle KO-Wechsel tatsaechlich einzeln abgearbeitet werden. Weiss ich aber nicht wirklich, ich hab zu wenig Wissen bzgl der Internals.

Ich hab schon zweimal angefragt, jetzt nochmal

gaert ist das so korrekt und beabsichtigt? Weil wenn, dann muss ich hier nicht mehr weitermachen...

gruesse :: Michael

[wintermute]

Habe ich bei der Verdrahtung noch einen Fehler drin? (Auch wenn es ja grundsätzlich funktioniert. Nur sehr langsam und dieser Stop-Status ist definitiv falsch.)

Ich kann jetzt nicht in jedes KO (und jede Ausgangsbox) gucken, aber prinzipiell sieht das ok aus. Alledings steuerst Du mit dem Kommando LBS beide Player parallel an (so wie es ausschaut). Also schickst du die Kommandos gleichzeitig an beide Player. In der Theorie sollte das auch funktionieren, ich werde spaeter mal versuchen das mit zwei Softwareplayern nachzustellen...
Es taete mich aber nicht wundern, wenn das irgendwie mit der Synchronisation zu tun hat...

Sobald ich Zeit finde probier ich Deine Verkabelung mal aus, ich meld mich dann nochmal.