- √ - neue Version 1.2 meines Rolladenbausteins (ID 11721) fertig...

[HartmutB]

Wie sich das bei SetPos% verhält, kann ich nicht sagen, da ich das derzeit nicht nutze.

Hallo Harald,
danke für die schnelle Antwort. Dann wird es klar: Mit der Änderung funktioniert die SetPos%-Geschichte nicht mehr und damit wird - leider - der ganze Baustein ziemlich wertfrei, da man keine Positionierung mehr machen kann.

Schade, da bleibt nur die Variante mit doppelten Adressen oder Marc baut da was um (für mich sind das nur absolut kryptische Zeilen in den Bausteinen).

Also im Moment (da ich nicht alle Adressen umbauen will): Zurück zu Holgers Baustein ...

Gruß
Hartmut

[HaraldP]

Hallo Hartmut,

die doppelten Gruppenadressen hatte ich, als ich noch den original Baustein von Marc verwendete. Nachdem ich den dann geändert hatte, habe ich weitere Rollos mit einer GA angeschlossen aber die alten nicht nachgezogen. Wie sich das bei SetPos% verhält, kann ich nicht sagen, da ich das derzeit nicht nutze. Marc's Kommentar habe ich so verstanden, dass es nur um die Weiterleitung der Lang- und Kurzzeitbefehle geht, aber so genau habe ich mir den Code nicht angesehen.

Gruß,
Harald

[HartmutB]

@HaraldP:

Hallo Harald,
ich möchte das Thema nochmals aufgreifen, da es bei mir leider (noch !) nicht funktioniert:

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:
...

OK, die Änderungen habe ich gemacht und sie sind auch wirksam im Sinne von "es hat sich was geändert".

Auf dem Aktor habe ich zwei Gruppenadressen. Eine direkt von Taster, die andere von Marc's Baustein aus dem HS.

Nach der obigen Aussage hast Du doppelte GAs eingesetzt (was man beim Originalbaustein von Holger Schwinghammer nicht braucht).

Da muss ich korrigieren. Ich habe sowohl Aktoren mit 2 Gruppenadressen, als auch solche mit einer. Beide funktionieren identisch.

