Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Kommende Attraktionen: Lastweiterleitung ins Fundament


Im nächsten Update wird das recht sicher drin sein: Die Lastweiterleitung ist dann so erweitert worden, das man auch Lasten ins Fundament weiterleiten kann.

image

Anders als bei den bisher bekannten Varianten kann man sich allerdings schon bei der Schnelleingabe für den Import aus einer Stütze entscheiden:

image

Die von den schon existierenden Varianten bekannte Methode mit der Definition eines Lastimport-Objektes gibt es aber natürlich auch.


So behalten wir unsere Test im Auge


Ich habe ja schon hin- und wieder darüber berichtet, das wir jede Nacht eine 32bit und eine 64bit Version der Baustatik auf Basis des aktuellen Entwicklungsstandes herstellen, und dann mit diesen Programmversionen eine Vielzahl an Dateien komplett durchrechnen – und die Ergebnisse dieser Berechnungen dann mit Referenzdaten vergleichen. Sinn der Sache ist es sicherzustellen, das eine durch die Weiterentwicklung entstandene Veränderung am Programm sich nicht auf die berechneten Ergebnisse auswirkt. Oder wenn, dann eben nur, weil das vom Entwickler auch gewünscht war.

Zur Zeit berechnen wir dabei pro Version ca. 3500 Eingabedateien (also insgesamt 7000). Und pro Datei gibt es dann natürlich noch jede Menge unterschiedlicher Ergebnissarten – und die an jeder Menge Stellen. Also zum Beispiel alle Auflagerkräfte für alle Lastfälle und Überlagerungen, aber eben auch alle Verformungen und Bemessungsergebnisse aller Faltwerkselemente in allen FE-Punkten. Mit einem Wort: Das sind echt viele Zahlen. Viele.

Und so machen wir das…

Zunächst mal haben wir 2 virtuelle Hyper-V Maschinen im Betrieb, beide mit installierter Quellcodeverwaltung und Visual Studio. Auf beiden werden abends Jobs angestoßen, und diese Jobs tun folgendes:

  • Aktuellen Quellcode runterladen
  • Programmversion herstellen (die eine virtuelle Maschine die 32bit Version, die andere die 64bit Version)
  • Aktuelle Testdateien runterladen
  • Für alle Testdateien alle möglichen Ergebnisse berechnen und protokollieren
  • Alle Ergebnisse mit den Referenzergebnissen vergleichen und eventuell aufgetretene Unterschiede protokollieren

Alles was protokolliert wird landet in einer Datenbank (in Azure), und dafür wiederum haben wir eine (interne) Webseite, mit der man sich die Daten ansehen kann. Die liefert zunächst mal eine Übersicht, aus der hervorgeht, welche Version überhaupt gebaut werden konnte, wo Testläufe durchlaufen wurden, und wo Testläufe fehlschlugen:

image

Im Fall eines Fehlschlags kann man auf den Testlauf klicken und bekommt eine Übersicht über diesen Testlauf. In dieser Übersicht sieht man dann auch schon, in welchem Bereich der Fehler lag:

image

Dort kann man dann wiederum auf den Fehler klicken und bekommt alle Details dazu, was genau nicht geklappt hat:

image

Danach kennt man also schon mal die Dokumente, bei denen es ein Problem gab und eine Zusammenfassung des Fehlers. Klickt man nun noch auf die Datei, gibt es auch (zum Teil etwas kryptische) Informationen darüber, welcher Teil der Berechnung genau nicht geklappt hat – und was genau der Fehler war:

image

Wenn man nicht ganz so tief in die Details gehen will, dann gibt es natürlich auch etwas höher angeordnete Statistiken, zum Beispiel wie viele Testläufe durchlaufen wurden, und wie lange das gedauert hat. (Wenn sich hier was ändert, dann ist zwar nichts wirklich falsch – aber langsamer werden soll die Sache natürlich auch nicht):

image

