Dynamo para Revit: grafos que otro puede mantener

Un grupo rojo con «NO TOCAR», tres pantallas de nodos y un archivo llamado definitivo FINAL. La programación visual ha conseguido una hazaña: esconder la lógica a plena vista. Si además necesita al autor para ejecutarse, no habéis entregado una herramienta; habéis concertado una visita guiada. Dynamo permite construir procesos útiles sin empezar por una aplicación completa. Vamos a exigirles algo más que funcionar durante la demostración de quien los ha montado.

Tomemos un ejemplo hipotético: un estudio quiere preparar vistas y planos a partir de una hoja de cálculo. La primera demostración puede ser espectacular; la prueba interesante llega cuando otra persona cambia un nombre, falta una plantilla o ejecuta el archivo por segunda vez. Ahí se descubre si hemos construido un flujo de trabajo o una ceremonia que requiere silencio, buena suerte y al compañero que sabe dónde no hay que tocar.

Empieza por lo que debe entender quien lo ejecuta

Antes de elegir nodos, explica la operación con palabras que reconozca el destinatario. En nuestro ejemplo, cada fila solicita una vista de una disciplina, vinculada a un nivel y a una plantilla, que después se colocará en un plano con un número determinado. Esa descripción ya obliga a decidir algo que una captura del grafo suele esconder: qué identifica una solicitud y qué significa que se haya resuelto. «Crear planos desde Excel» suena eficaz, pero permite demasiadas interpretaciones para tocar un modelo compartido.

La hoja necesita un contrato pequeño y visible. Un nivel debe referirse a un nivel existente de manera inequívoca; el número de plano tiene que cumplir la convención del proyecto; y una plantilla debe ser compatible con la clase de vista que se pretende crear. Si el equipo trabaja con varias disciplinas, conviene acordar sus valores admitidos y qué hacer con una celda vacía. No hace falta convertir la tabla en un formulario del ministerio. Basta con evitar que el grafo tenga que inventarse la información que falta.

También hay que distinguir datos de configuración. La ruta del archivo, la hoja que se leerá y las referencias del proyecto son entradas que el operador puede necesitar cambiar. El criterio para detectar duplicados o el tratamiento de errores pertenecen al comportamiento de la herramienta y deberían estar documentados. Esconder una ruta personal en un nodo, entre varias operaciones geométricas, convierte un cambio rutinario de carpeta en una pequeña expedición arqueológica.

Escribe además qué queda fuera. Tal vez el flujo cree vistas y planos, pero no ajuste automáticamente cada encuadre ni resuelva cómo distribuir varias vistas en una lámina. Reconocer ese límite evita que una salida técnicamente correcta se confunda con documentación lista para entregar. Automatizar una parte de la producción puede ser muy valioso; prometer que se ha terminado el trabajo cuando aún exige revisión solo desplaza el atasco hasta la siguiente persona.

El primer entregable puede ser una explicación de media página acompañada de una hoja válida y otra con errores deliberados. Si un compañero entiende qué debe aportar, qué obtendrá y cuándo debe detenerse, ya tienes una base que podrá trasladarse al grafo. Si necesitas abrir Dynamo para explicar qué significa una columna, el problema todavía está en la definición del proceso. Los cables pueden esperar unos minutos; suelen llevarlo bien.

Conserva la relación entre los datos antes de ordenar los cables

Una disposición clara ayuda: lectura, comprobación, preparación de cambios, escritura y resultado deben poder seguirse sin atravesar conexiones de un extremo al otro. Los grupos sirven para mostrar esas etapas y explicar decisiones, no para decorar el lienzo con nombres como «Grupo 12». La persona que recibe el archivo necesita localizar dónde se interpreta la hoja y dónde empieza el cambio sobre Revit. Una separación visual tiene utilidad cuando revela una separación real de responsabilidades.

Por debajo de esa organización hay una cuestión menos vistosa y mucho más importante: la estructura de las listas. Imagina tres filas con nivel, plantilla y número de plano. Si una plantilla no se encuentra y eliminas ese valor de su lista, pero conservas intactas las otras dos, puedes desalinear las relaciones. Desde fuera seguirá pareciendo que circulan tres conjuntos de datos razonables; dentro, una vista podría recibir información de otra solicitud. Un nodo que deja de estar amarillo no siempre anuncia una mejora de la civilización.