Hhhm. Reicht jetzt doch eine Gruppenadresse (und man muss nach Deinem "Patch" keine weiteren GAs auf die Aktoren legen ?

Bei mir habe ich folgenden Effekt: Ohne Änderung am Baustein und mit einer GA die bekannten Loops und den Rest kennt man. Steht ja oben in diversen Beiträgen. Mit der Änderung (und immer noch einer GA) klappt alles beim manuellen Fahren und die Position wird zurückgemeldet, fahre ich aber eine Position an über "SetPos %", dann kommt kein "Stop" mehr, die Positionsanzeige bleibt auf dem Wunschwert, aber der Rollo läuft auf oberes oder unteres Ende.
Mache ich was falsch, oder brauch es doch immer doppelte Adressen ? Und wenn ja, warum muss man dann noch patchen, dann sollte es auch so gehen, oder ...

Irgendwo habe ich auch einen Gedanken-Loop, denke ich mal ...

Gruß
Hartmut

[MarcNaroska]

Hallo Hartmut!

Wie schon gesagt, das mit dem Flag zum ein/ausschalten der Weiterleitung von Kurzzeit/Langzeitbefehlen ist in der nächsten Version dabei.
Über die "Linearisierung" muss ich noch mal nachdenken. Dabei gibt es ja auch noch das Problem, dass die meisten Motoren noch eine gewisse Zeit "nachlaufen" beim herunterfahren. Diese Zeit müsste man auch noch berücksichtigen, um die "linearen" Positionen anfahren zu können.
Mal sehen, was mir dazu einfällt...

[goeran]

Hallo,

10% Weg "oben" sind ja ganz was anderes als 10% Weg "unten", da sich der Durchmesser des Rollopakets mit dem Abspulen verringert. Ich weiß nicht, wie man das programmtechnisch oder mathematisch am besten machen kann,

Oho! Jetzt wird's knifflig....

Das wird insbesondere ein Problem, weil die Rollaeden ja nicht alle gleich grosse Lamellen haben und deswegen die Rolle mit kleineren Lamellen weniger stark an Durchmesser zunimmt, als eine mit grossen Lamellen.

[HartmutB]

Ach ja,
noch was für die Wunschliste (obwohl ich die Bausteine noch gar nicht nutze ):

Wie wäre es mit einer "Linearisierung" der Rolloposition beim 11722 ?

10% Weg "oben" sind ja ganz was anderes als 10% Weg "unten", da sich der Durchmesser des Rollopakets mit dem Abspulen verringert. Ich weiß nicht, wie man das programmtechnisch oder mathematisch am besten machen kann, aber es muß ja nicht absolut exakt sein. Es sollte sowas wie einen Parameter 0.0 .. 1.0 geben (mit Standard 0 oder 1), über den man (sowohl eingangs- als auch ausgangsseitig) die Prozentangaben "verzerrt". Bei unverändertem Standard sollte dann das Verhalten wie bisher sein (aus Kompatibilitätsgründen).


Danke und Gruß
Hartmut

[HartmutB]

Hallo HaraldP!

Das mit dem Flag kann ich ja mal auf die "Wunschliste" setzen.

Mallo Marc,

ich würde auch sehr gerne Deinen 11722 statt des Originalbausteins einsetzen und das dann weiter mit dem 11721 "verfeinern".

Tatsächlich war für mich bisher die fehlende direkte Ansteuerung das K.O.-Kriterium, egal wie andere zu dem Thema stehen.

Umso mehr war ich über den Beitrag von Harald erfreut. Auch ich würde mich also sehr über eine entsprechendes "Flag" freuen, da ein manuelles Ändern des Bausteins m.E. keine dauerhaft gute Lösung wäre. Du hättest dann (wenigstens) einen glücklichen Anwender mehr ...


Gruß
Hartmut

[HaraldP]

Hallo,

Auf dem Aktor habe ich zwei Gruppenadressen. Eine

Da muss ich korrigieren. Ich habe sowohl Aktoren mit 2 Gruppenadressen, als auch solche mit einer. Beide funktionieren identisch.

@Marc
Genauigkeitsprobleme habe ich bisher nicht bemerkt, aber das ist sicher ein Argument. Ein Parameter für Weiterleiten Ja/Nein wäre sicher das beste, vor allem in Hinblick auf neue Versionen.

Gruß,
Harald

[MarcNaroska]

Hallo HaraldP!

Das mit dem Flag kann ich ja mal auf die "Wunschliste" setzen.
Das Problem mit dem parallel Ansteuern (direkt und über 11721) liegt ja nur darin, dass die Genauigkeit der Positionierung darunter leidet, da direkte Befehle schneller aufgeführt werden als über den HS...

[MarcNaroska]

Hallo Goeran!

Um ALLE Bewegungen zu sperren, kannst du E31 und E32 im Baustein 11721 benutzen. Wenn E31=1 oder E31=2, dann werden keine Befehle mehr gesendet.
Die Sperre müsstest du dann über eine Logik entsprechend ein- bzw. ausschalten.

A10 von 11721 muss mit E6 von 11722 vebunden werden. A12 ist nur eine Statusrückmeldung...
Sobald die Sperre wieder aufgehoben ist, sollten manuelle Befehle wieder funktionieren. Es gibt keine Verzögerung bei Aufhebung der Sperre.

Für die Bestimmung des Status hell/dunkel habe ich mir einen kleinen Baustein gebastelt, der sicherstellt, dass nur was gesendet wird, wenn der Status sich ändert. Außerdem sorge ich in diesem Baustein dafür, dass die Beschattung erst 5 Sekunden nach hell freigegeben wird bzw. dass 5 Sekunden vor dunkel die Beschattung beendet wird und dass ein Statuswechsel erst dann gesendet wird, wenn der Status eine gewisse Zeit anliegt:

5000|"Naroska\dunkel&Beschattung (V1.0)"|0|5|"akt. Helligkeit"|"Hell morgens hoch"|"Hell abends runter"|"Verzögerung (sek)"|"Freigabe"|2|"dunkel"|"Freigabe Beschattung"
5001|5|2|2|1|15002|1|0|0
5002|2|100|0
5002|3|15|0
5002|4|60|0
5002|5|0|0
5003|1|0|0
5004|1|0|0|2|0
5004|2|0|0|2|0
5012|1|"EI or (EN[5]==0)"|""|""|0|0|0|0
5012|1|"OC[1] and (AN[1]!=ON[1])"|"ON[1]"|""|1|0|0|0
5012|1|"OC[2] and (AN[2]!=ON[2])"|"ON[2]"|""|2|0|0|0
5012|1|"OC[1] or OC[2]"|""|""|0|0|0|0
5012|0|""|"EN[4]"|""|0|0|1|0
5012|0|"SN[1]<1"|"1"|""|0|0|1|0
5012|0|"EN[1]>=EN[2]"|"0"|"int(SN[1])"|0|1|0|0
5012|1|"EN[1]>=EN[2]"|"1"|"int(SN[1])+5"|0|2|0|0
5012|0|"EN[1]<=EN[3]"|"0"|"int(SN[1])"|0|2|0|0
5012|1|"EN[1]<=EN[3]"|"1"|"int(SN[1])+5"|0|1|0|0

[HaraldP]

Hallo,

Hallo,

Hhmmm...., das klingt interessant. Hat das irgendwelche anderweitigen Nebeneffekte?

Dann hast Du auf den Aktoren auch nur eine GA, richtig? Nicht wie DaniSahne zwei?

Nebeneffekte sind mir keine bekannt. Auf dem Aktor habe ich zwei Gruppenadressen. Eine direkt von Taster, die andere von Marc's Baustein aus dem HS. Wenn der Taster aber einen Langzeit- oder Kurzzeitbefehl sendet, wird dieser direkt an den Aktor gesendet und der HS hört quasi nur mit und aktualisiert damit Daten wie z.B. für die aktuelle Position. Vorteil dabei ist, dass die Bedienung über die Taster auch ohne HS unverändert funktioniert.

Gruß,
Harald

[goeran]

Hallo Marc,

ich haette evtl. noch einen Erweiterungsvorschlag fuer Deinen Baustein "Rolladensteuerung 11721".

Im letzten Winter hatte ich zweimal ziemliches Pech mit zugefrorenen Rollaeden. Wer schon mal versucht hat, vereiste geschlossenen Rollaeden hoch zu fahren, weiss vielleicht wovon ich spreche. Das Ding hat sich komplett verwickelt und den Kasten und die seitlichen Fuehrungsschienen beschaedigt. Die Lamellen waren in der Fuehrung festgefroren oder einfach ganz zusammengefroren und konnten so beim Hochfahren nicht auseinandergezogen werden. Dann entstehen beim Aufwickeln eine wesentlich groessere Rolle und ganz unangenehme Geraeusche....

Wie liesse sich denn eine Frostsicherung nach den Bedingungen "wenn es in den letzten drei Stunden geregnet/geschneit hat, die Rollade geschlossen ist und die Temperatur unter zwei Grad gefallen ist" oder "wenn es friert und es zu regnen/scheien beginnt und die Rollade geschlossen ist" realisieren?

Damit meine ich nicht nur die Automatikfunktionen, sondern auch die eventuellen manuellen Fahrbefehle.

Natuerlich sollten die Rollaeden jedoch bei "trockenem" Frost fahren koennen.

Liesse sich das in den Baustein integrieren oder sollte/kann man das mit zusaetzlicher Logik machen? Wenn ich an E1 eine Sperre bzw. Sicherungslogik andocke, dann verhindere ich ja nur die automatischen Fahrbefehle, nicht die manuellen.

Hat jemand eine elegante Idee?

[goeran]

Hallo,

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:

Hhmmm...., das klingt interessant. Hat das irgendwelche anderweitigen Nebeneffekte?

Dann hast Du auf den Aktoren auch nur eine GA, richtig? Nicht wie DaniSahne zwei?

[HaraldP]

Hallo zusammen,

ich verwende auch den Baustein von Marc, wollte aber die Gruppenadressen weiterhin direkt an die Aktoren senden. Das geht auch ohne Probleme, wenn man folgende 2 Zeilen in der Logik auskommentiert:

### neue Position berechnen wenn Kurzzeit oder Langzeit in andere Richtung oder neue Position oder Positionierung beendet
### 5012|0|"(OC[4]==0) and (OC[5]==0) and (SN[6]!=-1) and ((EC[1] and (EN[1]!=SN[8])) or EC[2] or EC[6] or OC[3])"|"EN[2]"|""|3|0|0|0 # Kurzzeit weiterleiten

### Verhalten bei Langzeitbefehl
### 5012|0|"(OC[4]==0) and (OC[5]==0) and EC[1]"|"EN[1]"|""|2|0|0|0 # Langzeit weiterleiten

Wäre zwar eleganter, das Weiterleiten über ein Flag zu steuern, aber auskommentieren ging schneller. :-)