Insbesondere bei der Zeit sind kleinere Unterschiede aber zu erwarten, das bringt schon allein die Verwendung der virtuellen Maschinen mit sich: Wenn der physische Rechner in dem die sich befinden gerade etwas “interessantes” tut – also zum Beispiel ein automatisches Update einspielt – dann verändert sich die Performance der virtuellen Maschine darin – und darum kommt es zu anderen Laufzeiten. Die sollten aber immer nur gering sein – sonst stimmt mit dem Programm etwas nicht.

Und das ist im großen und ganzen die Methode, mit der wir die Übersicht über unsere Test – und das Verhalten der Baustatik – behalten: Viele, viele, viele Daten – in hübsche Graphiken verpackt. Eigentlich genau so, wie die Baustatik selbst Smiley


Blogs nun auch mit SSL


Wir haben die Umstellung unseres Web-Angebotes auf SSL nun abgeschlossen: Das letzte Problem waren unsere Blogs. Die hatten zwar schon SSL, aber es gab ein Restproblem mit der Blog-Software. Bei der erfolgt die Anzeige aller Bilder nämlich über einen Bilder-Handler. Das bedeutet im wesentlichen, das das Bild nicht direkt als Quelle im IMG-Tag angegeben wird, sondern es wird statt dessen der parametrisierte Handler aufgelistet. Und der ist – zumindest in der Version die wir verwenden- fest kodiert, und zwar mit einer HTTP-URL.

Nun habe ich damals beim einrichten der Blog-Webseite den Fehler gemacht das ganze nicht auf dem Quellcode der Blogsoftware beruhen zu lassen (was gegangen wäre), sondern ich habe die Binäre Distribution verwendet. Das war damals einfacher, macht aber heute Änderungen schwieriger. Mit der Quellcode-Variante hätte man das Programm einfach so ändern können, das es eine HTTP-UPR ausgibt, bei der binären Variante geht das aber leider nicht.

Darum produzierte das Blog weiterhin fröhlich Webseiten, die zwar per HTTPS erreichbar waren, aber ihrerseits Referenzen auf HTTP-URLs verwendete. Wegen diese Referenzen wurden die Blog-Beiträge darum von allen Browsern als nicht vollständig sicher eingestuft (zu Recht) – und die Adressleiste enthielt darum auch nicht die “grüne” Farbe bzw. das Schloss-Symbol, mit dem die sichere Verbindung gekennzeichnet wird.

Das ist aber nun geklärt- und auch die Blog-Seiten und Beiträge sind vollständig per SSL erreichbar. (Anders als auf der normalen Webseite www.die.de erzwingen wir aber zur Zeit die sichere Verbindung nicht: Wer will, kann also noch “unsicher” surfen.)

Wer sich für die technische Lösung interessiert: So haben wir es gemacht….

Das wesentliche Problem ist, das das ASP.NET Programm das HTML erzeugt, das dann, wenn alles fertig ist, an den Client geschickt wird. Am eigentlichen Prozess der HTML-Erzeugung konnten wir nichts beeinflussen. Man musste das HTML also verändern, nachdem es von der Blog-Software erzeugt wurde, und unmittelbar bevor es an den Client gesendet wurde.

Das ist aber bei ASP.NET kein Problem: Dazu muss man nur ein IHttpModule  implementieren und in web.config eintragen. Die Implementierung ist in diesem Fall trivial: Im “Init” hängt man einen Eventhandler an das PostRequestHandlerExecute Event. Dort, falls es sich beim “CurrentHandler” um die Page handelt, hängt man an den Response-Filter einen neuen Filter.

Der Filter erbt von Stream und muss die gängigen Methoden überladen, die einzig wichtige ist aber “Write”. Dort hat man den kompletten Puffer mit dem HTML, und kann dort – in diesem Fall – den Text einfach mit string.Replace() ersetzen, und dann das eigentliche Write aufrufen.


“Alte” Dokumentation wieder verfügbar


