Logik, Laufzeit und Reihenfolge der Berechnung

[MatthiasS]

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

[swenga]

Gebe ich Dir zu 100% Recht. Diskrete Ausführung sowie Schleifen und klare Bedingungen wären wünschenswert. Die zwangsläufige Abwärtskompatibilität wird hier IMHO aber eine gewisse Hemmschwelle seitens des Herstellers verursachen, leider....

mfg

[Tokamak]

Um Himmels Willen, die Bausteine können und sollen nicht mehr geändert werden. Man könnte sie höchstens erweitern, etwa, in dam man pro Eingang markieren kann, ob dieser die Berechnung des Bausteins triggert oder nicht.

Aber was spricht dagegen, den Logikeditor um Konstrukte wie "if" und "while" zu erweitern? Nur, wenn die genannte Bedingung erfüllt ist, wird die Logik im Body ausgeführt. Dort können dann die altbekannten Bausteine eingefügt werden.

[swenga]

Aber die Verbesserungen in den letzten Versionen bezogen sich fast nur auf die GUI

Ich habe mir auch schon einiges Mal ob der Logik-Abläufe im HS die Haare gerauft. Aber jetzt stell Dir mal vor, die ändern wirklich was an der Logikengine, plötzlich funktionieren einige hundert Bausteine beim Kunden nicht mehr, das ist eine Zeitbombe sondergleichen!

mfg

[Tokamak]

Ähnlich wie du habe ich mit der Ereignissteuerung des HS stark gehadert, weil sich damit viele Konzepte, die man aus der Standardprogrammierung kennt, nicht umsetzen lassen. Letztlich sind die Logiken des HS nichts anderes als EIB-Geräte, die GAn empfangen, dann tätig werden und GAn senden.

Um ein wenig besser klarzukommen, haben ich mir neben einigen anderen einen Baustein geschrieben, der alle unären und binären logischen und arithmetischen Operationen anbietet und bei dem gesteuert werden kann, wann er ein Resultat liefert (Eintreffen eines Wertes auf E1, Eintreffen auf E2 oder Eintreffen eines Triggers unabhängig von den Eingängen). So kann ich bestehende Werte erst dann nutzen, wenn ich sie brauche, d.h. eine Änderung eines Wertes triggert - so ich will - die Logik nicht.

Wenn Dacom Ifs und Schleifen anbieten würde, wäre die Welt schon einfacher. Aber die Verbesserungen in den letzten Versionen bezogen sich fast nur auf die GUI, die für mich uninteressant ist.

[GKap]

Hallo Tokamak!

...
Das geht in dem HS-Konzept letztlich nur mit eigenen Bausteinen.

Richig, und das führt mich gleich weiter zu meiner nächsten Frage, wie macht man sinnvollerweise Folgendes:
Um bei dem Beispiel mit den Helligkeitswerten zu bleiben: Oft ist es notwendig, den letzten Messwert oder den letzten Wert der Berechnung in die neue Berechnung mit einzubeziehen. In konventioneller Programmiertechnik weise ich das einfach einer Variablen "LastValue" zu, die ich dann mit verwende. Beim Homeserver geht das so nicht. denn wenn ich z.B. in ein KO "LastValue" etwas reinschreiben würde, dann würde das sofort wieder ein Neuberechnung auslösen.

Es fehlt mir hier die Möglichkeit eine "atomaren" Abarbeitung einer Logik, wie ich das von anderen Echtzeitsystemen kenne. D.h. eine Logik sollte auch aufgrund eines bestimmten Ereignisses ablaufen können und nicht nur bei jedem Eintreffen eines Telegramms!

Mit eigenen Bausteinen und remanenten Speichervariablen lässt sich das sicher machen. Vielleicht habe ich die Konzepte des Homeservers noch nicht genügend gut verstanden, aber wenn es für solche simplen Aufgabenstellungen standardmässig keine Methoden gibt, dann ist das schon etwas schwach!

meint
GKap

[Tokamak]

Nunja, die geeignete Methode ist eigene Bausteine.

