HS Logik - ich verstehe sie nicht!

[TRex]

mal ganz pragmatisch gefragt, hast DU in den KO die Option "Beim Start abfragen" gewählt?

Geb doch als INIT-Wert mal eine 1 vor. Dann hast DU das Problem genau umgedreht, oder nicht? Wäre aber kein Problem, denn wenn Du deinen HS startest biste eher ja mal zuhause - Stromausfall ausgeschlossen.

Peter

[tbi]

HSebug/Logik

Du meinst auf der HS-debug-Seite die Logik-Listen, die in :

Baustein-ID / Anzahl / Checksumme

gegliedert sind?

Hallo Christian,

Ja!
Es geht ja weiter: danach steht ja noch

"In" ist anscheinend wieviel Werte rein kamen
"Store" ist anscheinend wieviel Werte gespeichert sind
"Out" ist anscheinend wieviel Werte raus gingen
"Count" wie oft ?????

Erst wenn da was rein und raus geht, weißt du das wirklich was passiert.

Es wäre schön wenn wir hier im Lexikon auch eine Erklärung hierzu hätten.
Leider kann ich es nicht machen. Dann müste man nicht orakeln was das nun wirklich ist, vielleicht sind es ja logische Äpfel oder Birnen .

Mir hat es jedenfalls sehr geholfen.

Gruß Tbi

[ChristianB]

a!
Es geht ja weiter: danach steht ja noch

"In" ist anscheinend wieviel Werte rein kamen
"Store" ist anscheinend wieviel Werte gespeichert sind
"Out" ist anscheinend wieviel Werte raus gingen
"Count" wie oft ?????

Für das Problem hier bringt das nur überhaupt nichts, da sich nicht unterscheiden lässt, was genau an einem speziellem Ausgang von einem UND-Baustein passiert ist.
Diese Liste zeigt lediglich, dass an irgendeinem der vielen UND- Baustein etwas passiert ist.

[tbi]

Tracepunkt Logikbaustein ?

Naja,

es ist die Frage wie man es einsetzt.

Wenn Du dir einen Logikbaustein machst den Du nur einmal setzt, hast Du zum Beispiel einen Tracepunkt, den Du so immer überwachen kannst.

Vielleicht gibt es besser Techniken, aber es ist eine um innerhalb der Logik-Seite einen Tracepunkt zu haben.

Wenn man nicht weiter kommt, lohnt sich manchmal etwas mehr Aufwand am Testaufbau.

Gruß Tbi

[alteraffe]

Hallo,

ich muss den Thread noch mal nach oben holen, denn ich habe ein ähnliches Problem mit einem Logikmodul.

Zum Hintergrund: Das Modul hat 5 Eingänge, aber es müssen nicht alle verdrahtet werden. Ich möchte im Modul feststellen, welche Eingänge einen "Wert" haben.

In dem Logikbaustein frage ich also den Status des Eingangs mit EC[n] ab. Wenn am Eingang "n" ein Signal/neuer Wert anliegt, dann ist EC[n]==1. Den Wert selbst lese ich dann von EN[n] aus.

Soweit so gut und trivial...

Wenn ich aber auf einen Eingang ein remanentes iKO gebe, dann liegt der Wert dierekt nach dem Start an, aber EC[n] ist immer 0. Erst wenn sich der Wert ändert, oder erneut gesendet wird, ist auch EC[n]==1.

Somit kann ich nicht erkennen, ob ein "gültiger" Wert anliegt, oder nicht...

Bei Strings könnte ich noch auf '' (leer) prüfen, aber bei Zahlen kann die 0 am Eingang EN[n] entweder gewollt sein, oder es liegt kein (neuer) Wert an und 0 ist der Initialwert.

Meine Fragen:
- Wie kann ich in einem Logikbaustein auch für remanente iKOs 100%ig feststellen, ob am Eingang ein Wert anliegt?
- Ist das ein bekanntes Problem (habe nur diesen Thread dazu gefunden) und kann ich das wirklich nur über eine externe Verschaltung mit Telegrammverzögerung+Sperre lösen?

