MDT Logikmodul - Universal-Logik -> "Sonst"

[Fidelis]

Von daher passt das Verhalten, dass das Logikmodul den Ausgang erst sendet wenn vorher 1x die Logik wahr war.
Scheint so zu sein, wie es Florian auch bereits vermutet (auch wenn ich mir das aktuell nicht logisch erklären kann, weshalb der Ausgang nicht gesendet wird, wenn die Logik "falsch" ist).

Dieses Verstädnis taucht öfter mal hier im Forum auf. Das Problem der Logik ist aber, dass diese weder "wahr" noch "falsch" sein kann, wenn nicht alle Eingänge bekannt sind. Denn ohne definierte Eingänge, kann eine Logik keinen definierten Ausgang liefern. Sonst wäre es keine Logik, sondern Spekulation.

Wenn eine Logik möglichst schnell nach dem "Hochfahren" arbeiten soll, ist es hilfreich, wenn diese ihre Eingänge aktiv abfragt. Also ein "Frage-Telegramm" an die Geräte schickt, die diese Informationen liefern können. Diese Geräte müssen so parametriert sein, dass sie auf solche Telegramme auch antworten. Das ist mit dem "L-Flag" gemeint. Und mit dem Gruppenmonitor in der ETS kannst du dann prüfen, ob zunächst die Logik alle Eingänge abfragt und anschließend, ob alle anderen Geräte auch brav darauf antworten.

Wenn du Geräte hast, die ohnehin zyklisch senden, kann es auch völlig ausreichend sein, eben einen Zyklus abzuwarten, statt aktiv nachzufragen. Das hängt aber von der konkreten Situation ab. Sprich, wie regelmäßig wird gesendet und wie schnell soll die Logik ans arbeiten kommen.

[willisurf]

Genau richtig und als kleine Ergänzung: Wann immer möglich würde ich zyklisches Senden vermeiden.

[Beleuchtfix]

Wobei man meinen könnte, dass ein Oder-Gatter ja schon beim ersten True Wert auslöst, aber auch das ist nicht der Fall.
Gruß Florian

[DanielMueller]

Erst einmal nochmal Danke dafür, dass ihr Euch die Zeit nehmt.

Ich habe im Anhang mal einen Auszug vom Gruppenmonitor gepackt.
Ich habe eure Hinweise mir mal angeschaut und die Logik mit zyklisch senden nochmal deaktiviert.

Die Gruppenadresse 8/2/3 wird zwar nach dem Start gelesen, allerdings wird nichts geschrieben.
Gruppenadresse 8/2/1 hat die gleichen Flags und diese wird geschrieben.

Was ich jetzt wieder nicht raffe: Wenn ich im Gruppenmonitor die Adresse 8/2/3 unter "Lesen" abfrage, dann kommt das KO auf 8/2/4 (siehe blaue Pfeile).

[Fidelis]

Das die Interpretation des Logs angeht bin ich noch nicht ganz firm, deshalb korrigiert mich bitte, wenn ich hier Quatsch erzähle...

Wenn ich deine Screenshots richtig verstehe, schickst du bei # 391 ein GroupValueRead auf den Bus. Daraufhin antwortet das Logikmodul unter # 393 mit einem GroupValueResponse, also so wie es zu erwarten ist. Unter # 394 dagegen kommt ein GroupValueWrite, dass vermutlich durch deine Logik im Logikmodul ausgelöst wurde. Also nur indirekt mit dem GroupValueRead zusammenhängt.

Und da in deinen Formulierungen etwas Durcheinander zu den Themen KO und GA mitschwingt, hier ein kurzer Versuch das zu erklären:

• Die KO sind die Ein- und Ausgänge der Geräte. Im übertragenen Sinne so etwas wie Briefkästen (es soll ja Länder geben in denen die Ausgangspost ebenfalls im eigenen Briefkasten abgelegt und dort vom Postboten aufgesammelt wird).
• Die GA dageben sind ein Inhalt der Briefe und funktionieren mehr oder weniger wie Adressen. An den Geräten selber stelle ich mir die GA auch als "Filter" vor. Die Geräte bekommen ja sämtliche Post zu sehen, die über den Bus geht - quasi wie Postkarten - und greifen sich die Nachrichten raus, die eine passende GA im "Adressfeld" haben.

EDIT: Musste die # mit Zahlen dahinter "heilen". Kann mir jemand verraten, warum das Forum da einfach Unsinns-Links draus erzeugt?

[ollu77]

Hallo

Auf ein GroupValueRead sollte immer vom angefragten Teilnehmer ein GroupValueResponse folgen.

Dies ist bei

8/2/4 Leseanforderung von ETS
8/2/7 Leseanforderung von Logikmodul
8/2/3 Leseanforderung von Logikmodul und ETS

der Fall

wobei 8/2/3 einmal eine Leseanfrage vom Logikmodul hat und einmal eine von der ETS also müsste es 2x Antworten sein.

8/2/1 Antwortet nicht.

Dies könnte daran liegen das der Eingang 2 Mittelwert nicht verbunden ist. Daher kann es keinen Mittelwert geben.

Auch diese beiden Eingänge würde ich nach Reset Abfragen.

[Punker Deluxe]

Was hängt denn an 8/2/3 und 8/2/1... ?

[DanielMueller]

8/2/1 liefert den Mittelwert von der Temperatur (Den zweiten Eingang von der Temperatur habe ich noch hinzugefügt).
8/2/2 und 8/2/3 sind jeweils Verzögerungen (im Sinne einer Reihenschaltung). Eingänge nach Reset abfragen geht hier aber nicht.

Es ist jetzt nicht weiter tragisch. Im Endeffekt schlägt die Sperre an der Zeitschaltuhr erst zu, wenn die Logik wahr/falsch wird.
Von daher: Alles gut & Danke Euch nochmal