Tag: Git

Neurtura – O cómo sobrevivir en el mundo de la Monitorización Industrial

Ha costado que llegue el segundo invitado a Mascando Bits, pero nunca es tarde si la dicha es buena, y en este caso lo es. Hoy Xabier, compañero de fatigas en el trabajo, nos trae una retrospectiva con aplicación práctica de ingeniería de hardware y software al estilo open source que tanto ha marcado los inicios de Ingran Engineering, empresa de la que me siento orgulloso de pertenecer. Xabier ha sido y será siempre un MacGyver de la electrónica y la mecánica. Esperemos que esta sea la primera de otras muchas entradas.


Actualmente vivimos en un mundo complicado, luchando entre el software y hardware abierto y sistemas propietarios. En la confrontación entre la solución basada en ArduinoESP8266 de 5€ y el Siemens S7 de 500€. En el dilema de dar servicio a un precio adecuado y cumplir las directivas y el marcaje CE. Puede que aquí encontréis algo intermedio, o no. Pero por lo menos, fue nuestra solución durante un tiempo.

 

Introducción

La verdad que empecé a escribir esta entrada hace bastante tiempo, puede que hace más de uno año. Pero por fin lo he completado. A falta de que todavía monte un blog, quisiera agradecer a Rubén que me deje espacio en su blog para publicar.

Este va a ser la primera de varias entradas, comentando la funcionalidad de un sistema que en su día desarrollamos en Ingran Engineering, que actualmente ha quedado en desuso, al migrar a sistemas de adquisición de datos basados en Modbus-TCP, y también porque el módulo central del sistema, el Industruino que usamos en sus primeras versiones, nos dio bastantes problemas para los niveles de calidad y servicio que buscábamos. No obstante el fabricante ha sacado una revisión del Industruino que soluciona los problemas del primero y que además añade nuevas capacidades al dispositivo.

El las siguientes fotos os muestro la versión básica del Neurtura (nombre comercial del dispositivo de monitorización), en la primera podéis ver el aspecto exterior con los conectores:

 

En esta podéis ver los componentes internos:

Podéis observar de izquierda a derecha: Un magnetotérmico, un analizador de energía eléctrica, el Industruino D21G IND I/O (la versión más reciente) con su módulo ethernet al lado, una fuente de alimentación de 24 Voltios y un router Teltonika RUT230.

El la parte exterior tenemos conectores Harting, para la alimentación, para la conexión de las pinzas amperimétricas, para el analizador de energía, y para las conexiones de los sensores, actuadores y Modbus-485.

Si alguien no tiene demasiadas ganas de leer, que vaya al final, al apartado “Compilando“.

 

Contexto

¿Cómo narices se puede monitorizar un proceso industrial, en este caso concreto, una bomba de agua para regadío, de manera efectiva, eficaz y barata? Esa pregunta nos la hicimos en Ingran Engineering hace bastante tiempo, con la certeza de que tenía que haber una solución que tuviese las tres Bs (Bueno, Bonito y Barato). Esto era lo que necesitábamos:

  • Medida de parámetros eléctricos de una bomba: Potencia, Voltaje, Factor de Potencia…
  • Medidas de parámetros del acuífero: Conductividad eléctrica (salinidad), Nivel del agua bajo tierra…
  • Medida de parámetros del agua extraída: Caudal, Presión…
  • Registro de datos cada 10 segundos, y mostrarlos vía Web y en el móvil

Además, por si no fuera poco, teníamos las siguientes restricciones:

  • Necesidad de utilizar GSM/GPRS/3G para la comunicación.
  • Necesitaba tener marcaje CE y cumplirlo.
  • Tenía que ser compatible con lo que había ya montado: diversos tipos de caudalímtros/contadores, medidores de nivel de acuífero…

Aqualogy tenía una solución llamada IdroSmartWell que hacía todo eso, y más, a un precio que casi nos dio un infarto al escucharlo. La solución de software vino de la mano del proyecto EmonCMS de Open Energy Monitor y la de hardware tuvimos que apañárnosla.

 

Especificaciones técnicas