Oder habe ich noch etwas übersehen?

[Taxus]

Wenn Du ein remanantes iKO auf den Eingang legst, liegt doch ein gültiger Wert an, wozu noch "abfragen"? Verarbeite ihn intern einfach.
Wenn Du aber einen remanent gespeicherten Wert sicher schon beim Init vom Defaultwert unterscheiden möchtest - definiere einfach einen Defaultwert, der nicht im Wertebereich eintreffender Telegramme liegt.

[alteraffe]

Wenn Du aber einen remanent gespeicherten Wert sicher schon beim Init vom Defaultwert unterscheiden möchtest - definiere einfach einen Defaultwert, der nicht im Wertebereich eintreffender Telegramme liegt.

Hallo Taxus,

Danke für die schnelle Antwort!

Das reicht aber leider nicht! Auch wenn ich einen Defaultwert außerhalb des Werteberiches nehme (z.B. -1), kann ich damit nicht feststellen, ob der Eingang belegt ist.

Wie gesagt, das Modul hat n-Eingänge, von denen 1-n verdrahtet sein können.

Ähnlich einem 8-fach UND, da werden auch nicht alle Eingänge immer belegt sein. Hier funktioniert es m.M. nach aber auch nur, weil alle Eingänge mit 1 vorbelegt sind... Es werden immer alle 8 Eingänge "ver-undet".

Ich möchte aber nur mit den Eingängen "rechnen", die auch wirklich belegt/angeschlossen sind...

Ein einfacher Anwendungsfall: Das Modul soll bis zu 5 Texte (E1-E5), getrennt durch einem Trennzeichen (E6) zusammenfügen. Ein Text kann leer sein.

Bei E1="abc"; E2=""; E3="def"; E6="," soll A1="abc,,def" sein und nicht "abc,,def,,"...

Bei nicht remamneten iKO Werten kann ich - gemäß Doku - mit EC[n] abfragen, ob ein Telegramm am Eingang n anliegt, bei remanenten funktioniert das anscheinend nicht.

Na ja, alternativ könnte ich einen Eingang mit "Anzahl Eingänge" hinzufügen, aber dann müssten immer alle Eingänge aufsteigend belegt sein. E1,E3,E4 würde dann zu einem Fehler führen, da intern nur mit E1,E2,E3 gerechnet würde...

Habe nur ich das Problem, oder habe ich noch ein Verständnisproblem?

[Taxus]

EC[n] dient weniger der Feststellung des Anliegens eines KOs (das ist ein indirektes Nebenprodukt), sondern der Feststellung, dass es dieser Eingang ist, der den Baustein getriggert hat. Ein nicht remanentes KO kann nur über ein aktives Senden den Baustein triggern, das remanente iKO wird beim HS-Neustart aber bereits zur Initialisierung des Eingangs verwendet.
Zu meinem Vorschlag mal die entscheidenden Zeilen:

 
5003|3|42|1     # Eingang 3, Initwert 42, remanent
 
5012|0|"EN[3]!=42"|"SN[1]+EN[3]"|""|0|0|1|0
 
# oder als Text:
5012|0|"EN[1]!='x'"|"EN[1]"            |""|0|0|1|0
5012|0|"EN[2]!='x'"|"SN[1]+EN[6]+EN[2]"|""|0|0|1|0
5012|0|"EN[3]!='x'"|"SN[1]+EN[6]+EN[3]"|""|0|0|1|0
5012|0|"EN[4]!='x'"|"SN[1]+EN[6]+EN[4]"|""|0|0|1|0
5012|0|"EN[5]!='x'"|"SN[1]+EN[6]+EN[5]"|""|1|0|0|0

Hier ist es egal, ob der Eingang bereits bein HS-Start durch ein remKO oder später durch ein Telegramm 'belegt' wurde. Der Eingang ist gültig, wenn er vom Default abweicht, Du kannst auch ohne EC damit rechnen.

