Uwe möchte Lesestoff haben: na dann...
Also, Ihr habt alle recht. Irgendwie.
Und was in den Modulen abläuft (egal ob real oder virtuell) ist für sich genommen auch völlig logisch und in sich stimmig.
Nur die Interpretationen und Schlussfolgerungen passen nicht so ganz zusammen, das möchte ich im folgenden nochmal genauer zusammenschreiben, auch wenn manche manche Details wohl als Haarspalterei abtun würden.
Ach so: Es ist keiner gezwungen, mein Geschreibsel zu lesen
Wer es nicht tut, möge aber bitte das folgende quasi als Faustregel beherzigen, denn es führt zu robusteren Parametrierungen:
[zitat]
Original von BeleuchtfixEs ist schon sehr wichtig, welcher Befehl an welcher Stelle kommt. Und ob eine Reaktion nun vor oder nach dem nächsten Befehl kommt, ist nicht unbedingt vorherzusehen. Bei richtig zeitkritischen Anwendungen muss man noch eine Zeitverzögerung einbauen.[/zitat]
[hr]
Fangen wir nun an:
[zitat]
Original von BeleuchtfixNach allem, was ich bis jetzt weiß, werden die Befehle der Reihe nach A1-A8, jeweils zuerst kurz - lang -los und dabei zunächst Erstbelegung-Zweitbelegung ausgeführt.[/zitat]
Das kenne ich im Prinzip genauso, und es passt auch zu allen Bus-Mitschnitten in diesem Thread, ich würde anstelle des Wortes "Befehle" jedoch lieber "gedrückte LCN-Taste" verwenden wollen (autsch, das war das erste Haar).
[zitat]
Original von MartinHWenn dies so wäre, dann würden die LCN-Module ein Sende Taste Kommando wie "TASTEN 1234---- C=kurz" nicht atomar (unteilbar) abarbeiten (!) (?)[/zitat]
Der Sende-Taste-Befehl selbst ist atomar, er "drückt" hier gewissermaßen die Tasten C1 bis C4 kurz gleichzeitig. Und damit ist dieser Befehl auch schon komplett erledigt und das Modul kann sich der nächsten Aufgabe widmen, in diesem Fall nämlich nachzusehen, ob eine Taste gedrückt wurde.
Auf dem nächsten Haar steht daher: Es muss zwischen dem Tastendruck und der Abarbeitung desselben unterschieden werden.
Die Abarbeitung kann nicht atomar sein, das folgt aus der folgenden Aussage, die letztlich auch irgendwo in der PRO-Hilfe steht:
[zitat]
Original von UweUnd immer daran denken: die Module senden maximal 5 Kommandos pro Sekunde (!) [/zitat]
Mit einem einzigen Sende-Taste-Kommando lassen sich 4*8=32 Tasten gleichzeitig drücken. Zusammen mit den Schattentasten könntest Du also 64 Kommandos in den Bus senden. Bei maximal 5 pro Sekunde ist das Modul also schon einige Zeit damit beschäftigt. Soll es bei einer angenommenen "atomaren Abarbeitung" in diesen über 10 Sekunden also auf nichts mehr reagieren? Natürlich arbeitet das Modul währenddessen weiter und arbeitet laufende Timer ab und "drückt" ggf. die B-Tasten, falls ein BMI auslöst.
Wer sich übrigens schon mal gewundert hat, warum ein BMI "verzögert schaltet": Obige Unterscheidung liefert die Erklärung: Der BMI "drückt" erst die Taste, aufgrund vorübergehender "Arbeitsüberlastung" im Modul wird diese Taste jedoch erst etwas später abgearbeitet.
Sehen wir uns Heinrichs Bus-Mitschnitt mit diesem Wissen noch einmal genauer an:
13:12:40:606 - M007 an M050 TASTEN 1234---- C=kurz
Hier werden die vier Modul-Tasten gleichzeitig gedrückt. Das Modul hat gerade nichts weiter zu tun, beginnt also mit der Abarbeitung der Tasten. Es wird C1 kurz abgearbeitet, und da diese Taste nicht gesperrt ist, folgende Kommandos in den Bus gesendet:
13:12:40:646 - M050 an M050 Relais 100- ----
13:12:40:666 - M050 an M050 TastenSperre C: 1011 ----
Das Modul 50 liest vom Bus auch eben diese beiden Kommandos und arbeitet sie ab. Es klappern also die Relais und die Tastensperre Tabelle C wird geändert.
Danach langweilt sich das Modul wieder und arbeitet wieder die Tasten ab. C2 muss als nächstes abgearbeitet werden. C2 ist inzwischen nicht mehr gesperrt, es landen also die folgenden Kommandos auf der Datenader:
13:12:40:726 - M050 an M050 Relais 110- ----
13:12:40:746 - M050 an M050 TastenSperre C: 1101 ----
Ich denke, ich kann hier abbrechen, es sollte klar sein, warum es in einem realen Modul nicht funktioniert hat.
[zitat]
Original von Uwe[zitat]
Original von MartinH(!) Ein Firmware-Bug (?)[/zitat]
Definitiv nein, Martin. Das ist schon immer so - und das wird wohl auch so bleiben. Eben "Timing" der Kommandos ...[/zitat]
Es ist sicher kein Bug, sondern es ist eher so gewollt. Dahinter steckt letztlich ein geniales Konzept im Umgang mit knappen Ressourcen. Und da in der Realität andere Ressourcen knapp sind als in der virtuellen Welt, verhalten sich die vMs in diesem Punkt halt anders als reale Module.
[zitat]
Original von MartinHFrage an LinHK ist dann noch, warum die vM Firmware es anders
(besser!) macht?[/zitat]
Ob das besser ist, weiß ich nicht. Anders in jedem Fall: Das vM arbeitet erst einmal C1 bis C4 ab, bevor es neue Kommandos vom Bus auswertet. Die Prioritäten bei der Abarbeitung sind halt anders gesetzt.
[zitat]Und braucht LinHK dann eine vM Option damit Befehle "nicht atomar" ausgeführt werden, um kompatibel mit dem Vorbild zu bleiben?[/zitat]
In diesem konkreten Fall müsstest sich das vM genauso wie das reale Modul verhalten, wenn Du das vM auf "Interne Koimmandos nicht in den Bus senden" stellst. Habe ich aber nicht selbst ausprobiert.
[zitat]Bitte liebe Freunde des Tastensperrens meldet euch![/zitat]
Auch ich nutze erfolgreich die Tastensperre. Aber warum klappte Dein Ansatz hier nicht? Weil die Tasten sich selbst sperren und entsperren. Da ist dann wirklich die interne Abarbeitungsreihenfolge im Modul entscheidend (hier: gedrückte Tasten vs. neue Kommandos auf der Datenader) und darüber sollte man besser keine Annahmen machen, sondern sich besser an Florians goldene Faustregel halten. Bei mir werden die Tasten üblicherweise durch Sensoren (z.B. Dämmerungsschalter) gesperrt und entsperrt. Eine davon unbahängige Quelle ruft dann die betroffenen Tasten auf und nur eine wird wie gewünscht ausgeführt.
Bei Ueli hat eine weitere Taste das Sperren übernommen und dadurch die Situation entschärft. Und wenn man bei vier Tasten bleiben möchte, könnte man die derzeitigen LANG-Kommandos auf LOS legen und die derzeitigen KURZ-Kommandos auf LANG. Dann wären die kurzen Tasten frei für ein STV-Ziel, das die Tasten dann mit Verzögerung neu sperrt.
Schöne Grüße
Niko, der die ausgerauften Haare und das scharfe Messer jetzt wieder beiseite legt
)
Offizieller KNX Partner 