Vectorworks 2025 - Verfügbare Gesamtbreite für Fensterflügel

[szell]

Hi Zusammen.

 

Die Dokumentation für die verfügbare Gesamtbreite der Fenster ist leider sehr dürftig und für mich unverständlich. Das Beispielfenster ist nur mit 'glatten' Werten definiert (siehe Screenshots). Egal welche Einstellungen vorgenommen werden es bleiben immer Restwerte von ,21 oder ähnliches übrig. Wie genau ist es möglich den Restwert zu beeinflussen? Wie wird dieser ermittelt? Und wie genau werden die Flügelbreiten gemessen? Gibt es hierzu eine Dokumentation, abgesehen von der VWX Hilfe (die diese Fragen nicht beantwortet)?

Bzw versteht irgendjemand wie das Programm diese Werte errechnet? Für mich ists absolut nicht verständlich und nicht nachvollziehbar.

Feste oder gerasterte Flügelbreiten dürften doch nicht so ungewöhnlich sein.

[berndpaul]

ja, das ist ganz großer mist. versuche mal ein fenster mit x festverglasungen in der gleichen breite zu bauen, das geht nur, wenn der äußere blendrahmen halb so breit ist wie der rahmen zwischen zwei festverglasungen. setzt man dann in einen bereich einen flügel ein, werden die vertikalen rahmen (pfosten darf ich hier ja nicht sagen) willkürlich verschoben. es ist nicht zu kontrollieren

 

Bearbeitet 4. August von berndpaul

[Stefan Bender]

