Anfängerfrage, ETS-Verknüpfungen oder EibPC, wer hat das sagen?

[FHarry]

Hallo beinander,

hab nun auch meinen EibPC in Betrieb genommen und lese gerade das Handbuch. Und nun stellt sich mir eine ganz simple Frage:

Nehmen wir an, es ist bereits alles in der ETS parametriert. So wie z.B. im Handbuch des EibPC an einem Beispiel beschrieben:

Schalter

sendet auf '1/0/0'

Aktor (Lampe) empfängt auf '1/1/1'

Und jetzt kommt der EibPC daher und ich bastle noch ein wenig Logik drum herum, z.B. nur um eine bestimmte Zeit das Licht schalten.

Was ich jetzt nicht verstehe ist, "wer hat das sagen?". Schaltet das Licht nicht so oder so, weil es eben in der ETS so parametriert wurde? Wie gewinnt der EibPC jetzt die Oberhand?

Danke schon mal für die Erleuchtung,

Harry

[vento66]

Der erste Befehl auf dem Bus geewinnt. Wenn Du den EibPc dazwischenklemmen willst kommst du stellenweise nicht drumrum neue Adressen zu vergeben.


Sent from my iPhone using Tapatalk

[MatthiasS]

Naja, ich würde sagen, der letzte Befehl gewinnt

[Bodo]

Hoi

Genau, der letzte Befehl gewinnt.
Ich schalte ein Licht ein (=100%) und der EibPC dimmt nachts auf 30% sozusagen einen Wimpernschlag danach.
Der EibPC ist so schnell, dass man da nichts merkt von den zunächst 100%

[saft6luck]

Ich schalte ein Licht ein (=100%) und der EibPC dimmt nachts auf 30% sozusagen einen Wimpernschlag danach.
Der EibPC ist so schnell, dass man da nichts merkt von den zunächst 100%

Oder die GA für das Einschalten geht an den eibPC und der entscheidet dann, welcher Dimmwert an den Aktor gesendet wird.
Ob man lieber "Überschreibt" oder direkt den eibPC einsetzt, häng dann vom Vertrauen in den eibPC ab

[FHarry]

Ok, gut, der letzte Befehl gewinnt. Aber wie wird sichergestellt, daß es der EibPC ist, der als letztes kommt?

Noch ein Beispiel:
Sagen wir mal die ETS Parametrierung sagt, "Aktor an" und die Logik vom EibPC sagt aber "Aktor aus". Führt das nicht zu einem klick-klack in meinem Schaltschrank. Nicht das mich das stören würde. Aber es wäre dann mindestens ein Schaltvorgang überflüssig.

Schönen Sonntag noch,

Harry

[GLT]

Unter Umständen führt das zu den von Dir angeführten Klick-Klack-Phänomen.

Verhindern lässt es sich, wenn man die Logiken im EIBPC und die, mittels ETS-Projektierung vorgenommenen Logiken aufeinander abstimmt.

[Bodo]

Ok, gut, der letzte Befehl gewinnt. Aber wie wird sichergestellt, daß es der EibPC ist, der als letztes kommt?

Hoi Harry

Na der EibPC hört auf den Befehl vom Schalter und reagiert dann. Ohne Schaltbefehl passiert nix. Schalter 100% -> EibPC reagiert.

Die Idee dahinter ist: Der Bus soll auf jeden Fall die Grundfunktionen ausführen, auch wenn die Zusatz-Logik ausfällt.

[FHarry]

Servus Bodo,

schon klar, daß der EibPC das Telegramm vom Schalter mitbekommt. Nur war die Frage, bekommt's zuerst der EibPC und dann die "ETS" oder umgekehrt.?

Wie kann man sicherstellen, daß das Telegramm als letztes beim EibPC angkommt? Und überhaupt, wo ich diese Frage gerade stelle: Wenn ein Telegramm irgendwo einen Abnehmer findet und quittiert wird, dann verschwindet es doch vom Bus. Wie kann es dann überhaupt sein, daß es der EibPC noch mitbekommt?

