Qué hace
El sistema lee dónde está cada carga cincuenta veces por segundo, decide y manda. Todo lo demás está al servicio de eso.
1 Las cuatro piezas
El software son cuatro programas separados, no uno grande. Están separados por un motivo concreto: si fueran hilos del mismo proceso, una interfaz trabada congelaría el lazo con la carga en el aire.
①
El núcleo · Rust · 26.100 líneas
El lazo de 20 ms. Lee encoders, vigila, mueve y frena.
②
El servidor · Rust · 17.200 líneas
HTTP y WebSocket propios. Valida comandos y guarda el historial.
③
La consola web · 16.100 líneas
Lo que ve el operador. Sin framework, servida desde la Raspberry Pi.
④
El escritorio · C# · 22.700 líneas
Diagnóstico y puesta en marcha. Grafica el lazo.
Los une un contrato explícito: unos pocos tipos de datos —el estado, los comandos, la configuración— que las cuatro comparten y que viaja como texto JSON. Cambiar el contrato es un solo cambio coherente, no cuatro cambios que hay que mantener sincronizados a mano.
El servidor puede dejar de funcionar por completo y el núcleo de control sigue moviendo y frenando por su cuenta. Si había una secuencia de escena corriendo, la termina. Nadie queda con una carga a media altura porque se trabó un navegador.
2 El lazo de 20 ms
El corazón del sistema es un bucle que se repite cincuenta veces por segundo, siempre en el mismo orden:
| Paso | Qué hace | Por qué en ese orden |
|---|---|---|
| 1 | Lee la posición de los 13 encoders | Todo lo que sigue decide sobre datos de este ciclo, no del anterior |
| 2 | Vigila las reglas de seguridad | Antes de mover: una falla detectada tiene que frenar, no acompañar el movimiento |
| 3 | Lee la consola manual cableada | Un pulsador soltado frena en el ciclo siguiente |
| 4 | Atiende los comandos que llegaron | Ya con el estado fresco y la seguridad verificada |
| 5 | Corrige el sincronismo de cada grupo | Con las posiciones de este ciclo, no las de hace 20 ms |
| 6 | Avanza la secuencia de escena | La lleva el núcleo de control, no el servidor |
| 7 | Escribe las consignas a los variadores | Último: es lo único que mueve el mundo físico |
| 8 | Publica su estado hacia afuera | Diez veces por segundo, para las pantallas |
El núcleo de control mide cuánto tarda cada ciclo. Si se excede tres veces seguidas, lleva todos los ejes a velocidad cero por rampa —sin frenazos— y deja de aceptar órdenes, informando qué pasó. Las cargas quedan detenidas y sostenidas donde estaban: los frenos mecánicos las retienen, como con cualquier parada normal.
No es una precaución teórica: ocurrió durante el desarrollo, cuando una conexión de red mal ubicada metió medio segundo dentro del ciclo. El sistema se negó a seguir moviendo cargas en vez de seguir con un control degradado, y eso es exactamente lo que tenía que hacer.
Dentro del ciclo no se reserva memoria y no se espera a nadie. Las trece lecturas de encoder ocurren en paralelo, cada una en su propia conexión: en secuencia serían 26 ms y no entrarían.
3 Seguridad: lo que el software vigila
La protección de fondo está puesta donde nada puede desactivarla: la cadena de paro es cableada y corta potencia sin pasar por ningún programa, ninguna red y ningún procesador. Sigue actuando aunque el software se detenga por completo.
Sobre esa base, el software agrega una segunda capa: observa, registra y frena de forma ordenada antes de que la cadena tenga que actuar. Todo lo que se describe en esta sección es esa segunda capa — la primera no depende de ella.
Con esa premisa, el núcleo de control vigila en cada ciclo:
- Plausibilidad — compara lo que el variador dice que está haciendo contra lo que el encoder mide. Si el variador dice que gira y la carga no se mueve, hay un acople roto, un freno pegado o un encoder desconectado. Es el detector más rápido: una o dos vueltas del ciclo.
- Desfase entre ejes de un grupo — si dos varas sostienen la misma carga y una se atrasa, la otra empieza a llevarse el peso de las dos. Se corrige mientras se mueven, y si la diferencia pasa del margen, se detienen.
- Límites de recorrido — virtuales por software y físicos por final de carrera, en los dos extremos de cada eje.
- Cantidad de ejes moviéndose a la vez — es una restricción eléctrica: si se supera, salta la protección general y toda la instalación queda sin alimentación de golpe, incluidos los ejes que están sosteniendo carga. Los frenos mecánicos las retienen, pero es un corte brusco que no debe ocurrir.
- Comunicación con cada equipo — un encoder que deja de responder se trata como falla y detiene su eje. Nunca se sigue moviendo con la última posición conocida, que es lo que haría creer que la carga está donde ya no está.
Cuando algo falla, se detiene el eje afectado y también los que comparten su carga: si dos ejes sostienen la misma pieza y uno se detiene, dejar al otro subiendo la inclinaría. Detener los dos es lo correcto.
El lazo de control nunca se interrumpe. Todo error se convierte en una falla registrada con frenado ordenado, con su código, su descripción y el ciclo exacto en que ocurrió. Un programa que se cierra dejando cargas en el aire no es una opción.
4 Grupos y sincronismo
Un grupo es un conjunto de ejes que se mueven como uno solo porque sostienen la misma carga. El operador los arma según la obra: en una escena pueden ir cuatro varas coordinadas y otras cuatro sueltas, y en la siguiente al revés.
Cuando un grupo se mueve, el núcleo de control mide el desfase entre sus ejes en cada ciclo y corrige las velocidades para mantenerlos alineados. El umbral de falla no es un número fijo: se calcula desde la velocidad a la que se está yendo, porque un umbral fijo da falsas alarmas cuando el movimiento es rápido y es ciego cuando es lento.
Si un eje deja de moverse coordinado con su grupo —porque falló, o porque el operador lo pasó a manual a propósito— el grupo queda incompleto, y la interfaz lo muestra de forma imposible de pasar por alto. A partir de ahí, mover ese grupo ya no mueve ese eje: puede quedar a una altura distinta de la del resto.
Volver a sumarlo al grupo es una acción explícita del operador, y el sistema la rechaza si el eje quedó demasiado desalineado: primero hay que acercarlo a mano. Reincorporarlo de golpe desde lejos provocaría un tirón sobre la carga.
Cómo se opera
Tres formas de mandar: la pantalla, la lista de escenas y la consola de botones. Las tres pasan por las mismas verificaciones.
5 La consola web
Se abre en cualquier navegador de la red y no requiere instalar nada. La sirve la propia Raspberry Pi del sistema.
- Estado en vivo de todo — posición, velocidad, corriente y desfase de cada eje, diez veces por segundo.
- Mímico — las varas dibujadas a escala, donde están de verdad.
- Movimiento manual — a una posición concreta, o sostenido con hombre-muerto: el eje se mueve mientras se sostiene y para al soltar.
- Alarmas — con qué las causó y cómo se resuelve cada una, no solo un código.
- Configuración de la instalación — ejes, bombas, grupos y límites se agregan y se quitan desde la pantalla. El archivo de configuración es el resultado, no un formulario que haya que editar a mano.
Con cargas suspendidas, dos personas dando órdenes contradictorias sobre la misma carga es un riesgo real. Comanda una sola pantalla, y las demás ven todo pero no mandan.
No hay que pedirlo: la web toma el control al abrirse y lo suelta cuando la ventana pasa a segundo plano — la aplicación tiene que estar a la vista para poder comandar. Si hay más de una pantalla conectada, la interfaz lo avisa.
La parada nunca se restringe. Cualquiera puede detener todo, tenga o no el control.
6 Los CUEs: grabar y ejecutar un show
Un CUE es una pose: dónde tiene que quedar cada eje, a qué velocidad llegar y con cuánta rampa. Un show es una lista de CUEs que se ejecutan en orden.
Grabar es capturar. Se mueven los ejes hasta que la escena se ve bien y se graba: mucho más rápido que teclear coordenadas, y no hay que traducir de la vista al teclado.
| Lo que se puede pedir | Qué hace |
|---|---|
| Ejecutar un CUE | Lleva los ejes de ese CUE a su pose |
| Ejecutar del 3 al 9 | Los encadena en orden, uno tras otro |
| Pausa antes del CUE | Espera unos segundos antes de arrancar |
| Esperar el GO | Se detiene hasta que el operador lo dispare, como una consola de teatro |
| Espera por eje | Cada eje puede salir más tarde: una salida escalonada, las varas del telón con medio segundo entre una y otra |
| GO propio por eje | Un eje se queda quieto hasta que se lo dispare, con el resto de la escena ya en su lugar: la vara que acompaña al actor cuando el actor llega |
| Cancelar | Frena por rampa lo que se estaba moviendo |
Las secuencias las ejecuta el núcleo de control, no el servidor. Si el servidor dejara de funcionar a mitad de una escena, el núcleo de control la termina igual, en vez de dejar las cargas a media altura.
Si un eje falla en medio de una secuencia, se detienen ese eje y los que comparten su carga, y el resto de la escena sigue adelante. Es una decisión de operación tomada a propósito: no se interrumpe una función entera por una vara.
El precio es real, y por eso se muestra: los CUEs que vienen después se grabaron contando con que ese eje estuviera en su lugar, y ya no va a estarlo. La secuencia queda marcada como incompleta, con los ejes que quedaron detenidos nombrados uno por uno, y el aviso aparece en tres lugares de la pantalla a la vez. Sin esa marca, seguir la función sería peligroso.
7 La consola manual cableada
Una botonera física: un botón por motor y un joystick compartido. Se mantiene apretado el botón del eje que se quiere mover —o varios, para moverlos juntos— y se inclina el joystick: arriba y abajo mueven, izquierda y derecha ajustan la velocidad.
Ninguno de los dos alcanza solo. Un joystick inclinado sin ningún botón apretado no mueve nada, y un botón apretado sin joystick tampoco. Son dos barreras: el resorte del stick, que lo devuelve al centro, y la mano sobre el botón.
Es lo que un botón en pantalla no puede dar: un dedo puede quedar apoyado en un táctil sin que la persona esté atenta. Un pulsador de resorte se suelta cuando la mano lo suelta.
La consola se lee dentro del ciclo, no a través de la red: al soltarla, el eje empieza a detenerse 20 ms después, sin depender de que la red esté funcionando. Y si el módulo de entradas deja de responder, los ejes que estaba moviendo se detienen: cuando no se sabe qué están apretando los botones, un hombre-muerto tiene que suponer que se soltaron todos.
Un pulsador cableado no es una excepción a las reglas: pasa por las mismas verificaciones que cualquier comando —límites, cadena de seguridad, velocidad máxima y cantidad de ejes simultáneos—. Y como no pasa por el control de la pantalla, la web muestra un cartel mientras alguien la está usando: nadie ve una vara moverse sin explicación.
El cableado son 17 entradas digitales —13 botones y 4 del joystick— y ninguna analógica: entra en un solo módulo de entradas industriales.
8 Diagnóstico: gráficos e historial
Mostrar el ahora no alcanza para entender qué pasó. El sistema conserva y grafica.
- El gráfico del lazo — traza lo que se le pidió al variador contra lo que el encoder midió, y el desfase contra el grupo. Es el chequeo de plausibilidad hecho dibujo: ahí se ve un acople que patina o un freno que arrastra.
- Media hora de historia de cada eje — posición, velocidad, consigna, desfase y corriente, diez veces por segundo. Cubre un ensayo de puesta en marcha completo.
- Volcado a disco — cada minuto se escribe a archivo, un CSV por eje y por día. Si el volcado se atrasara y se perdieran muestras, el archivo lo dice: un hueco silencioso haría creer que el eje estuvo quieto.
- Historial de eventos — todo comando, toda falla y todo cambio de configuración, con quién y cuándo. Es un requisito de seguridad, no una comodidad.
- Exportación a CSV — para abrir en una planilla y analizar fuera del sistema.
No interpola, no promedia y no rellena. Una lectura que falló queda marcada como inválida y el gráfico corta la línea ahí. Inventar un valor plausible donde el encoder no contestó es lo contrario de una herramienta de diagnóstico: dibujaría un movimiento que no ocurrió.
Cómo está hecho
Las decisiones de construcción, lo que se verificó y lo que falta.
9 Decisiones de construcción
| Decisión | Por qué |
|---|---|
| Rust para el núcleo de control y el servidor | Se comparó escribiendo lo mismo en dos lenguajes. El comportamiento es idéntico; la diferencia está en qué pasa cuando falta una verificación: en C, leer el eje 7 de una lista de 5 devuelve un número plausible y el programa sigue como si nada |
| Casi sin dependencias externas | El núcleo de control y el servidor dependen de una sola biblioteca. El HTTP, el WebSocket y el protocolo con los equipos están escritos a mano: es poco código, y no hereda los fallos ni las actualizaciones de nadie |
| Driver de variador abierto | El proyecto no se ata a una marca. Un modelo distinto es un archivo de configuración con sus registros, no un programa nuevo |
| Todo en milímetros de carga | Nunca en pulsos ni vueltas de motor. La conversión ocurre una sola vez, en el borde del sistema, y así ejes con mecánica distinta son comparables entre sí |
| La interfaz sin framework | Un archivo que se abre y funciona, incrustado en el propio servidor. No hay compilación, ni versiones que caduquen, ni un paquete que deje de mantenerse dentro de tres años |
El proyecto documenta por qué se decidió cada cosa, no solo qué se decidió. Varias decisiones se reabrieron y se corrigieron con datos nuevos, y esas correcciones también están registradas. Quien retome esto dentro de dos años puede discutir una decisión sabiendo qué se tuvo en cuenta.
10 Las 521 pruebas
El software se verifica solo, en cualquier computadora y sin ningún equipo conectado. Eso es posible porque el sistema incluye una planta simulada: un mundo donde el variador empuja, la carga se mueve y el encoder la mide, con el mismo retardo de un ciclo que tiene el hardware real.
327
del núcleo
149
del servidor
45
del lanzador
521
en total
No verifican solo que las cosas anden: verifican que fallen bien. Que un encoder que deja de contestar detenga el eje. Que si la consola manual deja de responder, los ejes que estaba moviendo frenen. Que un comando imposible se rechace diciendo por qué. Que una escena incompleta no se vea igual que una completa.
Ninguna prueba automática reemplaza la puesta en marcha. Verifican la lógica, el protocolo y las conversiones —que 863,9 mm/s dan exactamente 50 Hz, por ejemplo—, pero ningún equipo real contestó todavía a este software. La primera conexión a un variador de verdad, con el motor desacoplado del tambor, es una puesta en marcha y no una prueba de software.
11 Qué falta
El software está completo. Lo que falta no es código: es hardware.
| Pendiente | Depende de |
|---|---|
| Confirmar los mapas de registros contra los manuales de los equipos comprados | Hardware |
| Primera conexión a un variador real, con el motor desacoplado | Hardware |
| Cablear el módulo de entradas de la consola manual | Hardware |
| Los drivers de las bombas hidráulicas | Datos de los cilindros |
Los datos que faltan para comprar —la acometida eléctrica disponible en el lugar y las características de los cilindros hidráulicos— están detallados en el proyecto de hardware.
12 Autoría
FlyNet · El software v1.0 · 16 de agosto de 2026.
Describe lo que el software hace hoy, verificado sobre planta simulada. No reemplaza la puesta en marcha con equipos reales, ni el proyecto eléctrico matriculado, ni la evaluación de riesgo en seguridad de máquinas — todos requeridos antes de operar con carga real.