Fehler und Bugs » Plancal stürzt immer wieder ab

Hallo Community.

Wir haben bei uns mehrere CAD-Arbeitsplätze im Haus.
Immer wieder haben wir das Problem das bei dem einen oder anderen User die Nova immer wieder abstürzt.
Er zeichnet gerade und dann kommt: "Keine Rückmeldung" und dann verabschiedet sich die Nova komplett.
Oft mal kommt auch die Meldung beim Speichern einer Zeichnung: "Server reagiert nicht/antwortet nicht"
Die anderen Benutzer können aber problemlos speichern etc. - Dies passiert immer wieder mal und das mal bei dem User und bei dem User.
Der Server an sich selber hat keine Probleme, der ist nicht ausgelastet und gar nichts.

Alle Änderungen sind dann natürlich verloren.


Bei den Clients ist die Nova 10 installiert.
Im Hintergrund läuft natürlich der Plancal Lizenzserver auf einem Server.
Auf dem gleichen Server liegt auch der Plancal Projektserver.

Hat auch noch jemand mit diesen Problemen zu kämpfen?

Hallo AH,

das ist natürlich eine recht pauschale Anfrage. Man braucht viele Detailinformationen über Arbeitsstation, Netzwerk und Server um auf die Fehlersuche zu gehen.
Zwei Punkt der sich schon häufiger als hilfreich erwiesen haben:
- Bei allen Rechner prüfen das das Betriebssystem aktuell ist (oft war das Problem das die Funktion automatisches Updaten für das Betriebssystem abgeschaltet war)
- Prüfen das der Lizenzserver und Projektserver auf aktuellem Stand sind.
Beide Punkte sollten immer vom Administrator (mit entsprechendem Kenntnisstand) ausgeführt werden.

Ansonsten müsste der Admin sich mal an den Support wenden.

Ja wir haben auch mit dem Problem zu kämpfen.

Bei uns im Büro sieht es auch so aus.
Bin gerade am Zeichnung bereinigen warte jetzt schon ne geschlagene halbe Stunde. Oben in der Leiste steht schon wieder keine Rückmeldung und die Fenster haben nen milchigen Schleier bekommen.
Außerdem kennen wir das Problem wenn wir abends die Zeichnungen Speichern und die Nova schließen wollen. Erst heißt es keine Rückmeldung und dann Nova reagiert nicht mehr.

Hallo zusammen,


wir haben immer wieder mit diesem Problembild zu tun gehabt (auch in der aktuellen Version 10.1 wieder).
Da es nicht immer die gleiche Ursache war, hier einmal die Liste der in den vergangenen 7 Jahren identifizierten Probleme/Lösungsansätze.
Meist ist nicht das Netzwerk zu schlecht für Nova sondern Nova zu schlecht fürs Netzwerk.
Was man tun kann, um das zu umgehen, steht im folgenden.

Die beste Lösung wäre eine Kundenbasis, die eine stabile Nova fordert und klar kommuniziert, welche Fehler eben doch nicht so selten sind.
Wer möchte, kann mich gern unter spassmitnova@g-ingenieure.de kontaktieren. So richtig will ich mich nämlich noch nicht damit abfinden, dass man das nicht ändern können soll.


Hintergrund


PlanCal Nova verwendet recht einfache Methoden, um auf die Projektdateien zuzugreifen und ist äußerst intolerant, was (auch nur kurzzeitige) Zugriffsprobleme angeht, die in Netzwerken selten aber eben doch vorkommen (müssen).
Während andere Technologien den Verlust einzelner Pakete verkraften und diese einfach noch einmal anfordern, behandelt der Nova Projektserver die hunderte MB großen Dateien über das Netzwerk immer noch so, als ob die Datei wie zu NOVA-Anfangszeiten lokal auf der Platte liegt. Während Windows bei einem Hänger im Kopiervorgang also die Schaltfläche "wiederholen" anbietet, gibt es so etwas bei Nova nicht. Stattdessen steigt die Software meist einfach aus.
Dies liegt auch daran, dass Nova gar nicht wirklich slebst auf die Datei zugrieft, sondern das einer Drittanbieterkomponente überlässt (mehr dazu unten) und deren Fehler mehr oder weniger nur weitergibt.

