El fimware 4.4.0 BETA2 para la Original Prusa MINI/MINI+ está disponible en nuestro GitHub y la novedad más importante es la compatibilidad con las conexiones Wi-Fi. Y no hay otra forma de decirlo: Hemos tardado mucho en cumplir lo prometido. Ha sido un largo y complicado viaje. Nos hemos encontrado con varios callejones sin salida, hemos tenido que encontrar soluciones a las limitaciones del hardware, y aún no hemos terminado. Sin embargo, el soporte para la carga inalámbrica de códigos G y la gestión remota de la MINI está funcionando y por fin podemos hablar de lo que hemos tenido que hacer para llegar a esta fase.

Lo que teníamos que hacer

La Original Prusa MINI+ es una máquina asequible pero muy capaz. Cuando el equipo de hardware la estaba diseñando, la clave era encontrar un equilibrio entre el número de características y el precio. Además, admitir todos los modelos de encriptación de los puntos de acceso modernos sería imposible en la actual CPU de la MINI. Por eso el chip Wi-Fi no estaba integrado en la placa base.

Así que, en lugar de eso, nos decantamos por la idea de añadir una cabecera simple en la placa base que permitiría la conexión de una placa ESP-01 barata, convirtiendo el microcontrolador externo en un puente entre la red inalámbrica y la unidad USB. Investigamos y encontramos varios proyectos de código abierto relacionados con las capacidades de red del ESP-01, así que el proyecto estaba en marcha.

¿Qué es una ESP-01? Es un módulo Wi-fi de bajo coste que consta de un stack TCP/IP junto con un microcontrolador incorporado. Su función principal es llevar la comunicación inalámbrica a los proyectos embebidos. Actúa como un microcontrolador autónomo, por lo que no requiere ningún otro microcontrolador (como Arduino o Atmel) para utilizar sus pines de E/S. Básicamente, es un puente inalámbrico a serie con memoria flash de 1MB, una CPU de 32 bits de bajo consumo y soporte para redes Wi-Fi 802.11 b/g/n. Es una solución increíblemente popular y asequible desde 2014. La Original Prusa MINI/MINI+ admite tanto la ESP-01 como la versión ligeramente modificada ESP-01S – se puede encontrar más información en el registro de cambios.

Empezamos a trabajar en el soporte Wi-Fi de la MINI cerca de finales de 2020 con la intención de hacer la parte de la programación correctamente desde el principio en lugar de limitarnos a juntar un montón de código y lanzarlo con prisa, porque eso significaría que tendríamos que reescribir todo desde cero de todos modos, tarde o temprano. Reunimos un equipo especializado al que se le encargó un análisis adecuado de todo el proyecto y la creación de un prototipo de la solución inalámbrica.

Hagámoslo bien

Desde el principio, buscábamos una solución compleja que soportara no sólo simples transferencias de códigos G a través de la red local, pero también sería compatible con nuestro (entonces próximo) software de gestión de granjas PrusaLink y Prusa Connect. El plan era crear un stack TCP/IP estable para Ethernet y Wi-Fi, tener la opción de usar sockets BSD y utilizar una capa de aplicación – un sitio web con capacidades de control remoto que se ejecutara en un servidor HTTP directamente en la impresora. El equipo recibió el encargo completo y se puso a trabajar.

Una de las ideas clave era mantener intacto el firmware actual de la ESP-01. Hay un número de variaciones diferentes de ESP-01 y programar (y mantener) nuestro propio firmware para estos microcontroladores se asumió como una sobrecarga. Ya existe un stack LwIP para la ESP-01 que se encarga del SLIP (Serial Line IP via UARTs), NTP y enrutamiento estático. Primero, intentamos añadir un stack IP paralelo y LwESP, que es una librería ligera de análisis de comandos AT de ESP. Utilizar una solución de código abierto parecía el camino correcto.

Sin embargo, aquí es donde empezamos a encontrarnos con callejones sin salida. Hay varias versiones de firmware para la ESP-01, cada una con un conjunto ligeramente diferente de funcionalidades y diversos niveles de calidad/fiabilidad. También significaba que teníamos que añadir una cantidad masiva de código en el firmware de la Buddy (placa base de la MINI) debido a la biblioteca LwESP. Al final, significaría tener dos stacks IP paralelos (un LwIP para ethernet y otro dividida entre Buddy y ESP) y cambiar entre ellas según sea necesario.

Y había más problemas – sólo 5 conexiones, falta de soporte para un servidor UDP y varios otros problemas. En teoría, podríamos hacer que funcionara de alguna manera, pero probarlo y depurarlo sería una pesadilla. Sin embargo, nuestro colega del equipo SLA encontró una solución bastante ingeniosa – creó un firmware especial y ligero hecho a medida para el ESP-01.

¡El momento Eureka!

Así que, finalmente, teníamos un prototipo de un pequeño firmware especial que convertía el ESP-01 en una interfaz de red, algo similar al chip Ethernet de la placa base Buddy. Era algo que realmente necesitábamos: un paso hacia la dirección correcta.

Y luego nuestro equipo recibió un nuevo refuerzo. Citando una película clásica: una persona que ha olvidado más sobre redes de lo que todos nosotros sabremos jamás. Y también un arquitecto de C++ altamente cualificado. Retomó el trabajo donde terminaron los intentos anteriores y empezó con un análisis completamente nuevo. Le llevó simplemente un mes para implementar un servidor HTTP flexible y eficaz que sea capaz de transmitir las respuestas de las peticiones (es decir, que se adapte a la limitada memoria RAM sin importar la longitud de la respuesta).

