Logikfunktionen in GPA

[Flowww]

Ist es denn korrekt, dass der Wert bei Umschalt-GAs gelesen werden kann?

Lese ich andere Umschalt-GA bekomm ich immer "0", unabhängig vom echten Wert, welchen ich nur über den Status (z.B. Aktors) lesen kann.

Als Beispiel habe ich eine Test-GA angelegt 0/1/123 auf welcher ich lese, dann eine "1" schreibe (siehe grün), dann lese (siehe blau).
GM Test-GA.png
Das GroupValue_Response (L-Flag) funktioniert, aber der Wert ist "0" statt "1". Bei diesem Test ist der GPA außen vor, kein anderes KO, etc. hat die Test-GA verbunden.

[knxPaul]

das mit dem Schreiben der "1" ist nicht KNX-konform - das kann ein SW Entwickler in seinem Debugger machen.

Beim Drücken der Patsch-Taste muss der Glastaster die "1" schreiben, und danach kann die "1" gelesen werden.

[Flowww]

Ahhh, spannend. Gibt es einen technischen Unterschied? Die GPA selbst (also z.B. ZSU) kann aber wie ein echter Sensor angesehen werden?

Normalerweiße "debugge" ich das System immer über die ETS und dem Schreiben von GAs. Für normale Aktoren funktioniert das auch wunderbar, allerdings wird dort ja auch ein echter Status verwendet der gelesen werden kann, so dass ein L-Flag nicht nötig ist.

Ich teste die Patsch-Taste in Kombination mit dem Lesen heute abend nochmal. Im Anschluss teste ich, ob dann bei Anwesenheit (= "1") die Rollo Befehl gefiltert wird und nicht durch kommt.

[Flowww]

Wie von knxPaul beschrieben, funktioniert das korrekte Lesen der Werte tatsächlich nur wenn die Patsch-Taste wirklich "physisch" betätigt wird...

Zu meiner Frage nochmals, woran liegt der Unterschied und wie schaut es mit der GPA (Handhabung wie Patsch-Taste bei Wertgenerierung) aus?

Tatsächlich ist das Debuggen mit der ETS dann auch bei komplexeren Funktionen mit Vorsicht zu genießen. Oder gibt es eine Möglichkeit das "echte" Umschalten zu emulieren?

Zurück zu meiner Ziel-Funktion (automatische Rollo-Fahrt bei Abwesenheit):
Mit dem UND-Gatter ist das leider nicht so einfach realisierbar. Wenn die ZSU (GA 0/3/0 oben) auf 1 = ab steht und am UND anliegt, so ist der UND-Ausgang nur noch von Abwesenheit abhängig und bei Patsch-Betätigung wird der Rollo auf/ab gefahren. Ich benötige etwas, dass die ZSU GA nur bei Abwesenheit an die Rollo-Fahrt-GA anlegt. Da ich aus der FPGA-Programmierung komme, ist mir die Multiplexer-Funktionalität eingefallen. Vermutlich lässt sich das aber nicht auf die GPA übertragen. Hier mal mein Entwurf mit der Bitte um Feedback, v.a. zu folgenden Fragen:
* Können die beiden Wertgeneratoren-Ausgänge verbunden werden (Umschaltung Eingang)?
* Ist die Rückkopplung der GA 7/0/1 (nur von GPA beschrieben) zulässig?
* Gibt es besser Alternativen?
* Um warum bitte ist die Nomenklatur von Gira so gewählt 0 = IN1, 1 = IN2, ... statt 1 = IN1 und 2 = IN2...

Danke


GPA Logikblatt 3.png

[araeubig]

Dan setze das L Flag am Ausgang

Aber eine "virtuelle GA" ist beim Neustart des Systems nicht belegt. Da hilft auch das L-Flag nicht, deshalb war mein Vorschlag es mit einem halb-virtuellem Datenpunkt des X1 zu verbinden.

[knxPaul]

woran liegt der Unterschied

Das KO ist aus Sicht des Glastasters ein Ausgang - mit der ETS kann man da normalwerweise nichts von außen hineinpressen.

Ich benötige etwas, dass die ZSU GA nur bei Abwesenheit an die Rollo-Fahrt-GA anlegt

Dann schaue den LBS Sperre (Online Hilfe des GPA) an

Können die beiden Wertgeneratoren-Ausgänge verbunden werden

Ja, im GPA wie im KNX erlaubt.

Ist die Rückkopplung der GA 7/0/1 (nur von GPA beschrieben) zulässig?