In einer puren Umgebung, in der nur Nova läuft (so wie es vermutlich bei Trimble/Plancal getestet wird) und wenn der Testzeitraum nur wenige Stunden beträgt, macht das keine Schnitte. Anders sieht es in einer produktiven Arbeitsumgebung aus. Bei der im Ethernet Standard definierten Fehlerhäufigkeit von 1 Fehler je 10.000.000.000.000 Pakete gibt es pro Benutzer und Jahr eben ca. 15 Fehlerpakete. Und das noch ohne andere konkurrierende Dienste auf dem Server und im Netzwerk. Das lässt sich also auch mit noch so guter Technik nicht erschlagen. Richtig wäre eine angemessene Fehlerbehandlung seitens Nova - seit Jahren höre ich aber immer nur, andere Kunden hätten diese Probleme nicht und wir sollten unser Netzwerk prüfen... Dabei haben wir nun schon unsere 3. Generation Netzwerk, Rechner und Server, die von unterschieldichen Leuten eingerichtet wurden.

Fangen wir trotzdem mal mit dem Netzwerk an:


Netzwerk

Das Netzwerk sollte (sehr) stabil laufen. Das bedeutet:

- Wird GigaBit Ethernet verwendet (ist eigentlich überall der Fall), sollte Cat7, bzw Cat6a Verkabelung zum Einsatz kommen mit Längen UNTER 65 Metern.
- Ein Messprotokoll der Verkabelung wäre ideal, um auszuschließen, dass diesen Punkt betreffend alles i.O. ist
- Wenn aber alle anderen Sachen über das Netz funktionieren (Outlook, Surfen, Dateien kopieren, ...), ist es auch so sehr unwahrscheinlich, dass das Netz einen grundlegenden Fehler hat
- Netzwerkkabel sollten NICHT beschädigt und NICHT in Radien unterhalb 15cm gebogen sein (auch innerhalb von Kabelkanälen nicht!)
- Wenn IPv6 nicht benötigt wird, sollte dies bei allen Teilnehmern des Netzwerks DEAKTIVIERT sein
- Die Clients (PCs) sollten STATISCHE IPs haben oder immer die gleiche IP vom DHCP-Server bekommen
- Vor allem der Rechner, auf dem der Projekt- und Lizenzserver installiert sind, MUSS eine statische IP bekommen
- Sonst erneuert er irgendwann seine IP und der Zugriff setzt möglicherweise kurz aus
- Zugriffs- und Lizenzfehler sind dann häufig die Folge
- Projekt- und Lizenzserver kann einer der PCs oder ein separater PC mit Windows 7 oder eben ein richtiger Windows Server sein
- Wird Windows 7 als Grundlage für den Server verwendet, können MAXIMAL 20 Benutzer/Geräte auf die Freigabe zugreifen!
- als Zugriff zählt aber auch wenn andere Personen oder Geräte die Freigabe nur auflisten (also prüfen, welche Ordner im Netzwerk verfügbar sind)
- sind die 20 Parallelzugriffe aufgebraucht, kommt evtl. ein Nova Nutzer nicht mehr an die Daten
- eine Lösung wäre, den Projektserver auf einen richtigen Windows Server zu installieren (dort gibt es die Beschränkung nicht)
- die andere Lösung ist, nur den eigentlichen Nova-Nutzern Zugriff auf die Freigabe zu erteilen
- wie das geht, und dass es die Beschränkung auf 20 User überhaupt gibt, dürfte gern in der Anleitung auftauchen - Windows 7 ist ja als unterstützter Host angegeben...
- Der Lizenz- und Projektserver werden am besten immer nur mit ihrer IP angesprochen statt mit ihrem Namen
- dadurch wird ausgeshlossen, dass die Namensauflösung über NetBIOS oder DNS Verzögerungen oder Mehrdeutigkeiten verursachen
- Wer schon Projekte auf dem Projektserver hat, muss nach so einer Änderung natürlich die Zeichnungs-Referenzen neu verknüpfen
- Die Firewall muss auf den Clients und dem Server die Ports für den Betrieb der Nova geöffnet haben
- Port für Lizenzserver
- Port für Projektserver
- Ports, um auf die Netzwerkfreigabe zuzugreifen
- Wer Lust hat, kann mit WireShark oder anderen Tools die Aussage des Supports überprüfen, ob das Netzwerk fehlerhaft ist, indem er nach Fehlerpaketen sucht
- Ich habe dabei noch nie etwas finden können
- ein extra bestellter Netzwerkspezialist eines Drittanbieters ebenfalls nicht
- auch der Support kann mir nicht zeigen, WAS da angeblich nicht geht (ist sich aber sicher, dass es so sein muss)


Virenscanner

Ein Virenscanner kann die Projektdatei länger festhalten, als der Nova recht ist, während er die Datei nach möglichen Viren durchsucht. Da Projektdateien recht groß sind, dauert auch der Scan recht lang.

