François Bastier

Bonjour,

Plugins tiers
Vous pouvez explorer par ici une liste de plugins qui permettent la relation Revit <> Excel.
Il y en a des gratuits et d'autres payants, de quelques euros à plusieurs dizaines d'euros.

• Du fait de leur gratuité ou très faible coût, ces plugins ne sont cependant pas toujours mis à jour ou sont parfois incomplets. Par exemple, Schedule To Excel est satisfaisant mais ne va que jusqu'à Revit 2022 et est très sommaire. Export/Import Excel est un peu plus puisant, mais l'import de fichiers Excel modifiés n'est valable qu'à partir de Revit 2022.
  
• Je ne vous en conseille pas un en particulier car, à cause des problèmes dont je viens de parler, je n'utilise plus ces plugins. J'utilise les solutions ci-dessous et DiRoots, qui est certes devenu payant mais dont le coût est absorbé par le temps gagné à l'année.
  
• Les plugins Revit<>Excel qui ont une bonne audience finissent au choix par disparaitre (intégrés à d'autres solutions ou non maintenus) ou deviennent payants.
  

(Vous êtes étudiant d'après votre profil, mais indiquez faire partie d'une entreprise. Je penche donc pour un stage. Si vous ne voulez/pouvez pas payer vous-même la licence, ce qui se comprend, peut-être qu'une discussion est possible avec l'entreprise?).

Dynamo
Vous pouvez vous tourner vers Dynamo, qui est gratuit et il est relativement facile de créer un script pour exporter/importer un fichier Excel de et vers Revit, même sans nœuds/packages externes.

DB Link for Revit
Vous pouvez aussi vous pencher sur un plugin gratuit d'Autodesk, trop souvent oublié : DB Link for Revit. Là, c'est plus technique, mais il offre aussi la possibilité de connecter Revit à des bases de données comme Access ou SQL. Cela en fait un outil puissant pour externaliser des données vers un CDE, un ERP ou tout autre gestionnaire de base de données plus poussé qu'Excel.

Bonjour,

Pour une fois que je prends des raccourcis dans mes réponses… Ah la vulgarisation, c'est plus ce que c'était !
Je vais détailler tout ça dans des images annotées. Ca évitera de faire des tartines ici et je pense que ça facilitera la compréhension.

Vous trouverez en pièce jointe le modèle à partir duquel j'ai fait mes captures d'écran, pour que vous puissiez manipuler les familles par vous-même.

Quoted from hélène mirleau on Mardi 12 Novembre 2024

Dans mon cas ce n'est pas possible [...]

Bon là, j'ai envie de dire Zut.

Quoted from hélène mirleau on Mardi 12 Novembre 2024

J'ai fait 2 familles (modèle générique pour les deux) avec le même nom de paramètre [...]

Ce qui importe, ce n'est pas le nom du paramètre, mais la catégorie de famille associée au paramètre de type <Type de famille>.
Je reconnais volontiers l'ambiguïté de mon explication précédente.

Toutes les explications à vos questions et retours de tests en images annotées :
Image 1 : Cas réel
La preuve en image… Mais ça n'arrive pas tout le temps.

Image 2 : Le pourquoi du comment c'est pas toujours le cas dans un projet
Pourquoi n'avez-vous pas rencontrer ce cas de figure lors de vos tests et quelles sont les conditions à réunir pour observer ce phénomène.

Image 3 : Une contrainte supplémentaire dans les familles
C'est plus récurrent et donc problématique dans les familles (sauf à détourner les catégories de familles).

Image 4 : Infos sur la structure des noms des paramètres et valeurs proposées
Y'a pas de mal à apprendre des trucs et l'exemple vous montre qu'il est possible d'ajouter autant de paramètres de type <Type de famille> que vous souhaitez, avec toutes les contraintes déjà citées.

Quoted from hélène mirleau on Mardi 12 Novembre 2024

je trouve ça aberrant que depuis le temps revit n'est prévu cette option qui me semble essentielle

Je vous rassure, tout le monde trouve ça aberrant. Mais on doit faire avec… enfin sans, du coup

En pratique on peut en mettre comme vous l'avez fait. Mais on n'est pas libre de mettre ce qu'on veut comme valeur et il persiste les contraintes présentées dans mes réponses.

J'espère que ça répond à vos questions et besoins.

Bonjour,

Que voulez-vous dire par :

Quoted from hélène mirleau on Mercredi 6 Novembre 2024

mais avec la méthode que j'utilise je ne peux pas en créer plusieurs

Dans tous les cas, les deux seules méthodes qui existent pour créer un menu déroulant comme liste de valeurs possibles pour un paramètre sont les suivantes :

• Créer une table de valeur au sein d'un projet (affecté à un paramètre partagé injecté dans une famille, au niveau de la famille ou du projet). C'est la solution présentée dans votre hyperlien.
  
• Créer un paramètre de type Type de famille (dans une famille, ça ressemble à Nom du paramètre<[Nom de la catégorie de famille]>) : soit dans la famille "hôte" pour pointer vers un type d'une famille imbriquée, soit dans le projet pour pointer vers une famille qui n'est pas imbriquée dans la famille "hôte".
  

La première méthode ne peut être appliquée qu'au sein d'un projet. Si le paramètre qui doit disposer d'un menu déroulant est appliqué de manière récurrente à tous ou partie de vos projets, alors la table de valeur doit être créée dans votre gabarit de projet et le paramètre partagé injecté dans les fichiers de familles.

La seconde méthode peut être appliquée au sein d'une famille ou au niveau du projet, mais elle est au final contraignante à l'usage, car lorsque vous allez insérer votre famille dans un projet, le paramètre Type de [Nom de la catégorie de famille] listera l'intégralité de toutes les familles répondant à cette catégorie qui sont chargées dans le projet.

Par exemple :

1. Vous créez une famille de prise électrique qu'on va appeler PE.
   
2. Dans cette famille, vous insérez une annotation générique qui représente le symbole de prise. On va appeler ce symbole SY.
   
3. Cette famille d'annotation générique contient plusieurs types, qu'on va appeler T1, T2, T3 (oui, on sent l'inspiration du grand auteur du XXIe siècle).
   
4. Dans la famille PE, vous créez un paramètre de type <Type de famille>, qui vous permet, via un menu déroulant, de sélectionner les types de la famille SY. On va appeler ce paramètre Patacouet (et pourquoi pas ?)
   
5. Vous chargez PE dans un projet. Or, dans ce projet, il existe déjà trois autres annotations génériques. Peu importe à quoi elles servent, on va les appeler X, Y et Z.
   
6. Alors, lorsque vous sélectionnez le paramètre Patacouet de la famille PE, le projet Revit va vous proposer tous les types de toutes les familles d'annotations génériques que trouve le projet. Donc tout ce qui est dans la famille PE et tout ce qui est dans le projet par ailleurs. donc, il vous propose T1, T2, T3, X, Y et Z.
   

Donc oui, cette solution peut vite devenir un petit enfer sur Terre. Sans compter que le type de paramètre <Type de famille> ne peut pas être appelé dans une formule.

En conclusion, ou en bref à votre convenance, privilégiez la solution 1, celle proposée dans votre lien hypertexte. Oui, tout ça pour ça.
Je suis en pleine rédaction d'un énorme support de formation, alors on va dire "déformation professionnelle" .

Bonjour,

D'habitude je fais des réponses de 14 kilomètres qui saoulent tout le monde, mais vue l'heure, je vais à l'essentiel. Je ne connais pas votre maitrise de Revit et de Dynamo, donc, voici les grandes lignes à connaitre :

• Le dernier nœud que vous utilisez n'est pas le bon et il n'est pas renseigné comme il faudrait pour qu'il fonctionne
  
• Pour être affichés dans les étiquettes, les paramètres dans la famille doivent être créés en tant que paramètres partagés (voir ici pour la méthode, au besoin)
  
• Vous devrez adapter le script, la famille et l'étiquette suivant les noms de vos propres paramètres
  
• Si vous souhaitez utiliser la partie du haut du script (pour calculer aussi le NGF du fil d'eau sans passer par des formules dans la famille), alors le paramètre de famille "Profondeur du fil d'eau" doit être un paramètre d'occurrence et non de type
  
• Suivant comment vous définissez les altimétries NGF dans vos projets, il faudra peut-être adapter le contenu du cadre orange du script.
  

Je vous invite à tester tout le bazar, avant qu'on aille plus loin au besoin.

PS : Je vois que dans votre profil, vous avez mentionné Maitre d'Ouvrage. Legagneur et Associés, c'est plutôt un bureau d'études de Maitrise d'Œuvre, non ? Gaëlle et Marc vont faire la tête ! Voilà, cette info sert à rien, mais ici je ne croise pas souvent de gens avec qui j'ai déjà travaillé, alors j'en profite .

Bonjour,

Les panneaux de treillis soudés ainsi que les barres d'armatures et les formes de cadres d'armatures d'usage courant existent déjà dans Revit, de manière native.

En revanche, Revit étant orienté conception et non exécution, il ne propose pas nativement de fonction d'automatisation liée au ferraillage.

Donc, si vous souhaitez effectuer rapidement un certain nombre de tâches, comme la génération en masse du calepinage des panneaux de treillis dans des voiles ou dalles, la répartition de cadres, l'ajout d'épingles et de liens entre cadres ou panneaux, la mise en page automatique etc., bref tout ce qui fait gagner du temps sur les trucs pénibles de la création de plan de ferraillage, vous devrez vous orienter vers des plugins, comme :

• Reogen, cité par Jean Edelmann
  
• Sofistik
  
• Naviate for Revit
  

Et j'en profite pour poser la question que je pose à chaque fois qu'un tel sujet se présente :

-> Pourquoi opter pour Revit pour faire du ferraillage ?

C'est une vraie question que je me pose : Autant que possible, je proscris la modélisation du ferraillage sur mes projets, mais lorsque c'est nécessaire, je me tourne plutôt vers Tekla Structures ou Allplan Structure.
Et n'ayant pour le moment pas obtenu de réponse qui m'incite à croire que c'est réellement utile et pertinent avec Revit, je poursuis mon investigation.

Hamel Alain
Je pense que la question était plutôt quelque chose du genre "Vaut-il mieux utiliser les paramètres intégrés (= fournis par Revit nativement) plutôt que de créer un paramètre (partagé ou non) pour faire la même chose ?"

En tout cas, c'est ce que je comprends de cette question (qui ne parle d'ailleurs pas de paramètre de projet )

Partant de ce postulat (merci à l'auteur de la discussion de bien vouloir préciser la question pour que nous puissions répondre de manière efficace), et pour rester concis, je dirais ceci :

Puisqu'il n'est pas possible de supprimer des paramètres intégrés, alors il est plus sécuritaire de ne pas créer de doublon. Donc il faut éviter de créer un paramètre qui fait la même chose qu'un paramètre intégré, tant que ce dernier est facilement exploitable.

Par exemple :
Une fois chargées dans un projet, les familles se voient automatiquement dotées d'un paramètre intégré qui permet de piloter leurs altimétries comme on veut (sauf dans le cas de certains hôtes, mais ce n'est pas le sujet).
Donc, créer un paramètre au sein d'une famille pour piloter l'altimétrie de celle-ci dans un projet, c'est prendre le risque de se retrouver avec une famille mal positionnée, car les deux paramètres sont aussi faciles à renseigner l'un que l'autre et les valeurs des deux paramètres s'additionneront pour donner l'altimétrie réelle.

En revanche, si le paramètre intégré n'est pas aisément modifiable, ou bien s'il est déduit automatiquement d'autres paramètres intégrés suivant une règle qui ne nous convient pas, alors ajouter un paramètre pour rendre la famille plus facilement pilotable est souhaitable.

Par exemple :
Revit fournit nativement le paramètre Numéro de circuit dans les familles qui disposent de connecteurs électriques. Or, ce paramètre ne peut pas être enseigné à la main (il dépend de tout un tas de trucs chiants dans les circuits électriques).
Dans ce cas, ajouter un paramètre textuel que l'opérateur renseignera lui-même est salutaire, car la dénomination des circuits est une logique interne à l'entreprise. Dans ce cas, nous ne nous soucions pas du paramètre natif, qui prendra bien la valeur qu'il veut.