Neue Logikbausteine für den L1/X1: Formelberechnung, Statistik und mehr...

[willisurf]

Parsley

Ich bräuchte mal einen Denkanstoß, wie Du Deine Statemachine implementiert hast.

Hat sich erledigt, siehe

hyman
Bei der Implementierung der etwas komplexeren Formeln habe ich wahrscheinlich einen reproduzierbaren Fehler in der Auswertung der Formel zum Aufstellen der Eingangsparameter gefunden. Verwendete Version ist die aktuelle 1.3.10
Wenn ich die z.B. diese Formel einsetze, werden keine Eingangsvariablen (hier ExtKz und ExtLg) erzeugt

Edit: Es scheint nicht nur an komplexen Formeln zu liegen, sondern wenn man gleich zu Beginn vor dem Einfügen von Variablen z.B. 5 Formeln auswählt. Dann werden auch einfache Variable nicht erkannt. Wenn ich dann z.B. nur zwei Felder (Formel 1 und2) mit einfachen Formeln/Variablen ausgefüllt habe und von 5 auf 2 Formeln zurückschalte werden die Variablen plötzlich aufgeführt. Bei komplexen Formeln funktioniert dies nicht.
(((_previousOut4_==1)|(_previousOut4_==0))?({ExtLg :I}==1?(byte?)3{ExtKz:I}==1?(byte?)2:0)):0)

Edit2: Es scheint immer dann ein Problem zu geben, wenn mehr freie Formeln als Variablen eingetragen sind oder wenn die Formeln wie u.a. komplexer sind.
Fehler Variablen.JPG

Nachdem ich das mit kurzen Formeln vorab erzeugt habe und danach die lange Formel verwende, kommt es zu einer Vertauschung der Eingänge siehe (rot umrahmt)
Edit: Einige Ausgänge waren auf Number gestellt, nachdem ich diese auf Byte zurückgestellt habe, war die Vertauschung weg. Das sollte man also nicht überbewerten...
Fehler Variablen2.JPG

[hyman]

Es scheint immer dann ein Problem zu geben, wenn mehr freie Formeln als Variablen eingetragen sind oder wenn die Formeln wie u.a. komplexer sind.

Das kann ich auch mit der aktuellen 1.3.16 reproduzieren, muss ich mir anschauen ... kann aber etwas dauern. Ich habe das Problem bisher nicht gehabt, weil ich so umfangreiche Formeln gern in mehrere zerlege.

Das mit der Vertauschung hab' ich auch gelegentlich nach mehrfachem Editieren der Formeln -- und keine Ahnung, woran es liegt. Workaround: Projekt schließen, wieder öffnen, dann tut es.

[willisurf]

Das kann ich auch mit der aktuellen 1.3.16 reproduzieren, muss ich mir anschauen ... kann aber etwas dauern.

Kein Problem, es gibt ja einen Workaround

Ich habe das Problem bisher nicht gehabt, weil ich so umfangreiche Formeln gern in mehrere zerlege.

Das Problem tritt auch bei einfachen Formeln auf, wenn ich mehrere Formeln auswähle (z.B. 5) und dann beginnend bei der ersten Formel einfache Platzhalter einfüge. Ich mache das per copy/paste, kann gerade.nicht sagen, ob das wichtig ist. Diese Platzhalter werden dann nicht als Eingang übernommen. Die Eingänge werden angelegt, wenn man die Anzahl der benutzten Formeln auf die aktuell ausgefüllten reduziert.

[hyman]

Generell werden alle Eingänge erst dann in einem Schwung angelegt, wenn alle Formeln ausgefüllt (und fehlerfrei) sind.

[willisurf]

Ah, alles klar. Dankeschön!

[GKap]

Hallo hyman!

Erst einmal großes Lob, die Formelberechnung ist genial! Ich verstehe nicht, wie Gira den X1 ohne einen solchen Baustein ausliefern kann - ohne deinen Baustein kann man ja kaum vernünftige Logiken programmieren! (Ich bin verwöhnt vom Homeserver, wo ich mir fehlende Bausteine selbst schreibe!)

Für eine Sache habe ich jedoch noch keine Lösung gefunden: Es wäre wünschenswert, wenn man auswählen könnte, welche Eingänge zu einer Neuberechnung führen! Konkretes Beispiel: Ich habe eine Formel für eine Interpolation angelegt. Die Stützstellen ändern sich immer wieder, diese Änderungen sollten aber nicht zu einem Telegramm am Ausgang führen. Nur wenn am Eingang X ein Wert ankommt, soll die Interpolation gerechnet werden. Gibt es irgend eine Idee dazu?

Gruß
GKap

[hyman]

Ich denk' mal drüber nach ... kann aber etwas dauern ...

[willisurf]

