Est-il possible d’avoir votre point de vue sur la création des composants dans la bibliothèque ?
j’aimerai aborder le sujet avec en arrière pensée la performance informatique.
Est-il plus intéressant d’avoir un composant fait de fichiers aux formes basifiées organisés en code fournisseur ou un fichier aux formes paramétrées organisé en code catalogue ?
Pour la première façon de faire, j’y vois l’avantage de pouvoir récupérer des listes de fichiers aux formes plus ou moins complexe (ce qui n’est pas forcément bien, à quoi ça sert de faire calculer des géométries qui sont souvent inutiles) et de les assembler en un seul composant. Le gros inconvénient est qu’il faut retourner dans tous les fichiers si on veut faire une modif…
Pour la seconde, elle a l’avantage de concentrer toutes les infos dans un seul fichier et donc un seul fichier à modifier en cas de besoin, l’inconvénient étant du coup la complexité que celui-ci peut atteindre. Un autre désavantage que je vois est qu’il faut prendre pas mal de temps pour faire la synthèse des variations du composant pour pouvoir le dessiner correctement et donc le piloter correctement… mais cela permet de simplifier la géométrie.
Comme je disais plus haut, j’aimerai orienter ma décision en fonction de la demande en ressource de calcul.
Avez-vous une idée de quelle méthode est la moins gourmande de façon générale ?
Charger des fichiers aux formes plus ou moins complexes mais basifiées.
Charger des fichiers aux formes simples mais paramétrées.
Je ne prends pas en compte les opérations puisqu’elles sont nécessaires dans les deux types de composants.
Voilà, j’ai d’autres remarques en tête mais la conversation risque de partir dans tous les sens…
A+
Mussaka
bon le sujet se pose principalement sur les tiroirs… pour ma part, j’ai redessiné le profil des côté de tiroir et j’ai agencé ma bibliothèque comme ceci :
c’est le plus simple que j’ai pu expérimenter car tu dessine une seule fois et tu fais des enregistrer sous de ton fichier d’origine (en modifiant juste ta hauteur), par contre t’as pas intérêt à avoir oublié un perçage (ce qui m’est arrivé) parce que la t’as une centaine de fichiers à modifier :
Merci FanchLQ pour ta réponse.
Effectivement c’est une solution. Dessiner un assemblage de composant dans un seul fichier permet de n’en charger qu’un seul.
Par contre comme tu l’as remarqué, tu as dessiné un fichier par variante et donc si il y a un oublie ou une modif’ à faire après coup…
Salut,
Je ne vais pas pouvoir répondre à ta question sur l’aspect “performance informatique” il faudrait faire des essais avec des composants lourd en utilisant la méthode 1 et 2 puis comparer.
je suis plutôt pour utiliser de la conception paramétrique non basifiée pour pouvoir faire évoluer facilement le composant dans le temps.
par exemple je ne fait pas des perçages que je déclare en tant qu’outil pour mes coulisses, je vais plutôt positionner des vis qui elles feront leurs usinage.
je vais limiter un maximum les conditions activation/désactivation qui augmentent le poids de mes composants, à la place je vais faire des conditions qui appellent tel ou tel sous-composant. (par exemple vis bois / vis euro)
pour la coulisse je fais une géométrie complètement paramétrique (comme fanchLQ)mais je ne vais pas générer tout les codes fournisseurs séparément mais plutôt les piloter avec mon catalogue.
ce qui permet d’avoir un assemblage final assez léger et de ne pas avoir des centaines de fichiers généré à un instant T.
tout ce que je dis reste de la préférence personnelle et ne répond pas réellement à ta question de performance brut.
[quote=Mussaka post_id=57612 time=1757323994 user_id=5925]
Merci FanchLQ pour ta réponse.
Effectivement c’est une solution. Dessiner un assemblage de composant dans un seul fichier permet de n’en charger qu’un seul.
Par contre comme tu l’as remarqué, tu as dessiné un fichier par variante et donc si il y a un oublie ou une modif’ à faire après coup…
D’autres opinions ?
[/quote]
Effectivement j’aurais pu tout mettre dans le même fichier mais après tu te retrouves avec 1 catalogue dans lequel tu dois aller retrouver précisément le modèle que tu recherches, la le fait d’avoir séparé prends du temps lors de la conception de ta bibliothèque mais réduit ton temps de recherche à chaque fois que tu veux mettre un tiroir spécifique donc je pense que c’est relativement vite rentabilisé, et ton compo tiroir une fois qu’il est fait tu n’y touche plus vraiment. maintenant comme le dit [mention]AnP[/mention] c’est aussi largement une question de préférence, et il faut à tout prix éviter les activation/désactivation pour préférer du sous-composant géré par catalogue.
AH si j’ajouterais qu’au maximum évite de faire des compo de compo de compo de compo … ce qui peut être fait ensemble doit l’être (pour reprendre l’exemple des tiroirs, mes côtés sont fait dans le même fichier que mes coulisses, mes fonds et mes dos. plutôt que de faire un fichier dos+fond, un fichier coulisses, et un fichier côtés.
Déjà expliquer mon contexte :
Je viens de créer une entreprise d’études et pour m’adapter aux ateliers et à leurs méthodes, il faut que mes composants soient modulables, je veux aussi pouvoir changer le fournisseur (la réf changeant avec)
Je risque donc de créer une grosse bibliothèque et j’essaie de bien réfléchir à sa rationalité et à son fonctionnement avant.
Après un petit temps de réflexion, je pense avoir trouvé mon compromis :
Limiter les bibliothèques à : Agencement, Décoration, Menuiserie, Mobilier, Outils d’usinage, Quincailleries
Pas de multiplication des bibliothèque (ex: tous les tiroirs (Blum, Hettich, Grass, etc…) au même endroit)
Un composant principal
De préférence en bloc pilote
Appel les sous-composants pour créer un ensemble
Garder le système flexible et évolutif offert par l’appel des sous-composants
Par exemple puisqu’on parlait des tiroirs, avoir :
un sous-composant paire de coulisses pour pouvoir changer la gamme (chez hettich, il y a un qté affreuse de solution…),
un sous-composant paire de côtés
un sous-composant dos
L’arborescence ressemble à ça :
Dans la mesure du possible, limiter les sous-composants à un étage (sauf les assemblages)
Par exemple :
Le composant de paire de côtés pourra appeler les attaches-façade car elles sont vendues séparément, il y a pas mal de montage possible (entre leur hauteur et leur nombre) et il faut les appeler pour qu’elles apparaissent dans la feuille de quincailleries…
Pour le composant coulisses j’ai dessiné la paire (paramétrées) dans le même fichier mais j’appelle les vis Euro
Voilà, voilà. Je ne sais pas si je vais rencontrer une situation qui va me forcer à remettre en question ce système, j’espère que non
Slt Mussaka ,
Il y a une multitude de variables à prendre en compte pour réaliser une bibliothèque de composants.
Si tu veux de la performance, limite la variation géométrique des pièces par exemple.
Le niveau de sous composants importe peu sur la performance, c’est plus subtile que ça.
Le sujet est très très vaste.
Si tu dois bosser en B to B, tu seras très souvent amené à travailler avec les outils de tes clients s’ils ont TopSolid
Vive les sous composants, mais du coup attention à la gestion du bordel
Je rejoins Peeny si tu es face à des entreprises qui utilise TopSolid, elles sont leur propre schéma de fonctionnement. Dans le cas où tu ne fournis “que” les plans et que la maquette topsolid n’est pas exploitée ce sera plus simple.
Si tu veux voir ce que ça peut donner, je te propose d’aller voir nos vidéos youtube, on a une playlist dédié aux composants
[quote=Peeny post_id=57656 time=1758224245 user_id=3952]
Le niveau de sous composants importe peu sur la performance, c’est plus subtile que ça.
[/quote]
Tu peux développer s’il te plait ?
Je comprends qu’une forme paramétrée demande potentiellement plus de calcul pour être générée, mais je me dis que la lecture d’une arborescence de sous-composant ne doit pas être négligeable non-plus…
