Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Fragen zum Baustatik-Programm


Ich hatte heute einige kleine Listen von Fragen zum Faltwerk zu beantworten: Hier die beiden "interessanteren" Antworten.

F: Wie kann ich die Grafik ausdrucken (z.B. nur die Momentenlinie)?

A: Es können grundsätzlich alle Graphiken ausgedruckt werden. Der Mechanismus mit dem das geht sind die "Navigationspunkte". Einen Naviationspunkt kann man zum Beispiel mit dem Button mit der Kamera drauf anlegen. Der Navigationspunkt speichert die aktuelle Ansicht und die momentan angezeigten Objekte, die Einstellungen aus "Optionen -> Einstellungen" sowie das angezeigte Ergebnis. Zu einem späteren Zeitpunkt kann man dann in der Dokumenten-Ansicht auf den Navigationspunkt klicken (rechte Maustaste) und den Punkt "anspringen". Man hat dann danach ein Fenster das genauso aussieht wie das Fenster zu dem Zeitpunkt, als der Navigationspunkt angelegt wurde.

Diese Navigationspunkte kann man auch ausdrucken. Wenn Sie die Ausgabesteuerung öffnen, dann finden Sie alle definierten Navigationspunkte darin wieder: Wenn Sie dann die Option zum ausdrucken einschalten, enthält der Ausdruck eine Graphik des Navigationspunktes.

Nun kann man den Ausdruck auf nur einige Elemente beschränken. Dazu wählt man die gewünschten Elemente in der Graphik aus, klickt mit der rechten Maustaste drauf, und wählt "Neues Fenster für Auswahl". Im neuen Fenster werden dann nur noch die ausgewählten Objekte angezeigt. In diesem Fenster kann man aber normal arbeiten und auch Ergebnisse anzeigen  - und von diesem Fenster kann man auch Navigationspunkte anlegen, die dann später ausgedruckt werden können.

F: Wie kann man am einfachsten Rohre definiere? Per "Sebst definierter Profile" ist das sehr aufwendig.

Man legt ein neues Profil an. Auf dem Dialog mit den Querschnittseigenschaften wählt man dann "Stahl -> Walzprofile 2 (Norm) -> Rohr". Daraufhin erscheint rechts eine Tabelle mit den vordefinierten Rohren. Darin scrollt man ganz nach unten und findet dort eine leere Zeile, in der man selbst das Rohr durch Eingabe von D und T definieren kann. Dieses selbst-definierte Rohr kann dann genauso benutzt werden, wie die mitgelieferten.


Erste Dokumentation für Baustatik-Makros


In diesem Beitrag hatte ich ein erstes Beispiel für ein "Baustatik" Makro vorgestellt. Der Großteil dessen, was man für ein rudimentäres Makro benötigt, wird vom Makro-Editor automatisch bereitgestellt. Soweit ist die Sache ja klar - etwas unklarer wird es dann an der Stelle, an der die Knoten erzeugt werden: Woher weiss man, das sich die Knoten im Namespace "DIE.Applications.Faltwerk.Objects.Nodes" befinden und man oben im Makro ein entsprechende "using" Statement braucht, woher weiss man das die Objekte "Node" genannt werden - und woher weiss man eigentlich, welche Objekte es sonst noch so alles gibt?

Lauter gute Fragen - hier ein paar Antworten. Der erste und einfachste - dafür aber nicht vollständige - Weg ist der hier: Sie können von hier eine Hilfe-Datei (Baustatik.chm ca. 15 MB) herunterladen, in der die erste verfügbare Dokumentation zusammengefasst ist. (Wenn der Browser fragt, ob die Datei geöffnet oder heruntergeladen werden soll: Laden Sie die herunter, und öffnen Sie sie erst lokal auf dem eigenen Rechner. Das beschleunigt die Sache, wenn Sie später nochmals reinsehen möchten.)

Es gibt nun eine etwas aktuellere Online-Variante: Dokumentation für die Programmierung mit dem Faltwerk in der Baustatik.

