Communauté
Bonjour,
J'ai automatisé la création de composants de réseaux sous pression, sans passer par le fichier CONTENT (un fichier par composant), mais avec un script en Autolisp pour les composants 'linéaires' (Exemple : Coudes segmentés de Stalder Extrusion, ou encore les collets à bride libres ou les réduction générés par une extrusion ) ou j'ai généré directement un fichier DWG contenant l'ensemble des blocs d'une famille (exemple : Coude 45° électrosoudables), qui eu sont des composants téléchargés directement depuis le site internet du fournisseurs
Pour le script en Autolisp, il me génère directement le contenu des tables des base SQLite (WA_ELBOW_MODEL pour les coudes, WA_FITTING_MODEL pour les collets, ...) ainsi que les informations des points de connexion qui sont contenu dans la table WA_CONNECTION_POINT, et ceci au format CSV. Pour les composants téléchargés, je saisi ces infos dans un fichier excel que je copie/colle dans les tables SQLite adéquate.
La prochaine amélioration sera la gestion directe des données dans la base SQLite.
Il y a un point qui m'intéresse dans votre message, c'est la référence au fichier XML. A ma connaissance les fichiers XML sont pour les réseaux gravitaires (PIPE NETWORK) et contiennent les valeurs des tailles des composants. qui eu même sont défini dans un fichier DWG, alors que les réseaux sous pression sont stockés dans des bases SQLite, qui font référence soit à un fichier par composant, ou alors le fichier représente une famille qui contient tous ses composants, sous forme de bloc DWG ?
OK pour le XML, je vais voir ça par curiosité, mais comme je n'utilise pas le CONTENT, ou très peu et seulement si je dois faire un composant rapidement, je ne savais même pas que c'était un 'zip' 😉
Pour les PART_FAMILY_ID (Identifiant de la famille), le PID (identifiant de chaque composant), qui est en fait un simple GUID, je le génère avec une routine en Visual Lisp trouvée sur le web.
Ceci doit aussi pouvoir se faire en VBA (de mémoire).
Du coup j'obtiens ceci (Exemple ci-dessous : Coude 45° électro-soudable GF+)
J'ai donc un GUID pour le PART_FAMILY_ID, que je vais aussi utilisé pour enregistré mon DWG (famille) qui contient mes composants. Puis je génère également un GUID pour le PID (un par composant) et ce dernier va aussi être utilisé pour générer et enregistrer le bloc DWG qui contient le Solide 3D (composant) et la 'Center line' qui doit aussi être dénommé avec le GUID du composant auquel on ajoute "_3" au nom.
En image ca donne ceci
Exemple : Coude segmenté 30°
[En sortie de mon script : fichier DWG de la famille, les deux fichiers CSV avec les données des composants et les points de connexion (que je ne crée pas, je renseigne juste les données dans la table SQLite)
Et un dernier fichier CSV pour m'y retrouver qui me donne juste le GUID et le nom de la famille :
Dans le DWG, j'ai chaque fois le bloc du composant et la Center line (que j'ai décalée pour plus de clareté. Et sauf erreur, on peut en faire un symbole 2D). Cette Center Line sera reprise et affichée selon le style utilisé dans le projet Civil 3D.
Le dernier composant est le DN400, dont le bloc est dénommé "9EBD3E1C-28DE-413C-BD97-D6E9BC4AF86C.dwg"
Juste en dessous, la 'Center Line' qui aurait du être dénommée "9EBD3E1C-28DE-413C-BD97-D6E9BC4AF86C_3.dwg" (et je viens de voir que j'ai oublié le '_3' dans mon code Lisp 😞 Je vais corrigé ça de suite).
Pour l'instant je ne gère pas l'ID des tables SQLite, qui doit respecter un ordre particulier. Je les saisis et modifie à la main en les insérant dans mon fichier Excel, avant de les copier-coller dans la base SQLite.
En résumé, si je garde l'exemple des coudes (c'est un exemple du principe) :
- table WA_ELBOW_MODEL :
- ID = 34, Coude segmenté DN400, ... Connection point = 2
- table WA_CONNECTION_POINT :
- ID = 35, point S1, ...
- ID = 36, point S2, ...
Pour chaque point, il faut définir la distance 3D de chaque axe depuis le point d'insertion du composant (bloc)
et il faut aussi définir la direction 3D en X, Y, Z.
Et en passant, perso, je saisis le FID =1 pour le fournisseur dans la table IM_MANUFACTURER
Pour en revenir aux coudes GF+ coudes (je n'ai pas encore introduit les coudes segmentés dans la base, d'où la découverte ce soir de mon oubli d'ajouter le '_3'), voici ce que ça donne (exemple coude 45+ électro soudable GF+)
WA_ELBOW_MODEL (Coude 45° PE100 160/150)
On voit les ID 167 (pour le 160/150), 170 (pour le 180/150). L'incrément de 3, correspond aux deux points de connexion de chaque composant (pour les coudes). Compris ?
et la table des points de connexion WA_CONNECTION_POINT
Les ID 168 (S1) et 169 (S2) correspondent au coude en 160/150 (ID 167)
Les ID suivants (171 et 172 correspondent au coude en 180/150 (ID 170)
A droite du nom du point de connexion, on voit aussi :
- S1 : 3D_X -1 / 3D_Y 0 3D_Z 0 (direction du point S1 par rapport au pt d'insertion)
- S2 : 3D_X 0.707107 3D_Y 0.707107 3D_Z 0 (direction du point S2 par rapport au pt d'insertion
et ensuite c'est la distance sur les 3 axes
- S1 : 3D_X -45.5 3D_Y 0 3D_Z 0
- S2 : 3D_X 32.2 3D_Y 32.2 3D_Z 0 (la distance X et Y de 32.2, c'est tout simplement phytagore (Racine de 32.2^2 + 32.2^2), soit 45.5
et tout cette codification en image, ca donne çaLe point d'insertion est pour un coude, le sommet des deux lignes du réseau (donc le 0,0 du bloc, c'est plus simple)
La longueur de 89 mm est la longueur d'engagement (Attribut ENGAGEMENT_LENGTH).
Les deux points rouges sont les points de connexion S1 (à gauche, à 45.5 sur l'axe X) et le S2 (à 45°).
Avec cette méthode je me passe donc du fichier CONTENT et surtout je n'ai pas besoin de créer ces points de connexion physiquement, je les codes directement dans la base.
Voilà, voilà, en résumé ma connaissance des bases SQLite des réseaux sous pression après plus de 400 heures passées à analyser, décortiquer, tester, saisir ces valeurs 🙂 Après il y a encore d'autres tables à renseigner, et une des plus importantes est la TB_UFID, qui répertorie les objets et le lock.Heureusement cette table se remplit toute seul (avec les Triggers définit dans la base SQLite). La seule condition pour que ça fonctionne, il faut saisir dans l'ordre : Composant dans sa table WA_xxx_MODEL, puis ses points de connexions (WA_CONNECTION_POINT)
Je suis entrain d'écrire un eBook sur la création des composants, de leur catalogues et la génération par script en Autolisp, pour expliquer tout ce que j'ai découvert et surtout les points qui me posent encore problème, comme notamment adapter les réseau sous pression à d'autres fluides, et notamment le chauffage à distance... et là alors, c'est tout une autre histoire.
Et mon problème majeur actuellement, c'est le temps à disposition... 😉
En complément, j'ai ouvert le XML du Content (zippé).
Et pour mon coude PE100 160/150, on retrouve bien :
<Part> avec son PID (GUID), l'Industry (WA - WATER) et sont PartType (ELBOW).
<ModelProperty> c'est vide
et ces deux points de connexions S1 et S2
Ce qui me surprend c'est les valeurs en Z. Soit le symbole DWG 3D de GF+ et mal modélisé ou je me suis planté en l'insérant. Mais globalement, on voit les 32.2 (arrondi) pour le S2, et les 45.5 (arrondi aussi) pour le X sur S1.
De plus quand on crée ce CONTENT File, le DN n'était pas encore définit (il est à 1) et les autres valeurs non plus.
Ces valeurs sont d'ailleurs à saisir lors de l'importation du Content File.
Donc pour une importation de masse, il faudrait mieux que ces valeurs soient définies si c'est possible, car s'il faut les saisir à la main, pour 10'000 composants... 🙂
Il faut juste faire attention au fichier 'Produits', car si tous les points de connexion sont regroupés dans la table WA_CONNECTION-POINT, les 'produits' sont séparé par 'Part Type' : ELBOW, FITTING, VALVE, ... et ces tables ont quelques attributs qui diffèrent, puis un tronc commun.
- Les tables WA_xxx_MODEL sont les tables 'Produits'
- Les tables WA_xxx_TYPE_TBD sont des tables de liste de valeurs (possible de traduire les 'Caption', d'ajouter des valeurs, ... - C'est des domaines de valeur) qui sont repris par leur ID dans les tables WA_xxx_MODEL.
- Et pour rappel, le FID est unique pour toute la base, les ID sont unique par table.
Courage
Bonjour @AnachrisRio , si certaines réponses vous ont permis de résoudre votre problème ou vous ont mis sur une piste intéressante, merci de les marquer comme solution approuvée.
Patrick Emin animateur de la communauté francophone
Vous avez trouvé un message utile? Alors donnez un "J'aime" à ce message!
Votre question a eu une réponse satisfaisante? Voulez vous avoir l'amabilité de cliquer sur le bouton APPROUVER LA SOLUTION en bas de la réponse qui apporte une solution?
Signez notre Livre d'Or
Liens vers les forums
Vous n'avez pas trouvé ce que vous recherchiez ? Posez une question à la communauté ou partagez vos connaissances.
Publier dans les forums
