Tag: Git

Hidden Console Start (HCS) – Esconde la consola y lanza procesos/aplicaciones en segundo plano

Dicen que no te das cuenta de algo hasta que lo pierdes… Esto es lo que me ha pasado cuando recientemente mi orientación profesional ha cambiado y he tenido  que trabajar con sistemas Windows en vez de GNU-Linux.

Acostumbrado a tener corriendo servicios en distintas máquinas con GNU-Linux acabas echando de menos su shell y la bestialidad de herramientas que hay. Vale sí lo reconozco, al final trabajaba en una máquina Windows, pero porque sigo pensando que las herramientas de desarrollo siguen siendo mejor que las que hay disponibles en GNU-Linux. Hay que reconocer que un Windows lo uso sólo para desarrollar (eso sí multiplataforma) y para jugar, para lo demás GNU-Linux sin duda!!!

Una de las cosas que he echado en falta recientemente es la posibilidad de usar el operador & de background tan potente en GNU-Linux. Este operador permite lanzar un proceso que se sigue ejecutando sin bloquear la shell y si la cerramos, éste sigue en segundo plano. Pues esto tan chulo, no puedes hacerlo en un Windows, porque su comando start no lo permite y la opción /B del comando no impide que al cerrarse la consola de comandos el proceso que has lanzado muera. A no ser que el proceso que has lazando cree su propio hilo no dependiente del proceso de la consola. Y tampoco es posible lanzar un proceso de consola de comandos sin consola, a no ser que esté programado explícitamente que la consola se oculte o no aparezca. Windows en este aspecto se cubre mucho, porque la única forma de crear procesos en background es construyendo servicios de Windows que tienen sus propias reglas a cumplir y por consiguiente hace falta desarrollo específico para que algo corra en segundo plano.

Visto el panorama y teniendo cierto conocimiento e idea, me decidí a generar una herramienta similar que funcionase en Windows como el operador &, o por lo menos a intentarlo. Para ello lo primero pensé en que quizás lo más adecuado fuese hacerlo en multiplataforma y generar una solución que funcionase tanto en Windows como en GNU-Linux. Atendiendo a este requisito, enseguida a mi mente llegó Python, porque además su instalación de paquetes es sencilla y potente a partes iguales, por no decir que es posible generar binarios (por ejemplo un .exe en Windows) si hiciera falta gracias a herramientas como py2exe y PyInstaller.

Con el punto de partida claro y unas horas de desarrollo, consigo lo que bautizo como Hidden Console Start o HCS. El proyecto puedes encontrarlo en Github:

Y su instalación es sencilla si tienes ya Python en tu equipo. En caso de no tener Python, pásate por la web de Python y descárgate la última versión disponible. Una vez instalado Python, solo tienes que ejecutar el siguiente comando en el CMD o PowerShell para instalar HCS:

pip install hcs --upgrade

Una vez instalado puedes ejecutar el proceso o aplicación que se quiera ejecutando HCS de la siguiente forma:

hcs -e "P1" "P2" ... "Pn-1" "Pn"

Pongamos un ejemplo:

hcs -e "ping 127.0.0.1 > log1.txt" "ping 192.168.1.17 > log2.txt"

En el ejemplo se lanzan dos comandos ping a distintas direcciones que son guardados en log1.txt y log2.txt respectivamente. Como se puede ver la consola de comandos no queda bloqueada y la información de los comandos ejecutados se va guardando el los ficheros.

Si por alguna razón tus procesos o aplicaciones no mueren o acaban, puedes finalizarlos en el caso de Windows abriendo el administrador de tareas:

Y en el caso de GNU-Linux con htop:

De esta forma podemos lanzar procesos y aplicaciones en segundo plano en sistemas Windows de una forma más o menos equivalente a como lo haríamos en GNU-Linux. Y obviamente podríamos usar HCS en GNU-Linux porque también funciona, pudiendo usarlo de la misma manera que en Windows.

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.