Die Programmdokumentation für die “alten” XFEMily-Programme wurde vor einiger Zeit vom Webserver entfernt. Es gab danach vereinzelte Anfragen nach dieser Doku – zwar wirklich nur seltene Fälle, aber gegeben hat es sie… Darum: Ab sofort ist die “alte” Dokumentation wieder über unseren Webserver erreichbar. (Ab dem nächsten Update wird diese URL auch von der Hilfe in den alten Programmen verwendet.)


Änderungen bei den Makros


Die Baustatik konnte man schon vom ersten Tag an mit selbst programmierten Makros erweitern: Das bietet sich zum Beispiel dann an, wenn man immer wieder sehr ähnlich Bauteile berechnet, bei denen sich nur wenige Parameter ändern – zum Beispiel Hochregal-Systemlager. Andere Kunden gehen da sogar deutlich weiter, so existiert beispielsweise ein Makro, das automatisiert die Berechnungsergebnisse der Platte in eine Datei exportiert, die vom CAD-System ZEIG gelesen werden kann.

Allerdings hat sich an den Makros auch nicht besonders viel getan. Bis jetzt: Denn ab dem nächsten Update gibt es eine völlig neue Makro-Umgebung. Das betrifft sowohl das Fenster zur Auswahl der auszuführenden Makros, als auch den Makro-Editor selbst.

image

Das beste Werkzeug zum bearbeiten von Makros ist weiterhin Visual Studio – aber zum schnellen bearbeiten oder für kurze Korrekturen gehts mit dem Editor eben einfach schneller.

Und das ist neu am Editor:

  • Es gibt nun keine “merkwürdigen” Dialoge zum anlegen oder öffnen von Makros mehr. Statt dessen gibt es die ganz normalen Windows-Fenster zum öffnen und speichern von Dateien.
  • Es gibt nun Undo und Redo
  • Es gibt ein ganz brauchbares Syntax-Highlighting für den C# Makro-Code.
  • Funktionale Blöcke können “gefaltet” werden:
    image

    image
  • Es gibt (endlich) eine gut funktionierende Zwischenablage
  • Man kann das Makro nun auch ausdrucken (auch mit Druckvorschau)
  • Und schließlich werden Fehlermeldung vom Compiler nun besser markiert.
    image

Insgesamt ist eigentlich alles nun deutlich aufgeräumter als zuvor: Das etwas merkwürdige Config-File für den Editor und den Compiler wird nicht länger benötigt – und bei der Gelegenheit haben wir auch die beiden mitgelieferten Beispielmakros an den neuesten Programmstand angepasst und wieder lauffähig gemacht.

Insgesamt sicher keine Aufwertung für viele Anwender – aber für alle, die diese Funktionalität verwenden, ganz sicher eine dramatische Verbesserung.


Neue Version der Programmierer-Referenz


Alle Kunden die Makros für die Baustatik schreiben konnten bisher auf die Programmierer-Referenz auf unserem Münchner Webserver zugreifen. Allerdings war die Referenz schon etwas in die Tage gekommen (das Material wird bei weitem nicht so oft upgedatet wie das Programm selbst).

Es gibt nun aber endlich eine neue Version davon, zu finden unter der bereits bekannten URL http://muenchen.die.de/API/.

Nun ist es so, das diese aktuelle Referenz deutlich umfangreicher ist als die alte – und darum vielleicht auch ein bisschen unübersichtlicher. Wir haben die alte darum aufgehoben: Wer die lieber mag, findet sie unter dieser URL: http://muenchen.die.de/APIold/


Kundenmakro: Export von AS-Werten nach ZEIG


Vom Ingenieurbüro Balster gibt es ein neues Makro für die Baustatik – um genau zu sein: Es gibt ein Paket das aus einem Baustatik-Makro und Prozeduren für unser CAD-System Zeig besteht.

Exportiert werden die berechneten AS-Werte aus der Baustatik, und importiert werden die dann nach ZEIG, und dort “halb” automatisch zu Bewehrungsplänen weiterverarbeitet.

Folgendes passiert (Beschreibung von Herrn Hobbensiefken, von dem das Makro stammt. Er ist auch bereit darüber hinaus im gewissen Umfang Fragen dazu zu beantworten):

