.xpr und .xas Dateien (PTC Engineering Solutions/Pro ENGINEER)

Hi Leute,

ich habe mich schon immer gefragt wofür diese .xpr und .xas Dateien eigendlich da sind. Beschleunigungsdatei !?!? Außer das diese Dateien bei mir viel Speicherplatz belegen, habe ich bis jetzt noch keine Vorteile bemerkt . Es kann ja sein, das meine Dateien zu "klein" sind!?

Kann mir jemand sagen ob diese Beschleunigungsdateien erst ab einer bestimmten Dateigröße sinnvoll sind?

Gruß, Taiko

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

Naja, bei meinen letzten Tests in V20 hat die Beschleunigungsdatei bis zu 50% Performancegewinn beim Aufrufen von Varianten gebracht.
Die neuen Versionen sind deutlich schneller beim Aufrufen von Teilen.
Wenn deine Teile so klein sind, daß es keinen spürbaren Effekt bringt, schalte die .xpr/.xas einfach aus und freu Dich über den gesparten Platz :-)

Die Doku sagt:
Das Aufrufen von Bauteil- oder Baugruppen-Varianten von der Festplatte erfolgt deutlich schneller, wenn die Variante in einer Variantenbeschleunigungs-Datei gespeichert ist.

Variantenbeschleunigungs-Dateien besitzen die Erweiterung .xpr (bei Teilevarianten) und .xas (bei Baugruppenvarianten).

config.pro-Option save_instance_accelerator:

- none (Standard) - Das Programm speichert die Variante lediglich durch Speichern des generischen Modells und seiner Familientabelle.

- Always - Beschleunigerdateien werden gespeichert, wenn die Variante selbst oder wenn sie durch ein Objekt einer höheren Ebene gespeichert wird.

- Explicit - Das Programm speichert die Beschleunigerdatei nur, wenn Du die Variante explizit speicherst.

------------------
Gruß
Lucky

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

Hi luck2k,

hast Du den Test mit 2001 oder noch mit 2000i² durchgeführt?

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

wie ich schrub: bei meinen letzten Tests in V20

------------------
Gruß
Lucky

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

Hi Leute,

das mit den Beschleuniger-Dateien hat sicherlich hier und da seine Berechtigung.
An dieser Stelle möchte ich jedoch zu bedenken geben, dass Beschleuniger-Dateien im Zusammenspiel mit einer zentralen Datenverwaltung "schwierig" sind (und das betrifft nicht nur Pro/INTRALINK, sondern eigentlich alle). Klar, weil die Dinger ja dann nämlich auch verwaltet werden müssten und sogar einen Bezug nicht nur zum Modell sondern auch zu jeder Version des Modells bräuchten.

Grüße aus Langenfeld
(wennŽs schon soooo warm ist, dann sollte wenigstens auch die Sonne scheinen. aber so?)

D. Bexkens

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

@dbexkens:

Der Einwand mit den PDM-Verwaltungsproblemen ist vollkommen korrekt.

Wir erlauben die Beschleunigerdateien nur für lokale Nutzung in den Arbeitsverzeichnissen der Konstrukteure. (PDM 3.7 will sie immer mit weiterleiten, weil er eine Abhängigkeit zum generic erkennt.)

------------------
Gruß
Lucky

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

Hi dbexkens,

wir haben noch kein Pro/INTRALINK wollen es aber ggf. nächstes Jahr einsetzten. Müssen bei INTRALINK alle von Pro/E erstellten Dateien
verwaltet werden ?
Sollte es so sein, müßten wir hier nämlich langsam mit dem Aufräumen anfangen.

Gruß, Taiko

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

