Proyecto UWS (4)

En la entrada previa sobre UWS terminaba proponiendo unas líneas de evolución del proyecto. Una de ellas era permitir la utilización de nombres simbólicos, en lugar de direccionamiento absoluto. Como se trata de algo casi directo de hacer (basta añadir un diccionario al ensemble, un método de importación y pequeñas modificaciones del servidor web), me he puesto manos a la obra. El uso de simbólicos permite al programador abstraerse de la estructura interna de los controladores, hace el desarrollo más inteligible, y con ello reduce las posibilidades de equivocación. En la nueva versión es posible agregar un símbolo de la siguiente manera, en Python:

Nota: Aprovecho para decir que he renombrado las áreas del controlador Modbus, y he dejado sus nombres en singular (coil, input, holding y register).
Aunque es posible incorporar los nombres simbólicos picando código, es obvio que no resulta eficiente. Lo ideal es trabajar con ellos en una hoja de cálculo, e importarlos al ensemble. Por ejemplo, podemos crear el siguiente archivo csv, en el que la primera línea contiene los encabezados y las siguientes, en orden, el nombre de la variable, controlador, área de memoria y posición. El separador usado es el punto y coma, para evitar ciertos problemas clásicos con el punto decimal en Windows y Excel.

Incorporar estos datos es tan sencillo como hacer una llamada al método importtags del ensemble, pasándole la ruta:

Hecho esto, la lectura y escritura de una variable se puede efectuar a través de los métodos get y set de Tag:

En este punto, existe una posibilidad de mejora del proyecto que reclama nuestra atención. En la versión previa de UWS existía el método fast_deploy, que permitía crear automáticamente los grupos de escaneo de la memoria de los controladores. Esta función permitía desentenderse de la tarea de definir una por una las zonas con información relevante. No obstante, si resolvía un problema, generaba otro, y es que, al desconocer qué datos son de interés para el usuario, se opta por mapear toda la memoria. Sin embargo ahora, una vez hemos importado todas las variables que va a usar la aplicación, se hace evidente que conocemos dónde se ubica la información útil. Sólo hay que revisar las direcciones de la tabla que hemos importado, determinar qué zonas de memoria se demandan, y dentro de cada una de ellas, cuál es el primer y último valor. Con esto, es inmediato definir las áreas y grupos de escaneo. Así, el nuevo método mejorado para lanzar las comunicaciones es smart_deploy:

Hasta aquí lo que toca al motor de comunicación con los controladores. Respecto al servidor web, las peticiones GET /?r y /?w se han redefinido para atender a nombres simbólicos. He mantenido el direccionamiento absoluto, pero con llamadas /?dr y /?dw. Es decir, podemos tener cinco respuestas a una URL:

• http://[host]:[puerto]/?r:[símbolo] devuelve el valor de la variable con dicho símbolo.
• http://[host]:[puerto]/?w:[símbolo][valor] escribe el valor de la variable con dicho símbolo.
• http://[host]:[puerto]/?dr:[plc][memoria][elemento] devuelve el valor de dicho elemento en la memoria de su controlador.
• http://[host]:[puerto]/?dw:[plc][memoria][elemento] escribe el valor de dicho elemento en la memoria de su controlador.
• http://[host]:[puerto]/[fichero] entrega un fichero.

Al renombrar la sintaxis de las peticiones para asociar ?r y ?w a los nombres simbólicos, no es necesario actualizar j.js, que ahora trabaja directamente con símbolos en lugar de direccionamientos absolutos.
Otra tarea pendiente era mejorar la parte gráfica. En realidad esto no es una evolución de UWS propiamente hablando, ya que queda en el lado del desarrollo web. Sin embargo, he querido introducir algunas modificaciones para mostrar el potencial de un SCADA de este tipo. No me voy a entretener en describir cómo funciona el nuevo j.js (que será bastante evidente para quien se maneje con Javascript), pero sí debo comentar qué hace con los atributos que localiza en la página:

• data-dir: Es el atributo que define un elemento como dinámico, y contiene el nombre simbólico que se va a representar. Por defecto, j.js decide qué hacer según la etiqueta que lo contenga:
  • Los campos de texto se interpretan como un espacio para introducir un valor numérico. Se usarán por tanto en la práctica para consignas.
  • Los checkbox permiten modificar valores digitales (un marcha/paro, automático/manual, etc.).
  • Si el atributo pertenece a una etiqueta p o spam, se entiende que su contenido es un valor que se debe visualizar (puede ser numérico o booleano).
  • Por último, si se aplica a una capa o div, el refresco se hace sobre su visibilidad.
• data-css: Si está presente, las modificaciones no se hacen conforme a lo anterior, sino sobre el elemento de estilo contenido en este atributo. Podemos por tanto, a través de este atributo, alterar el tamaño de un elemento, su visibilidad de nuevo, color, etc.
• data-transform: Permite realizar transformaciones sobre el valor. Se pueden anidar varias, separadas por punto y coma:
  • invert invierte el valor de una señal digital.
  • scale:[x0],[x1],[y0],[y1] lleva a cabo un escalado, conforme a la recta (x0,y0)-(x1,y1).

  Mediante estas nuevas funcionalidades, se puede hacer un SCADA perfectamente funcional como el que se muestra en la siguiente imagen:

  

  Para quien desee hacer pruebas, dejo enlace al código, como otras veces.
  Esta entrada continúa en Proyecto UWS (5).
  Recursos asociados:
  SCADA UWS (versión 1.1) y código de ejemplo.