Verknüpfte Logik funktioniert sporadisch nicht

[bavarianhias]

Vielleicht kann mir jemand helfen. Mir ist nun schon des Öfteren aufgefallen, dass meine verschachtelten Logiken irgendwie Blödsinn machen. Zur Erklärung:
Ich habe ich eine MDT SCN-GLED LED Anzeige im EG die an der Haustür die für jedes Geschoss durch eine aktive LED signalisiert, ob noch Licht brennt. Bei 3 Stockwerken also 3 LEDs. Dort sind ODER - Logiken aktiv, die pro Stockwerk den Status der Schaltaktoren abfragen. Zusätzlich habe ich im OG Schlafzimmer eine LED auf einem MDT GTII aktiv, die anzeigt, ob im EG oder UG noch Licht brennt. Soweit so gut. LED Anzeige im EG funktioniert tadellos. Diese hat ausreichend Logikeingänge. Jetzt zum eigentlichen Problem. Für die Anzeige im GTII im OG habe ich nun eine weiter Logik aktiv, die abfrägt ob die LED der LED Anzeige des EGs oder UGs aktiv ist.
Also:
Logik1 der LED Anzeige: GA1 Status 1 oder GA2 Status 2 oder GAx Status x = GA LED Anzeige1
Logik2 der LED Anzeige: GA3 Status 3 oder GA4 Status 4 oder GAy Status y = GA LED Anzeige2
Logik des GTII: GA5 Status - GA LEDAnzeige1 oder GA LEDAnzeige2 = LED am GTII

Jetzt hat letztes Mal die LED am GTII gebrannt, obwohl kein Licht im EG oder KG an war. Passiert scheinbar nur sporadisch.
Dieses Verhalten ist mir bei verschachtelten/verknüpften Logiken, die hintereinander geschaltet werden, schon öfter aufgefallen. z.B. wenn ich drei Lichterstatus mit 2 Logiken abfragen muss, weil eine Logik nur 2 ext. Eingänge hat, ich aber für 3 Lichter gleichzeitig den Status abfragen möchte und damit die 2 Logiken nochmal verknüpfen muss.
Was mache ich falsch?
Liegt es an der Logikverarbeitung (Eingangssignal - Ausgangssignalverhalten)?

Danke - ich finde einfach die Ursache nicht.

[Beleuchtfix]

Da kannst du an vielen Ecken etwas falsch machen. Die Logik funktioniert jeweils nur, wenn alle Statuseingänge gültig sind, hast du also mal etwas zwischendurch programmiert, kann ein Status fehlen und du bekommst dann eine falsche Anzeige. Es kann auch schon mal passieren, dass ein Signal nicht richtig gelesen werden kann, (kommt aber selten vor).
Du solltest jetzt mal jedes Signal auf dem Bus verfolgen und genau beobachten, ob jeweils das richtige passiert.
Viel Erfolg, Florian

[mumpf]

Hi,

Jetzt hat letztes Mal die LED am GTII gebrannt, obwohl kein Licht im EG oder KG an war. Passiert scheinbar nur sporadisch.

hast Du in dem Fall mal mit dem Gruppenmonitor und passenden Read-Requests nachgeschaut, ob alle Ein- und Ausgangswerte and den Teillogiken stimmen? Dann würdest Du wenigstens einkreisen können, an welchem Teil der Logik der Fehler liegt.

An sich sind solche Konstrukte wie OR(OR(a, b), OR(c, d)) in KNX stabil, genau so mit AND. Ich würde Florian zustimmen, wahrscheinlich sind nicht alle Eingänge initialisiert, weswegen manche Ergebnisse nicht stimmen.

Noch was zur Formulierung: Du schreibst immer wieder

Für die Anzeige im GTII im OG habe ich nun eine weiter Logik aktiv, die abfrägt ob die LED der LED Anzeige des EGs oder UGs aktiv ist.

z.B. wenn ich drei Lichterstatus mit 2 Logiken abfragen muss

Dort sind ODER - Logiken aktiv, die pro Stockwerk den Status der Schaltaktoren abfragen.

Deswegen glaube ich, dass Du auch denkst, dass da was abgefragt wird. Das ist aber eine falsche Vorstellung. Und mit einer falschen Vorstellung lässt es sich schlecht analysieren...

Eine Logik fragt nicht ab. Sie wartet so vor sich hin, bis ein Telegramm vorbei kommt, dass zu der GA am Logikeingang passt. Der Wert wird dann genommen und die Logik ausgeführt. Diese sendet dann das Ergebnis auf den Bus. Und dann geht das Telegramm in den nächsten Eingang einer Logik, falls es hier wirklich eine Kaskade von Logiken gibt. Das kannst Du dann passend im Gruppenmonitor testen, indem Du passende Telegramme mit der ETS verschickst. Und das klappt, weil eben nichts ABGEFRAGT wird.

Einige Hersteller ermöglichen eine Einstellung, die beim Neustart des Gerätes (und nur dann) die passenden Eingänge der Logik abfragt. Diese Einstellung sollte man immer machen.