Nach meiner Erfahrung verhindern sie das komplette durchregenerieren mit bei Änderungen, insofern beschleunigen sie schon dasd arbeiten. Sie machen aber nur Sinn mit größeren Teilen, bei Normteilen sollte man keine verwenden (Empfehlung von PTC in einer der beiden "30 Tips in 60 min" in Atlanta http://www.prouser.org/2002/ ).
Ich finde nur das manuelle Update sehr unelegant gelöst.
Seit PDM 3.6 geht eigentlich auch PDM vernünftig mit den Dingern um. Reinziehen wollte es die Dinger ja schon immer, seit 3.6 werden sie auch gefetched, immerhin.

------------------
freundlich grüßend
Sven

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

@Taiko (ist damit eigentlich der japanische Titel eines obersten Kriegerfürsten gemeint???),

bei einigen der von uns durchgeführten Projekten bei der Einführung von Pro/INTRALINK ist es zu Verzögerungen gekommen, weil die Modelle nicht aufgeräumt waren. Ich würde deshalb vorschlagen, dass man mit dem Aufräumen fertig ist, wenn es zum Einsatz einer zentralen Datenbank kommt. Dann kann man nämlich auch Tools zum massenweisen Import der Modelle benutzen, was erheblich Zeit und damit auch Geld (!) spart. Beim Beginn einer zentralen Verwaltung muss man den entstandenen Wildwuchs ja sowieso aufklaren. Dann kann man das ja auch gleich schon fertig haben.

Und ob man alle Modelle im Pro/INTRALINK haben sollte? Nun, meiner Meinung nach JA!!! Unbedingt. Aber es kann sicherlich spezifische Ausnahmen geben, die eine dezentrale Datenhaltung von speziellen Modellen erlauben oder fordern (sicherlich werde ich auch da noch genug Gründe finden, damit trotzdem alles reinkommt. Alter Normungsmensch eben, auch wenn schon lange im CAD-Business)

Viele Grüße

D. Bexkens

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

dbexkens hat ja wieder mal sowas von richtig. Mir bleibt einfach nix zum Ergänzen.
Zum Thema Datenhaltung bin ich ohnehin etwas radikal: Jeder Sales, der mehr als zwei ProE-Seats ohne IL (oder für giatsc ProFILE) verkauft, gehört

Es gibt einfach zu viel Ärger ohne und es erzieht zu einer sauberen Arbeitsweise. (Manche Konstrukteure lernen erst durch den Gebrauch einer Datenbank, was externe Referenzen sind.)

------------------
freundlich grüßend
Sven

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

@dbexkens

nein was Du meinst ist SHOGUN. TAIKO ist eine japanische Trommel.

@sadolf )
schläfts Du eigendlich auch mal ?
Du hast recht, das richtige Referenzieren ist auch bei uns ein Fremdwort. Wir haben schon versucht einigen unserer Konstrukteure das beizubiegen (bei einigen vergeblich)!
Mir graut jetzt schon vor der Einführung von INTRALINK !!!!!

Gruß, Taiko

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

@sadolf,

vielen Dank für das "wieder mal".

Grüße

D. Bexkens

PS: Wir loben uns selbst .... tut ja sonst keiner
PPS: @taiko: Menno, jetzt haste mich aber zu einer kleinen Internet-Recherche wegen Deines Nicks angeregt. Ok, das mit der Trommel ist richtig (was ich nicht wusste), aber den Titel gibtŽs auch: Taiko=oberster Feldherr, wird vom Shogun eingesetzt.

[Diese Nachricht wurde von dbexkens am 10. Juli 2002 editiert.]

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

Zitat:
Original erstellt von sadolf:
Zum Thema Datenhaltung bin ich ohnehin etwas radikal: Jeder Sales, der mehr als zwei ProE-Seats ohne IL (oder für giatsc ProFILE) verkauft, gehört

@sadolf: Danke für "die Klammer"

Ich hab leider auch in PRO*FILE keine Wunder mit XPR-Dateien bewirken können. Nachdem wir wussten, dass PRO*FILE XPR-Dateien unterstützt (ja wirklich dbexkens ) haben wir mit grossem Aufwand unsere fam-tab basierende Normteil-Bibliothek umgerüstet. Resultat: Mager!
Der Aufruf von Baugruppen mit XPR-Normteil-Dateien ist ca. 10% schneller aus P*F.

Ich würde heute auch nicht mehr XPR einsetzen. Im Zusammenhang mit PDM's (oder TDM's (Team Data Management) im Fall von INTRALINK) sind wohl Ansätze, alle Varianten als "echte Part's zu generieren an besten.

Ich warte schon lange darauf, dass PTC dieses Problem selber löst, und bin immer wieder erstaunt, dass diese Thematik hier so wenig Gewicht hat:
Die Performance beim Einsatz von Normteilen mit/ohne Fam-Tab ist BIS FAKTOR 5 unterschiedlich, also im Klartext:

STATT 10 MIN AUF EINEN BG-AUFRUF ZU WARTEN, GEHT DIES OHNE FAM-TAB'S
2-3 MINUTEN!!!

Rechne: 100 Konstrukteure x 60Euro (Stundenansatz) x 8/60 (Zeitersparnis pro BG-Aufruf nach Bsp.)

Ich erspare euch das "Milchbüchlein-Resultat" aber hier liegt "das Geld auf der Strasse..."

Mein Fazit:
Ich such mir eine NT-Lösung, die dies bietet. Leider ist dies wieder ein Drittprodukt mehr in "meiner Sammlung" und leider werde ich mir damit ein weiteres Altlastenproblem schaffen, wenn PTC jahre später selber eine Lösung bietet.....

Dann werd ich mir hier wieder den Vorwurf anhören müssen, dass man doch mit PTC eigenen Produkten fahren soll da diese ja so viel besser seien... ABER WO SIND SIE???

------------------
Gruss

Thomas

[Diese Nachricht wurde von giatsc am 10. Juli 2002 editiert.]

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

hi,

mir ist da grad so'n gedanke gekommen - is aber vielleicht nonsense...
also...
problem familientabellenteile und datenbank