Ja, läßt sich aber nicht direkt simulieren

Bitte um Feedback

warum nicht ohne die Wertgeneratoren vom Inverter über einen Typkonverter auf den Eingangswahlschalter?

[araeubig]

Tatsächlich ist das Debuggen mit der ETS dann auch bei komplexeren Funktionen mit Vorsicht zu genießen. Oder gibt es eine Möglichkeit das "echte" Umschalten zu emulieren?

Ich verstehe das Problem ehrlich gesagt nicht - ich habe einige sehr komplexe Logikblätter und das Simulieren funktioniert sehr gut.

[Flowww]

Ich verstehe das Problem ehrlich gesagt nicht - ich habe einige sehr komplexe Logikblätter und das Simulieren funktioniert sehr gut.

Ja da hast du natürlich recht. Die GPA Simulation funktioniert sehr gut. Mit der Ausnahme z.B. der externen Rückkopplung, was ehr ein Ausnahmefall ist. Auch die Dokumentation ist gut.
Ich meine allerdings das "Debuggen" mit der ETS, sprich wenn ich z.B. einen Schaltvorgang emulieren möchte und auf die GA schreibe. Logischerweise, wie von knxPaul erklärt, wird dann nicht der KO-Ausgang verändert sondern nur ein Telegram erzeugt. In der Welt von KNX/ETS ist nur ein Umdenken und Verständnis nötig, welches bei mir noch aufgebaut werden muss

Dann schaue den LBS Sperre (Online Hilfe des GPA) an

warum nicht ohne die Wertgeneratoren vom Inverter über einen Typkonverter auf den Eingangswahlschalter?

Danke für die Empfehlungen. V.a. der Typkonverter ist genau der richtige LBS.

Letztendlich hab ich zwar noch nicht das Problem gelöst (die Zielfunktion tut immer noch nicht), aber mit dem Wissen aus dem Thread sollte ich weiter kommen. Ich habe noch ein weiteres Logikblatt mit einem "UND-Gatter". Dort ist ein Eingang auf ein KO-Ausgang (Taster, L-Flag gesetzt) gelegt und der andere auf eine ZSU vom X1. Das Umschalten mit der ZSU klappt, allerdings nicht das Umschalten mit derm KO-Ausgang des Tasters. Ändert sich dort der Wert fragt GPA auch den ZSU Eingang ab, welcher vermutlich "0" liefert (muss), obwohl letzter erzeugter Wert eine "1" war.
Hier verhält es sich exakt so, wie ein KO-Ausgang ohne L-Flag (kein GroupValue_Respone). Ist es denn möglich ein L-Flag für den Ausgangsdatenpunkt der GPA zu erstellen? Was macht die Funktion "Wert beibehalten" bei Initialwerteinstellungen?

[knxPaul]

Das sind sehr grundlegende Fragen. Normalerweise sollte ich eine Schulung für den X1 empfehlen ... es gibt schon einzelne Videos neben der Online-Hilfe

Im GPA gibt es einen Datenpunktmonitor, der den aktuellen Zustand aller Datenpunkte anzeigt. Bei Variablen-Datenpunkten ist das die einzige Möglichkeit

Ist es denn möglich ein L-Flag für den Ausgangsdatenpunkt der GPA zu erstellen?

Nein, oft gefragt und hier gar nicht benötigt. Jeder Datenpunkt sollte einen Initialwert haben für den Zeitpunkt des Neustarts vom X1.
Die ZSU muss zu einem Zeitpunkt seinen Ausgangsdatenpunkt auf 1 setzten und zu einem anderen Zeitpunkt auf 0. Wichtig

• Der Eingangsbaustein liest von den hörenden GAs und von der Status-GA in seinem Datenpunkt.
• Der Ausgangsbaustein schreibt auf die Senden-GA in seinem Datenpunkt.

Beide GAs können gleich sein oder unterschiedlich.

Was macht die Funktion "Wert beibehalten" bei Initialwerteinstellungen?

Mit Einschränkung soll das den Wert vor dem Neustart nach dem Hochlauf des X1 verfügbar machen. Bitte da nachlesen.

[Flowww]

Danke, das sind die richtigen Hinweise!

Natürlich hatte ich den DPM angeschaut und auch Initialwerte versehen, allerdings alle mit vom "Vom KNX Bus lesen". Dies passt bei KO-Ausgängen mit L-Flag und der Wert ist richtig gesetzt. Im DPM direkt nach den Programmieren/Neustart sieht man, dass die ZSU keinen Initialwert schreibt und das Feld des aktuellen Werts ist leer. Das führt nach der Programmierung zu Effekten, die erst, nachdem die ZSU die Werte geschrieben hat, deterministisch werden.