- Daher sollte das Verzeichnis, in dem die Nova-Projekte liegen, von dieser Analyse ausgeschlossen sein
- Ansonsten hält der Virenscanner die Projektdatei während des Scans gesperrt und man erhält entsprechende Fehler
- Dieser Ausschluss muss auf dem Rechner, auf dem der Projektserver läuft und auf den Rechnern, die Nova nutzen, konfiguriert werden
- eine Erwähnung in der Anleitung oder während der Installation wäre schön, oder?


Datenbankdateien

Nova-Projektdateien sind eigentlich Microsoft SQL-Datenbankdateien, deren Endung umbenannt wurde. Nova setzt zum Zugriff auf diese Dateien intern Microsoft SQL Express ein.

- Nova Projekte sollten nicht größer als 2 GB werden - dann gibt es Probleme (wäre schön, wenn das in der Anleitung stehen würde oder die Software einen warnt)
- Dies kann verhindert werden, indem man Projekte regelmäßig komprimiert, BEVOR sie diese Größe erreichen (kann innerhalb einiger Tage manchmal schon so weit sein)
- Die Software fragt am Anfang auch, ob dies automatisch geschehen soll...
- Warum dem Nutzer diese Wahl, seine eigenen Daten potenziell zu verlieren, überlassen und überhaupt erst gestattet wird, ist mir schleierhaft
- Es gibt auch nirgendwo eine Erklärung, was schlimmstenfalls passiert, wenn ich "nein" klicke

Beim Komprimierungsbericht wird angezeigt, ob Fehler gefunden wurden.
Jedoch nur ein einziges Mal - die Fehler werden also anscheinend aus der Datenbank gelöscht.
Was dadurch betroffen ist (Heizkörper, U-Werte, Wandstärke, ...) wird einem nicht verraten.
Man kann sich also beim Auftreten solcher Fehler mit seinen eigenen zwei Augen auf die Suche beegeben, was heute anders ist als gestern oder vorgestern oder vor zwei Jahren...


Sicherung

Daten von denen das Überleben des Unternehmens abhängen, müssen gesichert werden (dazu zählen auch Nova-Projekte, die viele Jahre Arbeit enthalten).
Das sollte bestenfalls täglich erfolgen. Das geht relativ einfach und was die Software zum sichern angeht auch kostenfrei.
Nicht kostenfrei ist es, wenn Jahre Arbeit weg sind, weil ein Bit in einer Projektdatei falsch ist und keiner einem sagen kann, welches.

Eigentlich wäre es wünschenswert, wenn in Nova Snapshots gemacht werden könnten - also der aktuelle Zustand des Projekts "kopiert und eingefroren" werden.
Und zwar so, dass alle Nutzer des Projekts das eindeutig sehen.
Dies kann man aber auch händisch machen, indem man das Projekt in einen neuen Ordner kopiert und ab nun von dort weiterarbetiet.

Eine Sicherung ist das übrigens nicht (denn die sollte immer auf einem anderen Gerät und in einem anderen Brandabschnitt liegen - wenigstens als Festplatte beim Chef zu Hause). Aber es hilft, um schnell in die Historie des Projekts schauen zu können (wo waren die Heizkörper letzten Monat?, welchen Grundrisstand haben wir letztes Jahr verwendet?, ...).

Die Kombination aus Sicherung und Snapshots ermöglicht es einem, den Aufwand im Fehlerfall wenigstens halbwegs gering zu halten. Da wir nur die Nova haben, die wir haben, sollte man diese Maßnahmen ergreifen.


Der Kundensupport

Wie viele größere Unternehmen hat Plancal/Trimble einen mehrstufigen Support.
In der ersten Stufe gelangt man in der Regel zu einem Menschen, der mit Wellensittichen und anderen Geräuschen im Hintergrund offenbar von zu Hause arbeitet und einfache Fragen klärt wie "Haben sie den Bildschirm eingeschaltet", "Ist die aktuellste Version installiert" und so weiter. Natürlich hat dieser Supporter eine Schulung in der Software erhalten, aber gerade mit dem 2GB Datenbank-Limit und anderen "komischen" Effekten kennen sich diese Leute in der Regel nicht aus.

Dieses Personal ist vermutlich nicht bei Plancal/Trimble angestellt, sondern arbeitet bei einem Drittanbieter oder freiberuflich. Spürbar ist dies dadurch, dass es eine Zeitvorgabe zu geben scheint, nach der der Kunde an die nächste Stufe übergeben werden muss (also an Plancal/Trimble-eigene Mitarbeiter). Nachteilig ist, dass dies die "Performance" dieses Erstsupporters schlechter dastehen lässt, wenn er es in dieser Zeit nicht schafft einen zu "finalisieren". Das führt leider zur oft zur Verantwortungsinversion: nicht die müssen mir anscheinend erklären, warum ihr Produkt nicht funktioniert sondern ich soll beweisen, dass es nicht an mir liegt ("Ihr Netzwerk ist sicher defekt", "Andere haben diese Probleme bei mir noch nicht gemeldet", ...).

