Por qué los Proyectos en Texto lo Cambian Todo
Introducción
Al evaluar una plataforma PLC, hay una pregunta que revela más que cualquier lista de funcionalidades o benchmark:
¿El proyecto se guarda como texto plano o como archivo binario?
Puede parecer un detalle menor. No lo es.
Esta única decisión determina la flexibilidad, mantenibilidad y sostenibilidad a largo plazo de tu entorno de desarrollo. Y, sin embargo, rara vez forma parte de la conversación, especialmente desde el lado de los proveedores.
El desarrollo de software moderno ya ha resuelto muchos de los problemas que todavía existen en el mundo PLC. El habilitador clave es simple:
El código debe ser accesible, legible y procesable fuera del IDE.
Y eso solo ocurre cuando el proyecto está en texto plano.
1. El problema de los proyectos binarios
Muchos entornos PLC siguen almacenando los proyectos como archivos binarios.
Esto introduce limitaciones inmediatas:
- No existe un diff útil entre versiones
- Integración muy limitada con sistemas de control de versiones
- Dificultad para automatizar procesos
- Dependencia total del IDE
En la práctica, esto implica:
- No puedes revisar cambios correctamente
- No puedes automatizar tu flujo de trabajo
- No puedes integrar pipelines modernos de desarrollo
Los proyectos binarios convierten tu código en una caja negra.
2. El texto plano como base
Cuando un proyecto PLC se almacena en texto plano y organizado en carpetas, todo cambia.
Se habilita:
- Integración directa con Git
- Generación de código fuera del IDE
- Integración con herramientas de validación automática
- Revisión de código sin abrir el entorno de programación
Esto no es solo una mejora técnica.
Es un cambio de paradigma: de un desarrollo centrado en herramientas a un enfoque centrado en el flujo de trabajo.
3. Integración con Git sin fricción
Con proyectos en texto plano, Git funciona como debería. Sin plugins, sin soluciones específicas del fabricante.
Esto aporta ventajas claras:
- Libertad de elección
Puedes usar cualquier cliente Git: Sourcetree, TortoiseGit, línea de comandos, etc. - Acceso completo a funcionalidades
Cherry-picking, rebase, branching… sin limitaciones - Revisión de código sin IDE
Los cambios pueden revisarse en GitHub, GitLab u otras plataformas estándar - Mejor colaboración
Los equipos pueden trabajar siguiendo prácticas estándar de desarrollo software
Así es como debería funcionar el control de versiones.
Todo lo demás es un compromiso.
4. Programación fuera del IDE
Aquí es donde ocurre el verdadero salto.
Cuando el código está disponible como texto, dejas de depender del IDE y puedes automatizar tu flujo de trabajo.
¿Qué se puede hacer?
- Compilación masiva para múltiples configuraciones de máquina
- Validación automática entre el PLC y sistemas externos
- Gestión centralizada de alarmas y eventos
Ejemplo práctico: gestión de alarmas
En un entorno como mappView de B&R, en lugar de gestionar alarmas manualmente en el IDE, puedes:
- Definirlas en una hoja estructurada:
- Variable
- ID de texto
- Mensajes multilenguaje
- Código de alarma
- Severidad
- Usar un script en Python que genere:
AlarmsDefinition(XML)TextsDefinition(XML)AlarmsConditions(Structured Text)
Este enfoque permite:
- Reducir tiempos de desarrollo
- Minimizar errores humanos
- Garantizar consistencia en el sistema
Y, sobre todo, convierte tareas repetitivas en procesos automatizados.
5. Validación automática del código
Cuando el código está en texto plano, puedes aplicar prácticas estándar de calidad de software.
Herramientas y enfoques:
- Lizard
Analiza la complejidad ciclomática y detecta POUs demasiado complejos - IEC-Checker (PLCreX)
Valida código Structured Text según estándares PLCopen
Detecta:- Variables no inicializadas
- Código muerto
- Lógica excesivamente compleja
- Scripts personalizados (Python, etc.)
Permiten validar:- Convenciones de nombres
- Estructura del proyecto
- Consistencia entre múltiples sistemas
Estas herramientas pueden ejecutarse:
- Directamente desde el repositorio
- Como parte de pipelines CI/CD
- Sin necesidad de abrir el IDE
Diferencia clave
Existen herramientas dentro de IDEs (Codesys Static Analysis, TwinCAT TE1200), pero están ligadas a su ecosistema.
Los proyectos en texto plano ofrecen independencia total de herramientas.
6. Trabajar sin el IDE
Puede parecer un beneficio secundario, pero es crítico en entornos con equipos.
Como responsable técnico o líder de equipo, necesitas visibilidad:
- Qué cambios se han integrado
- Qué funcionalidades están en curso
- Dónde pueden aparecer problemas
Con proyectos binarios, esto implica:
- Abrir el IDE
- Exportar información
- Navegar estructuras complejas
Con proyectos en texto plano, es inmediato.
Desde cualquier cliente Git puedes:
- Revisar commits
- Comparar versiones
- Analizar cambios
- Entender la evolución del código
Impacto en el equipo
- Revisiones de código más rápidas
- Detección temprana de errores
- Mejor mentoring entre desarrolladores
- Mayor transparencia en el desarrollo
Un pequeño cambio que transforma completamente la colaboración.
7. El cambio real: adoptar prácticas de software
Más allá de herramientas, esto representa un cambio de mentalidad.
Los proyectos en texto plano permiten:
- Control de versiones real
- Automatización de tareas
- Validación continua
- Escalabilidad en equipos
Estas prácticas son estándar en desarrollo software.
En PLC, aún están emergiendo.
8. Reflexión final
El formato de tu proyecto PLC—texto o binario—no es un detalle técnico menor.
Define:
- Cómo trabajas en equipo
- Cómo mantienes el sistema
- Cómo escalas proyectos
- Cómo aseguras la calidad
Si tu código no puede leerse, procesarse y validarse fuera del IDE, estás limitando tu capacidad como ingeniero.
Modernizar el desarrollo PLC no empieza con nuevas herramientas.
Empieza con una decisión simple:
Hacer el código accesible.
Todo lo demás viene después.