1. Es werden nur die Bewehrungsdaten der ersten Bemessungsgruppe übergeben.
2. Automatisch erzeugte Bemesungsergebnisse werden nicht erfasst.
3. Das Export-Makro ist nicht fehlertolerant, soll heißen: o.g. Bedingungen werden nicht überprüft.
4. Die VEC-Datei mit den Bewehrungsdaten wird im Ordner der Xfalt-Berechnungen abgelegt (keine Auswahlmöglichkeit)
5. Die Bewehrungsrichtungen werden in der VEC-Datei als Layer abgelegt (asxu - 11, asxo -12, asyu -13, asyo -14, asw -15)
6. Für die automatische Erstellung der VEC-Datei wird der Zeig-Bildschirm-Maßstab auf 1:100 und der Zeig-Plot-Maßstab aus 1:50 festgelegt.


Zur Bearbeitung der Daten unter Zeig dient die Prozedur ASXYAB.PRC unter folgenden Bedingungen:

1. Die Datei mit den Bewehrungsdaten wird in eine VEC-Datei (z.B. zu bewehrender Grundriss) in die Detail-Ebene geladen.
2. Der Grundriss enthält vor dem Zuladen noch keine Detail-Ebene.
3. Die Funktionsweise unter Zeig auf Basis PicturesByPC Version 3.2 ist noch nicht getestet.


Die Arbeit mit den eingelesenen Bewehrungsdaten erfolgt momentan händisch über die Kommandoeingabe.

Nach dem Zuladen der Bewehrungsdaten in die Detailebene eines Grundrisses sind normalerweise alle Layer (11 - 15) der Bewehrungsdaten aktiv und die Texte stehen übereinander. Die Größe der Bewehrung wird als Text angezeigt. Der Startpunkt des Textes (ma ....  - Zeichenbefehl im Edit der VEC-Datei) ist die Lage des gerechneten Bewehrungspunktes. Die Farbe der Texte (6 - magenta) darf nicht verändert werden, da die Zeig-Prozedur in ihrer Funktion darauf abgestellt ist.

Mit den Befehl 'ly' können die gewünschten Layer ein- und ausgeschaltet werden. "ly -d 11..15" schaltet alle Bewehrungslayer aus. Mit "ly -e 11" kann Layer 11 (asux) wieder sichtbar geschaltet werden.
Der einfache Aufruf von "ly" öffnet den Layer-Dialog und die gewünschten Layer können im Dialog an/aus geschaltet werden.

Die Prozedur 'asxyab.prc' erstellt bei der ersten Benutzung der Bewehrungsdaten eine Sicherung der Bewehrungsdaten, sodass mit 'asxyab -u' der Anfangszustand wieder hergestellt werden kann, egal wieviel Operationen bis dahin ausgeführt worden sind. Mit 'asxyab -f (Skalierung) kann die Textgröße der Bewehrungsdaten prozentual geändert werden, dabei bedeutet z.B. 'asxyab -f 1.2', dass die Texte um 20% vergrößert werden.
Wird z.B. eine Grundbewehrung mit einer Matte Q-335A gelegt und es sollen die noch abzudenkenden Spitzen angezeigt werden ist 'asxyab 3.35' der benötigte Befehl. Es können beliebig oft Werte abgezogen werden, da mit dem Parameter '-u' der Grundzustand wieder herzustellen ist. Alle Befehle der Prozedur 'asxyab' wirken auf alle Bewehrungslayer gleichzeitig. Änderungen der Textgröße werden mit dem Parameter '-u' nicht zurückgenommen.


Soweit zur derzeitigen Verwendungsmöglichkeit des Bewehrungsdaten-Exportes nach Zeig. Wir verwendet diese Routinen in erster Linie bei größeren Decken mit ungleicher Belastung oder bei sehr unterschiedlichen Feldkonfigurationen.