Bleibt man hartnäckig und kann zum Beipiel nachweisen, dass die eigene Technik fehlerfrei ist (man lasse sich das wirklich mal auf der Zunge zergehen), erhält man unter Umständen einen fähigerenSupporter, der möglicherweise sogar schon einmal selbst programmiert hat (in seiner Ausbildung) oder zumindest durch seine Zugehörigkeit zum Unternehmen mit der inneren Struktur des Programms vertraut ist - und nicht nur mit den bunten Knöpfchen, die jeder sehen kann. Von so einem Ansprechpartner erhält man dann auch Informationen wie zur Beschränkung der SQL-Express-Dateien auf 2GB.

Häufig läuft es aber auch hier auf ein "reproduzieren Sie doch bitte mal den Fehler für mich" hinaus. Das ist natürlich schwierig, wenn es ein transienter Fehler ist, dessen Ursache der Nutzer gar nicht kennen kann, weil er eben nur selten auftritt. Ich habe auch noch nicht einnmal erlebt, dass ein Supporter im Fernzugriff in die Windows Ereignisanzeige geschaut hat. Dort ist deutlich zu lesen, welches Untermodul von Nova an welcher Adresse ausgestiegen ist. Diese Information wäre ESSENTIELL, also absolut nötig, damit ein Programmierer das Problem aufspüren und benennen - vielleicht sogar beheben oder besser abfangen kann. Oder dem Nutzer wenigstens eine Meldung ausgeben. Noch einfacher wäre es, wenn Plancal sich einen Fehlerbericht automatisch nach Haus schicken würde. Die häufigsten Fehlerbilder könnten dann bevorzugt angegangen werden.


Quintessenz

Ich betreue neben vieler anderer Software eben auch seit Jahren Nova-Installationen.
Von allen Produkten ist Nova seit Jahren der Spitzenreiter, was das Produkt aus Fehlerhäufigkeit und Fehlerreichweite angeht - also wie viel vom Nutzer gewartet und nachgearbeitet werden muss, wenn einmal ein Fehler auftritt und wieviel Aufwand zur Abwendung eines zu großen Schadens getrieben werden muss.
Die immer wiederkehrende Behauptung, man wäre der einzige Kunde, der den Fehler hat, finde ich eine Farce.
Noch schlimmer, ist dass immer wieder behauptet wird, das Netzwerk des Kunden wäre zu schlecht für Nova. Stattdessen ist Nova zu schlecht für's Netzwerk.
Dass man das dem Kunden gegenüber nicht so äußern kann, ist mir klar.
Aber ich würde erwarten, dass jemand das Problem nach Jahren einmal grundlegend löst. Dies betrifft die Aussagekraft der Fehlermeldungen, das Sammeln der Absturzberichte, das Ableiten häufiger Ursachen daraus und das härten des Codes gegen diese häufigen Ursachen. Oder wenigstens sollte man dem Kunden eine Liste mit den wichtigsten Stichpunkten geben, was zu Fehlern führen kann - dann würde man natürlich offenbaren, wie empfindlich das Produkt ist...

Letztlich muss man also sehen, dass man als Benutzer oder Systembetreuer die Software in Watte packt und am besten gleich von der Festplatte aus arbeitet mit lokaler Lizenz.
Ja ich weiß, das ist nicht realistisch oder kosteneffizient - aber stabil.
Ansonsten muss man sich auf Fehler in der Nova einstellen und Sicherungen und Snapshots vorbereiten für den Fall der Fälle.
Lieferzeiten einhalten wird man aber auch dann nur mit Überstunden können.

Die beste Lösung wäre eine Kundenbasis, die eine stabile Nova fordert und klar kommuniziert, welche Fehler eben doch nicht so selten sind.
Wer möchte, kann mich gern unter spassmitnova@g-ingenieure.de kontaktieren. So richtig will ich mich nämlich noch nicht damit abfinden, dass man das nicht ändern können soll.
Ich finde die Software an sich wirklich gut für Mittelständische Unternehmen. Nur der Sprung ins 21te Jahrhundert ist noch nicht so ganz geschafft.
Vielleicht bin ich ja aber auch nur zu anspruchsvoll? Lasst mich gerne wissen, ob sich euer Problem hat lösen lassen (und vor allem wenn nicht).