Gruß,
Harald

[goeran]

Hallo Marc,

ich habe in der letzten Nacht nun die ganzen Aktoren umadressiert und die komplette Bedienung ueber Deine Bausteine realisiert. Das funktioniert alles auch sehr gut. Prima Sache, das. Danke fuer Deine Programmierarbeit!

Zwei oder drei Fragen zu der Sperre habe ich noch.

1. Muessen die Ausgaenge 10 und 12 des 11721 parallel mit dem Eingang 6 des 11722 verbunden werden, wenn man moechte, dass die Rollade nach Beenedigung der Sperrsituation ihre vorherige Position wieder anfaehrt? Oder speichert der Baustein das intern und es wuerde A10 auf E6 reichen? (Ist ja fast wie beim Schach hier )

2. Kann es sein, dass nach Beendigung der Sperrsituation eine gewisse Zeit verstreichen muss, bevor wieder manuelle Befehle ueber E22 und E23 angenommen werden? Wenn ja, kann man dieser Zeit beeinflussen?

Meine Markiese wuerde ich bei Regen oder Wind ueber 7m/s gern sofort automatisch einfahren und dann eingefahren lassen. Man soll sie erst wieder manuell ausfahren koennen, wenn obige Bedingung fuer eine Stunde nicht mehr vorlag.

Dafuer wuerde ich mich ueber einen Tipp freuen (vielleicht mit Grafik?), wie ich es verhindere, dass so Zustaende wie "warm/sonnig" oder "nass/windig" flattern. Ich habe das mit zwei Watchdogs und einem RS-FlipFlop versucht (siehe meine Grafik), bin damit aber nicht so sehr zufrieden, weil ich den Eindruck habe, dass das nicht so ganz zuverlaessig funktioniert oder taeusche ich mich da?

Ich habe schon was von "Schwellwert mit Hysterese" gelesen, kann dem aber nicht wirklich folgen. Deswegen meine Frage nach einer Grafik. Sowas hilft immer den "Groschen fallen zu lassen".