Dynamo para Revit: construye flujos que otro pueda entender
La compañera abrió el grafo, esperó a que cargasen los paquetes y encontró un lienzo más ancho que varias plantas del proyecto. Había cables cruzando grupos llamados «prueba», tres entradas de texto sin explicación y un nodo Python con la tranquilizadora etiqueta «NO TOCAR». El archivo creaba planos, pero nadie sabía cuáles, con qué reglas ni cómo deshacerlos si algo salía mal.
Dynamo para Revit permite convertir lógica en un flujo visual, y precisamente por eso puede dar una falsa sensación de claridad. Ver todos los nodos no equivale a entender el proceso. Un grafo mantenible explica qué recibe, qué decide, qué modifica y qué devuelve. También puede ejecutarse sin que su autor permanezca junto al teclado como intérprete simultáneo.
Tabla de contenidos
La reconstrucción empezó por el resultado esperado
El objetivo era crear vistas de planta y colocarlas en planos a partir de una tabla. El grafo heredado mezclaba lectura de Excel, selección de niveles, nombres, creación, plantillas y colocación. Cuando fallaba una fila, era difícil saber si el problema estaba en el archivo, el modelo o una lista desalineada.
El equipo escribió un contrato. La entrada incluiría nivel, disciplina, tipo de vista, plantilla y código de plano. El sistema validaría datos, localizaría referencias, mostraría un plan de acciones y solo modificaría Revit tras confirmación. La salida distinguiría elementos creados, reutilizados, omitidos y bloqueados.
También se fijaron límites. La herramienta prepararía vistas y una composición inicial; no ajustaría encuadres ni anotaciones como si todos los planos compartiesen la misma intención. El contrato eliminó funciones accidentales y permitió saber qué significaba que la ejecución fuese correcta.
Las entradas dejaron de esconderse entre nodos
El nuevo grafo comenzaba con un bloque de configuración visible. Ruta, hoja, modo de ejecución y opciones permitidas tenían etiquetas, valores de ejemplo y una breve explicación. Los datos propios del proyecto se separaron de la lógica común.
La tabla se validaba antes de consultar el modelo. Columnas ausentes, filas duplicadas o valores vacíos producían mensajes que apuntaban al origen. La herramienta no intentaba adivinar que «Temp.» significaba «Plantilla», porque las abreviaturas humanas son una API con documentación muy irregular.
Las referencias de Revit también se comprobaban. Si un nivel o una plantilla no existían, el resultado mostraba la fila afectada. Un nombre visible podía no ser único; cuando era posible, la configuración utilizaba identificadores o reglas de selección más sólidas.
El lienzo empezó a contar el proceso de izquierda a derecha
Los grupos representaban etapas: configuración, validación, lectura del modelo, planificación, vista previa, ejecución e informe. Cada uno tenía una entrada y una salida reconocibles. Los colores se reservaron para funciones consistentes, no para reproducir el estado de ánimo del desarrollador.
Las conexiones largas se redujeron mediante nodos personalizados o funciones donde aportaban significado. «ConstruirNombreVista» explicaba una decisión mejor que una cadena de concatenaciones repetida cinco veces. Las funciones pequeñas podían probarse con entradas conocidas y reutilizarse sin copiar medio grafo.
No todo se encapsuló. Ocultar cada operación dentro de una caja negra habría convertido Dynamo en una interfaz para código invisible. El equipo mantuvo visibles las decisiones que los usuarios BIM necesitaban revisar y aisló la mecánica repetitiva.
Las listas recibieron una atención menos decorativa
Buena parte de los errores procedía de listas con niveles distintos, elementos nulos o índices que habían dejado de corresponderse. El flujo definió la unidad de trabajo: cada fila se convertía en un registro con sus datos y resultados. Así, nivel, plantilla y código viajaban juntos.
Los nulos no se eliminaban sin más. Se clasificaban: referencia no encontrada, dato ausente o elemento no aplicable. Borrar nulos podía volver a alinear una lista por casualidad o desplazar silenciosamente los valores. Un resultado vacío debía conservar su contexto.
Las operaciones indicaban el nivel de lista esperado. Los casos con una fila, muchas filas y colecciones anidadas formaban parte de las pruebas. El objetivo no era dominar todas las combinaciones de lacing, sino evitar que la estructura de datos cambiase sin que el grafo lo supiera.
La vista previa apareció antes que las transacciones
El flujo construía primero un plan: vistas nuevas, existentes, nombres, plantillas y planos de destino. Los conflictos se mostraban sin escribir. El usuario podía corregir Excel, ajustar configuración o excluir acciones.
Esta etapa separó errores de datos y errores de ejecución. Si una plantilla faltaba, no era necesario crear veinte vistas y fallar en la vigésimo primera. La previsualización también revelaba decisiones inesperadas antes de que formasen parte del modelo compartido.
Al confirmar, el grafo abría las operaciones necesarias con una estrategia definida. Un fallo crítico podía cancelar el conjunto; un elemento bloqueado podía registrarse y permitir continuar si el resultado parcial era aceptable. Esa decisión se documentó porque determina cómo se recupera el modelo.
El nodo Python perdió su aura de oráculo
Parte del acceso a la API de Revit necesitaba Python. El código se dividió en funciones con entradas y salidas claras, control de errores y comentarios sobre intención. Las referencias y transacciones se gestionaban de forma explícita.
El nodo ya no recibía doce cables genéricos. Recibía registros validados y devolvía resultados por acción. Si fallaba, indicaba elemento, operación y causa saneada. El detalle técnico completo quedaba en el log para soporte.
Python se utilizó cuando reducía complejidad o daba acceso a funciones necesarias, no para esconder un grafo desordenado detrás de otro tipo de desorden. Si la lógica podía leerse mejor visualmente y era estable, permanecía en Dynamo.
El informe respondió qué había ocurrido
Al terminar, el grafo mostraba recuentos y permitía exportar detalle. Cada fila conservaba acción prevista, resultado, identificador y mensaje. Las ejecuciones registraban versión del grafo, Revit, configuración y usuario.
Después de modificar, se releían propiedades clave. Una vista solicitada como creada solo contaba como correcta si existía con nombre y plantilla esperados. Esta comprobación evitaba confundir la ausencia de una excepción con un resultado válido.
Los logs no guardaban información innecesaria del proyecto. Servían para reproducir fallos y comparar versiones. Un registro útil explica el proceso; uno excesivo solo cambia el lugar donde buscar.
Las pruebas dejaron de depender del modelo perfecto
El equipo preparó un modelo pequeño con niveles, plantillas y planos conocidos. Probó entradas correctas, duplicadas, incompletas y referencias inexistentes. También incluyó vistas ya creadas y elementos no editables.
Las funciones de nombres y validación podían comprobarse sin escribir en Revit. La integración necesitaba abrir el modelo y confirmar cambios. Cada versión soportada de Revit ejecutaba el conjunto mínimo antes de distribuir el grafo.
Una copia de un proyecto real aportaba casos que el modelo pequeño no recogía, pero no era la única evidencia. «Funcionó el martes» dejó de ser la estrategia de calidad principal.
Los paquetes se convirtieron en dependencias declaradas
El grafo heredado utilizaba varios paquetes instalados desde hacía años. El equipo revisó cuáles eran necesarios, sus versiones y compatibilidad. Cuando un nodo sencillo podía sustituirse por funciones nativas sin perder claridad, redujo la dependencia.
Las versiones se fijaron y el entorno de distribución las instalaba de forma controlada. Actualizar un paquete requería probar el flujo. La última versión no entraba en producción por entusiasmo; entraba cuando resolvía algo y mantenía compatibilidad.
Dynamo for Revit, Core y Sandbox no se trataron como equivalentes. El grafo que modifica modelos dependía del contexto de Revit y su API. Sandbox podía servir para explorar lógica sin esa integración, pero no reproducía todas las condiciones del host.
Documentar significó explicar decisiones
La portada del grafo indicaba propósito, alcance, versión, responsable y pasos de uso. Cada entrada explicaba formato y ejemplo. Las reglas especiales incluían el motivo, no solo un comentario que repetía el nombre del nodo.
La documentación describía también lo que la herramienta no hacía, cómo interpretar estados y cómo recuperarse de un fallo. Un vídeo podía ayudar a empezar; el contrato y los casos de prueba permitían mantener.
Los cambios se registraban. Si una convención de nombres variaba, quedaba claro desde qué versión. Las configuraciones de proyecto tenían su propio ciclo y no exigían duplicar el grafo.
Distribuir fue distinto de enviar un archivo
El equipo publicó una versión aprobada en una ubicación controlada. Los usuarios no editaban la copia común. El grafo informaba de su versión y, cuando era necesario, avisaba de una actualización compatible.
Los permisos reflejaban impacto. Cualquiera podía ejecutar una vista previa; las modificaciones masivas requerían modelo editable y rol adecuado. La herramienta no saltaba bloqueos ni apropiaba elementos silenciosamente.
Soporte recibía versión, paso y error sin pedir una captura del lienzo completo. Este cambio redujo la dependencia del autor y permitió que el conocimiento se repartiese.
Retirar un grafo también forma parte del mantenimiento
Algunas funciones pasaron a herramientas más estables cuando aumentaron usuarios y riesgo. Otras quedaron obsoletas al cambiar el proceso. El equipo marcó versiones retiradas y ofreció una ruta de sustitución.
No todos los grafos debían crecer. Una rutina usada por una persona experta, con bajo impacto y buena documentación, podía seguir siendo pequeña. La ingeniería aumentaba con responsabilidad, no con prestigio tecnológico.
Si las reglas eran ambiguas o cambiaban constantemente, el equipo mantenía la tarea manual o automatizaba solo la preparación. Dynamo no convierte una discusión pendiente en un requisito.
Un grafo comprensible es una conversación que puede continuar
La compañera volvió a ejecutar la herramienta sin la presencia del autor. Validó la tabla, revisó el plan, corrigió dos referencias y creó las vistas previstas. Cuando una plantilla faltó, supo qué hacer. Ese resultado era menos llamativo que un lienzo gigantesco, pero mucho más útil.
Construir buenos flujos de Dynamo para Revit exige tratar datos, errores, transacciones y dependencias como parte del diseño. La programación visual ayuda a compartir lógica, siempre que la estructura cuente el proceso y no solo enseñe sus cables.
Si tu documentación principal sigue siendo un nodo llamado «NO TOCAR», ya tienes una pista excelente sobre dónde empezar. Puedes tocarlo, pero quizá haz una copia primero; Bimmy confía en el método, no en la temeridad.
Respuestas