Probleme mit DV WRC6 und FROLL

[cmjay]

Ich persönlich habe ein Unterprogramm entwickelt, dass die Sollwerte an den Aktor so vorher manipuliert, dass die erreichten Höhen ziemlich genau der Vorgabe entsprechen. Dabei müssen aber quadratische Gleichungen gelöst werden ....

"Scheiss Spatzen!" murmelte @Matsch und ging in den Keller um die Kanonen zu holen ...

[Xel66]

Ich persönlich habe ein Unterprogramm entwickelt...

So kann man es machen. Der Rest der Anwender spart sich das und fährt den Rollladen manuell dort hin, wo man ihn haben will, liest die in der WebUI angezeigte "Behanghöhe" aka Laufzeit ab und benutzt diese in den Steuerungen. Braucht man das für irgendwelche Visualisierungen, dann muss man eben die Behanghöhe dort rechnerisch korrigieren. Ist sicher der einfachere Weg.

Mir sind die angezeigten Behanghöhen völlig egal, denn ich sehe sie nirgends. Ich sehe nur die automatisch gesteuerten Rollladen, deren verschiedene Sollwertert ich einmalig in den Automatiksteuerung festgelegt habe. Darum brauche ich mich auch nicht an der technisch bedingt "falschen" Behanghöhenanzeige zu stören.

Gruß Xel66

[Matsch]

"Scheiss Spatzen!" murmelte @Matsch und ging in den Keller um die Kanonen zu holen ...

Keine Ahnung vom Anwendungsfall, aber darüber ein Urteil fällen! Ok, das ist der Trend der Zeit.

Ich habe den Anwendungsfall hier schon mehrmals erklärt:
Zur Beschattung führe ich den Rollladen so, dass die Schattengrenze im Raum immer an der gleichen Raumtiefe liegt (Schutz des Monitors oder von Orchideen vor praller Sonne). Deshalb führe ich den Rollladen dem Sonnenstand nach. Das geht aber nur, wenn die Unterkante des Behangs immer auch auf der wirklichen Höhe steht, die vorher berechnet wurde.
Das ist halt für mich auch smart.

So, und nun kannst du deine Knallerbse fallen lassen
Ich weiß, man kann auch mit wenig glücklich sein.

[cmjay]

Keine Ahnung vom Anwendungsfall, aber darüber ein Urteil fällen! Ok, das ist der Trend der Zeit.
So, und nun kannst du deine Knallerbse fallen lassen

Da muss ich mit meinem ironischen Kommentar wohl unbewußt einen wunden Punkt getroffen haben ...

[Matsch]

Das entschuldigt natürlich alles:

Irrung.jpg (5.17 KiB) 245 mal betrachtet

[Patt]

Sprich 50% sollte nach meinem Verständnis in der Mitte sein. ist es aber nicht.

Und? Warum ist das so?

Weil es prinzipbedingt eine Zeitsteuerung ist und nach der halben Zeit nicht die halbe Strecke zurückgelegt wird!
Das liegt zum einen am Zwischenraumspiel der Lamellen und im wesentlichen am sich permanent ändernden Wickeldurchmesser der sich konstant drehenden Achse.

Anscheinend stört das die allerwenigsten hier (leite ich aus bereits geführten Diskussionen ab).

Ich persönlich habe ein Unterprogramm entwickelt, dass die Sollwerte an den Aktor so vorher manipuliert, dass die erreichten Höhen ziemlich genau der Vorgabe entsprechen. Dabei müssen aber quadratische Gleichungen gelöst werden ....

Es sind ja aber keine Jalousien sondern Markisen. oder verstehe ich das jetzt nur falsch?
Der sich ändernde Winkeldurchmesser ist ja aber dennoch bei jeder Fahrt je nach Position immer der gleiche. Ich habe jetzt noch nicht nachgemessen, aber wenn es 40 sek dauert bis die Markise geschlossen ist, dann ist diese nach 20s eigentlich schon in der MItte, da die Laufgeschwindigkeit sich meines Erachtens nicht ändert. Lasse mich aber gerne von Euch Profis korrigieren, denn dafür bin ich ja hier

Klar es lässt sich je nach Anwendungsfall darüber streiten (diskutieren) ob man das braucht oder nicht aber mir gefällt es schon, wenn ich bspw. per App aus der Ferne sagen kann, fahre in die oder die Position x % und ich mich dann darauf verlassen kann dass es auch so ist.