Dabei handelt es sich nicht um die vollständige Programmier-Dokumentation für "Baustatik" sondern nur um die erste Version davon. Enthalten sind alle Faltwerks-Objekte (die finden sich in den Namensräumen "DIE.Applications.Faltwerk.Objects.*"), sowie die Objekte, mit denen man auf Berechnugsergebnisse zugreifen kann ( "DIE.Applications.Faltwerk.Results.*" ).

Außerdem gibts ein paar interessante und hilfreiche Objekte für geometrische Operationen in "DIE.Geometry.*".

Mit dieser Hilfedatei sollte man schon relativ weit kommen. Wer noch mehr braucht, und zwar bevor wir zusätzliche Dokumentation bereitstellen können, hat aber auch dafür diverse Möglichkeiten.

Das erste Tool wäre der kostenlose Reflektor. Damit kann man sich den Inhalt von Assemblies ansehen - man braucht also bloss die installierten DLLs von "Baustatik" damit zu betrachten.

Darüber hinaus geht das ähnlich auch mit Visual C# Express, mit dem man übrigens auch Makros programmieren kann: Im wesentlichen legt man dort ein Projekt an, fügt Referenzen zu den Assemblies hinzu - und hat Zugriff auf alle Methoden und Eigenschaften der Objekte. (Zur Entwicklung von Makros mit C# Express schreibe ich zu einem späteren Zeitpunkt nochmals etwas.)


Texturen in den 3D-Ansichten


In der "Echt" und der "Parallelprojektions"-Ansicht konnte das Faltwerksprogramm "schon immer" auch Texturen verwenden. Mit Texturen kann man die graphische Darstellung "realistischer" gestalten, ungefähr so:


Allerdings war man bisher auf eine handvoll Texturen limitiert - man konnte nur die von uns mitgelieferten verwenden. Ab der nächsten Version ist das anders: Bei der Auswahlliste der Texturen gibt es dann einen zusätzlichen Eintrag namens "ExternalFile" - und darunter gibt es eine Auswahlmöglichkeit, mit der man beliebige andere Texturen auswählen kann.

Die müssen sich im Ordner "Texturen" (auf gleicher Ebene mit dem Projektordner) befinden. Im Prinzip kann man dafür beliebige Bilder in beliebigen Auflösungen und Größen oder Formaten verwenden - jeh höher die Auflösung und die Farbtiefe, um so mehr Performance kostet die Sache aber. (Die von uns mitgelieferten Texturen sind Bitmaps in TrueColor mit 128x128 Pixeln.)

Eine Bodenplatte mit Stofftier-Textur sieht dann zum Beispiel so aus: 


Makros in "Baustatik"


Die neue Baustatik-Umgebung (zur Zeit mit dem Faltwerk und dem Dachprogramm) ist vollständig programmierbar - wer also will, kann eigene "Makros" schreiben, um den Funktionsumfang zu erweitern. Die Programmiermöglichkeit geht dabei sehr weit: Man kann den eingebauten Makro-Editor verwenden (die einfachste aber am wenigsten komfortable Methode), aber auch die (kostenlosen) Express-Ausgaben der Entwicklungsumgebungen von Microsoft - bis hin zum professionellen Visual Studio.

Ich habe vor im Laufe der Zeit an dieser Stelle häufiger auf die Makros einzugehen, heute will ich aber nur ein kurzes Beispiel für den Einstieg anbringen: Programmiert wird dabei nicht mit einem der externen Tools, sondern mit dem einfachen eingebauten Makro-Editor.

Um ein neues Makro anzulegen, klickt man auf Optionen -> Makro -> Makro erstellen.