Grüße!

Finde diese Auflistung sehr interessant. Auch wir haben mittlerweile so große Zeichnungen (Öffnen eines Layouts einer 3D Ansicht dauert auf einem leistungsstarken Rechner 45 Minuten) die erhebliche Rechnerleistungen benötigen. Das Problem dabei ist das Nova zu beschäftigt ist um die Lizenzen zu überprüfen. Wenn Nova dann etwas Luft hat kommt die Meldung das die Lizenz nicht mehr zur Verfügung steht. Ist man dann nicht am Rechner (Habe was besseres zu tun als zu warten) wird das Programm, ohne die Zeichnung zu speichern, geschlossen. Bei heutigen Programmen erwarte ich ein anderes Verhalten. Habe so schon eine Zeichnung die ich kaum mehr bearbeiten kann, wenn nicht gar nicht mehr. (Stellt sich noch heraus - bin am anderem Rechner am testen)

Das Problem mit den sporadischen Abstürzen haben wir aktuell auch wieder vermehrt.
Ich werde durch unseren Admin die Windows Versionen nach Updates prüfen lassen und beobachte weiter das Problem.

Wir haben bei großen Projekte auch oft die Meldung das aus fehlendem Speicher gelesen wird - soll heißen das der Arbeitsspeicher beschädigt wäre. Das ist der definitiv nicht. Der Fehler ist aktuell in einem Projekt (Sanitärberechnung) reproduzierbar. Der Mitarbeiter hat 5 Versuche gebraucht die zu berechnen. Der Fehler ist auch bei mehreren Rechnern aufgetreten. Das ist definitiv kein Arbeitsspeicher defekt sondern ein Programmfehler.

Die Meldung "Aus entferntem Speicher kann nicht gelesen werden" ist eine Meldung des von NOVA verwendeten Mcrosoft .NET Pakets - das sind Bibliotheken, die verwendet werden, weil NOVA mit Microsoft Visual Studio programmiert ist
In diesen Bibliotheken stecken Basisfunktionen, die die Nova dann verwendet (für Dateizugriffe, Netzwerkkommunikation, Bildschirmdarstellung, ...).

Der genannte Fehler kann dann zum Beispiel auftreten, wenn ein NULL-Pointer übergeben wird ...
"hä warte mal! halt stop... was soll sein?"
> für Nichtprogrammierer: Da wäre dann in der Programmierung was falsch:
> es wird von der NOVA bei .NET angefordert, etwas zu tun - jedoch wird nicht gesagt womit. Das führt zu "Verwirrung" (zu Recht) und dieser Meldung.
Es gibt auch andere Ursachenvarianten - ich kenne den Quellcode der NOVA nicht.
So eine Meldung tritt aber erfahrungsgemäß in dem beschriebenen oder in artverwandten Fällen auf (Suchen Sie mal den Meldungstext und fügen "Visual Studio" hinzu...)

Ich weiß auch, dass niemand (auch kein Programmierer) alles vorhersehen kann und daher Fehler einkalkuliert werden müssen.
Das heißt aber: antizipierender Umgang mit Fehlern zur Laufzeit.
Heißt: das Meiste vorab vermeiden, aber den Rest dann auch noch behandeln.
Ein Problem habe ich mit dem zweiten Teil.

Damit wären wir nämlich wieder mal beim Thema "Fehlerforensik":
> wer betreibt sie? Der Endkunde.
...oder hat bei jemandem schon mal der Support in die Ereignisanzeige geschaut und die Fehleradresse notiert, an der die NOVA abgestürzt ist? Für einen Programmierer wäre das doch eine "spannende" (notwendige) Information. Warum wollen die die partout nicht haben?
...Warum gibt es keinen NOVA-eigenen Fehlerbericht mit dem Zustand der Software zum Absturzzeitpunkt?
...und wer kennt nicht die Frage mit dem verschwörerischen Unterton nach ausstehenden Windows-Updates, einem besseren Rechner oder vermeintlichen Netzwerkproblemen? Irgendwie ist ohne jede Analyse immer schon gleich auf diesen Ursachenklassen der Fokus - nie bei der Software selbst. Das ist nicht selten auch Zeitverschwendung für den Support (und einen selbst).
> wer sollte die Fehlerforensik eigentlich betreiben? Ich denke zuerst einmal weder Menschen beim Support noch Menschen vor dem Rechner. Die Software selbst sollte automatisch einen Fehlerbericht erzeugen! Erst dann kann auch ein Mensch fundierte Aussagen treffen (die nicht einfach Glaskugellesen oder pauschales Durchprobieren möglicher Bedienfehler sind).
...so einen technischen Fehlerbericht würde die Software dann gleich zum Versenden an Trimble anbieten - mit allen relevanten Registern, dem Call-Stack, Speicherabbild, geöffneten Dateien, aktuellem Prozessschritt, idealerweise einem Pingtrace an Projektserver, Lizenzserver und das lokale Gateway, ...
Der Support hat mir auf solche Fragen mitgeteilt, das Führen eines Protokolls wäre "nicht möglich, weil imperformant"... Möglicherweise verstand dieser Mitarbeiter das so,dass Trimble die Debugversion an mich herausgeben soll - ich rede aber davon, dem Release eine fehlerforensische Funktionalität zu gönnen wie es vom großen Autodesk bis hin zum kleinen Ausschreibungstool doch eigentlich fast alle in irgendeiner Form machen.

