Wert nur auswerten, aber nicht mit Wert triggern

[Tokamak]

Hallo zusammen,

die Ereignissteuerung im HS bringt mich um. Für einen alten Entwickler aus Turbo Pascal-Tagen ist es schon ein hartes Stück Brot, kein echtes if...then...else zu haben.

Mein Szenario: Ich berechne den Zielstatus eines Schaltaktors in Abhängigkeit diverser Eingabeparameter. Am Ende vergleiche ich den Zielstatus mit dem aktuellen Aktorstatus. Bei Nicht-Übereinstimmung wird der Aktorkanal neu gesetzt. Nach Statusmeldung des Aktors stimmen Ziel- und Kanalstatus wieder überein. Fertsch. Ist einfach und klappt einwandfrei, weil der Zielstatus die Führung übernimmt, d.h. dieser immer zuerst geändert wird.

Nun ist allerdings neu hinzugekommen, dass sich der Kanalstatus auch aufgrund eines anderen Ereignisses ändern kann. Die bisherige Schaltung sorgte dann natürlich dafür, dass wieder der Zielstatus eingerichtet wurde, d.h. wurde der Kanal ausgeschaltet, sorgte die Programmierung über den Zielstatus dafür, dass er wieder eingeschaltet wird - was aber nicht passieren darf.
Vielmehr muss ein Eingangsparameter zur Berechnung des Zielstatus geändert werden, der dann dafür sorgt, dass der Zielstatus dem Aktorstatus entspricht. Auf diesen Weg kann ich schwer verzichten, da während der Berechnung einige andere Aktionen gestartet werden.
Das alles wäre im Prinzip einfach, wenn diese verquere Eregnissteuerung nicht wäre. Denn nun hat der Aktorstatus auf einmal die Führung.

In meiner bisherigen HS-Programmiererei hatte ich schon einiege Male ähnliche Probleme, konnte es aber bisher immer lösen, häufig durch den Einsatz der Sperre. Nun stehe ich auf dem Schlauch.

Mein Problem ist allgemeiner so umschrieben: Ich möchte gerne (Status-)Werte am Eingang von Logikbausteinen verwenden, ohne dass die Bausteine durch den Statuswert selbst getriggert werden. D.h. der Baustein soll nicht feuern, wenn eben diese (Status-)Werte neu gesetzt werden, seien sie geändert worden oder nicht. Sie sollen einfach nur genutzt werden.

Gibt es für solch ein Vorhaben einen Stereotyp, also eine Vorlage, wie sich das generell und immer gleichartig lösen lässt, ohne jedesmal neu darüber nachzudenken, wie man das in der konkreten Schaltung in den Griff bekommt?

Wie oft habe ich mir schon gewünscht, es gäbe einen echten If-Block, in dem alle Ereignisse innerhalb des Blocks nur dann einen Logikbaustein triggern, wenn eine bestimmte Bedingung erfüllt ist...

[NetFritz]

Hallo
Dan wäre das Wago 750-849 KNX-IP-Starterkit für Dich das richtige gewesen.
Da kanst du in CODESYS ST programmieren.
ST ist ähnlich wie Pascal.
Gruß NetFritz

[Tokamak]

*lach* Nein, das sollte nicht meine Botschaft sein. Allerdings muss ich gestehen, dass mir eine prozedurale oder objektorientierte Programmierung deutlich lieber wäre. Die Ereignissteuerung ist meilenweit von meinem Grundverständnis entfernt, und ich tue mich schwer damit. Das liegt sicher auch daran, dass mir vertraute Konzepte einfach nicht funktionieren, weil die HS-Ereignissteuerung weniger mächtig ist als andere imperative Programmierparadigmen. Aber das soll hier keine Grundsatzdiskussion werden, zumal das an dem oben beschriebenen Problem nichts ändert.

Daher hoffe ich, dass ein ähnliches Problem durch andere HSler geeignet gelöst wurde.

[swenga]

Als C++-Jongleur gings mir zu anfang ganz aehnlich, ich habe die wildesten Konstruktionen an (Standard-)Bausteinen verbaut und mir durch die Eventsteuerung die Haare gerauft.

Mittlerweile nutze ich fuer komplexere Dinge groesstenteils eigene Bausteine. Die Berechnung darin wird natuerlich auch bei Telegrammeingang/Wiederholung bzw. Änderung eines Eingangs getriggert, aber du hast es in der Hand wann du die Ausgänge beschreibst. Es gibt daher auch wieder "if then", wenn auch das else eher ein "if not then" ist...

mfg

[NilsS]

Wenns dir hilft versuch mal das hier https://knx-user-forum.de/knx-eib-fo...zpruefung.html

Da könntest du
 
class myclass:
  def __init__(self):
      self.a=0
      self.b=25
  def rechne(self,eingang):
      self.a+=float(eingang)
      return self.a
 
SN[1]=myclass()

dann kannst du in den späteren 5012er Zeilen
5012|0|"EC[1]"|"SN[1].rechne(EN[1])"|""|1|0|0|0
machen

