---

KQU-04_UPE.zip KQU-05_UPE.zip

Kurve aus Querschnitt funktioniert nicht.
Anbei zwei Testmodelle.
Modell KQU-04*.ASM  --  Kurve funktioniert nicht
Modell KQU-05*.ASM  --  Ein Bauchaufzug erzwingt das Regenerieren der Kurve

Modell KQU-04_UPE.ASM
Eine Notiz in KQU-04_1_2_SKEL_UPE.PRT steuert die Anzahl der Leisten (Säulen) in der BG
KQU-04_1_2_UPE.ASM.
Nicht gewünschte Leisten werden mit Pro/Prog unterdrückt.
In der BG KQU-04_1_UPE.ASM wurde ein Querschnitt (Schnitt) erzeugt.
In der BG KQU-04_1_UPE.ASM wurde eine Kurve durch Q-Schnitt nutzen erzeugt.
Problem: Werden Leisten der BG KQU-04_1_2_UPE.ASM unterdrückt, so wird die Kurve aus dem Querschnitt nicht regeneriert und ist damit falsch.
Nachfolgende Änderungen der Abmessungen von KQU-04_1_2_GRK_UPE.PRT oder
KQU-04_1_1_UPE.PRT haben keinerlei Auswirkung auf die Kurve. Die Kurve bleibt eingefroren.
Ein temporäres nachziehen der Kurve lässt sich erzwingen, wenn man die BG KQU-04_1_2_UPE.ASM umdefiniert (RMT auf die BG / Definition editieren / und ohne jegliche Änderung sofort grüner Haken).

Modell KQU-05_UPE.ASM
Durch einen Bauchaufzug erzwinge ich das Regenerieren der Kurve (der Querschnitt stimmt), indem ich die BG KQU-05_1_2_UPE.ASM mit einem Versatz einbaue. Diesen Versatz über eine Beziehung steuere. Und den steuernden Parameter wiederum bei jedem Regenerieren entweder auf 0 oder auf 0.001 stelle. Den kleinen Fehler von 0.001mm können wir tolerieren. Zu bedenken sind dabei möglicher weise auftretende Durchdringungen, die wiederum einen Fehler der Kantendarstellung in der Zeichnung zur Folge haben können.
Versatz: gesteuert durch REG_VERSA:0

