Undokumentierte Operatoren im Formalbaustein?

[Riemen]

Hallo,

ich bin gerade zufällig über folgenden Beitrag gestoßen: https://www.loxforum.com/forum/faqs-...formelbaustein.

Dort wird intensiv der INT-Operator genutzt, der anscheinend die Nachkommastellen einer Dezimalzahl verwirft (nicht kürzt). Damit steht der Name wohl für Integer.

Das ist erstmal super, denn genau eine solche Funktion habe ich die Tage gebraucht, aber leider nicht gefunden.
Was mich jedoch wundert ist, dass dieser Operator in der Loxone-Dokumentation nicht erwähnt wird: https://www.loxone.com/dede/kb/formel/.

Ist das ein Fehler und wurde bloß diese eine Funktion vergessen? Woher stammt das Wissen über INT? Gibt es irgendwo eine vollständigere Liste? Gibt es vielleicht noch weitere undokumentierte Funktionen? Damit wäre der Formelbaustein ja mächtiger, als ich bisher dachte...

[Robert L.]

links unten stehts

[CBeck]

Er meint warum die da zwar zur Verfügung stehen aber nirgends genauer erklärt werden. Ist mir die Tage aber auch schon aufgefallen. Gibt so einige Dokupunkte die nicht erklärt sind

[Riemen]

Bisher wusste ich ja nicht mal, dass die Funktion zur Verfügung steht. Darauf das in diesem winzigen Fensterchen links unten eine Funktion steht, die in der Doku fehlt, darauf wäre ich nie gekommen.

Anscheinend ist es aber nur diese eine Funktion, die vergessen wurde. Schade. Ich hatte gehofft, dass es da noch mehr gäbe. Die PicoC-Bausteine sind ja leider ohne wirklichen Grund auf 8 begrenzt.

[Labmaster]

... Die PicoC-Bausteine sind ja leider ohne wirklichen Grund auf 8 begrenzt.

Der Grund sind die stark begrenzten Hardware Resourcen des Miniservers. Der Miniserver ist eigentlich ein extrem minimales System verglichen z.B mit einem RaspberryPI.

[Riemen]

Das kann man aber so pauschal nicht sagen, denn ein ausgelieferter Baustein wie eine Lichtsteuerung oder eine intelligente Raumregelung dürfte auch einiges an Logik enthalten. Wenn ich jetzt einen Fünfzeiler mit einer Formel und einer If-Abfrage in einen PicoC-Baustein packe, wird dieser auch nicht mehr Leitung fressen, als so mancher Fertigbaustein. Das die PicoC-Bausteine teilweise so viel Logik enthalten, liegt ja eher daran, dass sie auf 8 begrenzt sind und man daher möglichst alle Ein- und Ausgänge nutzen will.

Aufgrund dieser Beschränkung wird oft versucht, wenn möglich PicoC-Bausteine durch komplexe Logiken mit zig herkömmlichen Bausteinen und mehreren Formeln zu ersetzen. Wenn ich an den Overhead der Verwaltung jedes einzelnen Bausteins denke, behaupte ich mal, dass ein einzelner PicoC-Baustein hier sogar Ressourcenschonender wäre.

Kurz gesagt: man kann den Miniserver auch mit herkömmlicher Logik überlasten. umgekehrt führen mehr als 8 aktive PicoC-Bausteine nicht zwangsläufig zu einem großen Ressourcenhunger.

Daher halte ich die pauschale Beschränkung auf 8 Bausteine für falsch.

[romildo]

....Kurz gesagt: man kann den Miniserver auch mit herkömmlicher Logik überlasten.....

Dafür werden aber schon einige Bausteine benötigt. Bei PicoC reicht eine Fehlprogrammierung.
Daher könnte man auch die Meinung vertreten, dass einer schon zu viel ist

In der Vergangenheit reichte auch oft schon ein einziger Fehler in einem Programmbaustein um das ganze System lahm zu legen und den Miniserver damit nicht mehr erreichbar zu machen.
Da lief dann nicht nur das System nicht mehr, sondern man hatte auch sämtliche Daten und Programme verloren, sofern diese nicht gesichert waren.
In den vorhandenen Bausteinen können Fehleingaben abgefangen werden, was aber in einem PicoC nicht so einfach möglich ist.
Auch kann mittels PicoC die restliche Programmierung beeinflusst werden und somit eine Fehlersuche erheblich erschweren.

Das hat jetzt natürlich nichts mit der Anzahl zu tun.
Persönlich würde ich aber davon abraten Programmbausteine zu verwenden so lange es möglich ist die Funktion auch mit bestehenden Bausteinen zu realisieren.

[Labmaster]

Das Problem bei einem Interpreter wie PicoC ist, daß man aber entweder die Umgebung in der man einen User arbeiten lässt stark und fix limitieren muss oder aber von Grund auf ausreichend Spielraum für alle Maximalfälle lässt, in beiden Fälle muss ich jedoch in einem stark begrezten System wie dem Miniserver gewisse resource vorhalten. Wieviel, daß ist wohl eine Gratwanderung.
Wir habe vor kurzem versucht den PicoC Code auf einem CortexM4 zum laufen zu bekommen, was auch grundsätzlich möglich war, jedoch soviel Resourcen gebraucht hat, das der Controller für nicht viel mehr anderes zu gebrauchen war und das unabhängig davon ob der Interpretercode nun 10 Zeile oder 100 Zeilen hatte. Das Hauptproblem war der Speicherbereich der mehr oder weniger global für den Interpreter zu reservieren ist.