¿Qué es DQMH?

Delacor Queue Message Handler, es un Framework de programación para LabVIEW desarrollado por Delacor con Fabiola de la Cueva como Arquitecta líder, actualmente DQMH ha evolucionado y está siendo mantenido por el DQMH Consortium.

En este blog te platicaré sobre:

5 puntos en como DQMH puede ayudarte en tus proyectos de LabVIEW

1.- Herramientas de Scripting

LabVIEW es un lenguaje de programación gráfico, el mismo cuenta con herramientas de Scripting, pero comencemos con definir, ¿Que es Scripting?, Scripting son herramientas de código para crear código nuevo o modificar código existente, ¿cómo?, si, así como lo escuchas, las herramientas de scripting desarrolladas en DQMH permiten crear y modificar tu código desarrollado con DQMH, si quieres saber un poco más de Scripting en LabVIEW te recomiendo el siguiente link.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/scripting_tutorial_intro/

https://dqmh.org/2016/12/15/5-steps-to-become-a-vi-scripting-ninja/

En DQMH hay herramientas para crear módulos, los hay de 2 tipos (Singleton y Cloneable), cada módulo tendrá un propósito en tu aplicación, DQMH tiene la manera de crear eventos para cada módulo, hay 4 tipos de eventos:

1. Request
2. Request and wait for Reply
3. Broadcast
4. Round Trip

Adicionalmente DQMH tiene herramientas para renombrar y borrar eventos, si creamos un evento y después tenemos la necesidad de cambiarle el nombre o incluso borrarlo, DQMH localiza el código en específico y usando la magia del Scripting modificará el código automáticamente.

Adicionalmente DQMH cuenta con herramientas para:

1. Convertir eventos
2. Crear Templates de módulos
3. Crear Unit Test para eventos de un módulo en específico
4. Validar módulos

A continuación te muestro 2 videos, el primero es un demo rápido de como crear un módulo DQMH y el uso de algunas de sus herramientas, el segundo es una presentación en el LUG LATAM donde se platica mas a detalle de DQMH. 

2.- Modularidad

En DQMH se crean módulos, los hay de 2 tipos, singleton y cloneable, cuando diseñamos una aplicación usando DQMH debemos pensarla modularmente, romper el problema en pequeños problemas y así resolver más fácil nuestra aplicación, a continuación platicaremos de un ejemplo de una aplicación y analizaremos cómo DQMH puede resolverlo usando su modularidad.

Supongamos una aplicación para control de calidad utilizando visión artificial, en esta aplicación se requiere el siguiente hardware:

1. Motores (3 pero con la posibilidad de agregar mas de ser necesario)
2. Cámaras ( 2 ya que se requiere visualizar el producto desde 2 perspectivas para observar sus detalles)
3. PLC (Para controlar neumática y poder detectar algunos sensores límite)

Esta aplicación realizará la adquisición de imágenes de cierto producto desde 2 perspectivas diferentes para abarcar mayor superficie, estas imágenes se procesarán para decidir si cumplen con la calidad estipulada, para esta máquina se cuenta con 3 motores encargados de el desplazamiento de una banda y para acomodar el objeto a ser inspeccionado en posición óptima; esta máquina cuenta con un PLC el cual está a cargo de sensores de posición y de algunos actuadores neumáticos, globalmente la máquina inspecciona productos y lleva un registro en una base de datos para tener estadísticas de la calidad.

Cuando vamos comenzando en el mundo de la programación tendemos a pensar en forma lineal, como una serie de pasos, siguiendo esta idea describiré la aplicación como una serie de tareas a realizar:

• Leer configuración de la máquina
• Abrir puerto motor 1
• Ajustar parámetros motor 1
• Abrir puerto motor 2
• Ajustar parámetros motor 2
• Abrir Puerto 3
• Ajustar parametros motor 3
• Abrir cámara 1
• Ajustar parámetros cámara 1
• Abrir cámara 2
• Ajustar parámetros cámara 2
• …..

Como podrás observar, describir este programa como una sucesión de tareas nos tomará mucho tiempo y la lista será muy larga y pensar de esta manera nos limita a hacer una cosa en cada momento, me gusta hacer analogías y visualizo a este problema como lo que sucede en algunas empresas cuando se micro administra el personal, es decir, hay una persona que está supervisando todas las actividades de los empleados en todo momento, cuando una persona quiere hacer su trabajo debe pasar por un cuello de botella que es el gerente que por estar supervisando minuciosamente todos los procesos siempre está ocupado, el micro gerenciamiento no ayuda a que una empresa sea eficiente, lo mismo puede suceder si al programar pensamos linealmente, a continuación una imagen describiendo 6 tareas ejecutadas en serie o en paralelo, como se puede ver, el tiempo de ejecución total de un ciclo es diferente, pensar en simultáneo puede hacer la diferencia en una aplicación con cierta complejidad, además, si visualizamos una aplicación como un conjunto de problemas a coordinar seguramente tendremos mas éxito.

Hablando del problema de ejemplo a continuación propongo una posible solución con un diagrama de elementos y su relación entre si:

DQMH permite crear módulos donde cada módulo tendrá un propósito específico, después de ver la imagen y usando DQMH tendremos los siguientes módulos con su respectivo tipo.

Probablemente te estés preguntando, ¿Por qué 2 tipos de Módulos DQMH?, eso lo explicaremos en el siguiente punto.

 3.- Concurrencia