Beziehung im Skelett:
IF REG_VERSA <= 0
REG_VERSA = REG_VERSA + 0.001
ELSE
REG_VERSA = REG_VERSA - 0.001
ENDIF
/*

Durch diesen Bauchaufzug gelingt es der Kurve aus dem Querschnitt die aktuellen Abmessungen aufzuzwingen.

Für etwaige Lösungsvorschläge des Problems ohne Bauchaufzug bin ich sehr dankbar, kann aber mit meiner Problemlösung leben.
Meine hauptsächliche Motivation dieses Verhalten von Kurven aus Querschnitten aufzuzeigen liegt darin, interessierte Pro/E-User auf das Problem aufmerksam zu machen.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

KQU_irgendwas.gif

Möglicherweise habe ich das Pro/blem nicht verstanden (ist aber auch schwierig bei so vielen KQUs...).
Jedenfalls macht Pro/E aus meiner Sicht nichts, was ich mir nicht erklären kann. Die Änderung der Komponentenanzahl über Pro/program ist nach meinem Verständnis für Pro/E aufgrund des direkten Programmeingriffs nicht erkennbar und löst somit keine Regenerierung aus. Diese muss dann von Hand angestoßen werden; dann geht es.
In Deinem Fall sind 3 Regenerierungsaufrufe erforderlich:

1. Reg.: Übergabe des Parameters vom Skelett an 1. BG,
2. Reg.: Pro/Program ändert (nachträglich) die Komponentenanzahl der BG
3. Reg.: Neue Komponentenzahl in nächster BG erkannt und Schnitterneuerung.

Das ist meiner Ansicht nach ein Fall für eine weblink-Applikation, die bei Änderung der Parameter die entsprechenden Regenerierungen automatisch anstößt.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Modell-Player.jpg

Dass das nicht Funktionieren einer Kurve ein zu erwartender Umstand sein soll, das will ich vorerst doch nicht glauben.

Wenn sie die Leistenzahl ändern.
Die Kurve diese Änderung aber nicht abbildet.
Und nun die Abmessungen des Grundkörpers in KQU-4_1_1_UPE.PRT ändern
Regenerieren
So bleibt die Kurve weiterhin unverändert!

Wer das erwartet, hat von Pro/E nicht mehr viel zu erwarten.

Obendrein: Wenn man diesen Modellzustand speichert und anderntags wieder aufruft, so ist auch jetzt noch die Kurve falsch dargestellt! Woher Pro/E weiß wie die Kurve gestern ausgeschaut hat ist mir ein Rätsel.
Und, wer sollte denn jetzt bitte wissen, ob, wo und wie man in ein komplexes Modell einzugreifen hat um eine Kurve aus Querschnitt in ein Skelett einer Unterbaugruppe korrekt weiterzureichen.

*Das Regenerieren muss von Hand angestoßen werden.*
Nach dem Ändern der Leistenanzahl, die Kurve wird falsch dargestellt, stoße ich also das Regenerieren von Hand an, indem ich den Modell-Player starte, KE regenerieren aktiviere, an den Modellanfang gehe und den ICON *zum letzten KE im Modell gehen* klicke.
Jetzt bin ich der Meinung, dass alle KE meines Modells regeneriert wurden.
Die Kurve ist aber weiterhin falsch!
Das habe ich nicht erwartet – das erschreckt mich!

------------------
mfg HP

[Diese Nachricht wurde von call4help am 29. Jan. 2010 editiert.]

[Diese Nachricht wurde von call4help am 29. Jan. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

KQ_irgendwas_2.gif

Zitat:

---

Original erstellt von call4help:
...das will ich vorerst doch nicht glauben. [...]
Wer das erwartet, hat von Pro/E nicht mehr viel zu erwarten. ...

---

Immer langsam und nicht gleich die Flinte ins Korn oder Pro/E in die Ecke werfen. Das was Du da machst ist so, wie Du es machst nicht unbedingt eine Standardanwendung:

• Ein Querschnitt muss logischerweise im allerletzten Schritt, also nach allen modellbildenden KEs berechnet werden, da davon auszugehen ist, dass jedes modellbildende KE wiederum den Querschnitt verändert. Nicht umsonst ist der Querschnitt deshalb im Ansichtsmanager und nicht beim Einfügen angesiedelt.
  
• Und dann kamen die ganzen Anlagenbauer und haben geheult, dass Sie so gerne 2D-Fundamentpläne aus bodennahen Querschnitten erstellen möchten. Darauf haben die Pro/grammierer ein Feature geschaffen, dass einen Querschnitt in eine Kurve übertragen kann.
  
• Und dann kam der nächste Kunde und benutzte den zur Kurve mutierten Querschnitt wiederum zur Modelldefinition. Das funktioniert dann netterweise auch noch im statischen Zustand, d.h nach dem vollständigen Durchregenerieren des gesamten Systems.
  
• Jetzt möchten Sie der ganzen Sache noch einen drauflegen und den Querschnitt in einem dynamisch sich verändernden Modell nutzen. Und damit nicht genug, soll die Dynamik der einzelnen Komponenten auch noch über Ihren programminternen Eingriff gesteuert werden.
  

Also ich finde es tatsächlich beeindruckend, dass das Ganze sequentiell, also mit mehrfachem Regenerieren funktioniert.

Blöde Frage:
Warum verwenden Sie nicht einfach den für so etwas von PTC vorgesehenen Weg über Layout? Der Vorteil liegt in der Gleichzeitigkeit der Veränderungsinformation. Wird der Parameter im Layout verändert, "wissen" alle durch Deklaration verbundenen Komponenten gleichzeitg über eine Änderung der Anzahl Bescheid und werden demnach von innen nach außen regeneriert. Wenn man dann die Komponntenanzahl noch über ein Muster steuert, braucht Pro/E auch nicht auf irgendwelche internen Programmeingriffe zu reagieren.

Dann geht es, wie ich finde viel einfacher, logischer und damit nachvollziehbarer.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Herzlichen Dank, dass sie bereit sind sich meines Problems anzunehmen.

Da sie mir den Weg über ein Layout empfehlen, fällt mir auf, dass ich nicht explizit darauf aufmerksam gemacht habe, dass es sich bei den von mir hochgeladenen Modellen um Testmodelle handelt, die ich ausschließlich zum Testen des angesprochenen Problems, und auf dieses reduziert, gebastelt habe.
Das Modell, in dem die nicht funktionierende Kurve auffällig wurde, ist Teil eines *riesigen* Basismodells (wir nennen es Vorlagenmodell), das über Layout (eine mehr als umfangreiche Tabelle) gesteuert wird. Die betroffene Baugruppe selbst wird über mehre Hundert Eingabeparameter aus einer Textdatei, regenerieren aus Datei, gesteuert und treibt seinerseits alle der BG folgenden Komponenten. Die aus dem Querschnitt entstehende Kurve steuert in den folgenden Komponenten Einbaulagen, Materialschnitte und unzählige andere Abhängigkeiten.
Die Sache stellt sich mehr als umfangreich dar, es handelt sich dabei um ein Modell, das man wirklich sehr, sehr komplex nennen kann. Das Basismodell enthält an die 100 Werkstattzeichnungen und beinhaltet etwa 2000 Komponenten (Normeile nicht eingerechnet).

Wenn sie mir sagen, dass es sich bei meiner Vorgehensweise *nicht unbedingt um eine Standardanwendung* handelt, dann hätte ich aber gerne eine Liste von PTC mit den Standardanwendungen, damit ich dann auch weiß, was funktioniert.

An diesen Vorlagemodellen, wir haben in unserer Abteilung im Wesentlichen 7 Stück (Varianten) davon, die sich wiederum aus Basismodellen (so an die 200 Stück) zusammensetzen, arbeite ich nun seit etwa 10 Jahren. Und das funktioniert super!
Kopieren des passenden Vorlagenmodells zum Auftragsmodell
Regenerieren aus Datei des treibenden Modells – mein Problemmodell.
Layout der folgenden BG (Skelett) ausfüllen
Regenerieren - Regenerieren
Und ein Riesentrum komplexer Bauteil ist im Grunde fertig.
Die Werkstattzeichnungen sind vorbereitet und harren nur mehr einer optischen Aufbereitung.

Nur: Es ist vieles davon falsch, ein Schaden von etwa 500.000€, zusätzlich Lieferterminüberschreitung um etwa 3 Monate und damit wird eine saftige Pönale fällig - weil eine Kurve nicht regeneriert wird. Da wird der Herr Geschäftsführer aber schön schauen, wenn ich ihm sage, dass PTC zwischen *funktionierenden* und *nicht Standard* Anwendungen unterscheidet, und ich in meinem Pech eine nicht als solche ausgewiesene *nicht Standard Anwendungen* erwischt habe.

Ich für meinen Teil bin mehr als froh, dass mir das rechtzeitig aufgefallen ist, dass ich einen Bauchaufzug gefunden habe um das Problem zu umgehen - bin aber in Sorge, dass da noch andere *nicht Standard Funktionalitäten* in meinen Modellen schlummern könnten.

Ich habe inzwischen gelernt, Modelle *meist* so zu basteln, dass ein mehrfaches Regenerieren nicht erforderlich ist. Funzt was nicht, oder sicher ist sicher, man regeneriert ein zweites mal.
Bisher war ich der Meinung, dass sich mit dem Modell-Player, bei entsprechender Einstellung, ein Modell tatsächlich KE für KE durchregenerieren lässt. Bei Kurven aus Querschnitt ist dem aber nicht so, wie ich erkennen musste. Die bleiben einfach beharrlich stecken, bis man *händisch* eingreift. Und da muss man dann schon wissen wo man hinzugreifen hat, wenn man überhaupt erkennt, dass da etwas nicht stimmt.
Für mich ist es eine Bombe, die mit diesem Problem in so manchen Modellen lauert.
Und aus diesem Grund habe ich es aufgezeigt.

Fällt mir erst nachträglich auf:
Was sie da in ihrem Film zeigen güldet nicht:
Ich habe mein Testmodell im Augenblick zwar nicht zur Verfügung da ich zu Hause bin, glaube aber folgendes sagen zu können:
Ob man etwas über ein Layout oder eine Notiz steuert sollte meiner Meinung nach keinerlei Unterschied machen, da in beiden Fällen von einem zentralen Skelett aus ein Parameter etwas steuert – einmal wird der Parameter durch die Notiz, das andere mal vom deklarierten Layout verändert.
Zweitens fällt mir auf, dass sie ein Muster gebastelt haben – das geht mit meinen Leisten nicht, da die Sache ein bisserl komplizierter ist als im Testmodell reduziert dargestellt. Benennung *-04* und *05*, da die Varianten *-01*, *-02*,*-03*, zu sehr vereinfacht wurden und noch funktionieren.
Und als Drittes scheint mir ihre Kurve um eine Baugruppenebene höher zu liegen als dies in meinem Modell der Fall ist – das macht einen Unterschied.
Das explizite händische Regenerieren einer BG, eines Teiles oder gar eines KE irgendwo versteckt im Modell, nach einer Anpassung, ist aus Gründen der Komplexität des Modells nicht möglich (den usern nicht zumutbar). Das muss mit *Regenerieren automatisch* funktionieren!

------------------
mfg HP

[Diese Nachricht wurde von call4help am 29. Jan. 2010 editiert.]

[Diese Nachricht wurde von call4help am 29. Jan. 2010 editiert.]

[Diese Nachricht wurde von call4help am 29. Jan. 2010 editiert.]

[Diese Nachricht wurde von call4help am 30. Jan. 2010 editiert.]

[Diese Nachricht wurde von call4help am 30. Jan. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von call4help:
...

---

Hallo call4help.

Selbstverständlich kann ich weder der Kompelxibilität Ihrer Modellanforderung, noch Ihren sonstigen Ansprüchen und Fähigkeiten im Einzelnen gerecht werden. Was ich versucht habe zu verdeutlichen, ist dass, in für mich nachvollziehbarer Weise, eine Querschittsdefinition erst erfolgen kann, wenn die Volumendefintion abgeschlossen ist und sich daher bei der Verwendung einer Kurve aus Querschnitt für nachfolgende Modellierungsvorgänge Probleme ergeben müssen, oder eben ein mehrfaches Regenierieren notwendig machen.
Gleiches gilt in Ihrem Beispielmodell insbesondere für die Kombination mit dem Pro/Program-Eingriff.

Mit dem Hinweis auf diese von mir beobachteten Zusammenhänge wollte ich nicht Ihre Modellierungsfähigkeiten in Frage stellen, sondern eine Hilfestellung zum besseren Verständnis der Schwierigkeiten geben. Gleiches gilt für den im Film dargestellten Altenativweg. Er zeigt lediglich, dass grundsätzlich Lösungen möglich sind.

Bei der von Ihnen angegebenen Modellkomplexität und den aufgeführten Fehlerkosten kann ich nur dringenst dazu raten, sich höchst qualifizierte Unterstützung zu suchen/holen.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich habe mir inzwischen Ihr Modell noch einmal in den einzelnen Regenerierungsphasen angesehen und finde meinen Denkansatz darin bestätigt:

Ausgangssituation:

Ändern des Parameters Anz_Lei aus der Hauptbaugruppe im Skelett:

Regenerieren aus der HBG

1. Regenerierung

• Die Regenerierung startet aus der HBG und erkennt keine Änderung derselben. ->Keine Änderung
  
• Die Regenerierung geht weiter in die UBG und erkennt keine Änderung derselben.  ->Keine Änderung
  
• Die Regenerierung ist im Skelett HBG und erkennt die Änderung derselben.  ->Änderung des Parameters
  
• Wegen des Pro/Prgramm-Bezugs direkt auf den Skelett-Parameter Anz_lei:0 hat Pro/E den Parameter Anz_lei nicht in der Parameterliste der UBG bzw. HBG und hat daher auch keine Ursache, diese erneut zu Regenerieren. ->Keine Änderung (Abhilfe siehe unten)

2. Regenerierung:

• Die Regenerierung startet aus der HBG und erkennt keine Änderung derselben. ->Keine Änderung
  
• Die Regenerierung geht weiter in die UBG und erkennt dort den geänderten Parameter Anz_lei aus dem Skelett.  ->Änderung der Baugruppe.
  
• Wegen des durch den Pro/Programm-Eingriff gesteuerten Änderns der Komponentenanzahl, fehlt dem Regernerierungsprozess der HBG eine Information über diese Änderung. Daher erfolgt keine Änderung der HBG.

3. Regenerierung:

Die Regenerierung startet aus der HBG und erkennt die geänderte Komponentenzahl der UBG und ändert dementsprechend den Querschnitt, sowie die Kurve aus Querschnitt.

Abhilfe:
Der erste Regenerierungaufruf lässt sich einsparen, indem der Pro/Program-Verweis auf die Skelettkomponenten durch einen gemeinsamen Layout-Parameter ersetzt wird, also anstatt Anz_lei:0 nur Anz_lei und Anz_lei deklariert und gesteuert in Layout. (Man kann ja mehrere Layouts deklarieren).

Der zweite Regenerierungsaufruf lässt sich einsparen, indem die Komponenten anstatt über Pro/Program mit Hilfe eines Musters eingebaut werden. Das dürft zugegebener Weise modelltechnische nicht ganz einfach zu realisieren sein. Daher mein Vorschlag es eventuell mit einer Weblink-Appliaktion oder Map-Key für mehrfaches Regenerieren beim Ändern der Leistenanzahl zu versuchen.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wiederum ohne das Modell vor mir zu haben folgender Einwand:
Ist durch eine Veränderung der Unterbaugruppe, die in meinem Basismodell durch eine Berechnung der Leistenlage und Unterdrücken mit Pro/Prog von nicht benötigen Leisten über einen Mapkey mit J_LINK aus dem Skelett der Unterbaugruppe erfolgt, die Kurve eingefroren, dann hilft auch kein mehrmaliges Regenerieren der obersten Baugruppe um die Kurve nachzuziehen. Im Testmodell simuliert durch Unterdrücken mit Pro/Prog in der Unterbaugruppe, was das gleiche Ergebnis zeigt. Auch eine Änderung der Abmessungen irgendeines Körpers in der Gesamtbaugruppe zieht kein Nachziehen der Kurve nach sich – die Kurve ist eingefroren. Lediglich ein direkter Eingriff in die Unterbaugruppe (RMT auf die Unterbaugruppe / Definition editieren /sofort grüner Haken) zieht die Kurve nach. Interessanter Weise wird der Querschnitt aus dem die Kurve entsteht aktuell gehalten. Der Querschnitt stimmt – die Kurve aus Querschnitt ist falsch.
Aus den verschiedensten Gründen wird von mir nur ein Layout und das im Skelett der obersten Baugruppe deklariert. Auch das Mehrfache deklarieren eines Layouts vermeide ich strikt.
Wie schon gesagt, der Weg über ein Muster ist nicht gangbar, der vorgeschlagene zentrale Parameter nur mit immensem Aufwand und unter Verkomplizierung des gesamten Modells möglich und daher zu verwerfen, und auch ein mehrfaches Regenerieren hat keinerlei Auswirkungen.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

call4help_1.wmv.txt call4help_2.wmv.txt

Tja: 0help4call4help   

Die im Folgenden aufgelisteten Aussagen von Ihnen kann ich in WF4 und WF5 nicht bestätigen (siehe Film call4help_1.wmv).
Vielleicht ein Problem der WF3 oder der Wochenversion?

Zitat:

---

Original erstellt von call4help:
... Auch eine Änderung der Abmessungen irgendeines Körpers in der Gesamtbaugruppe zieht kein Nachziehen der Kurve nach sich – die Kurve ist eingefroren. Lediglich ein direkter Eingriff in die Unterbaugruppe (RMT auf die Unterbaugruppe / Definition editieren /sofort grüner Haken) zieht die Kurve nach. Interessanter Weise wird der Querschnitt aus dem die Kurve entsteht aktuell gehalten. Der Querschnitt stimmt – die Kurve aus Querschnitt ist falsch. ...

---

Bei mir wird bei einer Änderung an einer Komponente nichts eingefroren, sondern vielmehr gleich alles einschließlich der KaQ richtig regeneriert.

Ich denke, Sie werden gute Gründe für Ihre Vorgaben und Modellierungsart haben.
Unverständlich ist aber aus meiner Sicht Ihre strikte Vermeiden der Mehrfachdeklaration eines Layouts.  Tatsächlich macht genau das den signifikante Unterschied eines Layouts gegenüber einem Skelett aus:
Eine Parameteränderung im Layout wird allen per Deklaration verbunden Elementen gleichzeitig mitgeteilt und löst überall die Regenerierung aus. Vom Skelett aus müssen Parameteränderungen einzeln über Beziehungen (siehe auch Ihr Pro/Program) zugewiesen werden.

Fall Sie sich doch zueiner Layoutnutzung durchringen können, funktioiert das Ganze auch ohne Ihren versetzenden Bauchaufzug mit einem einzigen ganz normalen Regenerierungsaufruf:

• Layout mit Parameter anz_lei
  
• Layout deklarieren auf Skelett und Leisten
  
• zusätzlicher Punkt rel. Koord in Komponente Leiste
  
• KE-Beziehung : 1. Punktmaß=anlei

Bei einer Änderung der Leistenanzahl im Layout wird sofort die gesamte HBG einschließlich KaQ vollständig regeneriert (siehe Film call4help_2)

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mal eine kleine Frage am Rande: Was sagt eigentlich die kleine Regenerierungsampel während des ganzen Spielchens.
Sollte diese während der Aktion die Farbe Grün zeigen, obwohl noch etwas durch eine nachfolgende Regenerierung geändert wird, wäre dies ein sehr guter Grund, PTC einen entsprechenden Call aufzumachen. Sollte diese aber beharrlich die Farbe Gelb zeigen, kann man Pro/E noch nicht mal einen Vorwurf machen.
(Bitte um Entschuldigung für die Frage, aber ich habe zu Hause kein Pro/E, mit dem ich es testen könnte.)

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Link durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel • Unities • kLEINSCHREIBUNG

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wenn sich mein Modell bei mir so verhielte wie sie es mir von ihnen schildern, dann gäbe es diesen Beitrag nicht! Und wenn ich dreimal regenerieren muss, ich könnte damit leben. Aber bei mir, da ändert sich die Kurve überhaupt nicht mehr. Wie schon gesagt, auch wenn ich mehrmals mit dem ModellPlayer darüber gehe, also, wie ich glauben muss, tatsächlich KE für KE regeneriere - die Kurve ändert sich nicht. Erst, wenn ich die entsprechende BG durch umdefinieren aktiv anstoße, dann wird die Kurve nachgezogen. Auch Kurvensegmente, die mit der Problembaugruppe nichts zu tun haben, aber inzwischen geändert wurden, werden erst dann nachgezogen. Die Kurve ist eingefroren bis man händisch eingreift.
Zum Layout:
Wenn ich allein wäre, dann würde ich natürlich Layouts sonder zahl verwenden. Dann würde ich diese wahrscheinlich auch mehrmals in Skeletten von Unterbaugruppen deklarieren.
An meinen Modellen arbeiten aber zumindest 3 Konstrukteure (es sollten aber auch mehr sein können) gleichzeitig, wobei einer von ihnen die Hauptbaugruppe bearbeitet (das ist der Kapo). Und die Burschen machen das sehr gut. So können alle Unterbaugruppen (Konstrukteure) betreffende Änderungen zentral gesteuert werden, und die Konstrukteure der einzelnen Bauteile können ihre Baugruppen trotzdem unabhängig voneinander gestalten. Concurrent Engineering – ist das, was ich als oberstes Gebot ermöglichen muss. Es muss auch sicher gestellt sein, dass das Team, das an einem Modell arbeitet, auch mit den gleichen Daten werkt. Daher, auch aus Gründen der einfacheren Wartung der Modelle (ein Großteil der verbauten Modelle in der Hauptbaugruppe sind für sich wiederum abgeschlossene Vorlagenmodelle), daher: Ein oberstes, zentrales Skelett (das in Wirklichkeit auch schon in einer Unterbaugruppe steckt), aus Datei regeneriert mit einer Unmenge an steuernden Daten – In einer parallelen Baugruppe, die bereits Daten aus dem zentralen Skelett erhält, ein darauf deklariertes Layout, eigentlich nur um die Dateneingabe zu erleichtern (ausfüllen einer Tabelle) und von diesem Skelett werden in Form von Parametern, oder über Pub und KopGeo die notwendigen Referenzen nach unten verteilt. Die Gefahr, dass aus Unwissenheit, aus irgendeiner dummen Fehlleistung, unterschiedliche Daten in einem Modell herumgeistern (was mit mehrfach deklarieren eines Layouts möglich wäre, weil einer aus dem Team sich durch deklarieren eines anderen Layouts eine Konstruktionsvariante angeschaut hat und vergaß dies wieder zurückzusetzen) diese Gefahr ist mir einfach zu groß. Meine Erfahrung: Wenn irgendwo in einem Modell die Möglichkeit schlummert, dass ein Anwender etwas anstellen kann, dann wird da auch was angestellt. Wir wandern eine Gratwanderung zwischen möglichst großen Freiheiten für jeden einzelnen, und der gleichzeitigen Sicherstellung des gemeinsamen Zugreifens auf zentrale Daten – ich habe Angst vor Katastrophen.
Bitte glauben sie nicht, dass ich stur bin, wenn ich ihren Vorschlag des mehrfachen Deklarierens eines Layout, oder mehrerer Layouts nicht annehmen kann. Wir haben unsere Gründe wie ich versuchte darzulegen. Es ist mir auch bewusst, dass es sich bei unserer Arbeitstechnik um eine sehr spezielle handelt.
Ich werde sicherlich noch ein wenig an der Sache daran bleiben. In meinen Vorlagenmodellen habe ich inzwischen den Bauchaufzug nachgebastelt.
Wenn ich mehr weiß, melde ich mich.

------------------
mfg HP

[Diese Nachricht wurde von call4help am 30. Jan. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es würde mich auch interessieren, was da noch herauskommt.
Insbesondere würde ich einen Test mit einer anderen WF oder wenigsten einer anderen Wochenversion machen.
Meine Filme sind nicht nachgearbeitet, sondern es funtkioniert genau so.

Viel Erfolg!

PS: Ich habe mir schon oft gewünscht, dass man Skelett-Parameter wie ein Layout deklarieren könnte. Das wär`s dann nämlich.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mehrfach_Regenerieren.gif Massaenderung_und_Regenerieren.gif

Guten Abend zusammen,

ich habe mir das ganze mal mit WF3 M090 angesehen.
Interessant ist das Verhalten der "Ampel"!
Trotz einer Änderung an der Notiz, bleibt diese so lange grün, bis ich das Regenerieren spontan anstoße.
->Siehe Anhang 1

Änderungen der Modellmaße bewirken hingegen ein sofortiges umspringen auf gelb.
Ich konnte jedoch kein "Einfrieren" feststellen!
-> Anhang 2

Die Kombination aus Massänderung und Korrektur der Anzahl, läuft ebenfalls erwartungsgemäß ab. (2x Regenerieren)
->Ebenfalls Anhang 2

Möglicherweise sind die Beispieldateien schon zu sehr Vereinfacht worden, als das sie die mangelhaften Effekte wiedergeben könnten.

Einzig feststellbarer Fehler bleibt die grüne Ampel, trotz Änderung der Notiz.

Liebe Grüße,
Nina

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

wenn ich mich richtig erinnere hatte Pro/E früher Probleme mit Querschnitten. Bauteile oder KE`s, die nach dem Querschnitt erzeugt oder eingebaut wurden, wurden im Schnitt nicht berücksichtigt. Was geholfen hat, den Querschnitt in Pro/Program an das Ende zu verschieben.

Vielleicht kann es helfen.

Gruß

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich arbeite für ein relativ großes Unternehmen. Derzeit haben wir noch WF3 im Einsatz - in Bälde werden wir aber auf WF4 umsteigen. Ich werde mir in der kommenden Woche WF4 dazu – installieren, mir die Sache anschauen und lasse von meinen Erfahrungen hören.
In ihrem ersten Video ändern sie nicht nur die Leistenzahl, sondern auch noch das Profil. Das könnte Auswirkungen haben. Was geschieht, wenn sie nur die Leistenzahl ändern?
Im zweiten Video ändert sich im Teil LEI ebenfalls etwas, der Parameter ANZ_LEI wurde d56 zugewiesen. Ändert sich also der Parameter, so muss er auch hier in den Teil. Wie die Sache sich in WF4 verhält, wenn sich ausschließlich die Lage und die Anzahl der Leisten ändert, schaue ich mir kommende Woche an.
Danke für ihre Mühen – ich lasse von mir hören

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das Video *mehrfach regenerieren* von Nina verblüfft mich.
Wenn ich im hochgeladenen Modell KQU-04_UPE.ASM nur die Leistenanzahl ändere (so wie Nina es im Video zeigt), dann kann ich 100-mal regenerieren - die Kurve ist falsch und eingefroren. Wenn ich danach die Abmessungen des Grundkörpers in KQU-4_1_1_UPE.PRT ändere, hat das keinerlei Auswirkungen auf die Kurve.
Es kann nicht daran liegen, dass ich zu sehr vereinfacht habe, da das Testmodell KQU-04 bei mir nicht funktioniert.
Morgen werde ich der Sache nochmals auf den Grund gehen.
Vielleicht handelt es sich tatsächlich um ein Problem der von uns eingesetzten Wochenversion.
An die Möglichkeit, dass ich den Querschnitt *zu früh* erzeugt haben könnte habe ich gedacht, ihn gelöscht und ganz zum Schluss neu erzeugt. Auf die Idee ihn in Pro/Prog einfach nach hinten zu schieben bin ich zu meiner Schande nicht gekommen! Es hatte aber keinerlei Auswirkungen auf das Verhalten der Kurve.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von call4help:
... In ihrem ersten Video ändern sie nicht nur die Leistenzahl, sondern auch noch das Profil. Das könnte Auswirkungen haben. ...

---

Ich hatte das 1. Video ja genau wegen der von Ihnen mit "einfrieren" beschriebenen Reaktion auf eine Profiländerung erstellt und im Begleittext auch darauf hingewiesen.

Zitat:

---

Original erstellt von call4help:
... Was geschieht, wenn sie nur die Leistenzahl ändern?...

---

Die reine Änderung der Leistanzahl wurde schon im Video KQU_irgendwas.gif meines ersten Beitrags dargestellt.

Zitat:

---

Original erstellt von call4help:
... Im zweiten Video ändert sich im Teil LEI ebenfalls etwas, der Parameter ANZ_LEI wurde d56 zugewiesen. ...

---

Auch dazu hatte ich im Begleittext explizit beschrieben, dass ich als Lösungsvorschlag den zusätzlich Punkt mit der Beziehung eingeführt hatte.

Das Thema und die Anforderungen sind äußerst komplex. Die Auseinandersetzung mit Ihrer, wie ich finde interessanten Frage hat einiges an Zeit gefordert, sowohl um Ihren recht speziellen Modellaufbau zu verstehen, als auch um die Probleme darin zu erkennen und Lösungen zu suchen. Die Komplexität der Fragestellung hat selbst bei Ihrem abstrahierenden Ersatzmodell mit Sicherheit die Grenzen der Möglichkeiten einer freier Forumsberatung erreicht.

Bitte nehmen Sie sich dann aber auch die Zeit, die Antworten sorgfältig zu prüfen und analysieren. Sonst ist so etwas in dieser Tiefe hier nicht mehr leistbar.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@ Wyndorps
Es war mir von Anbeginn bewusst, dass ich mit diesem Beitrag, wenn überhaupt, nur Pro/E – Freaks ansprechen werde können. Ich bin auch mehr als dankbar, dass man sich in das Modell eingelesen und sich mit der Sache auseinander gesetzt hat.
Zu ihrem Video call4help_1.wmv:
Das Einfrieren der Kurve erfolgt bei mir nach einer ausschließlichen Änderung der Leistenzahl (gesteuert über Notiz) und anschließendem regenerieren. Nach dem Regenerieren ist die Kurve eingefroren und auch eine Änderung des Profils hat keine Auswirkungen mehr auf die Kurve.
Wenn ich nicht grob unaufmerksam geschaut habe, ändern sie in Video 1 den Parameter ANZ_LEI, und ohne dazwischen zu regenerieren auch das Profil in den Leisten. So viel als Versuch einer Rechtfertigung, da ich das Ausgeschimpft werden nicht mehr gewohnt bin.
Wie schon gesagt, ich werde mich morgen nochmals damit auseinandersetzen und lasse von mir hören.
Wie eingangs geschrieben lag meine Motivation dieses Verhalten von Kurven aus Querschnitten aufzuzeigen darin, interessierte Pro/E-User auf das Problem aufmerksam zu machen und habe auch schon im Einstiegsbeitrag eine Lösung (zugegeben ein Bauchaufzug) angeboten.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von call4help:
... Wie eingangs geschrieben lag meine Motivation dieses Verhalten von Kurven aus Querschnitten aufzuzeigen darin, interessierte Pro/E-User auf das Problem aufmerksam zu machen und habe auch schon im Einstiegsbeitrag eine Lösung (zugegeben ein Bauchaufzug) angeboten. ...

---

Diese Lösung sollte aber nur genutzt werden, wenn keine Datenverwaltung eingesetzt wird. Ansonsten ist bei jedem Aufruf der Kampf mit der Datenbank notwendig, da diese dann von Änderungen im Modell ausgeht. Dies sollte natürlich vermieden werden.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Link durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel • Unities • kLEINSCHREIBUNG

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Sorry, ausschimpfen wollte ich nicht, aber ich gebe zu, dass ich ob der Nachfragen wegen der inverstierten Zeit etwas verärgert war.
Das gif-Video aus meinem ersten Beitrag zu diesem Thema ist genau der von Ihnen beschriebene Vorgang der ausschließlichen Änderung der Leistenzahl.

Der einzige Unterschied ist, dass bei meiner Konfiguration der Zugriff auf die Notizparameter deaktiviert ist und ich daher in das Skelett gehen muss (Aktivieren) um den Parameter zu ändern. Ansonsten zeigt mein Rechner exakt dasselbe Verhalten, wie der von Nina: 3x Regenerieren und gut ist's, ohne einfrieren.

Für die anderen Filme sind die Modifikationen im Text formuliert.

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Gut: Habe mir das Problem mit WF4 M120 angeschaut und das Modell verhält sich gleich wie mit WF3 beschrieben. Die Kurve ist nach einer Änderung der Leistenzahl eingefroren.
Jetzt denke ich an eine config-Option, die bei uns ein bisserl speziell gesetzt ist.
Der Start von Pro/E ohne persönliche config.pro brachte keine Änderung im Verhalten der Kurve.
Für Tests mit der allgemeinen config muss ich mich mit unserem Pro/E-Admin besprechen.
Werde sie auf dem Laufenden halten.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von call4help:
Gut: Habe mir das Problem mit WF4 M120 angeschaut und das Modell verhält sich gleich wie mit WF3 beschrieben. ...

---

Heute früh mit der gleichen Version getestet und kein Einfrieren festgestellt. Änderung der Leistenanzahl nach 2x Regenerieren auch in der Kurve abgebildet.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Link durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel • Unities • kLEINSCHREIBUNG

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Habe das Modell mit WF3 als auch mit WF4 ohne jegliche config.pro und config.win getestet – die Kurve wird nach dem Ändern der Leisten eingefroren und ändert sich erst, wenn man durch *Definition editieren* der Baugruppe KQU-04_1_2_UPE.ASM das Regenerieren händisch anstößt.
Wir sehen uns am Ende unserer Weisheit und glauben, dass es sich um eine config.pro Option handeln wird, die bei uns nicht entsprechend gesetzt ist.
Wenn jemand ansonsten wirklich nichts Gescheites zu tun hat, sich Ü’s verdienen und mir eine große Freude machen möchte, dann könnte er vielleicht das von mir hochgeladene Modell KQU-04_UPE.ASM ohne config.pro und ohne config.win testen. Wenn er mir dann allerdings sagt, dass die Kurve nach 2-maligem Regenerieren stimmt, dann glaube ich an böse Geister.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Keine bösen Geister!

Ohne Konfiguration ist keine Änderung der Kurve zu erzwingen.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Link durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel • Unities • kLEINSCHREIBUNG

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von U_Suess:
Keine bösen Geister!

Ohne Konfiguration ist keine Änderung der Kurve zu erzwingen.

---

Wow!
Da hat aber ein Adimin etwas Wichtiges abgeschaltet!
Bitte unbedingt zurückmelden, welche Konfigoption es war.

  Das "Pro/E-Halbwertverfahren" zum Auffinden der verantwortlichen Option kennen Sie?

1. Konfig-Pro halbieren
2. erste Hälfte laden.
3. Wenn kein Fehler, dann zweite Hälfte laden
4. Mit Fehlerhälfte wieder zurück zu Schritt 1

Repeat until Bösewicht gefunden!

------------------
----------------

"Ich stimme mit der Mathematik nicht überein. Ich meine, daß die Summe von Nullen eine gefährliche Zahl ist."  (Stanislaw Jerzy Lec)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Jaa natürlich!!

mass_property_calculate automatic!!!!!

Wetten?!?

LG, Nina

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Herzlichen Dank für die Unterstützung.

Wie nicht anders zu erwarten: Nina hat ihre Wette gewonnen!

Die config.pro Option von mass_property_calculate by_request  auf  mass_property_calculate automatic umgestellt – und siehe da: Zweimaliges Regenerieren und die Kurve stimmt!

Nochmals herzlichen Dank.
Ich werde mal schauen, dass ich das Ganze mit einmaligem Regenerieren hinbringe.
Ja: Die congfig.pro – Änderung werde ich mit unserem Admin auch zu besprechen haben.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Damit die Kurve aktualisiert wird,
kann man in der Baugruppe KQU-04_UPE
zwischen der Bezugsebene und der Schnittkurve ein
Analyse-Ke erstellen:
#Analyse #Modell #Masseneigenschaften #Ke erzeugen
Nach einem Unterdrücken bzw. Zurückholen von einzelnen Streben genügt eine Regenerierung und die Kurve paßt.

Gruß
Arni

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das funktioniert bei mir nicht zuverlässig.

Nach dem Einfügen des Analyse-KE Leistenzahl auf 2 geändert - Kurve stimmt
Leistenzahl auf 4 - Kurve stimmt
Leistenzahl auf 1 - Kurve flasch
Leistenzahl auf 5 - Kurve wird regeneriert stimmt
Leistenzahl auf 3 - Kurve falsch
Leistenzahl auf 1 - Kurve falsch
Leistenzahl auf 4 - Kurve wird regeneriert stimmt

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo nochmal,

das mit mass_property_calculate kann ich bestätigen in WF4 M120. Jetzt meine Interpretation: diese Option bewirkt im konkreten Fall, dass die Baugruppen als "geändert" markiert werden, weil sich die Masse geändert hat und diverse Beziehungen, die Masse und Schwerpunktkoordinaten zuweisen, veraltet sind. Als Nebeneffekt führt das zum aktualisieren der QS-Kurve beim zweiten Durchlauf.

Funktionieren sollte es aber doch auch ohne diese Option, oder? Das Ticket bei PTC müsste sinngemäß lauten: Eine aus Querschnitt erzeugte Kurve wird nicht auf den referenzierten Querschnitt aktualisiert. Der Querschnitt selbst ist nämlich aktuell.

------------------
Viele Grüße,
Manuel

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

So wie es derzeit ausschaut, werde ich wohl einen kleinen workaround in meine Modelle einbauen. Auch, weil es dann mit einmaligem Regenerieren getan ist.
Die config.pro Änderung werden wir uns überlegen. Es hat allerdings schon seinen Grund, dass bei uns mass_property_calculate auf by_request steht, da es die Regenerierungszeit erheblich verkürzt. Für die explizite Massen- und Schwerpunktsberechung verwenden wir einen Mapkey, der temporär die entsprechenden Einstellungen trifft.

------------------
mfg HP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nochmal ein Nachsatz, weil mir das Problem keine Ruhe lässt:

Ich habe die Baugruppe nochmal nachgebaut mit eigenen Startmodellen usw. in WF4 M120.

Die gute Nachricht: es funktioniert jetzt einwandfrei mit EINMAL regenerieren.

Die schlechte Nachricht: Es funktioniert nur, wenn die Anzahl der Leisten ERHÖHT wird. Wenn ich sie REDUZIERE, bleibt die Querschnittskurve, wie sie ist, auch nach x-Mal regenerieren.

Irgendwie lustig, solange man nicht einen ernsthaften Anwendungsfall hat...

------------------
Viele Grüße,
Manuel

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP