Logikabläufe

[SeatSLF]

Kann man der Logikengine irgendwie angewöhnen, das die Bausteine erst wieder senden wenn sich der Ausgangswert wieder verändert?

[gaert]

Falls Du "Send-by-change" meinst - dafür ist der entsprechende Baustein zu verwenden (also quasi zwischen dem entsprechenden Ausgang und dem Eingang "schalten").

[SeatSLF]

AHHHH, okay Brett vorm Kopf, Baustein eingefügt und funktioniert bestens

[gaert]

Zur Info:
Bei der Initialisierung der Logiken (also beim EDOMI-Start) haben die Fixwerte folgende Bedeutung/Priorität:

• jeder Fixwert (!=NULL, also leer) triggert den Eingang
• jedes KO (!=NULL, also leer) triggert den Eingang und übersteuert dabei den Fixwert
• jede Verbindung triggert und übersteuert dann den Fixwert (KO kann ja nicht übersteuert werden, weil der Eingang kein KO enthalten kann...)
  • sofern die Verbindung "etwas macht" (der Quell-Baustein also an seinem Ausgang etwas ausgibt), wird der Ausgangs-Wert verwendet
  • liefert die Verbindung keinen Trigger (weil der Quell-Baustein an seinem Ausgang nichts ausgibt), wird ggf. der Fixwert verwendet (s.o.)
• Schleifen zwischen den Logikbausteinen werden i.d.R. erst NACH der Initialisierung ausgewertet, da keine der Triggerbedingungen erfüllt sein wird
• soll ein LBS bewußt erst NACH der Initialisierung gestartet werden, nimmt man das System-KO 2 (Systemstart) als Trigger (statt einem Fixwert)

Zu kompliziert? Ok, ich habe versucht ALLE Eventualitäten in diese Beschreibung zu packen... Programmiererkrankheit...

Kurz gesagt:
Wenn ein Fixwert angegeben ist, wird dieser beim Start verwendet. Ist zusätzlich(!) ein KO vorhanden, hat der KO-Wert Priorität gegenüber dem Fixwert. Ist das KO jedoch "leer" (kein InitScan, kein Defaultwert, nicht remanent, etc.), wird auf den Fixwert zurückgegriffen. Gleiches gilt für "Verbindungen" zwischen den Logikbausteinen - diese verhalten sich quasi wie ein KO.

Mit "Schleifen" ist folgendes gemeint: Sind mehrere Logikbausteine untereinander derart verbunden, dass sich daraus eine "Schleife" ergibt, ist dies durchaus legitim. Es gibt Situationen, wo das durchaus Sinn machen kann - man muss aber genau wissen, was man tut - sonst läuft die Logik für alle Zeiten... Wenn also in einer Schleife keine "externen" Triggerfaktoren vorhanden sind (z.B. KO-Wert), wird beim Start diese Schleife nicht getriggert: Es gibt ganz einfach nichts, was diese Schleife "anlaufen" läßt.

[timberland]

Irgendwie stehe ich grad auf der Leitung.
Ich würde die ZSU mit der Dämmerung kombinieren, aber so schaltet sie immer ein bei einem Neustart.

ZSU.PNG

[SeatSLF]

hast du die KOs auf Initscan und das KO von der Uhr remanent?

[timberland]

Ja, habe ich.

[SeatSLF]

Der Grenzwert steht aber definitiv auf 0 wenn du startest?

[timberland]

Bei der Abfrage sind dann beide auf 1.

[SeatSLF]

Das ist komisch das habe ich bei mir nicht, sonst hätte ich heute die Nachbarn schon 2mal auf der Matte wegen Fehlalarm,
sicher das Edomi beim Starten den Grenzwert abfragt und eine Antwort bekommt?

[gaert]

Die Logik als solches ist korrekt. Bliebt die Frage welchen Wert die beiden KOs haben beim Start?

Die GA sollte gescannt werden (Initscan also aktiviert sein).

Tipp: Das System-KO 6 editieren, so dass alle KOs geloggt werden (Projekt anschließend aktivieren). Hilft bei der Fehlersuche

[timberland]

So schaut es nach dem Start aus. Aber sobald die ZSU aktiviert ist schaltet auch das Licht ein . Obwohl zeitmäßig die ZSU eigentlich aus sein sollte.

ZSU1.PNG

[SeatSLF]

Bei mir funktionieren die UZSU hast du für das Ein/Ausschalten der UZSU die selbe GA wie für das Schaltobjekt?

[gaert]

Dann hast du wahrscheinlich das falsche KO erwischt: statt dem "Schalt-KO" das Status-KO der ZSU...

[gaert]

Die ZSU hat 2 KOs: eines zum steuern des Zustandes der ZSU selbst und eines, das letztlich "geschaltet" wird...

Tipp: Altuelle PDF-Doku lesen