Muchas ocasiones se tienen procesos idénticos, siguiendo con el mismo ejemplo pueden ser los 3 motores o las 2 cámaras, pero, ¿que pasa si estos motores y cámaras son idénticos o muy similares?, si no tenemos la modularidad en mente, terminamos copiando y pegando el mismo código 2, 3 o N veces, las que sean necesarias, probablemente estés pensando, un subVI puede resolver el problema, pero déjame preguntarte, ¿Que tal si cuando arranquemos la aplicación aun no sabemos cuantas cámaras y cuantos motores estarán presentes?, podemos utilizar el mismo subVI en varios lugares, pero eso se decide cuando estamos editando el código, no cuando ya está corriendo o como ejecutable, también, ¿que pasaría si queremos que cada motor y cada cámara tengan datos privados y estado propio?, es decir, cada motor es independiente de otro, entonces en algún lugar se debe almacenar esta información, las cosas se empiezan a complicar.

DQMH tiene la solución para estos problemas 😎, los módulos Clonables, este tipo de módulos tienen habilitada la reentrancia de código, por lo cual, cuando estamos editando el código solo editamos una vez, pero cuando ejecutamos el código podemos decidir cuántas instancias simultáneas de ese código se ejecuten, cada una con su propio espacio de memoria, esto es fantástico ya que permite crear por ejemplo un driver para un tipo de motor pero esto no limita a que solo se puede usar un motor en la aplicación, al ser cloneable podemos ejecutar N instancias de este código y cada una tendrá un ciclo de vida diferente al de sus hermanos clones, la aplicación general se puede comunicar con cada clon mediante el “Module ID”, también nos podemos comunicar a todos los clones cuando “Module ID=All”.

A continuación un breve video mostrando un módulo Cloneable, se observa cómo se ejecutan 5 instancias del mismo, y cómo podemos dirigir nuestros comandos a cada instancia o bien a todas las instancias. 

4.- API Tester

Todo módulo DQMH viene con un vi llamado API Tester, este nos sirve para probar el módulo, mediante el API Tester podemos arrancar el módulo, probar sus eventos, tener la capacidad de usar el API Tester para un módulo de toda la aplicación nos permite enfocarnos, por seguir el ejemplo, al abrir el API Tester del módulo de Motor, se pueden ejecutar 3 instancias para poder probar los 3 motores en nuestra aplicación, esto, completamente aislado de las cámaras o las bases de datos, cuando tenemos un código monolítico esto es casi imposible, se tiene que ejecutar toda la aplicación para poder probar solo una parte de la misma, en ocasiones no se cuenta con todo el hardware y probar se convierte en otro problema a resolver, se tiene que deshabilitar todo el código del hardware que no se tiene acceso para poder probar el hardware que si se tiene acceso, en DQMH esto está resuelto, podemos probar cada módulo con su API Tester de una manera aislada a otros módulos.

En repetidas ocasiones Fabiola de la Cueva durante mi tiempo trabajando en Delacor me decía, “El API Tester es la documentación viviente de tu módulo DQMH”, “Solo necesitas ver el diagrama de bloques de tu API Tester para saber como usar el módulo”, esto es completamente cierto, si heredamos un código DQMH, y lo vamos a utilizar en nuestra aplicación y no sabemos como, solo tenemos que revisar el código del API Tester, este código ejercita el módulo y te enseña a arrancar el módulo, ejecutar sus requests, escuchar sus broadcast, etc.

5.- Trabajo Colaborativo, Uniformidad-Herencia

DQMH al permitir modularizar una aplicación, podemos delegar a muchos desarrolladores una aplicación grande y después, de manera coordinada podemos comenzar la codificación de la aplicación, por ejemplo, podemos delegar el desarrollo de los módulos de Cámara y Motor a 2 desarrolladores, cada uno estará enfocado en desarrollar un módulo para manejar un hardware en específico, después, cuando terminen su módulo, este puede ser utilizado por los siguientes módulos de mas alta jerarquía como el Manejador de motores o el procesador de imágenes, imaginemos una aplicación como un set de bloques de Lego, cada bloque tiene un tiempo de desarrollo y después este módulo se utiliza en otro módulo con mayor jerarquía, por supuesto que podemos empezar desarrollando todos los módulos al mismo tiempo pero esto causará que perdamos contexto, tienes que ser muy cuidadoso planificando tu aplicación, cuando me he encontrado en esta situación, trato de entender primero todos los detalles posibles, después ya podré empezar a codificar mis módulos, tener un conocimiento amplio de tu aplicación hará que desarrolles mejores módulos, otro tip, siempre comunícate con tu equipo, infórmate que es lo que están haciendo si es importante en lo que tu estés trabajando, y también informa a tus compañeros que es lo que estás haciendo si eso es importante para que ellos desarrollen mejor su trabajo, la comunicación en un equipo de trabajo es esencial, creeme.

DQMH por naturaleza genera modularidad, y las herramientas de Scripting que tienen, generan código uniforme, fácil de leer, esto ayuda mucho porque, cuando estas usando un módulo, solo debes buscar el API tester para probar el módulo, Fabiola de la Cueva siempre me decía “El API tester es una documentación viviente de tu módulo”, no podría estar mas de acuerdo, el API Tester ayuda a saber usar el módulo, probarlo aislado de otros módulos, ahorra mucho tiempo para entender código que en el contexto que te encuentras no es relevante, si quiero usar un módulo solo tengo que observar como hacerlo en el API Tester.

¿Que opinas?,¿Te gustaría pode utilizar DQMH en tus aplicaciones?, me encantaría ayudarte a lograrlo, envía un correo a info@pantherlab.com.mx o bien agenda una cita dando click en el siguiente botón, gracias por leer.