Mantén cada solicitud unida a su fila de origen y a sus referencias resueltas. Cuando exista un error, conserva ese registro y añade un diagnóstico: «fila 7, plantilla no encontrada», por ejemplo. Así podrás excluir de la escritura una solicitud inválida sin perder la explicación de por qué desapareció del resultado. Los nodos de inspección son útiles para comprobar la estructura en puntos concretos; mirar únicamente la salida final obliga a deducir dónde se rompió una asociación.

La guía de creación de elementos de Dynamo muestra cómo las listas intervienen en la generación de varios elementos. Para nuestro caso, la consecuencia práctica es cuidar qué representa cada nivel de agrupación antes de aplicar una operación: una solicitud, sus vistas o el conjunto de planos no son intercambiables. Esa interpretación debe resultar visible en el nombre de los grupos y en las comprobaciones intermedias.

Si una secuencia se repite y tiene una responsabilidad estable, puedes encapsularla en un nodo personalizado. Por ejemplo, resolver y validar una plantilla a partir de una referencia acordada. La entrada y la salida deberían permitir entenderlo sin abrir su interior en cada uso. Encapsular tiene sentido para reducir el esfuerzo de lectura; ocultar medio proyecto dentro de una caja con nombre tranquilizador solo traslada el laberinto a otra habitación.

Enseña el cambio antes de permitir que llegue al modelo

La lectura de la hoja y la búsqueda de referencias pueden producir una propuesta sin crear todavía vistas o planos. En ella debería verse qué se crearía, qué ya existe, qué se omitiría y qué impide continuar. Esta vista previa no necesita una interfaz deslumbrante. Una tabla comprensible con la fila de origen, el destino previsto y el diagnóstico resulta más útil que una lista de identificadores que únicamente entiende quien programó el grafo.

Supongamos que la hoja contiene veinte solicitudes. Diecisiete son coherentes, dos repiten un número de plano y una pide un nivel inexistente. Antes de escribir hay que decidir si se detiene el lote completo o si se permite ejecutar un subconjunto válido. Ambas políticas pueden tener sentido según el trabajo, pero deben ser explícitas. En una entrega que requiere un conjunto completo de planos, producir diecisiete y dejar tres pendientes puede resultar engañoso aunque el código no falle.

La confirmación debe referirse a esa propuesta concreta, no a una expectativa genérica de que «va a crear algo». Entre preparar la lista y ejecutar, el modelo podría haber cambiado: otra persona puede haber creado uno de los planos o el usuario puede haber seleccionado otro archivo de datos. Por eso conviene volver a comprobar las condiciones críticas justo antes de modificar. Guardar una vista previa y tratarla como una garantía indefinida es concederle más autoridad de la que merece.

Las modificaciones deben respetar el contexto de ejecución y la gestión de transacciones de Revit y Dynamo. Para quien empieza, lo importante es entender que escribir en el documento no equivale a transformar una lista en memoria: puede fallar por condiciones del modelo y exige una estrategia de recuperación. Añadir llamadas de transacción copiadas de otro entorno dentro de un nodo Python no es una precaución universal; el entorno que aloja el código ya impone sus reglas y hay que conocerlas.

Después de ejecutar, informa de lo que realmente ocurrió. «Sin errores» no explica si se crearon todos los planos, si alguno se reutilizó o si una vista quedó sin colocar. Recuperar y comprobar las referencias afectadas permite presentar un resultado con nombres, identificadores útiles y pendientes de revisión. El operador debe poder contrastarlo en Revit sin tener que leer el grafo. De lo contrario, hemos sustituido trabajo manual por una investigación manual posterior, que suele quedar fuera de la diapositiva del ahorro.

La segunda ejecución forma parte de la herramienta

Un flujo que funciona una vez puede ser una demostración suficiente para aprender. Cuando va a usarse en un proyecto, hay que definir qué ocurrirá al repetirlo. Si la fila ya produjo una vista y un plano, ¿se mantienen, se actualizan o se bloquea la solicitud? ¿Qué pasa si cambias el número del plano? ¿Y si el usuario borró la vista entre dos ejecuciones? Estas preguntas afectan al comportamiento que espera el equipo, no a una refinación reservada para programadores especialmente nerviosos.