Kurz: man kann selbst & sofort nicht viel tun, wenn dieser Fehler mit dem "Speicher" auftritt.
Was man aber mittelfristig tun kann, ist mit fundierten Fragen auf die Einführung eines Features zu drängen, das Informationen an die Entwickler zurückzuübertragen vermag und zu hoffen, dass wenn der Anbieter es oft genug hört, es fruchtet.
Wenigstens sollte man immer wieder fragen, wie die jetzt eigentlich genau wissen, was passiert ist ohne Fehlerbericht seitens der NOVA. Glaskugel? Transzendentes drittes Auge?

Wer sich den Spaß machen will, soll die Aussagen des Supports gern mal durch einen IT-Experten auf Plausibilität prüfen lassen.
Meine Lieblings-Highlights:

> Support: "die Kühllastsimulation dauert so lang, weil Sie zu wenig Arbeitsspeicher in Ihrem Rechner haben"
> Fakt: von dem eingebauten RAM war während der ganzen Simulation und Berechnung nur knapp die Hälfte belegt
> Für Nichtprogrammierer: wenn ich mehr leere Regale in eine Bibliothek stelle, geht es am Drehkreuz nicht schneller durch
(und ja: ich weiß, was ein Swapfile ist, aber bei halbvollem RAM interessiert das nicht und auch auf meinem Testgerät mit 196 GB RAM (kein Tippfehler) geht natürlich nix schneller)

> Frage von mir: "Warum laufen alle NOVA-Prozeduren nur auf einem CPU-Kern, obwohl seit 10 Jahren nur noch über mehrere Kerne Leistungssteigerung erreicht werden kann, weil die Taktfrequenzen seitdem nicht mehr steigen - aber sehr wohl die Anforderungen z.B. an die Kühllast?"
> Support: "Die Kühllastsimulation und andere Prozesse lassen sich in der Programmierung nicht parallelisieren. Kaufen Sie einen "Ferrari"-Rechner mit maximaler Taktfrequenz"
> Fakt: Die Strahlengangssimulation ist algorithmisch nach Tagen aufteilbar (denke ich zumindest, wenn ich mir das ansehe). Jeder CPU-Kern kann sich um 1 Tag kümmern und wenn (bei 4 Kernen) 4 Tage berechnet sind, geht es mit den nächsten 4 weiter. Auch eine Aufteilung nach Räumen, Gebäuden oder anderen logischen Dimensionen wäre denkbar. Ebenso der PDF-Export nach einzelnen PDFs getrennt und das darstellen mehrerer Views nach View getrennt (schon mal 4 Views in einer Modellzeichnung angelegt und gemerkt, wie es irgendwann kriecht, wenn mehr und mehr Geometrie enthalten ist?)
> Für Nichtprogrammierer: Ja - einen Ferrari-PC kaufen, macht die Simulation, die Views, die PDF-Erzeugung, ... (etwas) schneller. Aber NOVA fährt diesen Ferrari immer nur im 1. Gang (auf einem CPU-Kern). Selbst ein Mittelklasse-PC bietet mit 4 Kernen x 3 GHz mehr Leistung an (12) als eine Hochleistungs-Workstation auf nur 1 ihrer 4 Kerne x 4 GHz (4)... Die Software fordert die vom System bereitgestellte Leistung einfach nicht ab.
(und ja, ich weiß, dass es zu nicht/wenig parallelisierbaren Datenpfaden kommen kann - aber doch nicht bei Dingen, die ich sogar "händisch"parallelisieren kann, indem ich den einen Teil auf dem einen PC anstoßen kann und den anderen auf einem anderen und kollisionsfrei zu einem gültigen, schnelleren Ergebnis komme... Das ist doch Unfug)