Su colega recogió el firmware hecho a medida y empezó a evolucionar el prototipo de tarjeta de red que actúa como ESP. En primer lugar, comenzó con la conexión inalámbrica y conectó el ESP mediante UART (interfaz serie) a un ordenador portátil estándar. De este modo, conseguimos velocidades de hasta 9/6 Mbit (descarga/carga). Por fin teníamos una conexión inalámbrica fiable con una velocidad que superaba el rendimiento máximo de la interfaz UART del MINI, que es de 4,6 Mbaud.

La conexión del ESP a la interfaz de la capa física al stack LwIP del firmware Buddy no sólo trajo ahorro de código, pero también eliminó la mencionada esquizofrenia de los stacks IP mezclados para dos interfaces diferentes. Las cosas empezaron a pintar muy bien.

Unidades USB malditas

Estábamos haciendo grandes progresos. El servidor HTTP estaba funcionando bien y empezamos a añadir más funciones, como cargar códigos G desde PrusaSlicer y descarga de códigos G desde la impresora. Hemos añadido un nuevo navegador de archivos con miniaturas en la interfaz web y hemos implementado las funciones de inicio/parada de la impresión (y varias más).

En abril de 2022, teníamos una conexión inalámbrica estable y el firmware estaba casi listo para su lanzamiento. Sólo quedaba una cosa por resolver. Era, por desgracia, un problema importante: asegurar la estabilidad y compatibilidad de varias unidades USB – desde los modelos chinos más baratos sin nombre hasta los discos USB de marca. Sólo una pequeña curiosidad – muchos de los discos chinos baratos sin nombre funcionaban de hecho con más fiabilidad que los modelos más caros. 🙂 En cualquier caso, tuvimos que resolver tiempos de espera incorrectos en la unidad USB primero. Conseguimos resolverlo en colaboración con STM. Pero luego estaba lo otro, algo verdaderamente diabólico. Mientras que las tarjetas SD tienen tiempos de respuesta muy claramente especificados, los discos USB no tienen nada de eso. Pueden quedarse «en silencio» incluso durante decenas de segundos, además de que hay otra cosa que se llama «housekeeping».

En pocas palabras: Las unidades USB están hechas para funcionar principalmente con ordenadores estándar – como ordenadores portátiles, reproductores multimedia y consolas de videojuegos. Estas máquinas tienen grandes cantidades de RAM (más de 1 MB :-)), así que cuando empiezas a copiar archivos en una unidad USB y ésta deja de responder durante unos segundos, sigue habiendo un gran búfer que ayuda a superar este retraso. «Housekeeping» es algo que la unidad USB hace automáticamente, es una rutina responsable de la copia interna de bloques de datos para repartir el nivel de desgaste más o menos uniformemente en la memoria flash para prolongar la vida del dispositivo de almacenamiento. Sin embargo, esta «clasificación» lleva algún tiempo.

Algunas unidades USB están tan mal diseñadas que pueden dejar de responder hasta 10 segundos. Asignamos 10 kB de RAM en la placa base Buddy para que sirviera de búfer y así suprimimos este problema. Aunque teóricamente es posible cargar los códigos G incluso durante los trabajos de impresión activos, no se recomienda utilizar esta función debido a los problemas de rendimiento.

Y finalmente, tuvimos que resolver el problema con la biblioteca FATfs. Esta biblioteca se utiliza principalmente para los dispositivos embebidos y trata de mantener el sistema de archivos tan consistente como sea posible. Esto significa que cada vez que se escribe un fragmento de un archivo, el chip de la unidad comienza a actualizar la tabla FAT principal y de respaldo. Esto es otro asesino del rendimiento que acabará reduciendo la vida útil de la unidad USB. Por suerte, hemos encontrado una solución: una vez que se empieza a cargar un archivo de código G, ya sabemos el tamaño total del archivo – así que simplemente pide al sistema de archivos que reserve espacio para todo el archivo primero. Una vez terminada la carga, sólo entonces se actualiza la tabla FAT.

El camino que tenemos por delante

El firmware 4.4.0 BETA actual ya ofrece la funcionalidad de red avanzada y una carga de código G fiable. Sin embargo, aún nos queda trabajo por hacer. Estamos investigando si podemos transmitir archivos de código G de forma fiable cuando la MINI/MINI+ está imprimiendo. Como ya hemos explicado, estamos limitados por la tecnología de las unidades USB y, aunque la transmisión es teóricamente posible, todavía hay muchos problemas potenciales.

Seguimos mejorando el código, por lo que las velocidades actuales son algo más de 100 kB/s dependiendo de la calidad de la conexión inalámbrica y 300 kB/s en ethernet. Todavía queda algo de margen. En teoría debería ser capaz de alcanzar unos 460 kB/s de velocidad bruta en UART/ESP. Esperamos que la velocidad final esté en algún lugar entre 250-350 kB/s cuando se optimize adecuadamente.

También nos gustaría centrarnos en hacer que toda la experiencia sea más fácil de usar. En la actualidad, es necesario copiar un archivo INI especial en la unidad USB, lo cual es una solución bastante básica. Funciona, pero sin duda se puede mejorar. Y queremos implementar más mejoras de calidad de vida – como un indicador real de la intensidad de la señal, por ejemplo. ¡Haznos saber qué más te gustaría ver!

Hay muchas unidades USB diferentes y varios modelos del módulo ESP-01 que pueden afectar a la velocidad de una manera u otra. Estaremos muy agradecidos si decides a probar el nuevo firmware de la MINI y nos dices qué dispositivos (ESP y USB) estás utilizando y cuál es tu experiencia con ellos.

Echa un vistazo a la versión actual del firmware en nuestra página de Github.