oder halt auch komplexer bis sehr sehr viel komplexer

[Tokamak]

Mittlerweile nutze ich fuer komplexere Dinge groesstenteils eigene Bausteine. Die Berechnung darin wird natuerlich auch bei Telegrammeingang/Wiederholung bzw. Änderung eines Eingangs getriggert, aber du hast es in der Hand wann du die Ausgänge beschreibst. Es gibt daher auch wieder "if then", wenn auch das else eher ein "if not then" ist...

Ich hatte befürchtet, dass es darauf hinausläuft

dann kannst du in den späteren 5012er Zeilen
5012|0|"EC[1]"|"SN[1].rechne(EN[1])"|""|1|0|0|0
machen

oder halt auch komplexer bis sehr sehr viel komplexer

Deinen Thread habe ich soeben abonniert. Wie beim Vorschlag von swenga muss ich mich dann also doch mit der Logikbausteinprogrammierung und Python auseinander setzen. Schade, dass ich das wohl nicht vermeiden kann...

Dabei ließen sich meines Erachtens viele Schaltungen mit den Standardbausteinen realisieren oder bestehende Schaltungen vereinfachen, wenn denn Dacom eine kleine Erweiterung einbauen würde:
Wenn man pro Eingang eines Logikbausteins innerhalb einer Schaltung nicht nur den Fixwert eingeben könnte, sondern auch angeben könnte, ob der Wert/das Telegramm genau diesen Baustein triggert, hätte man schon die halbe Miete. Dann könnte man Werte abfragen, ohne dass diese den Baustein auslösen. Wenn standarsmäßig die Konfiguration "Eingang triggert Baustein" ist, ist das sogar kompatibel zum bisherigen Verfahren.

Vermutlich wäre diese Änderung im Experten und HS noch nicht einmal schwierig.

[Taxus]

Der 'Telegrammgenerator mit Triggereingang' (sehr unglücklicher Name) löst viele solcher sync-Probleme. Hier kannst Du auf dem Eingang E3 Werte auflaufen lassen, ohne dass der Baustein 'feuert', und dann gezielt durch triggern auf E1 oder E2 erst den Wert von E3 weiterleiten.

[Tokamak]

Ich stimme dir zu, der Name ist wenig eingängig.

Aktuell dachte ich daran, mir 2 einfache Bausteine zu schreiben. Einer sollte dabei was ähnliches machen wie der genannte "Telegrammgenerator mit Triggereingang". Allerdings hätte ich auf die unterschiedlichen Trigger (<>0, =0) verzichtet, weil sich das leicht mit einem vorgeschalteten Filter lösen ließe.

Dachtest du an eine Anwendung wie die anhängende Schaltung? Mir ist zur Zeit nicht klar, ob in dem Beispiel das XOR-Gatter einmal oder zweimal durchlaufen wird, da der Telegrammgenerator mit Triggereingang auch eine gewisse Durchlaufzeit hat, so dass das Telegramm 1 und 2 zu unterschiedlichen Zeit eintreffen.

[Taxus]

... Allerdings hätte ich auf die unterschiedlichen Trigger (<>0, =0) verzichtet, weil sich das leicht mit einem vorgeschalteten Filter lösen ließe.
...

Gehr hier doch auch, nur andersrum, hier kannst Du ja mit einem vorgeschalteten Auslöser aus 0 oder 1 eine 1 machen. Egal.

ob in dem Beispiel das XOR-Gatter einmal oder zweimal durchlaufen wird,

Dreimal!
Ein Beispiel habe ich angefügt: ich lege darin den kommenden Schaltwert fest, der gesendet wird, falls über einen Taster irgendwann ein Signal kommt.

[Tokamak]

Wieso dreimal? Das würde nur dann passieren, wenn der Telegrammgenerator den Wert zwei Mal senden würde. Der Wert der ersten Variable ist entweder 0 oder 1, weswegen der Telegrammgenerator nur einmal den Wert senden sollte. Damit dürfte das XOR höchstens zwei Mal durchlaufen werden.
Da das Gatter aber mehr als ein Mal durchlaufen wird, hilft mir der Telegrammgenerator zumindest in der Form, wie ich es geschaltet habe, nichts.

Bei deinem Beispiel verstehe ich nicht, warum du den Eingangsauswahlschalter verwendest. Eine Negation des Gruppentelegramms sollte das selbe machen. Wofür benötigst du den Baustein?

Allerdings erschließt sich mir noch nicht, wie mir deine Schaltung bei meinem Problem helfen kann. Kannst du mir da auf die Sprünge helfen?

[Taxus]

Ja, das war verwirrend, sorry:
1. Recht hast Du, zweimal natürlich nur!
2. Den Auswahlschalter habe ich hier 'historisch' nur, weil es dieselbe Schaltung x-mal im Arbeitsblatt gibt, auch für %-Dimmschritte. Geht hier natürlich wie von Dir beschrieben mit Negation.