Es wäre wünschenswert, wenn man auswählen könnte, welche Eingänge zu einer Neuberechnung führen!

Wenn die Neuberechnung nicht stört und Du nur die Telegramme am Ausgang gezielt senden möchtest, würde doch eine Sperre am Ausgang der Berechnung genügen, die von den gewünschten Eingangsgrößen freigegeben wird.

[hyman]

So, Nachdenken hat zu folgender Idee geführt: Ich löse das

auswählen ... welche Eingänge zu einer Neuberechnung führen

nicht über Einstellungen an den Eingängen, sondern über zusätzliche vordefinierte Variablen: _is<name>ValueSet_, wobei <name> der Name des Eingangs ist. Damit kann man für jede Formel getrennt festlegen, ob sie ihren Ausgang aktualisieren soll oder nicht.

Was haltet ihr davon?

[willisurf]

Das klingt erstmal sehr sinnvoll. Eine kurze Frage nur dazu, der Default, bzw. das heutige Verhalten bleibt dadurch unberührt, richtig?

[hyman]

Klar, ich kann nix inkompatibles machen, sonst haben alle Nutzer einen Haufen Arbeit. Es bleibt alles wie es ist, solange man die neuen Variablen _is<name>ValueSet_ nicht explizit in einer Formel benutzt.

Zum Glück ist das im Baustein recht einfach zu implementieren, hab ich mal gemacht -- gleich mit automatischer Testabdeckung.

Dann sieht das in der Simulation z. B. so aus:

FormelNoValueSet.png
Zuletzt wurde ein neuer Wert an den Eingang NoTrigger geschickt. Dieser hat zwar eine Neuberechnung von Formel 1 ausgelöst, nicht aber die Ausgabe des neuen Werts an Ausgang 2.

Wenn das so bleiben soll, muss ich es jetzt "nur noch" dokumentieren. GKap , vielleicht stellst Du mir dazu Dein Anwendungsbeispiel zur Verfügung, damit da was praxisorientiertes steht.

Grüße von Horst

[willisurf]

Sehr schön, echt Klasse!

Ich habe das jetzt nicht durchdacht, ist das nebenbei auch eine Optimierung für die Implementierung einer Statemachine, die wir letztens diskutiert hatten?

[hyman]

Ich hatte den Gedanken auch schon in einer hinteren Gehirnwindung, bin aber noch nicht dazu gekommen, das zu durchdenken. Vielleicht kann man sich das Umsetzen aller Eingabewerte auf einen Eingang damit sparen ... sollten wir dort weiter diskutieren.

[GKap]

GKap , vielleicht stellst Du mir dazu Dein Anwendungsbeispiel zur Verfügung, damit da was praxisorientiertes steht.

Also konkret geht es um eine Tageskurve für die Farbtemperatur bei HCL. Die Tageskurve ist in mehrere lineare Interpolationen unterteilt, wobei es 2 Intervalle pro Tag gibt, deren Länge sich jeden Tag verändert: (Sonnenaufgang + X Stunden) bis (Sonnenuntergang - X Stunden) und (Sonnenuntergang + X Stunden) bis (Sonnenaufgang - X Stunden). Wenn ich nun die Farbtemperatur auch in diesen Bereichen variabel halten möchte (ob der Anwender das dann auch tatächlich nutzt sei mal dahingestellt!), muss die Interplation wissen, wann der Endwert erreicht werden soll. Bei jeder Neuberechnung dieser Zeitspanne, die als Endwert der Interpolation verwendet wird, würde in der bisherigen Version ein unerwünschtes Telegramm ausgesendet. Weiters würden bei Veränderung der Farbtemperatur-Stützstellen (durch Bedienung auf der Visu) unerwünschte Telegramme ausgesendet.

_is<name>ValueSet_

Ganz habe ich das Konzept noch nicht verstanden: Meine Interpolation besteht derzeit aus einer einzigen Formel. Kann ich dein neues Konstrukt in der Form {_isEndwertValueSet_} in meiner Formel verwenden, so dass der Eingang "Endwert" nicht zu einer Neuberechnung führt, oder muss ich eine 2. Formel anlegen, die nur aus einem Trigger zur 1. Formel besteht?

Gruß
GKap

[hyman]

Am Einfachsten lässt Du Deine erste Formel wie sie ist und fügst eine zweite hinzu, die im Prinzip wie in meinem obigen Beispiel aussieht (ohne geschweifte Klammern um _is...ValueSet_!). Wenn Endwert der Eingang ist der nicht triggern soll, dann musst Du aber nicht den referenzieren, sondern stattdessen den, der die Ausgabe auslösen soll (wie auch immer der heißt)!

Geht aber mit der aktuell verfügbaren Version 1.3.x noch nicht, musst Dich also gedulden bis zum Release 1.4.x, der wegen fehlender Doku noch etwas dauern kann.