Das alles ist natürlich davon abhängig, was der Baustein nun wirklich machen soll - wenn er aber immer alle Werte zusammenfügen soll, ist die EC-Abfrage entbehrlich.

[alteraffe]

Ok, habe verstanden...

Vielen Dank für die ausführliche Erklärung!

Dass bedeutet aber dann, ich kann mich eigentlich nicht (nur) auf EC verlassen, denn das Modul hat ja keine Kenntniss über das anliegenden iKO (remanent, oder nicht).

5012|0|"EC[1]"|"..."

kann funktionieren, muss aber nicht. Für eine Abfrage, ob ein Wert anliegt, oder sich geändert hat, wäre es dann:



5012|0|"EC[1] or (EN[1]!='x')"|"..."


Richtig?

Nachteil: Diese Zeile würde jedesmal ausgeführt. Auch wenn der Wert sich nicht geändert hat und ein anderer Eingang die Berechnung getriggert hat...

Eigentlich bin ich auf der Suche nach einer Lösung für "berechne wenn sich der Wert am Eingang geändert hat". Na ja, dann muss ich diese Kröte wohl schlucken

Werde dann den Vergleichswert in eine SN packen und mit EN vergleichen... wenn ungleich, dann berechnen und SN=EN setzen:

5003|1|"x"|0

5012|0|"EC[1] or ((EN[1]!='x') and (EN[1]!=SN[1])"|"..."
5012|0|"EC[1] or ((EN[1]!='x') and (EN[1]!=SN[1])"|"EN[1]"|0|0|1|0

Nicht schön...

[TRex]

mein Ansatz wäre, den internen Wert als "richtig" zu betrachten und nur bei Änderung dann zu überschreiben

EN[1] == EA[1]

Ich habe mir so einen Baustein gebastelt, der mir Wertänderungen einfach abfragt, dann bei Änderung eine 1 sendet und den alten wert auf 2 KO...

[alteraffe]

hilft leider auch nicht... Bei der Initialisierung ist EA[x] immer gleich EN[x].

Ich habe mal mein dummy/test Modul angehängt.

Es hat 5 Eingänge und einen debug Ausgang... Eingang 5 ist zum reset. Es gibt EI und die verschiedenen Zustände EA, EC, EN der Eingänge als debug String an A1 aus...

Beispiele:

E1 : remanentes iKO, Wert 3
E2 : remanentes iKO, Wert "def"
E3 : kein Anschluss, default -99
E4 : kein Anschluss, default "x"

A1 : EI=1; EC[1]=0; EN[1]=3.0; EA[1]=3.0; EC[2]=0; EN[2]=def; EA[2]=def; EC[3]=0; EN[3]=-99; EA[3]=-99; EC[4]=0; EN[4]=x; EA[4]=x;

Erst wenn sich ein Eingang wirklich ändert ist EA[x] != EN[x]. Dann ist aber auch EC[x]!=0

E1 : remanentes iKO, neuer Wert 2

A1 : EI=0; EC[1]=1; EN[1]=2.0; EA[1]=3.0; EC[2]=0; EN[2]=def; EA[2]=def; EC[3]=0; EN[3]=-99; EA[3]=-99; EC[4]=0; EN[4]=x; EA[4]=x;

Gleiches Verhalten bei nicht remamnet, d.h. das Verhalten bei der Initialisierung hat nichts mit remanent zu tun, sondern "works as designed"(?)...

Oder fällt jemanden noch etwas dazu ein??

[TRex]

KNX ist eventbasiert, d.h. der Wert steht nur im Moment des Eingangs zur Verfügung...

[alteraffe]

KNX ist eventbasiert, d.h. der Wert steht nur im Moment des Eingangs zur Verfügung...

Ja, das ist eine schöne Umschreibung meines Problems

Per Definition ist wohl das Setzen der Eingänge bei der Initialisierung kein Event für den jeweiligen Eingang.

Na ja, schade... Muss ich es anders (aufwändiger) lösen...

Danke an alle für die Unterstützung!