Probleme mit Absoluter Position bei Jalousieaktor MDT JAL-0810.02

[gogo20012002]

Mit etwas Logik auch recht schnell hinzubekommen. Habe das mit dem Homeserver recht einfach gelöst

Kalibriert.JPG

[cybersmart]

Ok, du hast dir einfach für verschiedene Werte des Aktors "kompensierte" Ausgangswerte definiert.
Das löst halt leider nicht das Problem, dass der Aktor, wenn er von Ausgangsposition "oben" z.B. 50% anfährt den Rollo an einer anderen Stelle stoppt als wenn 50% von Ausgangsposition "unten" angefahren wird.

Wenn 50% nie gleich 50% sind ist das irgendwie schwierig mit dem Kompensieren.

Mal sehen wie ich das bei mir noch etwas verbessern kann, jeder Tipp ist hilfreich, werde mich auf jeden Fall auch an einer Kompensationslogik im X1 mal versuchen.

[hjk]

Das löst halt leider nicht das Problem, dass der Aktor, wenn er von Ausgangsposition "oben" z.B. 50% anfährt den Rollo an einer anderen Stelle stoppt als wenn 50% von Ausgangsposition "unten" angefahren wird.

Wenn 50% nie gleich 50% sind ist das irgendwie schwierig mit dem Kompensieren.

Dann stimmen die eingestellten Zeiten nicht. Normal sind die Positionen gleich.

[gogo20012002]

Ok, du hast dir einfach für verschiedene Werte des Aktors "kompensierte" Ausgangswerte definiert.
Das löst halt leider nicht das Problem, dass der Aktor, wenn er von Ausgangsposition "oben" z.B. 50% anfährt den Rollo an einer anderen Stelle stoppt als wenn 50% von Ausgangsposition "unten" angefahren wird.

Wenn 50% nie gleich 50% sind ist das irgendwie schwierig mit dem Kompensieren.

Mal sehen wie ich das bei mir noch etwas verbessern kann, jeder Tipp ist hilfreich, werde mich auf jeden Fall auch an einer Kompensationslogik im X1 mal versuchen.

Doch, bei mir stimmen die. Wie hjk schon sagte, werden dann bei dir die Zeiten nicht stimmen.
Bei mir ist es egal ob ich die von oben oder unten anfahre.
Die Werte für die Kurve kannst du ja ggfs. bei dir auch anpassen. Ich habe die Position 25/50/75/95 manuell angefahren und mir dann die Werte notiert die der Aktor mir als Position lieferte. Also z.B. 50=36 und dann in die Anpassung eingetragen. Alle anderen Werte dazwischen werden dann linearisiert.

PS: 95 ist bei mir immer das die Rollos auf Schlitz sind.

[cybersmart]

Also mehr als Stoppuhr und Zeit messen und eintragen kann ich bzgl. der Werte ja nicht machen ...

Ich werde das jetzt an anderen Rollos nochmal verproben. Das ist schon eigenartig.

[Beleuchtfix]

Also mehr als Stoppuhr und Zeit messen und eintragen kann ich bzgl. der Werte ja nicht machen ....

Doch, Anfahr- und Nachlaufzeiten können auch das Bild verfälschen. Ist vielleicht Auf und Ab vertauscht, so dass der Aktor mit der jeweils falschen Zeit rechnet?

Ich würde jetzt einmal komplette Fahrten messen in einem durch und bei 50% die Zwischenzeit stoppen, und dann das ganze in die andere Richtung. Da solltest du eigentlich innerhalb 1 Sekunde rechnerisch richtig liegen. Oder dein Rollo hat eine extrem unterschiedliche Drehgeschwindigkeit im Motor zwischen Anfang und Ende.
Viel Erfolg, Florian

[wendland]

cybersmart Konntest du das Problem noch lösen ?

Ich habe irgendwie das selbe Thema !

Wenn ich die real gemessene Zeiten eingebe, z.b AUF 27 Sek und AB 26 Sek und ich dann auf 50% fahren, ist der Rolladen ca 70% geschlossen.

Das kann es ja nicht sein. Ich muss ca. 20 Sek für AB und 21 für AUF eingeben !?!

[Saeldric]

Wenn die Positionsbestimmung über die Fahrzeit, also die Betriebszeit des Motors, ermittelt wird, kann 50% ja niemals die Mitte des Fensters sein. Alleine für das "Schliessen" und "Öffnen" der Spalte zwischen den Elementen des Rolladen werden ja schon x% Fahrzeit benötigt. Diese müssten immer gegengerechnet werden.
Wenn ich möchte das der Rolladen auf eine bestimmten Höhe gefahren wird, fahre ich ihn manuell dorthin, notiere mir die angezeigten % vom Taster/Visu/etc., und trage diesen Wert in die Applikation ein. Und wenn Höhe Fenstermitte dann 69% sind, ist doch egal. Der Rolladen steht da wo ich es will.
Funktioniert perfekt, egal ob er von unten, oder oben die Position anfährt.

[Beleuchtfix]

Und wenn Höhe Fenstermitte dann 69% sind, ist doch egal

es ist eher 29%, aber der zweite Teil deines Satzes ist der wichtige, und der ist absolut korrekt

[Saeldric]

Ich glaube das kommt auf die Fensterhöhe an. Bei mir sind es die 69% für fast mittig.

[Beleuchtfix]

<ot>Komisch, der Außenumfang der aufgewickelten Rolle ist doch größer als innen, und bei gleicher Drehgeschwindigkeit müsste doch anfänglich mehr abgewickelt werden, egal ob das Fenster 50 cm oder 5 m hoch ist. Oder ist bei dir offen = 100%?</ot>
Gruß Florian

[Saeldric]

Nein, 100% sind komplett geschlossen. 0% ist komplett offen. Die 69% ist die Höhe der zu erreichenden Position und eher zufällig fast mittig.
Das fast mittig bezieht sich auch auf die Glasfläche. Was ja in der Regel der optische Bezugspunkt für eine Rollladenposition ist. Der Fahrweg des Rolladen, auf den sich die Prozentangaben beziehen, ist natürlich länger (Glasfläche plus Flügelrahmen plus Blendrahmen). Was auch wieder dafür spricht das 50% fahren nie Mitte Fenster sein können.

[wendland]

Das ist einfach Schrott. Es wäre technisch ohne weiteres möglich gewesen. Werde mal morgen MDT dazu löchern !

[cybersmart]

Also da es ja „nur“ eine Fahrzeitmessung ist habe ich mich einfach dran gewöhnt, dass man damit niemals bei 50% auch die Mitte des sichtbaren Fensterbereichs erreicht. Blöd ist es aber schon, da es ja auch nicht irgendwie einheitlich „falsch“ ist sondern von der Fensterhöhe massgeblich mit abhängt.

Gehe auch davon aus die Aktorenhersteller könnten das besser lösen indem bei der Einrichtung noch die Fahrzeit bis 50% (Fensternitte)abgefragt wird und man dann den „Stand im Fenster“ besser errechnen kann.
Man kann sich auch für jedes Fenster aber ne Logik basteln die dann „umrechnet“ und am Display andere Werte ausgibt, hab mir das aber nicht angetan bisher.

Wenn jemand ne schicke Lösung hat aber immer her damit …

VG
Uwe

[wendland]

Also ist hab heute mit MDT telefoniert. Problem ist den Entwicklern bekannt. Es müssen sich einfach mehr Leute melden, dass was passiert. Sonst wird es eben nicht priorisiert.