• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Leggi altro.

Gestione assiemi libreria vs commessa

Fabietto

Utente Junior
Professione: Progettista
Software: Pro/e
Regione: Veneto
#1
Buongiorno a tutti,

come da titolo mi piacerebbe discutere con voi
sul modo migliore di gestire gli assiemi nel rapporto tra libreria e commessa.

Mi spiego meglio, lavoro nel settore stampi per materie plastiche,
e sempre più sto utilizzando componenti e portastampi standard (sia d'acquisto
che di costruzione interna).

In questi giorni sto ristrutturando un po tutta la struttura delle directory
e pensavo di fare in questo modo:

1 dir stampi con relative sottodir di tutti i suoi componenti (matrice-punzone-portastampo-movimenti-ecc).
Nella dir stampi ci metto solo l'asm che mi pesca tutti i componenti necessari tramite search_path.

1 dir normaleria

1 dir accessori

ecc.

Nelle varie dir ogni componente ha il drw, asm se necessario, e mfg.

I miei dubbi su una struttura del genere sono 2:

1 qual'ora voglio creare un nuovo asm stampo con dimensioni diverse come faccio?
(carico l'assieme desiderato, mi sposto su un'altra dir e faccio un salva copia,
ma cosi copio tutto all'interno della directory e non nelle posizioni di partenza
e il mfg non si copia...)
2 Al mio stampo standard devo cacciare dentro l'impronta della commessa
(salvo una copia dello stampo desiderato nella dir comm, però cosi facendo perdo il legame con
la libreria, e se mi accorgo che devo cambiare qlc sullo standard lo devo cambiare 2 volte,
libreria e commessa).

Praticamente il mio dubbio è: come posso interfacciare parte standard e parte su commessa
in maniera da non dover lavorare su 2 assiemi distinti e cmq non perdere eventuali modifiche fatte nella commessa?

Scusate la lunghezza, ma spero di ricevere qlc consiglio.

Ps uso ancora la wf2..

Grazie

Fabio
 

AMinati

Utente Standard
Professione: Ingegnere
Software: ProE
Regione: VENETO
#2
Problemi analoghi ne ho anch'io! Nel mio caso però mi limito a mettere in libreria preferibilmente solo le parti. Se da un progetto ad un altro la parte viene modificata in libreria aggiungo una istanza alla parte. Lo stesso potresti fare anche con l'assieme, ma se le modifiche sono di volta in volta di natura differente (per componenti, posizioni, etc.) dopo poco tempo l'assieme generico in libreria diventa ingestibile (soprattutto perchè quando modifichi un assieme e le sue parti devi essere certo che tutto sia oK anche per le altre istanza).

Come dicevo io standarizzo le parti e aggiungo istanze di volta in volta, per gli assiemi, che a volte sono anche molto annidati e complessi, lavoro sempre creando una nuova directory, copiandoci dentro l'assieme secondo me più simile e modificandolo.

Sperando di esserti utile

AMinati
 

Fabietto

Utente Junior
Professione: Progettista
Software: Pro/e
Regione: Veneto
#3
Grazie per la risposta.
Ma lavorando con search_path, come gestisci le modifiche a componenti che sono in libreria?
Cioè, se carico un assieme vecchio ed io nel frattempo ho fatto delle modifiche ha dei componenti standard, l'assieme vecchio carica i nuovi componenti modificati, e non quelli con cui era realmente stato eseguito.
Ogni volta che modifichi un componente dai un nuovo nome al componente standard?

E se ad esempio un assieme ha un cilindro con lo stelo tutto fuori, ed un altro assieme ha lo stesso cilindro con lo stelo tutto dentro, come riesci a gestire la cosa? Fai una copia del cilindro nella dir di lavoro?

Fabio
 

AMinati

Utente Standard
Professione: Ingegnere
Software: ProE
Regione: VENETO
#4
La difficoltà e la bravura sta nel mantenere valide anche configurazioni precedenti!
Quando modifichi qualche parte devi accertarti che questo non ne invalidi altre.
Se utilizzi le family table puoi sempre modificare il generico, creare nuove istanze per esigenze nuove e mantenere inalterate quelle vecchie. In questo modo se riapri un assieme vecchio questo andra a recuperare sempre la sua istanza e non le nuove che potrebbero essere in conflitto.