Dynamo dispone de mecanismos de seguimiento y vinculación de elementos en sus integraciones. La documentación de Element Binding y Trace explica esa relación. Eso no permite asumir que cualquier combinación de nodos, paquetes y código propio resolverá automáticamente todos los duplicados. El flujo concreto debe comprobarse con los nodos y versiones que utiliza, y su política de repetición tiene que seguir siendo comprensible para el operador.

En nuestro ejemplo, una regla podría conservar el plano existente si coincide con la identidad acordada de la solicitud, y detenerse si encuentra una colisión que no puede resolver con seguridad. Otra herramienta podría ofrecer una actualización explícita. Lo decisivo es no deducir propiedad únicamente porque un nombre se parece. Un plano creado manualmente puede compartir parte de la convención y pertenecer a otro proceso. «He encontrado algo parecido» es una observación; todavía no es permiso para modificarlo.

Prepara un modelo de prueba con casos pequeños que permitan inspeccionar el resultado: una fila válida, un duplicado, una plantilla ausente y una solicitud ejecutada previamente. Añade la repetición sin cambios y otra con una modificación controlada. No se trata de acumular escenarios para presumir de pruebas, sino de descubrir si el grafo conserva sus promesas cuando cambia una condición. Si no puedes describir el resultado esperado de un caso, aún falta una decisión funcional.

Estas comprobaciones son una propuesta para validar la herramienta; el ejemplo de este artículo no acredita que se haya ejecutado un grafo real. En un proyecto propio, registra qué versiones y casos has probado y conserva los archivos necesarios para repetirlos. Quien herede el trabajo necesita saber en qué se apoya la confianza depositada en él. La frase «a mí me funcionó» tiene mucha tradición, pero una capacidad bastante limitada para resolver incidencias.

Entrega un flujo mantenible, no una dependencia personal

Python puede ayudar cuando una operación exige una lógica que se vuelve difícil de seguir entre nodos o cuando necesitas acceder a capacidades que tu solución actual no expone de forma adecuada. También puedes resolver partes del flujo con nodos estándar, nodos personalizados o DesignScript. La guía de desarrollo de Dynamo presenta esas opciones. La elección debería mejorar la claridad y el mantenimiento; insertar Python para que el lienzo parezca más avanzado es una manera innecesaria de encarecer el soporte.

Si lo introduces, conserva una responsabilidad acotada y entradas explícitas. Un bloque que recibe solicitudes ya validadas y devuelve un resultado por solicitud es más fácil de inspeccionar que otro que busca archivos, adivina referencias, cambia el modelo y redacta mensajes por su cuenta. Tampoco conviene convertir todas las excepciones en una lista vacía. El usuario necesita distinguir «no hay elementos» de «no he podido consultar los elementos», aunque ambos resultados quepan en el mismo cuadro de salida.

La entrega incluye las versiones de Revit y Dynamo utilizadas, los paquetes y sus versiones, y cualquier dependencia adicional. Un archivo que abre en un equipo no demuestra que vaya a comportarse igual en otro. Evita instrucciones del tipo «instala lo último», porque hacen que el entorno cambie sin que cambie el nombre de la herramienta. Si alguien necesita reconstruir el flujo meses después, esa indicación ofrece aproximadamente la precisión de «usa un ordenador».

Acompaña el grafo de una hoja de ejemplo, las reglas de entrada, la política de repetición y un resumen de errores habituales con su significado. Identifica quién mantiene la herramienta y cómo se comunican cambios de comportamiento. La documentación debe ayudar a tomar decisiones al ejecutar, no obligar a estudiar cada nodo antes de poder empezar. Si una dependencia deja de mantenerse o la necesidad desaparece, retirar el flujo también puede ser una decisión sensata.

La prueba decisiva consiste en entregar el grafo a otra persona con sus datos de ejemplo y comprobar si entiende qué hará y cómo revisarlo. Si necesita rescatarte por mensajería, apunta qué información faltaba y mejora esa parte. El grupo «NO TOCAR» puede seguir siendo rojo; lo que no debería conservar es la responsabilidad de explicar toda la arquitectura.