Las especificaciones técnicas de Neurtura que habéis visto en las fotos anteriores son las siguientes:

  • Analizador de energía eléctrica trifásica: Conexión a pinzas amperimétricas externas de 5A o 1A. Medida de V, I, P, PF, THD y más cosas…
  • 4 Entradas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 18 bits.
  • 2 Salidas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 12 bits.
  • 8 Entradas/Salidas digitales: Opción de usarlas como contadores de pulsos.
  • Conexión de Modbus-485 para conectar mas dispositivos.
  • Opción de postear (enviar) a EmonCMS directamente.
  • Guardado de datos en la SD local.
  • Guardado de parámetros de configuración en la EEPROM.
  • Guardado de datos de contadores y demás datos cambiantes en la FRAM propia.
  • RTC local.
  • Actualización del firmware remota: Utilizando el RUT230.

 

Compilando y cargando el firmware

El Industruino se programa utilizando el IDE de Arduino por USB, aunque también se puede programar por Ethernet utilizando TFTP, cosa que ya comentaré explicaré mas adelante en otra entrada.

En la Organización de Ingran Engineering de Github podéis encontrar el firmware y las librerías necesarias:

Para compilarlo y subirlo al Industruino, seguid estos pasos:

  1. Decargar el IDE portable de Arduino, versión 1.8.5
  2. Extraer arduino-1.8.5-windows.zip
  3. Dentro de la carpeta de arduino-1.8.5 crear una carpeta llamada “portable
  4. Abrir el programa arduino.exe
  5. Instalar la placa del industruino -> clicando Tools -> Boards Manager y buscando “industruino” -> Insalar “Industruino SAMD Boards 1.01
  6. Cerrar el entorno de programación de Arduino
  7. Descargar el proyecto Ikusi-Makusi de GitHub y extraerlo en donde se quiera
  8. Descargar el proyecto Ikusi-Makusi-libraries de GitHub y copiar las librerías en la carpeta arduino-1.8.5\libraries
  9. Abrir el programa arduino.exe de nuevo, en Herramienta->Placa seleccionar Industruino D21G y en Herramientas->Puerto el puerto de series correspondiente.
  10. Abrir el archivo Industruino_ethernet.ino del proyecto Ikusi-Makusi con el IDE de Arduino.
  11. Compilarlo y subirlo al Industruino.
  12. Conectad el Industruino a una red con DHCP y encenderlo.
  13. Con los botones navegar hasta la pantalla RED y mirad la IP asignada.
  14. Meter la IP en cualquier navegador web y empezar a experimentar.

Continuará…

 

Clonar la Wiki de un proyecto “forkeado” en GitHub

GitHub es una plataforma increíble que hace todo más fácil en la gestión de proyectos versionados con Git. Una de las grandes cosas que tiene GitHub es la de hacer un fork, que es una copia vinculada al repositorio original bajo tu completa administración.

Esta copia no es completa, puesto que no incluye algunas cosas relevantes como la Wiki, que es donde se documenta la información del proyecto. A efectos prácticos la Wiki se comporta exactamente igual que un repositorio gestionado con Git y que se compuesto por ficheros markdown. A mi juicio, el hacer un fork del proyecto debería incluir tanto el repositorio principal del proyecto como el repositorio Wiki del mismo. Quizás en un futuro no muy lejano lo veamos, quién sabe… 😉

Cuando hacemos un fork de un proyecto y vamos a la Wiki nos anima a crear nuestra primera página:

Aunque pudiera parece que al haber una sección Wiki, existe un repositorio, esto no es así. Hasta que no creemos la primera página que suele denominarse “Home”, el repositorio de la Wiki no existirá. Si se intenta hacer push al repositorio, seguramente os arroje un error como este:

remote error: access denied or repository not exported

Esto es un error de falta de permisos que puede hacerte perder bastante el tiempo, si no caes en la cuenta que el error no es por falta de permisos, sino por la ausencia de repositorio.

Una vez aclarado el tema basta con darle a “Create the first page“:

Dejaremos tal cual está todo porque sobrescribiremos el contenido, sólo lo hacemos para que se cree el repositorio de la Wiki. Avanzamos hacia abajo y le damos a “Save Page“.

Ahora tenemos nuestra Wiki inicializada con su reapositorio activo:

Una vez llegados a este punto hay dos formas de hacer las cosas. En la primera de ellas, puede que la más fácil, sea hacer un clone del repositorio Wiki del original, hacer otro clone de nuestro repositorio Wiki en el fork, y copiar todos los archivos del repositorio Wiki original al de nuestro fork. De esta forma al hacer commit y luego push en nuestro repositorio, tendremos la Wiki. El mayor problema de este método es que primero vamos a tener un commit inicial y que luego vamos a tener un segundo con toda la Wiki. Esto nos hace perder el versionado que traía consigo el repositorio Wiki del proyecto original.

Otra forma más óptima que nos permite mantener el versionado del repositorio Wiki del proyecto original, es el que paso a describiros a continuación de manera detallada.

Primero hacemos un “git clone” del repositorio Wiki del proyecto original:

git clone url_wiki_original

Una vez clonado añadimos nuestra Wiki del fork como remoto con “git remote” (no usar como “remote_name” el nombre de origin):

git remote add remote_name url_wiki_fork

Ahora con el nuevo remoto añadido podemos hacer un “git push” forzado:

git push remote_name master --force

El parámetro “remote_name” es el mismo que cuando hemos añadido el remote en el paso anterior (el de la Wiki de nuestro fork), la rama es “master” (rama principal pero que puede ser cualquier otra que se quiera), y el parámetro “–force” que sirve para sobrescribir la referencia que tuviese anteriormente de la rama y sobrescribir por la que se manda (cuidado con este parámetro que puede resultar peligroso).

El resultado como podéis ver es la de nuestra Wiki actualizada con la del proyecto original:

Ahora queda un minúsculo detalle y es el “HEAD”, la referencia que indica cual es remote y rama por defecto. Por defecto apunta a “origin/master“, que es el remoto de donde se hace el clone. Por esta razón hay que cambiar el “HEAD” para que apunte a nuestro fork como origin y a nuestra rama master. La manera más sencilla es coger y hacernos un “git clone” del repositorio Wiki de nuestro fork y todo listo. 😉

Con este procedimiento ya podéis incluir en vuestros forks la tan preciada y a veces escasa documentación  que se adjunta en los repositorios de los proyectos.

Crear y Eliminar un Submódulo Git de un Proyecto

Una de las formas más eficientes de gestionar la adhesión de subproyectos y librerías en Git, es mediante el uso de submódulos que nos permiten trabajar con ellos dentro de un proyecto, o de manera desacoplada con cada submódulo como si fuera un repositorio Git.

La creación de un submódulo dentro de un proyecto se limita a ejecutar el siguiente comando dentro del directorio deseado en el que se quiera añadir el submódulo, dentro de la raíz del proyecto:

git submodule add http:\\porject-url

Donde la URL después del comando “add” indica la localización del proyecto Git que queremos montar como submódulo.

Una vez tengamos el submódulo añadido podemos gestionarlo como si fuera un proyecto Git independiente, moviéndonos hasta la raíz del submódulo, o ejecutar comandos en lote sobre los submódulos de un proyecto.

Si deseas clonar el repositorio e incluir en el clonado los submódulos, deberás hacer un clone recursivo:

git clone --recursive http:\\porject-url

Donde deberás especificar la URL del proyecto.

Si no realizas el clonado recursivo, del proyecto deberás realizar una inicialización manual de los submódulos:

git submodule init
git submodule update

Por otro, lado, igual que es interesante crear un submódulo dentro del un proyecto, lo es también eliminar un submódulo de un proyecto. Por ejemplo porque queramos moverlo de sitio o porque queramos prescindir de él. Para ello os explicaré la forma de hacerlo borrando el repositorio, que puede servir para conseguir ambos objetivos.

Escontrándonos en la raíz del proyecto que contiene el submódulo que queremos borrar ejecutamos los siguientes comandos:

# Desinicializamos el submódulo de la lista de submódulos
git submodule deinit path/submodule
# Borramos físicamente el directorio del submódulo
git rm path/submodule
# Eliminar cache del árbol de trabajo de Git
git rm --cached path/submodule
# Eliminamos la meta información del submódulo que por alguna razón no borra Git
rm -rf .git/modules/path/submodule

Con las sucesión de comandos detallados, desvincularás totalmente el submódulo deseado y eliminarás los archivos innecesarios.

De esta forma queda cubierta la gestión de submódulos Git en su carácter más esencial, siendo una herramienta muy potente a la hora de gestionar las dependencias de un proyecto, y a la vez facilitando la actualización de las mismas.

Corregir colores ANSI en la consola de Windows 10 tras la actualización Windows Anniversary