Per quanto riguarda i cilindri a volte ho agito così:
creazione delle parti relative al corpo cilindro e allo stelo (+ eventuali attacchi etc.)
Creazione dell'assieme cilindro completo di corpo, attacchi e stelo.
Lo stelo sarà vincolato al corpo mediante vincoli cinematici con i relativi limiti (posizione di stelo tutto dentro e tutto fuori).
Nei miei assiemi quando ho bisogno di assemblare il cilindro lo assemblo anche lì con vincoli cinematici posizionandolo con vincoli in parte riferiti al corpo e in parte allo stelo.
In questa maniera il cilindro in automatico mostrerà lo stelo sfilato alla lunghezza necessaria (se compatibile con i vincoli).

Attenzione se nel medesimo assieme ci sono più cilindri con posizionamenti differenti devi creare istanze diverse altrimenti la rigenerazione dell'ultimo posizionamento riscrive le lunghezze di sfilamento per tutti.


AMinati
 

michele81

Utente Standard
Professione: Progettista - Disegnatore
Software: Solidworks 2011 - Pro-E WF4 - Autocad LT09 - Cosmos - FEMM
Regione: Piemonte
#5
Questo è un argomento molto discusso nel forum...per tutti i software.
Credo che ognuno debba ricavare un proprio metodo in funzione di come gestisce le commesse. Io per esempio preferisco avere una libreria di riferimento, ma non usare direttamente questi file nelle commesse, per evitare con il passare del tempo e delle revisioni di modificare commesse vecchie. Pertanto ogni assieme o parte che mi serve viene rinominato in modo opportuno nella cartella di lavoro della commessa su cui lavoro. Così creo si più copie della stessa parte ma sono sicuro che modifiche in quella commessa non creino problemi altrove. Questo metodo va bene a me perchè tratto tente commesse piccole (come numero di pezzi) e alcune molto grandi; quindi il numero dei file non è eccessivo.
 

maxopus

Mod. Creo e Reverse Eng.
Staff Forum
Professione: Progettista meccanico
Software: Creo Parametric
Regione: Marche (PU)
#6
Beh le librerie vanno gestite con le revisioni. Se modifichi un componente devi dargli un indice di revisione ed avra' un codice diverso (xxx_r01). In questo modo avrai un r0 per i vecchi ed un r1 per il nuovo progetto. Ancora meglio se le revisioni vengono gestite in family table.
 

Fabietto

Utente Junior
Professione: Progettista
Software: Pro/e
Regione: Veneto
#7
Grazie a tutti, provo a mettere in pratica tutti i vostri consigli e poi vi faccio sapere se ho qlc altra domanda.
 

Fabietto

Utente Junior
Professione: Progettista
Software: Pro/e
Regione: Veneto
#8
Ho provato a creare alcune family table di componenti ed ho assemblato le istanze in un assieme.
Ho fatto poi un backup dell'assieme in un'altra dir con conseguente backup delle parti che hanno family table.
Ora quando provo ad assemblare una nuova parte nell'assieme, oppure aprire una parte, nella finestra di apertura file mi compaiono anche tutte le varianti delle varie family.
Se ho molte varianti mi escono un casino di file (uno per variante), rendendo incasinata la ricerca dei file che voglio aprire.
Ho visto che si crea un file .idx, se lo cancello, le varianti non compaiono più, ma poi come per magia ricompare.
C'è un modo per evitare di far comparire tutte la varianti dopo un backup?
Oppure sbaglio qualcosa?
Il backup in certe occasioni mi torna molto utile..

Grazie

Fabio
 

DANI-3D

Utente Senior
Professione: PROGETTISTA MECCANICO
Software: PRO-E WF5
Regione: TOSCANA
#9
Scusate il ritardo ma questa discussione mi era sfuggita.
Se vi può interessare io i miei progetti li ho organizzati così e mi trovo molto bene:

cartella dei COMMERCIALI, con le rispettive sottocartelle inserite nel search.pro.
cartella dei particolari COMUNI, con le rispettive sottocartelle inserite nel search.pro
cartella delle MACCHINE vere e proprie con le sottocartelle dei vari modelli non inserite nel search.pro per non rischiare di modificare una macchina anzichè un' altra.

Per aprire una macchina imposto la sua cartella di lavoro dove ci sono i files specifici di quel progetto e apro l' assieme pricipale che richiama i particolari comuni ed i commerciali.

