Archiv verlassen und diese Seite im Standarddesign anzeigen : Design interner KO im HS
Hallo,
nachdem ich meine Freizeit nun mit dem HS verbringe merke ich, dass die ganzen Spielereien zu einer Erhöhung der Telegrammrate führen. Ich bin zwar noch - wie ich meine - weit entfernt von einer nennenswerten Auslastung aber bevor ich mir jetzt eine Menge Arbeit mache und die Logiken nachher wegwerfe wäre es nett, wenn ihr mir aus euren Erfahrungen ein paar Tipps geben könntet.
Meine Idee ist, dass ich die Meldungen der einzelnen Sensoren nach Eingang in ein internes KO überführe, sodass ich, wenn ich die Werte später in anderen Logiken verwenden möchte, nicht jedesmal auf den Bus muss um diese zu ermitteln.
Ist dies aus eurer Sicht sinnvoll oder überflüssig? Es handelt sich um ein kleines EFH, d.h. die Anzahl der KOs ist durchaus überschaubar.
In einer solchen Vorgehensweise hätte ich aus meiner Sicht den Vorteil, dass ich auch die Verknüpfungen zwischen den Sensoren und Aktoren nicht direkt machen müsste, sondern alles über den HS steuern könnte. Da dies jetzt recht theoretisch war, möchte ich es an einem Beispiel aufzeigen:
IST
BWM im Gäste-WC sendet Meldung auf GA 1/1/1
Theben-Wetterstation sendet Helligkeit auf GA 2/2/2
Im HS wird jedesmal wenn 1/1/1 eintrifft geprüft, ob die Helligkeit < n Lux ist und sendet dazu einen Lese-Request an 2/2/2. Wenn die Bedingung erfüllt ist, wird das Licht eingeschaltet und der Rollladen runtergefahren.
PLAN
BWM sendet weiterhin auf 1/1/1
Die Theben meldet ja sowieso jede Helligkeitsänderung auf 2/2/2, daher dachte ich, macht es Sinn diese auf ein internes KO im HS zu speichern, sodass in der Logik, die entscheidet ob Rollladen zu und Licht angeschaltet werden muss, nicht jedesmal ein Lese-Request auf den Bus muss.
Das ganze lässt sich auf n verschiedene Logiken übertragen. Ich möchte nur vermeiden, dass ich bereits im Ansatz einen grundlegenden Fehler mache.
Wie sind denn so eure Meinungen?
eib-starter
20.07.06, 11:01
Matthias und die anderen Profis mögen mich korrigieren,
aber wieso jedes Mal eine Leseanfrage?
Die Sensoren senden Ihre Werte doch sowieso (entweder Zyklisch oder bei Änderung müsste jedenfalls so sein wenn die Werte auch z.B. in der Visu angezeigt werden sollen) dieses „hört“ der HS laufend mit und hat somit ständig den derzeitigen Wert.
Die Logik überprüft bei jedem eingehen Telegramm (hier also BM oder Helligkeit) ob die Bedingungen erfüllt sind und gibt die entsprechenden Werte am Ausgang aus...
Gruß
Frank
Matthias Schmidt
20.07.06, 11:18
Die Sensoren senden Ihre Werte doch sowieso (entweder Zyklisch oder bei Änderung müsste jedenfalls so sein wenn die Werte auch z.B. in der Visu angezeigt werden sollen) dieses „hört“ der HS laufend mit und hat somit ständig den derzeitigen Wert.
Ganz genau, so ist es. Leseanfragen sind nur in absoluten Sonderfällen notwendig.
Die Sensoren senden Ihre Werte doch sowieso (entweder Zyklisch oder bei Änderung müsste jedenfalls so sein wenn die Werte auch z.B. in der Visu angezeigt werden sollen) dieses „hört“ der HS laufend mit und hat somit ständig den derzeitigen Wert.
Die Logik überprüft bei jedem eingehen Telegramm (hier also BM oder Helligkeit) ob die Bedingungen erfüllt sind und gibt die entsprechenden Werte am Ausgang aus...
:confused: Kann es sein, dass ich dann irgendwo noch eine falsche Einstellung im HS-Experten gemachte habe?
Leseanfragen sind nur in absoluten Sonderfällen notwendig.Ich hatte im Busmonitor den Request gesehen und darauf basierte ja dann letztendlich meine Überlegung. Kann es sein, dass ich durch suboptimale Nutzung des Produktes einen solchen Sonderfall erzeugt habe?
Aber ich werde es heute abend auf jeden Fall nochmal testen! Wenn die Werte automatisch zwischengespeichert werden, dann ist meine ganze Idee natürlich für den Eimer :o...
und ich muss mir die ganze Arbeit mit den internen KOs nicht machen :)
auch ich gehe ganz sparsam mit leseanfragen um.
in diesem zusammenhang ist es auch ganz wichtig,
dass alle flags in der ets und im hs richtig gesetzt
sind. sobald nämlich scanfehler auf der debug seite
auftauchen, wird beim neustart mehrfach abgefragt. also immer mal wieder die debug seite
genauer ansehen.
man muss aber auch folgendes beachten:
stellt man nicht auf abfragen, werden die init werte der ko´s, nach einem neustart des hs, in der visu angezeigt. somit kann es zur falschen
darstellung kommen, bis die ga einmal gesendet hat.
der weg über die internen ikos´kann aber auch zu
fehlern führen. du müsstest die auf remanent stellen, was aber auch wieder dazu führen kann,
dass der wert nicht richtig angezeigt wird, nämlich
dann, wenn wärend eines neustarts der wert sich
ändert.
zu hoher buslast kann es auch kommen, wenn
das zyklische senden in der ets, bzw das züglische
abfragen vom homeserver, übertrieben wird.
manche fragen ja, wie michel unlängst geschrieben hat, alle 2 sekunden seinen server ab, ob jemand im stammtischchat ist und das 24/7.;-)
gruss
günther
eib-starter
20.07.06, 13:55
der weg über die internen ikos´kann aber auch zu
fehlern führen. du müsstest die auf remanent stellen, was aber auch wieder dazu führen kann,
dass der wert nicht richtig angezeigt wird, nämlich
dann, wenn wärend eines neustarts der wert sich
ändert.
Aber dafür braucht mann doch keine iKO's die normalen KO können doch auch im HS remanent gespeichert werden.
Das mit den möglichen Fehlerquellen ist allerdings so, wobei ich mit einer falschen Anzeige in der Visu eigentlich leben kann, viel schlimmer ist's wenn so ein Wert einem ein Archiv und damit ein Diagramm zerschießt. ;)
Gruß
Frank
stellt man nicht auf abfragen, werden die init werte der ko´s, nach einem neustart des hs, in der visu angezeigt. somit kann es zur falschen
darstellung kommen, bis die ga einmal gesendet hat. Dann wird vermutlich hier mein Problem liegen. :rolleyes:
Ich habe die KOs nämlich auf "Lesen" gesetzt. Aber das werde ich heute abend nochmal prüfen.
Matthias Schmidt
20.07.06, 14:17
Mal prinzipiell, zum Thema "Wald":
Die größte Verständnisschwierigkeit am Anfang ist, sich darüber klar zu werden, dass der EIB ereignisorientiert funktioniert und nicht, wie z.B. bei einer SPS, im Millisekundenbereich zyklisch Eingänge abgefragt und Ausgänge gesetzt werden.
Ein Beispiel: Türkontakt, Tür offen 1, Tür zu = 0, kein zyklisches Senden.
Wenn die Tür geöffnet wird, sendet der zugehörige BinEIN ein Telegramm mit dem Wert "1" auf den Bus. Alle Teilnehmer können dieses Telegramm empfangen. Auch der HS lauscht kontinuierlich mit und setzt in seinem internen Prozessabbild den Wert für dieses EIB-Objekt auf 1.
Wir die Tür geschlossen, geschieht dasselbe mit einem Telegramm und Wert "0".
Starte ich den HS hingegen neu, während die Tür offen steht, dann weiß er im Normalfall nicht, wie der Zustand der Tür jetzt ist. (Gleiches gilt natürlich auf für andere Visu-Elemente, Infodisplays etc., nicht nur für den HS).
Deswegen gibt es im HS die Möglichkeit, wichtige EIB-KO beim Starten des HS abzufragen, damit das Bild im HS wieder synchron zum tatsächlichen Stand auf dem Bus ist. Wichtig ist jetzt, blue hat es erwähnt, dass der HS überhaupt in der Lage ist, den Zustand des Binäreinganges abzufragen.
Deshalb MUSS bei diesen Objekten das Leseflag mit der ETS gesetzt sein. Das Kästchen "Lese-Flag" im HS hat damit absolut nichts zu tun, das ist inder Regel immer deaktiviert!!
Die Debugseite zeigt im Bereich "Scanfehler" an, wo der HS versucht, den Zustand auszulesen und wo ihm das mangels Lese-Flag nicht gelingt.
Interne KO braucht man zum Visualisieren der Buszustände und zum Schalten von Gruppenadressen prinzipiell überhaupt nicht.
Aber dafür braucht mann doch keine iKO's die normalen KO können doch auch im HS remanent gespeichert werden.
Das mit den möglichen Fehlerquellen ist allerdings so, wobei ich mit einer falschen Anzeige in der Visu eigentlich leben kann, viel schlimmer ist's wenn so ein Wert einem ein Archiv und damit ein Diagramm zerschießt. ;)
Gruß
Frank
hallo frank,
das ist schon richtig. ich habe es deshalb geschrieben, weil touareg dies gedanklich
so machen wollte. aber grundsätzlich gilt
das natürlich auch für iko´s, die nicht mit
dem bus getrickert werden.
gruss
günther
eib-starter
20.07.06, 14:32
hallo frank,
das ist schon richtig. ich habe es deshalb geschrieben, weil touareg dies gedanklich
so machen wollte. aber grundsätzlich gilt
das natürlich auch für iko´s, die nicht mit
dem bus getrickert werden.
gruss
günther
Dann sind wir uns da ja einig:Prost:
Ich wollte nur nicht das jemand denkt um KO's remanent zu speichern MÜSSEN diese erst auf ein iKO gelegt werden...
Gruß
Frank
Matthias Schmidt
20.07.06, 14:59
Aber dafür braucht mann doch keine iKO's die normalen KO können doch auch im HS remanent gespeichert werden.
Da habe ich mich schon ausführlich dazu geäußert. Den Haken "remanent" bei einem EIB-Objekt, also nicht bei einem iKO, sollte man nur mit größter Vorsicht verwenden und nur, wenn man weiß, was man tut! Eine real existierende GA ist von sich aus remanent!
Der ist eigentlich dazu da, ein im realen Bus nicht vorhandenes EIB-Gerät (GA) zu emulieren und nicht, um eine vorhandene GA zu speichern!
Maßgeblich in einer professionellen Anlage sollte immer das tatsächliche Geschehen auf dem Bus sein und nicht irgendwelche zufällig angelegten Prozessabbilder (Pfusch, IMHO).
Jetzt schau'n mer mal ob ich's verstanden habe:
Eine real existierende GA ist von sich aus remanent! Weil dies im Busankoppler des entsprechenden Gerätes sowieso gespeichert werden muss und ich beim Start des HS - sofern mir das KO wichtig ist - das Flag "Lesen bei Start" setze und ab diesem Zeitpunkt der HS alle Änderungen mitbekommt !?!
eib-starter
20.07.06, 15:17
Da habe ich mich schon ausführlich dazu geäußert. Den Haken "remanent" bei einem EIB-Objekt, also nicht bei einem iKO, sollte man nur mit größter Vorsicht verwenden und nur, wenn man weiß, was man tut! Eine real existierende GA ist von sich aus remanent!
Maßgeblich in einer professionellen Anlage sollte immer das tatsächliche Geschehen auf dem Bus sein und nicht irgendwelche zufällig angelegten Prozessabbilder (Pfusch, IMHO).
Hallo Matthias,
da gebe ich dir natürlich recht, aber manchmal kann auch das remanente speichern eines realen KO's ganz wichtig sein, z.B. tut sich das fm446 mit leseanforderungen schwer. (z.B. Warmwasser ist temp.)
Um sich hier nicht das Archiv mit irgendwelchen defaultwerten zu zerschießen ist das remanente speichern nötig.
Bitte korrigier mich wenn ich da falsch liege! :)
Der ist eigentlich dazu da, ein im realen Bus nicht vorhandenes EIB-Gerät (GA) zu emulieren und nicht, um eine vorhandene GA zu speichern!
verstehe ich nicht ganz, kannst du da mal ein Beispiel geben?
Gruß
Frank
Matthias Schmidt
20.07.06, 15:35
Das mit dem FM446 kann ich so nicht bestätigen. Funktioniert bei mir mit "Scan bei Start" hervorragend.
Ein Beispiel für im HS angelegte remanente Objekte:
Texte, z.B. Raumbelegung auf Infodisplays. Nach einem Busausfall können die Displays die betreffende GA aus dem HS auslesen.
eib-starter
20.07.06, 17:01
Das mit dem FM446 kann ich so nicht bestätigen. Funktioniert bei mir mit "Scan bei Start" hervorragend.
Echt? komisch... wird dann wohl noch ein Fehler aus "meiner Anfangszeit" sein... ich guck mir das heute abend noch mal an...
(Den Tipp dieses KO remanent zu setzen hatte ich übrigens mal im Chat von dir bekommen :Prost: )
Texte, z.B. Raumbelegung auf Infodisplays. Nach einem Busausfall können die Displays die betreffende GA aus dem HS auslesen.
Danke :)
Powered by vBulletin® Version 4.2.4 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.