Die mir von Ihnen zur Verfügung gestellten Methoden habe ich mit den entsprechenden Änderungen in das Makro integriert und umbenannt, um die Originale im Programmcode auszusparen. Zur besseren Verifizierung zwischen Ihren ursprünglichen Methoden und meinen Änderungen, bzw. den bis heute im Programm vorliegenden Methoden habe ich Ihnen die alten Dateien noch mit in die Zip-Datei gepackt.

Wer mag, kann alles zusammen hier herunterladen.


Makros in der Baustatik


Die Baustatik ist vollständig vom Anwender programmierbar und damit erweiterbar. Ein gutes Beispiel für eine solche Erweiterung ist die Variantenkonstruktion, also eine Art der Konstruktion, bei der immer ähnliche Konstruktionen mit veränderten Parametern angelegt werden.

So sind zum Beispiel die Regale der Firma Heiss konzipiert. Die sehen ungefähr wie folgt aus und haben auch die ersichtlichen Parameter:

image

Dafür gibt es nun ein Makro – und wer will, kann das auch ausprobieren. Dazu ist folgendes zu tun:

Sie gehen in der Baustatik nach "Optionen -> Makro -> Makro herunterladen".  (Der Rechner muss dazu einer Internetverbindung haben.)

image

Das zeigt das Fenster mit den Makros an. Dort wählen sie "Regalerzeugen.cs" aus, und klicken dann auf "Speichern". Dadurch wird das Makro auf Ihren Rechner herunterladen und dort abgelegt. (Man kann es auch alternativ direkt vom Server aus ausführen, aber dann müssen Sie sich immer wieder verbinden, und können auch nichts ändern.)

Dann legen Sie ein neues leeres Faltwerks oder Rahmendokument an, und gehen dann auf Optionen -> Makro -> Makro ausführen. In der Liste taucht das "Regalerzeugen.cs" Makro dann wieder auf: Da drücken Sie auf "ausführen".

image

Das Makro startet dann, und öffnet zunächst ein Fenster, in dem die Parameter fürs Regal erfagt werden:

image

Die einfach eingeben (alle Abmessungen in [m], und "Kommas" mit ".") und OK drücken -> Das RegaL wird erzeugt. Die Stäbe darin haben dann bereits die "richtig" sortierten Querschnitte - die sind aber noch "leer" und Sie müssen also die Querschnittsdefinitionen über die Dokumenten-Ansicht noch ergänzen.

Wenn man das getan hat, sieht die ganze Sache ungefähr so aus – und alles mit nur 6 eingegebenen Werten:

image


Kleine Statistik zur Baustatik


Weil ich kürzlich mal wieder drauf geschaut und darum die Zahlen zur Hand habe: So sieht die Baustatik aus Entwickler-Sicht aus:

Eigentlicher Quellcode: circa 19.000 Dateien, 3000 Ordner mit insgesamt etwa 1.5 GB
Testumgebung: circa 8600 Dateien in 65 Ordnern mit etwa 3.7 GB
Begleitende Webseite (Doku, Case-Management, etc.): circa 3700 Dateien, 120 Ordner, 500 MB.

… alles zusammen also etwa 30.000 Dateien. Schon eher ein größeres Projekt Smiley


Ein Makro zum auswählen und bearbeiten


Heute kam die Frage auf, ob wir nicht ein Beispiel-Makro fürs auswählen und bearbeiten von Objekten hätten. Haben wir… Smiley

Der einfachste Weg ist natürlich der, einfach ein Objekt auszuwählen und dann den Eigenschaften-Dialog anzuzeigen. Fürs auswählen selbst braucht man kein Makro: Das geht ja “einfach so”. Ein Beispiel für das anzeigen des Eigenschaften-Dialoges gibt es im Makro “AuswahlBearbeiten”.

image

Was aber tun, wenn man in einer Schleife nacheinander mehrere Objekte auswählen und dann bearbeiten will. Also: Objekt auswähle, Objekt bearbeiten –> und dann wieder von vorne anfangen? Das ist etwas komplizierter (das vorige Makro ist ein Einzeiler), und darum gibts hier eine kurze Erklärung dazu, was das Ding tut. Der Quellcode dazu findet sich in “ObjektAuswählenUndBearbeiten”.