> Frage von mir: "Wie lang darf eine Kühllastsimulation dauern?"
> Support antwortet quasi, dass es bei ihnen alles schnell läuft; auch mit "großen" Projekten
> Fakt: ich habe ein Projekt hingeschickt, den MA die Simulation und Berechnung starten und mir das Ergebnis zurückschicken lassen sobald es fertig ist, damit er seine Behauptung beweisen kann - es dauerte doppelt so lang wie bei uns. Dann war es auf einmal "natürlich klar", dass "so ein" Projekt so lange braucht...
> Für Nichtprogrammierer: Es klingt sicher verlockend, wenn der Support behauptet, der Chef müsste "nur eine Höllenmaschine von PC locker machen" (also hauptsache teuer) und alles ginge schneller - aber die zu erwartenden Zeitgewinne stehen ab einem gewissen Punkt nicht mehr im Verhältnis zu den Kosten. Dennoch "funktioniert" das: Sie werden Ihrem Chef ja nicht gern verraten, dass das teure Teil nicht viel gebracht hat, das SIE unbedingt wollten - richtig klasse so ein Ergebnis: nix gelöst, aber keiner kann mehr was machen ohne das Gesicht zu verlieren. Also bleibt's und das Geld ist weg - besser hätte man einen separaten PC hingestellt, auf dem in Ruhe die Kühllast rattern kann, während man auf seinem eigenen Rechner schon wieder was anderes in der NOVA tun kann.
(Und ich bin jetzt mal ganz gewagt: warum kann ich solch aufwändige Berechnungen nicht an einen zentralen NOVA-SimServer schicken, den die mir als Software bereitstellen, damit das im Hintergrund laufen kann? Da würde ich sogar für bezahlen, wenn es gut gemacht ist und der preis plausibel - statt meine User in VMWARE ESXi einweisen zu müssen.)

> Frage von mir: "Warum kann ich in den Einstellungen, die automatische Projektkomprimierung auswählen, aber es passiert nie was? Auch keine Meldung, dass etwas nicht funktioniert hat?"
> Support: "Na das ist doch seit Jahren bekannt, oder?"
> Fakt: habe ich dann mal nachvollzogen: ja, das ist seit vielen Verisonen so - und jetzt?
> Für Nichtprogrammierer: "psychologisch" gesehen wird hier der Ansatz der Normalisierung betrieben: obwohl es ein Problem gibt, ist es angeblich "mein eigener" Fehler, dass ich mich nicht endlich damit abfinde "wie alle anderen" statt zu erwarten dass der Fehler behoben wird (zum Beispiel wenigstens gar nicht erst eine sinnlose Option angeboten zu bekommen, die falsche Erwartungen weckt). Dabei muss man wissen: eine unterlassene Projektkomprimierung kann bei n4p-Dateien ab 2GB zum Datenverlust führen... da geht's also nicht um irgendeine kleine Nörgelei oder "nur" um die Performance...

Stimmt also mit dem User etwas nicht, der sich immer noch nicht daran gewöhnt hat, "dass das eben so ist"?
Ich empfehle einmal den Wikipedia Artikel zu "Erlernte Hilflosigkeit" und "Doppelbindungstheorie" zu lesen.
Zusammengefasst:
Sie erhalten vom Support widersprüchliche Botschaften:
> "Es liegt AN IHNEN SELBST wenn die Software langsam ist oder abstürzt" (Wegen Hardware, Netzwerk, ...)
Das hieße ja dann, sie KÖNNEN sich selbst RETTEN indem sie einfach teurere Hardware kaufen oder die Fehler im Netzwerk finden lassen.
> "Es liegt NICHT AN IHNEN wenn die Software langsam ist oder abstürzt" (wenn man konkreter nachbohrt und schrittweise mögliche Fehlerursachen im eigenen System ausschließt und von denen mal konkret gezeigt bekommen will wo es angeblich hakt)
Das hieße, sie KÖNNEN also doch NICHT GERETTET werden.
Was denn nun? Bin ich schuld oder nicht? Kann mir überhaupt geholfen werden oder nicht?