Ich teste meine Logiken immer komplett mit dem Gruppenmonitor durch, bevor ich diese produktiv nutze.

Gruß, Waldemar

[bavarianhias]

Du in dem Fall mal mit dem Gruppenmonitor und passenden Read-Requests nachgeschaut

dazu müsste der Monitor wohl mehrere Tage laufen, bis ich es erwische. Habe ich also noch nicht gemacht und wollte daher vorher hier fragen, ob jemand das Problem kennt.

wahrscheinlich sind nicht alle Eingänge initialisiert

Die Eingänge müssen stimmen, da die LED Anzeige im EG (LED1 und LED2 aus) das richtige anzeigt.

wenn alle Statuseingänge gültig

...sind sie damit. Blos eben der nächste Logikschritt am GTII - wenn LED1 oder LED2 an, dann zeige "EG oder KG Licht an" macht Probleme. Die LED am GTII war an.

dass Du auch denkst, dass da was abgefragt wird

Sorry schlecht formuliert....

Sie wartet so vor sich hin

....ist schon so auch gemeint.
Aber du bringst mich auf eine Idee. Kann es vielleicht sein, dass es von der Einstellung in der Logik selbst abhängt? Es gibt in den MDT GTII Logikeinstellungen "Sendebedingung bei Eingangstelegram" oder "Sendebedingung bei Änderung Ausgang". Bei mir steht es auf "Eingangstelegram", weil ich es so verstehe, dass wenn sich Eingang Logik (Ausgang LEDAnzeige LED1 oder LED2) ändert, dann sende auf den Bus (also schalte LED am GTII ein). GTII LED soll sich nun bei der Änderung seines Eingangs (also das was auf dem Bus liegt) entsprechend verhalten. Ich habe mal die KO vom GTII hier angehängt.
Logik am GTII.png

[mumpf]

Hi,

dazu müsste der Monitor wohl mehrere Tage laufen, bis ich es erwische.

neee, Du kannst von Gruppenmonitor aus GA schreiben und auch lesen. Du kannst Deine Logiken ganz bequem vom Schreibtisch aus testen, ohne irgendwelche Schalter o.ä. bedienen zu müssen. Einfach die passenden GA senden und sehen, was die Logiken antworten. Ich habe Logiken, die nur 2-3 mal im Jahr laufen, da warte ich nicht erst, bis die passende Zeit kommt, um das zu debuggen.

Um bei Deinem Beispiel zu bleiben: Schicke einfach eine 1 auf die 0/2/36, dann sollte die 0/2/37 ein EIN senden. Dann auch eine 1 auf die 0/2/11, die Logik sollte wieder ein EIN senden. Anschließend eine 0 auf die 0/2/36, die Logik sollte immer noch EIN senden, dann eine 0 auf die 0/2/11, dann sollte die Logik AUS senden.

Wenn das so passiert, dann funktioniert Deine Logik erstmal. Das Nächste ist, jeweils die 0/2/26, 0/2/11 und 0/2/37 zu lesen. Es darf nur von genau einem Gerät eine Antwort kommen. Wenn nicht, ist das eine Potentielle Fehlerquelle.

Du hast bei Deinem Bild leider die A-Flags abgeschnitten. Falls die gesetzt sind, muss man verifizieren, wann / von welchem Gerät die 0/2/26 und die 0/2/11 gelesen werden. Falls Du das nicht unbedingt brauchst, würde ich sonst die A-Flags an KO 65 und KO 66 entfernen, um hier eine mögliche Fehlerquelle auszuschließen. Achtung: Soll kein genereller Hinweis sein, A-Flags auszuschalten! Nur eine Möglichkeit, bei diesem speziellen Problem den Fehler einzugrenzen.
Falls das Problem mit dem Entfernen der A-Flags verschwinden sollte, bitte nochmal melden, damit man die eigentliche Ursache ergründen kann.

Das wäre es jetzt für den Augenblick...
Gruß, Waldemar

[bavarianhias]

Danke.

Du kannst von Gruppenmonitor aus GA schreiben

ist bekannt. Ich versuchs mal doch auf diesen weg. Auch wenn ich wahrscheinlich zig Schleifen drehen muss, bis der Fehler kommt (wie gesagt, taucht nur sporadisch auf und die Ursache ist unklar, somit sollte es sich wohl mit dem Schreiben der GAs auch so verhalten). Aber einen Versuch ist es in jedem Fall wert.

dann funktioniert Deine Logik erstmal

- Logik sollte wohl funktionieren weil der Fehler von geschätzten 100 mal nur 1 mal kommt. Aber ich werd so vorgehen.
Deiner Erklärung entnehme ich, dass du meine o.g. Vermutung

"Sendebedingung bei Eingangstelegram" oder "Sendebedingung bei Änderung Ausgang".

auschließt - oder?
Ich meld mich wieder falls ich was (oder nichts) rausfinde.

[knxPaul]

Deiner Erklärung entnehme ich, dass du meine o.g. Vermutung ... auschließt - oder?