Neben dem normalen immer für Makros benötigten Kram gibt es im wesentlichen 3 Methoden:

1.) DoIt()

Das ist die Funktion, die die eigentliche Arbeit tut: Sie wird auch ganz am Anfang im Execute() des Makros aufgerufen. Das Ding tut folgendes:

  • Ein neues MouseTool vom Typ “ObjectSelectionMouseTool” erzeugen. MouseTools sind die Dinger, mit denen man in der Graphik interaktiv arbeiten kann. Wenn man z.B. in der Graphik mit der Maus irgendwo draufklickt und das angeklickte Objekt wird rot, dann war da das normale “SelectionMouseTool”. Wenn man mit der Maus einen Zoom durchführt, dann passiert das mit dem ZoomMouseTool etc.. Das ObjectSelectionMouseTool ist dafür da, ein (oder mehrere) Objekt(e) beliebigen Typs in der Graphik auszuwählen.
  • Das MouseTool hat mehrere Ereignisse, die man mitbekommen kann. Die beiden die man hier braucht sind “SelectCanceled” und “SelectFinished”. Das erste Ereignis tritt ein, wenn die Auswahl abgebrochen wurde (Rechte Maustaste gedrückt), das zweite tritt ein, wenn eine Auswahl durchgeführt und ein Objekt ausgewählt wurde.
  • Das Makro hängt sich nun an beide Ereignisse dran: Im Cancel-Fall wird dann die Methode Cancel() aufgerufen (die zeigt einfach nur eine Meldung an, damit man mitbekommt, das die Sache nun ein Ende hat), im anderen Fall wird Finished() aufgerufen.
  • Das MouseTool ist nun fertig und kann aktiviert werden. Das passiert mit FormBase.ActivateMouseTool().

2.) Cancel()

  • Tut wie gesagt nicht viel: Auf die Meldung darin kann man eigentlich verzichten, aber damit man hier im Beispiel mitbekommt, das irgendwas passiert, wird sie eben angezeigt.

3.) Finished()

  • Hier wird zunächst das erste der ausgewählten Objekte aus den Argumenten der Funktion extrahiert. Das Objekt ist garantiert vom Typ IDocObject (weil das MouseTool nichts anderes auswählen kann.). Das ganze sieht darum etwas kompliziert aus, weil das MouseTool eigentlich darauf ausgelegt ist, mehrere Objekte auszuwählen. In unserem Fall gibt es aber immer nur ein Objekt, und darum kann das aus dem Array-Parameter mit “[0]” rausgeholt werden.
  • Dann wird eine neue “DocObjectCollection” angelegt, und das eine ausgewählte Objekt wird in diese Sammlung reingesteckt. Die Sammlung braucht man – obwohl es nur um eine Element geht – weil auch der ganze restliche Code immer darauf ausgelegt ist, mehrere Objekte gleichzeitig zu bearbeiten.
  • Dann wird mit Hilfe des FactoryManagers ein Eigenschafts-Dialog erzeugt. Der Eigenschafts-Dialog ist dabei einer, der für den Typ Objekt zuständig ist, das ausgewählt wurde. Darum muss der Typ des Objektes übergeben werden. (Dieser Typ ist also der konkrete Typ “Beam”, “Node”, etc. – und nicht der “allgemeine” Fall “IDocObject”)
  • Als nächstes wird die zuvor vorbereitete Sammlung in den Dialog gesteckt.
  • Dann hängt sich der Code noch an das “Closed” Ereignis des Dialogs. Dieses Ereignis tritt ein, wenn das Fenster geschlossen wird. Ist das der Fall, wird wieder “DoIt” aufgerufen – die ganze Sache geht also wieder von vorne los.
  • Und schließlich wird die Dialogbox angezeigt.

Ich hoffe mal, mit dieser Erklärung wird das alles etwas klarer….