Hay errores en un plano CAD que no necesitan presentación: Una línea que aparece donde no debe, un texto que parece escrito para una valla publicitaria o una cota que decide atravesar media planta. Los ves en dos segundos.
El problema son los otros. Los errores silenciosos. Los que dejan el plano con una pinta estupenda, permiten imprimir un PDF perfectamente presentable y pasan una revisión rápida sin levantar sospechas. Hasta que alguien necesita modificar el proyecto seis meses después.
Entonces aparecen las sorpresas: superficies que no cuadran, bloques que ya no son bloques, referencias que han desaparecido, objetos que nadie sabe de dónde han salido y un archivo que parece haber sido dibujado por cinco personas distintas… aunque solo lo haya hecho una.
Vamos con diez de los más habituales.
1. Dibujar a una escala incorrecta
Este es un clásico que se resiste a desaparecer.
Si una pared mide 5 metros, en el espacio modelo debe medir 5 metros. O 5000 unidades si trabajamos en milímetros. No 5 centímetros porque el plano vaya a imprimirse a 1:100. La escala se controla después, mediante las presentaciones, ventanas gráficas y configuración de impresión.
Cuando empezamos a dibujar directamente «a 1:50» o «a 1:100», al principio parece que no pasa nada. El problema llega después: cotas, textos, bloques, referencias externas y superficies empiezan a requerir soluciones diferentes para cada plano.
Y entonces el archivo deja de ser un dibujo y empieza a parecer un rompecabezas. La regla es sencilla: modelo a tamaño real; escala al presentar o imprimir.
2. Objetos en capas que no les corresponden
Este error es especialmente traicionero porque, mientras todas las capas estén activadas, prácticamente nadie lo nota. Una ventana puede estar en la capa de mobiliario. Un texto en la de cotas. Una línea de estructura en la de arquitectura.
Todo parece correcto. Hasta que alguien apaga una capa. Y entonces desaparece media ventana, una parte de la estructura o, en el peor momento posible, ese objeto que llevabas veinte minutos buscando.
Las capas no están para decorar el administrador de capas. Son una forma de organizar la información del proyecto.
Por eso conviene que cada objeto tenga una ubicación lógica y que esa organización sea siempre la misma.
3. Explotar bloques como si no hubiera mañana
Insertas un bloque de una puerta. Necesitas modificar una cosa y lo explotas. Y piensas que «Solo será esta.» Dos semanas después hay 37 puertas explotadas por todo el proyecto.
Visualmente siguen pareciendo puertas, así que nadie sospecha nada. El problema llega cuando decides cambiar el modelo. Si son bloques, puedes actualizar el conjunto. Si son líneas sueltas, empieza el ejercicio de localizar, seleccionar y modificar una por una.
Y cuando llevas unas veinte empiezas a preguntarte por qué tomaste aquella decisión. Un elemento que se repite y que previsiblemente habrá que modificar merece ser un bloque. No hace falta convertir absolutamente todo en un bloque. Pero tampoco convertir los bloques en líneas por comodidad.
4. Bloques dentro de bloques dentro de bloques
Aquí tenemos el extremo contrario. Un bloque contiene otro bloque, que contiene otro bloque, que contiene otro… y en algún momento aparece un bloque para la manilla de la puerta. Los bloques anidados pueden ser muy útiles. El problema aparece cuando se utilizan sin una estructura clara.
Si para modificar una ventana tienes que entrar en tres niveles de edición, recordar qué bloque contiene a cuál y después salir sin saber exactamente qué acabas de cambiar, probablemente hemos ido demasiado lejos.
Un bloque debería facilitar la edición y la reutilización. Si empieza a necesitar un manual de instrucciones, algo ha salido mal.
5. Geometría duplicada
Este es uno de los errores más difíciles de detectar a simple vista. Dos líneas exactamente superpuestas parecen una sola. Pero para el programa son dos objetos.
Puede ocurrir después de copiar, pegar, importar información de otro archivo o superponer diferentes versiones de un dibujo.
Las consecuencias pueden aparecer en los sitios más inesperados: superficies que no funcionan, selecciones extrañas, archivos innecesariamente pesados o resultados incorrectos en determinadas operaciones. La geometría duplicada es especialmente frecuente en archivos que llevan muchos años evolucionando.
Por eso herramientas de limpieza y revisión como OVERKILL, PURGE o AUDIT no deberían reservarse exclusivamente para cuando el archivo empieza a dar problemas.
6. Polilíneas que parecen cerradas… pero no lo están
Esta escena es bastante conocida. Seleccionas el contorno de una habitación que parece cerrado. Intentas calcular el área y nada. Vuelves a mirar y sigue pareciendo cerrado, pero amplías… y ahí está el culpable: un pequeño hueco de unas décimas de milímetro que nadie había visto.
Cuando una geometría va a utilizarse para superficies, regiones, mediciones o cualquier operación basada en un contorno, conviene trabajar con polilíneas realmente cerradas. No basta con que «parezca» cerrado.
El ordenador, por desgracia, no trabaja con intuiciones.
7. Dibujar a kilómetros del origen
Otro error que suele permanecer oculto durante bastante tiempo.
El proyecto funciona perfectamente… hasta que empieza a comportarse de manera extraña. Objetos que se seleccionan mal, problemas de visualización, precisión inesperada o comportamientos raros al hacer determinadas operaciones. Una causa frecuente es que el dibujo esté situado a una distancia enorme del origen.
Esto puede tener sentido cuando se trabaja con coordenadas reales, cartografía o sistemas de referencia geográfica. En esos casos hay que plantear la estrategia desde el principio. Pero si estamos dibujando una vivienda y la fachada está a 800.000 metros del origen porque alguien pegó una referencia «donde cayó», tenemos un problema.
Para proyectos que no necesitan coordenadas reales, mantener el dibujo cerca del origen suele ser una buena práctica.
8. Cada texto con un estilo diferente
Este suele aparecer poco a poco: un texto se creó con Arial, otro con Romans, otro con una SHX… Otro fue copiado de un proyecto antiguo, otro llegó desde Internet y nadie sabe qué fuente utiliza.
A simple vista puede que todos parezcan iguales. Hasta que llega el momento de cambiar la tipografía del proyecto. Entonces descubrimos que cada texto tiene vida propia.
Una plantilla bien preparada debería limitar el número de estilos y definir claramente cuáles se utilizan para títulos, notas, cotas, referencias, etc. No necesitamos veinte estilos para escribir cinco tipos de información. Cuanto más controlada esté la plantilla, menos tiempo pasaremos corrigiendo cosas que nunca deberían haberse descontrolado.
9. Escalas anotativas mal configuradas
Las propiedades anotativas son muy útiles… cuando se entienden bien. Si no, pueden convertirse en una fuente constante de confusión.
Textos que aparecen en una ventana gráfica y desaparecen en otra. Cotas que tienen tamaños diferentes. Bloques que se ven en una escala y no en otra.
El problema no son las escalas anotativas en sí. El problema es utilizarla sin tener claro cómo funciona.
Antes de implantar un sistema anotativo conviene decidir si realmente aporta algo al flujo de trabajo. Si el estudio trabaja con un sistema de escalas perfectamente definido mediante estilos, bloques y presentaciones, quizá no sea necesario complicarlo más. Una buena herramienta es la que ahorra trabajo.
Si necesita una explicación cada vez que alguien abre el DWG, quizá haya que replantearse cómo está configurada.
10. Entregar el archivo sin revisarlo
Este es probablemente el más importante. Un plano puede verse perfecto y estar internamente hecho un desastre. Por eso una revisión final no debería limitarse a mirar si las líneas están en su sitio y si el PDF queda bonito.
Antes de entregar el archivo merece la pena hacer una pequeña revisión de calidad.
- Comprobar capas.
- Revisar bloques.
- Buscar geometría duplicada.
- Auditar el dibujo.
- Purgar elementos innecesarios.
- Comprobar referencias externas.
- Revisar escalas y ventanas gráficas.
- Comprobar las presentaciones.
- Y, sobre todo, imprimir un PDF de prueba.
Porque el PDF tiene una habilidad especial: encontrar errores que llevábamos tres horas mirando sin ver.
El siguiente paso: que el propio CAD haga la revisión
Aquí es donde la cosa se pone interesante. Si hacemos este tipo de comprobaciones en todos los proyectos, tarde o temprano aparece la misma pregunta:
¿Por qué tenemos que revisar todo esto a mano? En un entorno profesional sería muy útil disponer de un comando de control de calidad que analizara automáticamente el DWG y generara un pequeño informe.
Por ejemplo:
Errores: Capas no permitidas, referencias externas perdidas, polilíneas abiertas que deberían estar cerradas o bloques que han sido explotados.
Advertencias: Objetos alejados del origen, estilos de texto poco habituales, geometría duplicada o presentaciones sin revisar.
Información: Número de bloques, capas utilizadas, referencias externas, escalas existentes o elementos que conviene conocer antes de entregar el archivo.
No hace falta que el programa arregle todo automáticamente. A veces es incluso mejor que simplemente diga: «Aquí tienes cinco cosas que deberías revisar antes de entregar esto.» Porque el problema no es que CAD no sepa dibujar. El problema es que nosotros también podemos dibujar bastante bien… y bastante mal.
Un plano bonito no es necesariamente un buen plano
Un buen archivo CAD no se mide únicamente por cómo queda en pantalla. También importa cómo está construido por dentro. Un proyecto bien organizado debería poder abrirse dentro de seis meses y permitir que otro técnico entienda rápidamente qué hay, dónde está cada cosa y cómo modificarla.
- Capas coherentes.
- Bloques bien planteados.
- Geometría limpia.
- Textos controlados.
- Escalas claras.
- Presentaciones ordenadas.
- Referencias correctamente gestionadas.
- Y una revisión antes de entregar.
Porque hay una diferencia bastante grande entre un plano que parece correcto y un archivo que está realmente bien hecho. Y esa diferencia normalmente no se descubre el día que lo dibujamos. Se descubre el día que tenemos que modificarlo. O, peor todavía, cuando lo abre otra persona.
Y todos sabemos que no hay prueba de calidad más exigente para un DWG que dejarlo en manos de otro técnico y escuchar después la frase: «¿Quién ha hecho esto?»
Espero que la información te haya sido útil. Cada semana iré ampliando la cantidad de artículos dedicados al CAD, incorporando ejemplos prácticos sobre los temas tratados. Aunque existen otros programas de CAD, en este blog daremos prioridad a ProgeCAD, sin que ello signifique que la mayoría de los comandos no sean compatibles con la mayoría de los programas de CAD del mercado. Y si te ha quedado alguna duda con el artículo puedes hacerme un comentario en el siguiente cuadro, que te la intentaré resolver.






Deja una respuesta