La actualización de Windows Aniversario por fin llegó a mi equipo y aunque en general parece ser más robusto y seguro, era imposible no encontrarse con nuevos fallos introducidos a causa de esta enorme actualización. No obstante por la curva de fallos real del software, en cada actualización se introducen nuevos fallos no existentes anteriormente o mal solventados.

curva_fallos_software

Obviamente en esta actualización no iba a ser menos, dado el calado tan ambicioso de la actualización. El fallo que he detectado se corresponde a la interpretación de los colores ANSI de la consola de Windows. Concretamente el problema reside en que no se procesan los códigos ANSI de escape, que antes estaba activado por defecto gracias al flag de la consola ENABLE_VIRTUAL_TERMINAL_PROCESSING.

Esto supone un problema para todas las librerías y códigos de Python que usaban los colores ANSI para cambiar de color la letra y fondo de la consola de manera trasnaprente en todos los sistemas.

Ejemplo de la problemática que se empieza a notar en algunas librerías:

https://github.com/pyreadline/pyreadline/issues/46

Ante este problema se me ocurrieron 2 formas de arreglarlo.

 


Solución 1


cmder-main

La primera pasa por añadir un frontend a la maltrecha consola de comandos de Windows y pensé en Cmder por ser un proyecto que además es portable. De esta forma con un lanzador .BAT/.CMD es posible lanzar sobre Cmder lo que queramos y dejar a un lado la problemática de los colores.

La solución consiste en descargar Cmder en su versión portable y añadir el siguiente .BAT que nos permita lanzar Cmder y ejecutar comandos en su inicio:

@echo off
set CMDER_ROOT=%~dp0
start %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.exe /icon "%CMDER_ROOT%\cmder.exe" /title Cmder /loadcfgfile "%CMDER_ROOT%\config\ConEmu.xml" /cmd cmd /k "%CMDER_ROOT%\vendor\init.bat cd %CD% && cd .. && %~1"

Este archivo que puedes llamar “cmder.bat” debe estar al mismo nivel de directorio que el ejecutable “Cmder.exe“. En este caso además se asume que Cmder está en una carpeta en la raíz del proyecto y la consola se posiciona en el nivel inmediatamente superior al que se encuentra “cmder.bat” y “Cmder.exe“.

La forma de usar “cmder.bat” asumiendo que está en la carpeta “cmder” sería la siguiente:

start /B cmder.bat "python main.py" ^&^& timeout 5 ^&^& exit

En este caso se lanza un programa en Python, cuyo archivo de ejecución principal es “main.py“. Con el parámetro “/B” se lanza la aplicación sin crear una nueva ventana. Adicionalmente se le indica con “^&^& timeout 5” que la consola espere 5 segundos antes de procesar la salida de la consola gracias a “^&^& exit”. El resultado sería algo similar a esto:

cmder-launch

 


Solución 2


La segunda solución pasa por añadir un parche en la librería de Python que usa colores ANSI o en su defecto en el “main” de la aplicación. Las líneas de Python que debes añadir para corregir el problema específico de la interpretación de los colores ANSI de la consola de Windows tras la actualización de Windows Aniversario, es la siguiente:

import os
import platform

if os.name == 'nt' and platform.release() == '10' and platform.version() >= '10.0.14393':
    # Fix ANSI color in Windows 10 version 10.0.14393 (Windows Anniversary Update)
    import ctypes
    kernel32 = ctypes.windll.kernel32
    kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)

Gracias a la librería ctype que proporciona tipos de datos compatibles con C, se pueden hacer llamadas a DLLs o librerías compartidas. Esencialmente lo que se hace es habilitar la flag ENABLE_VIRTUAL_TERMINAL_PROCESSING.

De esta forma los colores de la consola pasan de verse así:

ansi_win_before

A verse así:

ansi_win_after

¡Mucho mejor!, ¿no?

Dejo a continuación la referencia al Fix completo publicado en Gist de GitHub:

ANSIColorFix.py

 

Ambas soluciones resuelven la problemática del color ANSI en la consola de Windows tras la actualización Aniversario del sistema. No obstante la primera solución puede ser menos invasiva al no requerir de cambios en el código, pero la segunda es una solución de enfoque más nativo, ofreciendo una solución transparente a los desarrolladores que hacen uso de las librerías afectadas por este problema.