Viele geben dann einfach auf und werden zum "depressiven" Benutzer, der einfach alles hinnimmt und nur ab und an noch vor sich hin flucht oder mit anderen Leidensgenossen sarkastisch darüber lacht, dass man in dem gleichen Boot mit Loch sitzt... Untergehen tut man aber trotzdem jeden Tag.
Akzeptieren Sie also so ein Verhalten nicht wenn Sie es bei sich selbst feststellen - es gibt durchaus Möglichkeiten zur Verbesserung.
> Lassen Sie pauschale Behauptungen sachkundig überprüfen! Schließlich kann ja auch wirklich mal was mit dem Netzwerk nicht stimmen - das will man doch wissen, oder? Oder es fällt eben als Ursache weg.
> Hinterfragen Sie die Argumentation/Methodik des Supports: Wie können z.B. Schlüsse gezogen werden, wenn nicht alle Fakten klar sind? Wieso will man dort garnicht genau wissen, was beim Absturz technisch passiert ist und stellt immer gleich auf Benutzungs- und Systemfehler ab? Wo ist der Absturzbericht? Wo ist der Absturzbericht? Wo ist der Absturzbericht?
> Lassen Sie sich nicht in ein "keiner weiß woran es liegt" einlullen sondern schließen Sie systematisch Fehlerursachen aus (schonmal einen Projektserver auf den gleichen Rechner wie die NOVA installiert und verglichen, wie lange Öffnen per Datei und Öffnen via Projektserver aus dem gleichen Ordner dauern? Danach erzählt Ihnen keiner mehr was von Netzwerkproblemen)
> Lassen Sie sich nicht in die Verteidigungsposition drängen sondern setzen Sie mit konkreten Fragen umgekehrt den Hebel an. Dazu muss man auch kein IT-Experte sein. Grundlegend logisch denken kann jeder hier - sonst könnte man diesen Beruf garnicht machen.
> Tauschen Sie sich mit anderen aus, um festzustellen, dass nicht nur Sie betroffen sind. Das motiviert zum Weitermachen - auch die anderen.
> Erwarten Sie nicht nur von sich etwas (bei der Fehlersuche mitzuwirken) sondern auch (auch!) vom Anbieter der NOVA (einen Fehlerbericht mit einzuprogrammieren oder wenigstens die paar Infos aus der Ereignisanzeige abzufassen, die dort auch heute schon stehen).

Ich beneide übrigens den Support nicht und ich denke auch überhaupt nicht, dass dort die Ursache liegt - die Jungs und Mädels müssen ja auch mit dem arbeiten, das sie haben.
Machen Sie ÜBER den Support Druck auf das dahinterliegende Personal - machen Sie NICHT DIREKT DEM SUPPORT Vorwürfe.
Das führt nur zu genau diesen oben genannten Schutzbehauptungen. lassen Sie die aber auch nicht aus Mitleid "durchrutschen" . ein Job ist ein Job.
Sein Sie also einfach bestimmt und sachlich.

Ich denke, es fehlt einfach ein Informationspfad zum Entwickler zurück über die Probleme zur Laufzeit - vor allem im DETAIL und nicht nur "DANN WAR DAS FENSTER WEISS" - daraus könnte ich auch nichts ableiten.
Dieser Informationsrückfluss ist im Moment quasi nichtexistent, wie mir scheint, oder funktioniert nur "tröpfchenweise".
In Zeiten von BIM und BCF-Workflow sollte eigentlich jedem klar sein, dass frühzeitiger, vollständiger, klarer Informationsfluss ohne unnötige Hürden hilft, Probleme schneller ODER ÜBERHAUPT lösen zu können.
Das ist auch in der Softwareentwicklung kein Novum - jeder Informatiker hört an der Uni auch Lehrveranstaltungen zu Projektmanagement und nicht nur zu Entwurfsmustern und Algebra.

Und zu guter Letzt:
Nicht die Existenz dieser Probleme stört mich - ich streite mich nicht mit der Realität.
Leid gehört eben zum Leben.
Nur vermeidbares Leid muss doch nicht auch noch obendrauf sein.
Oder?

Hallo Stephan

Geht uns extrem ähnlich und ist sehr ärgerlich.
Gut geschrieben das Ganze. Man(n) könnte noch vieles ergänzen, das so in den letzten Jahren aufgelaufen ist.

Ich warte auch schon lange auf "das" Neue im Nova. Bisher war zumindest für uns nur viel angefangen, aber nicht fertiggmacht.
Die "Neuen Stammdaten" und generieren.... Toll, wenn es den mal klappt. und es ist ein Zufall, das die richigen Armaturen kommen.
Rohrleitungsbau mit diesem Stammdaten.. eben falls super.. nur schade, gibt es dann keine "Anschliessbaren" Armaturen aus neutralen Bauteilen..

Und ja, ich kenne DOS und habe noch DOS im Einsatz :)
Zusammen mit Novell Lite funktioniert noch vieles :) der Server ist ein 486 mit 32 MB RAM.
Darauf läuft eine ganze Geschäftsverwaltung inkl Lager, Buchhaltung und so weiter :)