Das öffnet ein Fenster, in dem man verschiedene Dinge eingeben kann:

  • Makroname: Das ist der Name, unter dem das Makro später wieder gefunden werden kann.
  • Namensraum: Für den Anfang uninteressant. Lassen Sie hier ruhig "MeineMakros" stehen.
  • Kurzbeschreibung: Ein kurzer Text, der das Makro beschreibt. Dieser Text erscheint später hinter dem Namen des Makros.
  • Dateiname: Name der Datei, in der das Makro abgelegt werden soll.
  • Programmiersprache: Entweder CSharp (C#) oder VisualBasic - meine Beispiele werden alle in CSharp verfasst sein. (Mit den externen Tools wie Visual Studio (Express) können Sie auch in anderen Sprachen programmieren - jede .Net fähige Sprache ist uns Recht. [Hint: Nehmen Sie C#])

Dann klickt man "Erstellen" - und dann hat man auch schon sein erstes eigenes Makro. Das wird in einem Textfenster angezeigt, in dem man auch editieren kann. Das Makro tut zwar noch nicht viel - man kann es aber bereits laufen lassen. Das geht, indem man auf den grünen Pfeil in der Werkzeugleiste des Editors klickt: Das Makro wird dann ausgeführt - und zeigt eine Meldungsbox an.

Im folgenden wird das Makro nun erweitert, um Knoten für eine Faltwerksdatei zu erzeugen.

Ganz oben im Makro-Editor sehen Sie die Zeile "using System;" - direkt darunter fügen Sie dann die folgende Zeile ein:

using DIE.Applications.Faltwerk.Objects.Nodes;

Damit wird der Namensraum der Knoten (Nodes) dem Makro bekannt gemacht. Was ein Namensraum ist müssen Sie eigentlich nicht wissen - was Sie wissen müssen ist: Wegen dieser Zeile können Sie später im Makro die Objekte vom Typ "Node" (die Knoten) verwenden.

Dann kommen einen Zeilen, die automatisch für Sie erzeugt wurden und nur der Infrastruktur dienen: Die können Sie getrost ignorieren - der interessante Teil kommt bei der Zeile:

public override void Execute(IExecuteCommandContext context)

Bei dieser Zeile startet das eigentliche Makro: Im automatisch erzeugten Code finden Sie im Funktionskörper der Funktion "Execute" den Ausdruck, der das Meldungsfenster anzeigt. Den können Sie eigentlich löschen, und dann das gewünschte Makro schreiben: Das Makro soll einfach ein regelmässiges Feld aus Knoten erzeugen. Das geschieht mit 2 Schleifen: In der einen wird der Wert für x gesetzt, die andere (innere) setzt einen Wert für Y. Die Z-Koordinate wird einfach immer auf 0 gesetzt. Das sieht dann so aus:

for( double x =0; x<12; x+=4)
{
   for( double y =0; y<7; y++)
   {

X nimmt also die Werte "0", "4", und "8" an. Für jeden dieser Werte nimmt Y alle Werte von "0" bis "6" an. Mit diesen Werten wird dann ein Knoten erzeugt, und dem neuen Knoten werden seine Koordinaten zugewiesen:

 Node node = new Node();
 node.X = x;
 node.Y = y;
 node.Z = 0.0;

Zuletzt muss der Knoten noch in das aktuelle Dokument getan werden: Dadurch erscheint er auch in der Dokumenten-Ansicht, in den graphischen Fenstern und in der Tabellen-Ansicht:

context.TargetDocument.AddObject( node);

Wie man sieht: Die Sache ist wirklich einfach - und ungeheuer mächtig. Mit Makros können Sie nicht nur Objekte erzeugen - Sie können diese auch verändern, Sie können Ergebnisse erfragen - und unter Umständen berechnungen auf Basis der Schnittgrößen durchführen, die wir von Haus aus nicht mitliefern. Und: Makros können auch eigene Fenster haben - wer will kann also auch komplett eigene Dialogboxen programmieren. Ich will versuchen, alle diese Bereiche hier in Zukunft abzudecken, da die Dokumentation zu den Makros momentan leider sehr spärlich ist.

Knotenfeld.cs (.6 KB)

Debug.Assert() - eher ein Kommentar


Nimmt ein eher Debug.Assert() oder eher "throw new XXXException()" - offenbar eine Frage über die sich häufig zu wenig Gedanken gemacht wird.

Die Kurzanleitung lautet: Debug.Assert() nimmt man besser nie.

Etwas mehr Hintergrund:
Letztlich dient sowohl das werfen einer Exception als auch Debug.Assert() der Fehlersuche. Beim Assert() stellt man sicher, das eine bestimmte Bedingung vorliegt, was allerdings nur in Debug-Builds (also nicht beim Anwender der Software) passiert. Wirft man eine Exception, so verhält sich die Sache anders: Der Test der Bedingung findet vor dem werfen der Exception statt - und beides passiert sowohl in Debug- als auch in Release-Builds.

Man muss sich die Frage stellen: Was will man eigentlich erreichen, wenn eine Fehlerbedingung eintritt. Und die Antwort ist da relativ einfach: Mal will, das das Programm abstürzt - und zwar so schnell wie möglich (und wenn irgend möglich, auch mit einer passenden Fehlermeldung - am besten mit einer, die man auch noch gleich auf einen eigenen Mail- oder Webserver transportieren kann.).

Mit "so schnell wie möglich" ist gemeint, das das Programm möglichst nicht mit einem fehlerhaften Zustand weiterbetrieben werden sollte, denn das führt nur dazu, das Folgefehler auftreten: Die machen es aber schwieriger, das eigentliche Problem zu diagnostizieren. Behandelt man aber Fehler mit Debug.Assert(), und tritt der Fehler dann beim Anwender - also in einem Release-Build - auf, dann läuft das Programm einfach ganz "normal" weiter - nur eben in einem Zustand, für das es nicht gedacht war. Dieser Zustand für dann dazu, das es zu einem späteren Zeitpunkt und an einer ganz anderen Stelle ganz sicher zu einem Absturz kommt - und zwar zu einem, dessen Ursache nicht mehr zu erklären ist: Ein Zustand, der bei der verwendung einer Exception statt eines Assert()s erst gar nicht eintreten würde.

In den allermeisten Fällen reicht es schon aus, einfach nur die eingehenden Parameter einer Funktion zu prüfen - und das dürfte praktisch nie ein Performance-Problem machen. (In den seltenen Fällen wo das vielleicht doch mal der Fall ist, nimmt man halt eben doch mal Debug.Assert()). Passt ein Parameter nicht, wirft man eine Exception.

Ein Debug.Assert() ist bestenfalls eine Art sehr deutlicher Kommentar, aber kein sinnvoller Mechanismus für die Qualitätssicherung.


Zur Projektverwaltung in "Baustatik"


Seit dem letzten Update im Faltwerk gibt es nun auch einen Menüpunkt "Datei -> Speichern untern". Damit kann man das aktuelle Dokument unter einem neuen Namen speichern. Das ist praktisch - hat aber einige Implikationen, die auf den ersten Blick nicht ganz klar werden. Wenn man per "Speichern unter" eine Datei abspeichert, dann kann man natürlich nicht nur einen neuen Namen, sondern auch einen neuen Pfad angeben.

Der neue Pfad liegt dabei aber natürlich nicht unbedingt dort, wo auch der Pfad des aktuellen Projektes ist. Würde das nicht nicht gehen, dann könnten man die Datei aber nicht zum Beispiel auf einer anderen Festplatte speichern - und also lassen wir das zu.

Die Behandlung im Projekt unterscheidet sich aber: Ändert sich nur der Dateiname, so wird die "neue" Datei automatisch zum Projekt hinzugefügt. Ändert sich aber auch der Pfad - dann wird sie das nicht. Also nicht wundern, wenn die Datei auf eine andere Platte gespeichert wurde, und dann im Projekt nicht auftaucht: Das ist mit voller Absicht so.


Neue DIN 1045, neue EC2


Heute vor eine Woche waren wir in Berlin um an einer Sitzung einer Arbeitsgemeischaft des DBV teilzunehmen; der DBV arbeitet schon länger an der deutschen Ausführungsrichtlinie für den EC2. Mehr dazu gibts bei meinem Bruder nachzulesen.

Die wichtigsten Informationen in Kurzform: Vorraussichtlich wird der neue EC2 2010 verbindlich eingeführt - allerdings gibt es danach noch einen Zeitraum von 3 Jahren, in denen die 1045 weiter verwendet werden kann. Vorher gibts aber nochmal eine neue 1045 - und das unter Umständen sehr schnell, und zwar noch in diesem Jahr.