vorteil: austauschbarkeit der familientabellenmitglieder über ersetzen in baugruppe
nachteil: langsam

nun mein gedanke:
ich hab da vor kurzem was gelesen, dass mann "shrinkwarp"-teile auch irgendwie über "ersetzen" in der baugruppe austauschen kann.
wäre es also denkbar/sinnvoll (?) sozusagen von den "varianten" shrinkwarp-teile zu machen um so die performane hoch zu halten (weil ja dann nur ein teil) und gleichzeitig den vorteil der familientabellen zu vereinen (über 2maliges ersetzen in baugruppe; erst shrinkwarp zu familientabellenvariante und dann innerhalb der familientabellen)
oder funktioniert das so nicht, weil ich mir wieder nicht über die ganzen "hintergründe" im klaren bin

------------------
cu
fossy
meine kleine website

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

Zitat:
Original erstellt von giatsc:
Die Performance beim Einsatz von Normteilen mit/ohne Fam-Tab ist BIS FAKTOR 5 unterschiedlich, also im Klartext:
STATT 10 MIN AUF EINEN BG-AUFRUF ZU WARTEN, GEHT DIES OHNE FAM-TAB'S
2-3 MINUTEN!!! [/b]

Liegt das am Aufrufen(Filezugriff) oder am Regenerieren der Normteile (Wir haben in den Hauptanwendungen wenig Normteile)
Ich gehe davon aus dass Ihr USE_TEMP_DIR_FOR_INST benutzt.

Von meiner Vorstellung her müssten sich auch die Normteile mit dem INHERITANE-Feature aus 2001 abbilden lassen.
Hier funktioniert aber dann das Erstzen durch Familientabellen-Mitglieder in der Baugruppe nicht.

PS: Sadolf schläft nicht; Er möchte seinen Bugati möglichst schnell haben

Servus
Alois

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

Zitat:

Ich gehe davon aus dass Ihr USE_TEMP_DIR_FOR_INST benutzt.

Hallo Alois

Nein, diese Option war (nach kurzem Check) nicht eingeschaltet, hat aber (nach kurzem Check) nichts gebracht. Ich werd's aber nochmals gründlich testen. Ich kannte diese Option nicht, also erstmal 20 Unities an DEINEN Bugatti....

Die Zeit für den Aufruf von Fam-Tabs wird offensichtlich überall verloren:
Beim Kopieren und vor allem beim Regenerieren
Leider verwenden wir häufig auch DOPPELSTUFIGE Fam-Tabs, was die Sache nochmals verlangsamt.

Es kommt auf die HW und das Netz an, welche Option mehr bringt:
-XPR-Dateien generieren: Längeres Kopieren, Weniger Regenerieren
-ohne XPR: Weniger Kopieren mehr Rechenleistung.

Bei einem schwachen LAN und einem TOP-Client (Gibt's das?) kann also die Erzeugung von XPR-Dateien sogar kontraproduktiv sein!

Bei PDM's kommt erschwerend dazu, dass die XPR Dateien auch aus der Datenbank kopiert werden müssen und danach die Varianten erst ihre generischen Teile über Referenzlisten "suchen" und aufrufen müssen. Danach kommt der Zugriffs- und Parametercheck usw.

------------------
Gruss

Thomas

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

hi leute,

also meine "idee" von oben war nicht so gut...
pro/e "weiß" beim ersetzen nicht automatisch, welches teil das shrinkwrap-ke enthält und somit ist der "aufwand" relativ hoch.

------------------
cu
fossy
meine kleine website

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

Hallo Allerseits!

Folgendes Problem:

WF3 erstellt, beim Verändern bzw. Erweitern von Familientabellen alter Objekte -die in 2001 erstellt worden sind-, jedes Mal .xps / .xas Dateien.

Wie soll ich damit umgehen? Soll ich die Dinger killen oder mitpflegen? Und wenn diese Beschleunigungsdateien tatsächlich überflüssig sein sollten, kann man dem System es nicht abgewöhnen, die kleinen Plagegeister zu schnitzen?

Die Option: "save_instance_accelerator" steht bereits auf: "non"!

LG: gahiv

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

Zitat:
Original erstellt von gahiw:
... "save_instance_accelerator" steht bereits auf: "non"!

Wenn das kein Schreibfehler ist, setzte die Option mal auf "none"

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

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

Hallo!

Bei diesen Familientabellenteilen wurde meines Erachtens das Erzeugen der Beschleunigungsdateien explizit im Modell eingestellt.
#Variantenoperationen
#Beschleunigeroptionen
Hier müßte #immer eingestellt worden sein.
Da greift dann auch die config.pro Option nicht mehr.
Also diese Einstellung auf #Keine setzen, Modell speichern, Beschleunigungsdateien löschen.

Gruß
Arni

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