Per creare una macchina nuova parto da quella che si avvicina di più e copio i files che mi servono in una nuova cartella, facendo un backup o un salvacopia ma molto spesso faccio una copia manualmente almeno copio anche le messe in tavola e non le devo rifare.

La cosa essenziale è che via via che si modificano i vari pezzi o gli assiemi di cambiargli subito il codice in modo che non ci siano pezzi uguali con codice diverso o pezzi diversi con lo stesso codice.

Quando la macchina è finita cancello dalla nuova cartella tutti i codici che non sono stati modificati e ci lascio solo i nuovi pezzi. I primi 2 caratteri del mio codice identificano la macchina percui riconosco facilmente i nuovi codici.

Qualsiasi codice che serve a più di una macchina deve essere messo fra le parti comuni.

Può sembrare complicato ma una volta capito il meccanismo è molto intuitivo.

Scusate se mi sono dilungato, ma ho cercato di riassumere vari anni di lavoro.

Saluti
 

Fabietto

Utente Junior
Professione: Progettista
Software: Pro/e
Regione: Veneto
#10
Grazie Dani per la spiegazione, all'incirca è cosi che faccio anche io, solo che non cancello le parti comuni, ma le lascio all'interno della dir di lavoro, nel caso in cui poi debba archiviare la commessa e magari ricaricarla dopo molto tempo, tempo in cui magari ho cambiato qualcosa alle parti comuni.

Cmq capita a volte, a causa del poco tempo, di non estrarre dalla dir di lavoro le parti che magari possono diventare comuni, e quindi vanno quasi perse, a meno di non ricordarsi dove sono quando poi ti servono...

Qualcuno sa qualcosa sul problema family table?

Auguri di buone feste se non ci si sente prima...

Fabio
 

DANI-3D

Utente Senior
Professione: PROGETTISTA MECCANICO
Software: PRO-E WF5
Regione: TOSCANA
#11
Salve

Non cancellare le parti comuni dalle cartelle delle varie macchine è pericoloso, perchè non sai mai quali ti carica visto che sicuramente avrai particolari con lo stesso codice sparpagliati in più cartelle.

Ti capita mai che aprendo un assieme trovi dei particolari che perdono i vincoli inspiegabilmente che poi nella sessione successiva riappaiono ?

Dipende dal fatto che magari lo stesso commerciale identico viene caricato da una cartella oppure da un' altra, secondo la cartella di lavoro che usi.

Purtroppo nel nostro lavoro la precisione è tutto e coviene tenere ben ordinate le varie cartelle, anche se può sembrare una perdita di tempo.

Per le family table sono un' ottimo strumento da prendere a piccole dosi perchè rallentano la rigenerazione e rendono spesso complicate le modifiche ai progetti specialmente se passa del tempo. Io le adopro molto per i commerciali tipo viti, raccorderia, motori ecc. dove sono eccezionali.

Auguri
 

maxopus

Mod. Creo e Reverse Eng.
Staff Forum
Professione: Progettista meccanico
Software: Creo Parametric
Regione: Marche (PU)
#12
Le parti comuni non le teniamo mai nelle cartelle di progetto.
Significa generare parti doppie la cui gestione può essere molto problematica.
Noi abbiamo una cartella generale di libreria, all'interno della quale ci sono le cartelle dei produttori.
Per evitare problemi di codifica (può essere che due diversi produttori usino lo stesso codice ...) quando scarico un file, rinomino lo stesso in modo da avere tutte le parti indicizzate secondo un nostro criterio interno.
Al contempo ho un file di excel che contiene l'elenco di tutte le parti di libreria e di tutte le caratteristiche delle stesse (materiale, produttore, descrizione, directory ... ecc ecc) che deve essere tassativamente aggiornato ogni volta che si crea una nuova parte.
Il search.pro deve semplicemente contenere tutte le cartelle di libreria ed eventualmente le cartelle di progetto ove queste servano a costruire assiemi contenenti più progetti.
 

DANI-3D

Utente Senior
Professione: PROGETTISTA MECCANICO
Software: PRO-E WF5
Regione: TOSCANA
#13
Ottimo, siamo in perfetta siontonia.

Come anagrafica io uso un file di Access dove magari è più semplice fare ricerche.

Saluti