Grüße,

Harry

[Bodo]

Hoi

das Signal ist auf dem Bus und es können sich mehrere angesprochen fühlen, sozusagen darauf hören, AFAIK

Dann ist es weg und der EibPC kann ja nur zweiter sein.

Die ETS hat da nicht's zu tun, der Bus ist autark. Die ETS kann nur ebenfalls wie ein Teilnehmer mithorchen (Monitor).
Oder zum Parametrisieren (Gruppenadressen vergeben und Parameter einstellen, bzw. Programme und Einstellungen in die Teilnehmer senden, damit die sich dann danach verhalten.)

[salixer]

Dann ist es weg und der EibPC kann ja nur zweiter sein.

Naja, der EibPC empfängt das Telegramm ja gleichzeitig mit dem Aktor und braucht dann etwas Zeit um seine Logik abzuarbeiten. Dann schickt er ein neues Telegramm hinterher. Probleme sollten da erst auftauchen, wennd er Bus überlastet ist.

[FHarry]

Ok ist klar,

das Telegramm dreht auf dem Bus seine Runde. Und der EibPC bekommt es auf jeden Fall. Durch zusätzliche Verarbeitungszeit im EibPC ist er immer der letzte. Somit hat er die Oberhand.

Dann hab ich's gerafft.

Habt vielen Dank,

Harry

[MatthiasS]

Und wenn man es ganz sauber machen will, dann nutzt man zur Triggerung im EibPC nicht das Schalttelegramm, sondern das Statustelegramm des Aktors.

Der meldet nämlich auf Wunsch: Ich habe jetzt geschaltet. Somit ist sichergestellt, dass nachgeordnete Logik an der richtigen Stelle einsetzt.

[Brick]

Hoi

Genau, der letzte Befehl gewinnt.
Ich schalte ein Licht ein (=100%) und der EibPC dimmt nachts auf 30% sozusagen einen Wimpernschlag danach.
Der EibPC ist so schnell, dass man da nichts merkt von den zunächst 100%

mal noch ne frage zur "Geschwindigkeit" ... wie is es wenn ich zb.. ne GA für "Licht ein" ganz normal über die ETS parametriert habe. Also Objekt vom Schalter und vom Aktor in einer GA. Jetzt kommt zusätzlich der EIBPC dazu. Ich sage ihm wenn der Sensor ein Telegramm schickt (z.b 1) soll er erst eine bestimmte Bedingung prüfen und dann entweder 1 oder 0 schicken. Da der Aktor ja aber über die GA schon das 1 bekommt schaltet er sowieso. Jetzt kommt der EIBPC nach was weiß ich.. 10ms später daher und meldet aber eine 0 (wegen der Bedingung). Somit schaltet der Aktor wieder aus.

Erste Frage: kann das schnelle und vor allem unter umständen doppelte Schalten den Aktor beschädigen
Zweite Frage: schaltet er schnell genug das zb. Lampen nicht Flackern. ?!?!
(nicht gedimmte Lampen)..

Gruß Martin

[enertegus]

Erste Frage: kann das schnelle und vor allem unter umständen doppelte Schalten den Aktor beschädigen

Naja, es würde gehen, ABER: Die Anzahl der Lebenzeit-Schaltzyklen deines Aktors würde sich mind. halbieren. So würde ich das nicht machen. Manchmal haben die Aktoren noch einen Logikeingang, so dass Du ggf. den nutzen kannst, wenn Du den manuellen Betrieb umschalten willst. GGf. könnte u.U. eine Einschaltverzögerung was bringen. Auch das geht bei manchen Aktoren.

Zweite Frage: schaltet er schnell genug das zb. Lampen nicht Flackern. ?!?!
(nicht gedimmte Lampen)..

Ich denke nein.