Mir fehlen auch einige Konzepte in der Ereignissteuerung, die man aus prozeduralen Programmiersprachen kennt. Ein echtes "If" fehlt mir am meisten, d.h. ein Möglichkeit, ganze Logiken nur dann auszuführen, wenn bestimmte Bedingungen zutreffen. Ansonsten sollen sie nicht ausgeführt werden.
Das geht in dem HS-Konzept letztlich nur mit eigenen Bausteinen.

[GKap]

Hallo Tokamak!

Um der Unsauberkeit, die ich genauso empfinde, zu umgehen: Eigene Bausteine. Einer meiner Bausteine heißt "Ungleich", der nur dann einen Wert auf dem Ausgang schickt, wenn er ungleich einem zweten Wert ist. In deinem Fall wäre der zweite Eingang 0.

Ja, an einen eigenen Baustein habe ich auch gedacht. Aber nachdem bei mir eine solche Konstellation öfters vorkommt, habe ich angenommen, dass es dazu eine geeignete Methode geben müsste! Ich werde doch nicht der einzige sein, der über eine Bedingung manchmal Aktionen sperren möchte!

meint
GKap

[Tokamak]

lso habe ich es mit "Logik2.gif" probiert. Das funktioniert zwar wie erwartet, aber es kommt mir ziemlich unsauber vor! Vor allem: wie klein könnte ich die Verzögerung machen, damit die Zuverlässigkeit bleibt?

Es ist auch so nicht zuverlässig. Selbst die Verzögerung von 1 Sekunde könnte - theoretisch, praktisch wohl nicht - nicht reichen.

wie löst ihr so etwas?

Um der Unsauberkeit, die ich genauso empfinde, zu umgehen: Eigene Bausteine. Einer meiner Bausteine heißt "Ungleich", der nur dann einen Wert auf dem Ausgang schickt, wenn er ungleich einem zweten Wert ist. In deinem Fall wäre der zweite Eingang 0.

Viel Erfolg
Marcus

[MatthiasS]

Ich mache einen Vergleich ungleich Null und setzte bei Ja das Anzeige/Archivobjekt auf den Eingangswert (Setze auf Wert von KO...)

Man müsste mal probieren, ob diese Methode beim KO-Dialog auch den Eingangswert begrenzt:

Min-Wert, Max-Wert
Diese beiden Grössen setzen die Minimal-/Maximalwerte die durch den HS/FS auf den EIB ausgegeben werden (bezüglich des aktuell ausgewählten Objekts).
Dieser Bereich ist unabhängig vom Wert des Aktor/Sensors auf dem EIB.
Hiermit können unter anderem Fehler in der Programmierung global unterdrückt werden, die kleinere/grössere Werte als beabsichtigt auf das Objekt schreiben.

[GKap]

Hallo alle!

Eine Frage zur Logik und zur "Sauberkeit" der Programmierung:

Eigentlich eine ganz einfache Aufgabenstellung: Helligkeitswerte aus einer Wetterstation sollen geglättet werden, das geht gut mit dem Baustein "Gleitender Durchschnitt". Leider kommt von der Wetterstation hin und wieder tagsüber der Wert 0, was zu einem Fehlverhalten der Jalousien führen würde. (Das ist ein Fehler der Wetterstation, wurde vom Hersteller bestätigt und ist in Arbeit...) Diesen Fehler möchte ich im HS korrigieren.

Ich möchte daher 0-Werte einfach verwerfen. Das habe ich zuerst so probiert, wie in ""Logik1.gif" zu sehen ist. Manchmal funktioniert das, manchmal nicht. Das ist auch logisch für mich, da bei der Sperre das Telegram möglicherweise schon durchgeleitet wurde, noch bevor der Vergleich die Sperre sperren würde!

Also habe ich es mit "Logik2.gif" probiert. Das funktioniert zwar wie erwartet, aber es kommt mir ziemlich unsauber vor! Vor allem: wie klein könnte ich die Verzögerung machen, damit die Zuverlässigkeit bleibt?

wie löst ihr so etwas?
fragt mit Grüssen
GKap

PS, noch eine Zusatzfrage: Der Baustein "Telegrammverzögerung" liefert lt. Hilfe nur einen 1-Bit Wert am Ausgang. Nach meinen Beobachtungen werden aber alle Telegramme, unabhängig vom Datentyp richtig durchgereicht! Ist das ein Fehler in der Doku?