Harte Initialwert sind auch nicht möglich, weil sie eben von der Schaltzeit bzw. ZSU abhängen. Eine Initialisiserung der GAs mit der ETS funktionert, will man aber nicht jedes mal händisch machen.

Mit Einschränkung soll das den Wert vor dem Neustart nach dem Hochlauf des X1 verfügbar machen. Bitte da nachlesen.

Lt. Hilfe: Wird diese Option aktiviert, wird der Wert des Datenpunktes zwischengespeichert und bleibt auch nach dem Neustart des Gerätes erhalten.
Ich hatte das so verstanden, dass dauerhaft zwischengespeichert wird. In meinem Falls würde es aber natürlich helfen, mit der Ausnahme, dass die Programmierung/Neustart in den Schaltzeitpunkt der ZSU fällt (Wertwechsel während Programmierung/Neustart).

Sollte es noch eine alternative Lösung für das ZSU Startverhalten geben, lasst es mich gerne wissen. Das Thema ist das soweit erledigt.

Danke an alle und besonders an knxPaul 👍

[araeubig]

Letztendlich hab ich zwar noch nicht das Problem gelöst

Sorry, dass ich auch noch meinen Senf dazugebe: Zeige uns für eine gewünschte Hilfe das jeweils passende Logikblatt und gerne dazu auch noch einen Screenshot der ETS mit den entsprechenden GA's und vielleicht auch noch die KO's. Dann wäre im Zweifel auch noch ein Screenshot des im X1 angelegten Datenpunkts von Vorteil (denn dieser hat je nach Funktion zwei GA's eingetragen -> bzw. sollte dann zwei eingetragen haben).

[araeubig]

ZSU

Was ist denn eine ZSU?

Aber egal: Dein Logikblatt kann für mich so nicht funktionieren....

Du benötigst einen Datenpunkt für den Auslöser zur Verwendung in der Zeitschaltuhr und als Eingang auf dem Logikblatt. Nach "Abarbeitung" der Logik geht es auf die normale Gruppenadresse und gut ist.

In der Anlage mal ein Beispiel (nur schaltend und auch mit einer Logik-Sperre - aber das soll erstmal nicht das Thema sein). Vielleicht hilft Dir das:

Screenshot (822).png Screenshot (823).png Screenshot (824).png Screenshot (825).png Screenshot (826).png

[knxPaul]

Was ist denn eine ZSU?

Zeit Schalt Uhr ist eine übliche Abkürzung, siehe #1.

[araeubig]

übliche Abkürzung

es war auch eher scherzhaft gemeint. DPM, ZSU, MFG - da kommt mir doch gerade Fanta4 in den Sinn.....

[Flowww]

Zeige uns für eine gewünschte Hilfe das jeweils passende Logikblatt und gerne dazu auch noch einen Screenshot der ETS mit den entsprechenden GA's und vielleicht auch noch die KO's. Dann wäre im Zweifel auch noch ein Screenshot des im X1 angelegten Datenpunkts von Vorteil

Da hast du natürlich recht, sollte das "Bildchen" sparen nicht so ernst nehmen 😉

Meine Zielfunktion "Abwesenheitsgesteuerte Rollo-Fahrt" ist aktuell mit Sperre realisiert (lässt Rollo Fahrt ZSU nur durch, wenn Abwesend).

Anbei noch Screenshots. Testen werde ich erst heute Abend zuhause.

Folgende Anmerkungen:

• Wert beibehalten scheint zu funktionieren, wie gesagt mit der Einschränkung bei Programmierung/Neustart während des Umschaltzeitpunktes.
• Die DP mit leeren Status-Adressen sind GAs die nur aus der GPA geschrieben werden. Belegt man die Status-GA mit der Sende-GA wird der Wert im DPM richtig angezeigt. Ändert aber nichts an der Funktionalität.
• Natürlich könnte ich auch einen Schaltzeitraum statt zwei Schaltzeiten vorgeben. Ob der Wert nach dem Neustart dann allerdings passt oder ob er bis zum ersten Zeitpunkt wartet muss ich noch testen.
• Die Bezeichnung in den GAs mit persönlichen, irrelevanten Infors habe ich geschwärzt.

GPA Logikblatt 4.png

ZSU.png

Datenpunkte nach Programmierung 2.png

GAs.png