Falsch - als (Mit-) Leser kann ich überhaupt nicht ergründen, wie das Fehlverhalten entsteht. Du selbst bist derjenige, der die Vermutung durch die wunderbar in #5 beschriebene Methode erhärtest oder widerlegst, das kannst nur Du 😀

[bavarianhias]

Falsch

Sorry, aber #6 war eine Antwort auf #5. Warum fühlst du dich angesprochen.

[mumpf]

Hi, zu

"Sendebedingung bei Eingangstelegram" oder "Sendebedingung bei Änderung Ausgang".

Das siehst Du richtig, ich denke nicht, dass es daran liegt. Es geht erstmal um ein einfaches OR, und da wird sich diese Einstellung ziemlich sicher nicht auswirken.
Bei einem OR bedeutet

• Sendebedingung bei Eingangstelegramm, dass selbst wenn das OR schon 1 als Ergebnis hat, eine erneute 1 am Eingang trotzdem zum Senden einer 1 am Ausgang führt. Und ob eine leuchtende LED nochmal eingeschaltet wird, ist egal, denn es wirkt sich nicht aus.
• Sendebedingung bei Änderung Ausgang, dass sich wiederholende 1 oder 0 am Ausgang unterdrückt werden und nicht mehrfach gesendet werden. Das ist zwar das, was Du eigentlich machen solltest (weil eine bereits eingeschaltete LED nicht nochmal eingeschaltet werden kann). Doch die Einstellung würde hier nur Telegramme auf dem Bus sparen und nicht das Verhalten ändern.

Ich habe immer noch Lese-Requests im Verdacht. Poste doch mal, was nach einem GroupValueRead auf 0/2/26 bzw. 0/2/11 zurückkommt.

Gruß, Waldemar

[bavarianhias]

Hier meine GAs zur Logik so wie die Gruppenmonitoraufzeichnung. Beleuchtung war aus.
Gruppenmonitor 0_2_37_aus.jpg GAs Logik.jpg Gruppenmonitor 0_2_36_aus.jpg Gruppenmonitor 0_2_11_aus.jpg

[mumpf]

Ok, auf die ReadRequests antwortet nur einer, damit ist meine Vermutung hinfällig, dass da noch jemand anders dazwischen funkt.
Die GA sind auch vernünftig verknüpft. Ich würde sagen, das von Dir beschriebene Problem gibt es gar nicht . Aber mal ernsthaft: Ich kann hier keinen Fehler bzw. Seiteneffekt erkennen. Hast Du sehr viele Geräte und eine so hohe Buslast, dass Telegramme verloren gehen könnten (so was wie 20 Temp-Sensoren, die sekündlich ihre Temp auf den Bus senden)?

Gruß, Waldemar

[knxPaul]

Wenn ich eine Logik-Schaltung überprüfe, brauche ich fünf Telegramme nach diesem Muster (die GAs weiss ich nicht):

Logik Eingang 1 A	Logik Eingang 1 B	Logik Ausgang 1
0	0	0
1	0	1
1	1	1
0	1	1
0	0	0

Hoffentlich ist verständlich, wie ich das meine: Für die erste Zeile braucht es zwei GroupValueReads auf die beiden GAs, die mit den beiden Logik-Eingängen verbunden sind, im Zustand alles aus.
Für die zweite Zeile nur ein GroupValueWrite := '1' auf die GA, die mit Logik Eingang 1 A verbunden ist. Das kann von einem Taster kommen.

[bavarianhias]

Meinst du so (Anhang)?
Sorry etwas unübersichtlich. Habe versucht es zu markieren.
Vorgehensweise: Logik 1A war zuerst true d.h. EG Licht war an.
Dann habe ich so durchgeschaltet wie in deiner Tabelle #12. Kann aber nichts abwegiges erkennen und wie Anfangs gesagt, es tritt nur sporadisch auf. Und hier hat es
funktioniert - sieht man am 0/2/37.

Problem gibt es gar nicht

...und ich bin mir sicher, dass es das Problem gibt. Kann es nur nicht eingrenzen. Eben weil es nur ab und zu auftritt und ich dazu genau den Zeitpunkt der Aufzeichnung erwischen müsste.
Busmonitor Status schalten Licht.jpg

[knxPaul]

Das Bild ist aufschlussreicher als erwartet. Ich kann mich gar nicht richtig auf die Logik konzentrieren, wegen der "blauen Streifen". Zuerst dachte ich, das sind mehrfach markierte Zeilen. Aber die Farbgebung im Gruppenmonitor sagt "weiss vor blau = Gesichert".

• Sind da gesicherte (secure) und nicht gesicherte Geräte gemischt im Betrieb?

[mumpf]

Sind da gesicherte (secure) und nicht gesicherte Geräte gemischt im Betrieb?

Nö, das sind nur einfach mehrere markierte Zeilen. Weder der GT2 noch die GLED haben secure-Applikationen, zumindest nicht dass ich wüsste.

Gruß, Waldemar