Daher würde mich die technischen Möglichkeiten durchaus interessieren wie du das gelöst hast.
Wenn man gerne schießt und halt nur ne Kanone da ist, dann nehm ich auch diese

[Matsch]

Der Wickeldurchmesser bleibt ja nicht der gleiche, auch nicht bei Markisen (wobei bei denen die Änderungen nicht so stark ins Gewicht fallen wie bei Rollladenbehängen). Bei voll aufgewickeltem Behang und maximalem Wickeldurchmesser ist ja der zurückgelegte Weg pro Zeiteinheit größer als bei voll abgewickeltem und geringem Wickeldurchmesser ( u = Pi * d ).
Die Laufgeschwindigkeit ändert sich also doch, umso mehr, je dicker der Behang ist.
50% der Fahrzeit ist nicht identisch mit der Hälfte des zurückgelegten Wegs.

Wenn die Gesamtfahrzeit nicht korrekt eingetragen ist, dann stimmt natürlich auch der 50%-Wert nicht, kann ich aber bei dir ja nicht beurteilen.

Daher würde mich die technischen Möglichkeiten durchaus interessieren wie du das gelöst hast.

Da bist du aber wahrscheinlich der einzige, der das nicht lächerlich findet. Bei wirklichem Interesse würde ich mein Projekt dazu schon mal vorstellen. Das ist aber nicht auf einer Seite erläutert und der Aufwand muß sich dann schon lohnen.

[Patt]

Daher würde mich die technischen Möglichkeiten durchaus interessieren wie du das gelöst hast.

Da bist du aber wahrscheinlich der einzige, der das nicht lächerlich findet. Bei wirklichem Interesse würde ich mein Projekt dazu schon mal vorstellen. Das ist aber nicht auf einer Seite erläutert und der Aufwand muß sich dann schon lohnen.

Ich kann nicht für die anderen sprechen, aber ich habe definitiv Interesse daran. Ich glaube auch, dass wenn du das als Beitrag veröffentlichst, nicht nur ich den Beitrag interessant fänden

Viele Ideen was man damit sonst noch anstellen kann, ergeben sich für viele ja erst dann wenn Sie davon erfahren haben.

Grüße

[cmjay]

Da bist du aber wahrscheinlich der einzige, der das nicht lächerlich findet.

Häng das Thema doch bitte ein paar Sprossen tiefer. Hier hat doch niemand deinen Ansatz für lächerlich befunden. Meine Auffassung - und scheinbar auch die einiger anderer Foristen - ist lediglich, dass man das Problem auch auf einfachere Weise angehen kann. Keine perfekte Lösung, aber für die meisten Nutzer ihren einfacheren Ansprüchen genügend.
Alles eine Frage des Aufwandes, den man bereit ist zu treiben. Da kommt dann das legendäre Paretoprinzip (80/20-Regel) zum Tragen.
https://de.wikipedia.org/wiki/Paretoprinzip

Bei wirklichem Interesse würde ich mein Projekt dazu schon mal vorstellen. Das ist aber nicht auf einer Seite erläutert und der Aufwand muß sich dann schon lohnen.

Auch wenn ich selbst nicht beabsichtige, deine aufwändige, perfekte Behanghöhenkontolle bei mir zu implementieren, wäre ich durchaus an deiner technischen Umsetzung interessiert.

Viele Ideen was man damit sonst noch anstellen kann, ergeben sich für viele ja erst dann wenn Sie davon erfahren haben.

So ist es. Man weiss ja nie, ob man es nicht irgendwann nochmal brauchen kann ...

[Xel66]

Nun ja. Auch die prozentuale reale Behanghöhe bzw. deren Sollwert bei unterschiedlicher Elevation muss berechnet werden. Somit könnte man in diese Berechnung auch gleich die Umrechnung auf den sich durch die zeitbasierten Behanghöhen der CCU und der sich daraus ergebenden Bedeckung des Fensters einbeziehen. Vorteil der Lösung. Man würde direkt mit den von der CCU verarbeiteten Werten arbeiten. Und würde sich die Hin- und Herrechnerei sparen. Rechnen muss man sowieso.

Und ob z.B andere Apps mit korrekturgerechneten Werten und ihrer Zuodnung zu den Aktoren so sauber und ohne zusätzliche Winkelzüge umgehen können, steht wieder auf einem anderen Blatt. Bei einer selbst zusammengestellten Visualisierung ist das aber weniger ein Problem.

Gruß Xel66