Sehr geehrter @szell, die Berechnung der Flügelbreiten ist leider ein sehr komplexes Thema. Es gibt sehr viele Parameter (Laibung, Rahmengesamtmass Breite, Rahmenbreiten, Flügelrahmenbreiten, eventuelle Mittelpfosten, verschiedene Übergangsvarianten zwischen verschiedenen Flügeltypen (festverglast/drehkipp...), die hineinspielen. Um wichtige Grundwerte des Fensters wie etwa die Gesamtbreite und die Werte im Reiter "Rahmenwerte" einhalten zu können, ist es zwingend nötig, mindestens einem Fensterflügel eine variable Breite zu belassen. Die Berechnung der Flügel geht zunächst von der Rahmengesamtbreite aus und berücksichtigt die eingegebenen Rahmenbreiten/Überstände/Flügelanzahlen usw. Danach wird ermittelt, wieviel Platz für die Flügel zur Verfügung steht und ob dieser ausreicht (wäre zB nicht der Fall, wenn eine manuell eingegebene Flügelbreite größer als das Rahmengesamtmaß des Fensters wäre). Die eingegebenen Flügelbreiten werden von der zur Verfügung stehenden Breite abgezogen und gleichmäßig auf die Flügel mit automatischen Breiten verteilt. Der "Restwert für automatische Flügelbreiten" ist <Zur Verfügung stehende Breite> - <Summe der eingegebenen Flügelbreiten>. Eine Dokumentation gibt es dazu nicht.

[szell]

Hallo Herr Bender, danke für die Antwort. Allerdings ist diese wenig zufriedenstellend. Auch wenn das Thema komplex ist, kann es doch nicht sein, dass die einzelnen Flügel, wie berndpaul es treffend forumliert hat 'nicht zu kontrollieren' sind. Gibt es ein Workaround? Bzw zumindest eine Angabe an welcher Stelle schlußendlich die Flügelbreite gemessen wird? Der einzig verlässliche Weg ist mE das Fenster mit Symbolen zu erstellen. Was in der Auswertung am Ende unnötig kompliziert ist.

[Stefan Bender]

Die Flügelbreiten werden inklusive des Rahmens/Flügelrahmens gemessen, nicht an der Flügelrahmeninnenseite. Bei Übergängen zwischen unterschiedlichen Flügeltypen ist es noch komplizierter. @Michael Gass Was meinst Du dazu? Hast Du Ideen für ein anderes Konzept der Flügelbreiten?

Bearbeitet 4. August von Stefan Bender

[Stefan Bender]

Die Flügel sind durchaus zu kontrollieren, wenn die Flügelbreiten manuell eingegeben werden. Ich muss aber zugeben, dass das eine üble Fummelei werden kann.

[berndpaul]

flügelbreite wäre sinnvoll von mitte blendrahmen bis mitte blendrahmen, egal ob in diesen feldern bewegliche flügel vorhanden sind oder nicht. ähnlich pfosten-riegel-system. für das gesamtmaß könnte man eine zugabe definieren die die äußeren blendrahmenbreiten an den anschlägen steuert. alle flügelbreiten + die zugaben rechts und links ergeben das gesamtmaß.

 

Bearbeitet 4. August von berndpaul

[Stefan Bender]

Vielen Dank für die Anregungen! @Michael Gass Was meinst Du dazu?

[szell]

vor 8 Stunden schrieb berndpaul:

flügelbreite wäre sinnvoll von mitte blendrahmen bis mitte blendrahmen, egal ob in diesen feldern bewegliche flügel vorhanden sind oder nicht. ähnlich pfosten-riegel-system. für das gesamtmaß könnte man eine zugabe definieren die die äußeren blendrahmenbreiten an den anschlägen steuert. alle flügelbreiten + die zugaben rechts und links ergeben das gesamtmaß.

 

Wenn es so funktionieren würde, wäre das top! Und das manuelle korrigieren obskurer, willkürlich wirkender Werte endlich nicht mehr nötig!

[Stefan Bender]

@Michael Gass Was hältst Du davon? Aber auch bei diesem Vorschlag würden die Flügel unter Umständen unterschiedlich breit erscheinen, wenn die Rahmenbreiten rechts und links eines Flügels unterschiedlich sind.

[Stefan Bender]

Auch wenn wir die Definitionen für die Flügelbreiten ändern würden, wird trotzdem das Problem bleiben, dass mindestens eine Flügelbreite berechnet werden muss, um in die gesamte zur Verfügung stehende Breite zu passen. Die äußeren Rahmengrenzen werden durch die Fensterbreite vorgegeben, und die (Flügel)rahmenbreiten und Überlappungen usw. sind ebenfalls eingegebene Werte, da gibt es keinen Spielraum.

[szell]

vor 41 Minuten schrieb Stefan Bender:

Auch wenn wir die Definitionen für die Flügelbreiten ändern würden, wird trotzdem das Problem bleiben, dass mindestens eine Flügelbreite berechnet werden muss, um in die gesamte zur Verfügung stehende Breite zu passen. Die äußeren Rahmengrenzen werden durch die Fensterbreite vorgegeben, und die (Flügel)rahmenbreiten und Überlappungen usw. sind ebenfalls eingegebene Werte, da gibt es keinen Spielraum.

Das Problem ist ja auch nicht die automatische Breite eines Flügels, sondern die grundsätzliche Arbeitsweise. Wenn beispielsweise eine Gesamtbreite von 7,50m Fertigmaß für das Fenster gewählt wird. Ein 30cm Pfosten ergänzt wird und das Fenstertool dann (bei einer Laibung ohne Einzug etc) eine verfügbare Restbreite für Flügel von ca. 7,21m anzeigt, ists an der Stelle schon fragwürdig. Und ein manuelles Eingeben der Breiten kann nur Abhilfe schaffen, wenn nachvollziehbar ist, auf was sich das Maß bezieht - egal obs nun entsprechend des Beispiels ist, oder eine andere Methode herangezogen wird. Aus meiner Sicht ist das Fenstertool aktuell brauchbar, solang ein Fenster mit Flügelanzahl x und einer Gesamtbreite gebraucht wird. Sobald es fixe, verlässlich steuerbare Flügelbreiten braucht, ist es im Workflow nicht mehr wirtschaftlich nutzbar. 

[Stefan Bender]

Wen sich Flügel benachbarte überlappen (zB ein festverglaster und ein Dreh-/Kippflügel), kann es theoretisch vorkommen, dass die Summe aller Flügelbreiten größer als das Rahmengesamtmaß ist. Ich verstehe aber schon, dass die gegenwärtige Situation nicht optimal ist.

[berndpaul]

vor 1 Stunde schrieb Stefan Bender:

Auch wenn wir die Definitionen für die Flügelbreiten ändern würden, wird trotzdem das Problem bleiben, dass mindestens eine Flügelbreite berechnet werden muss, um in die gesamte zur Verfügung stehende Breite zu passen. Die äußeren Rahmengrenzen werden durch die Fensterbreite vorgegeben, und die (Flügel)rahmenbreiten und Überlappungen usw. sind ebenfalls eingegebene Werte, da gibt es keinen Spielraum.

nein, das wäre kein problem. flügelbreite ist immer mitte blendrahmen bis mitte blendrahmen und fix. die gesamte fensterbreite beträgt dann immer flügelbreite(n) + 1 x blendrahmenbreite + 2 x seitliche zugabe. wie weit flügelrahmen die blendrahmen überlappen ist im grunde uninteressant. grundsätzlich müsste man über die logig der "pfosten" nachdenken. für mich wären diese überflüssig weil teil des (aus mehreren felder bestehenden) blendrahmens. man kann ihn auch beibehalten, müsste aber festverglasung neben pfosten ermöglichen.

[Stefan Bender]

Leider ist es in Wirklichkeit viel komplizierter, da bei Fenstern mit deutlich mehr als zwei Flügeln sehr viele unterschiedliche Fälle auftreten können, wie Übergänge zwischen festverglasten/nicht festverglasten oder zwischen zwei Dreh-/Kippflügeln ohne Blendrahmen dazwischen (Flügelrahmen trifft auf Flügelrahmen). Es ist möglich, dass die derzeit berechnete "Zur Verefügung stehende Breite" in manchen komplexen Fällen kein korrektes Ergebnis liefert, ich werde das bei Gelegenheit überprüfen. Eine Änderung der Definition der Flügelbreite muss aber von unseren Fachingenieuren kommen. Selbst wenn irgendwann eine solche Änderung kommen sollte, können wir bestehende Fenster nicht mit einem neuen Algorithmus berechnen lassen, weil sich dann deren Aussehen ändern würde. Stattdessen müßten dann zwei Berechnungssysteme nebeneinander mit Umschaltmöglichkeiten für die Benutzer existieren.

[Stefan Bender]

Die (automatischen) Flügelbreiten können sich auch ändern, wenn das Fenster in eine (andere) Wand eingefügt wird, da dann die Laibungseinstellungen das Rahmengesamtmaß und damit auch die Breite der Flügel beeinflussen. In vielen Situationen (Stil bearbeiten, Werkzeugeinstellungen bearbeiten...) stehen im Dialog keine realen Laibungseinstellungen zur Verfügung. Für die Berechnung der "Zur Verfügung stehenden Breite" werden deshalb in manchen (offenbar fehlerhafterweise in zu vielen) Situationen angenommene Laibungswerte verwendet, was zu Diskrepanzen führen kann. 

[szell]

vor 21 Minuten schrieb Stefan Bender:

Die (automatischen) Flügelbreiten können sich auch ändern, wenn das Fenster in eine (andere) Wand eingefügt wird, da dann die Laibungseinstellungen das Rahmengesamtmaß und damit auch die Breite der Flügel beeinflussen. In vielen Situationen (Stil bearbeiten, Werkzeugeinstellungen bearbeiten...) stehen im Dialog keine realen Laibungseinstellungen zur Verfügung. Für die Berechnung der "Zur Verfügung stehenden Breite" werden deshalb in manchen (offenbar fehlerhafterweise in zu vielen) Situationen angenommene Laibungswerte verwendet, was zu Diskrepanzen führen kann. 

Es wäre auf jeden Fall wünschenswert, wenn in kommenden Versionen an dieser Stelle nachgebessert wird.

[Stefan Bender]

Ich bin gerade dabei, mir das im Detail anzuschauen und ggf. offensichtliche Fehler zu korrigieren. Konkrete Fehlermeldungen wegen falscher Flügelbreiten liegen uns aber meines Wissens nach nicht vor.

[Stefan Bender]

Hier noch ein paar kurze Infos zur Berechnung der Flügelbreiten:

Die für alle Flügel zusammen verfügbare Breite ist die Differenz zwischen Beginn des ersten und Ende des letzten Flügels.

Ausnahme: Sind Mittelpfosten zwischen zwei Dreh-/Kippflügeln eingefügt, 
          wird davon noch für jeden Mittelpfosten der Wert 
          <Breite Mittelpfosten - 2*Überlappung Mittelpfosten/Flügelrahmen> 
          abgezogen.

Für die automatischen Flügelbreiten bleibt der Wert <Gesamte verfügbare Breite> - <Summe aller eingegebenen Flügelbreiten> übrig.

Beginn des ersten / letzten Flügels:

Außenkante Flügelrahmen (Dreh-/Kipp) bzw. Außenkante Rahmen (festverglast)

Übergang festverglast/nicht festverglast: Flügelbreite beginnt / Endet bei Mitte der Überlappung

Übergang Dreh/Kipp zu Dreh/Kipp: Flügelbreite beginnt/endet an Grenze der Flügelrahmen

Übergang Festverglast zu Festverglast: Flügelbreite beginnt/endet an Grenze der Flügelrahmen

Übergang Mittelpfosten / Drehkippflügel: Flügelbreite beginnt/endet an Grenze der Flügelrahmen

[Stefan Bender]

Die beanstandeten Unstimmigkeiten mit der gesamten zur Verfügung stehenden Breite traten vermutlich bei der Bearbeitung von Objektstilen, Werkzeugeinstellungen oder nicht in Wände eingefügten Fenstern auf. In diesen Fällen existieren keine Laibungseinstellungen, so dass für die Berechnung der Flügelbreiten im Dialog bestimmte vorgegebene Laibungseinstellungen angenommen wurden. Für Vectorworks 2026 werden diese Laibungseinstellungen vereinfacht, so dass weniger Unstimmigkeiten auftreten sollten. Allerdings können sich die automatischen Breiten trotzdem ändern, wenn das Fenster anschließend in eine reale Wand mit anderen Laibungseinstellungen eingefügt wird und sich das Rahmengesamtmaß ändert, weil die Fensterbreite über Rohmaß oder Fertigmaß bestimmt wird.