4.

Implementación y adaptación del laboratorio remoto

basado en LabVIEW.
Este capítulo está destinado a la implementación de un proyecto existente llamado
“Entorno integrado en LabVIEW para el desarrollo de aplicaciones prácticas basado en el
sistema DSK6711 de Texas Instruments” realizado por Isabel Román.
Buscamos tener un servidor que ofrezca a los clientes a través de Internet una
herramienta para controlar y monitorizar diversos equipos de laboratorio.
Para una primera implementación, necesitaremos un lenguaje de programación de tipo
visual (para ofrecer un interfaz visual con el que controlar y monitorizar los equipos) y un servidor
que ofrezca dicho Interfaz a través de Internet. Para hacer todo esto escogeremos el programa
LabVIEW de National Instruments, principalmente por ser el escogido en los proyectos
anteriores en los que está basada la realización del panel del que nosotros partiremos.

4.1. Instalación y configuración de programas necesarios.

4.1.1. GPIB.
Para poder mandar comandos hacia los instrumentos de medida a través del Bus GPIB
tenemos que instalar el driver que lo controla, para ello necesitaremos el GPIB-32 library de
Measurement Computing. En la página oficial de Measurement Computing no es posible
descargar estos drivers, hay que comprarlos, por tanto se ha usado el mismo que se utilizaba en
el proyecto en el que está basado este Laboratorio.
Consiste en una instalación típica que se instala por defecto en C:\GPIB_32, la única
dificultad es que el sistema necesita copiar el archivo GPIB-32.dll en la carpeta de sistema
System32 de Windows, el mismo programa instalador lo hace y para ello pregunta al usuario si
puede hacerlo.

4.1.2. Code composer Studio.

El programa Code Composer Studio (CCS) mejora y acelera el proceso de desarrollo,
para los programadores, que crean y prueban, en tiempo real, aplicaciones de procesamiento de
señales.
Se tiene que instalar en el servidor ya que es el encargado de programar el DSP que se
encuentra en la placa de desarrollo, el programa creado en LabVIEW se comunica con este
programa cuando hay que interactuar con el DSK, para ello hay que instalarle un módulo
adicional al LabVIEW (se hará en apartados posteriores).

- 21 -
 La instalación es típica así que no tendremos ningún problema, por defecto se instalará
en la carpeta C:\Archivos de programa\CCS. En este proyecto se ha instalado la versión 2.21
ya que es la que se encontraba en el proyecto anterior a éste, aunque conocemos la existencia
de la versión 3.2 y sabemos que es compatible con este proyecto ya que se instaló inicialmente,
pero se decidió volver a la versión anterior debido a que esta nueva versión tiene la misma
funcionalidad y añadía complejidad al manejo y a la instalación.

4.1.3. LabVIEW.
Necesitamos instalar el LabVIEW, para ello hemos elegido la versión 7.1. Actualmente
existe la versión 8.0 pero para nuestras necesidades nos basta con la versión elegida. La
instalación es sencilla, ya que se puede realizar una configuración típica, solamente debemos
conocer el password requerido para la instalación, hemos utilizado como nombre eDSPlab y
organización Laboratorio remoto.
Como este laboratorio está basado en un proyecto anterior tendremos que partir de los
archivos de ese proyecto, por tanto necesitamos el programa creado en LabVIEW, para ello
Isabel Román creó un CD con estos archivos, así que es necesario guardarlos en el PC
destinado al nuevo Laboratorio donde lo estamos implementando. La ubicación de estos
archivos debe ser la misma que se indica en el proyecto, ya que así no tendremos que
modificarlo en el programa, por tanto lo grabaremos en C:\LabCSED, esta carpeta se compone
de dos subcarpetas.

x Archivo alumnos: donde se guardarán los archivos subidos de los alumnos

para programar el DSP.

x Labremoto: contiene los archivos necesarios para la ejecución del programa en

LabVIEW.
Los programas hechos con LabVIEW se llaman VI (Virtual Instrument), como se ha
comentado LabVIEW es una herramienta gráfica de programación, esto significa que los
programas no se escriben, sino que se dibujan. Se dividen en Panel Frontal y Diagrama de
bloques. El Panel Frontal es el interfaz con el usuario, en él se definen los controles e
indicadores que se muestran en pantalla. El Diagrama de Bloques es el programa propiamente
dicho, donde se define su funcionalidad, aquí se colocan iconos que realizan una determinada
función y se interconectan.
4.1.3.1. Drivers.
Para la comunicación del programa con el bus GPIB y el programa Code Composer
necesitamos instalar algunos controladores, para que LabVIEW sea capaz de comunicarse con

- 22 -
el bus, esto es debido a la evolución de todos los estándares que se han llevado a cabo a partir
de la creación del bus GPIB. Estos drivers están disponibles en la página de National
Instruments http://www.ni.com/ aunque los adjunto con el CD del presente proyecto. Para
entender mejor el porqué necesitamos estos controladores se muestra a continuación un simple
esquema explicando como estarían dispuestos éstos dentro de la comunicación.

Figura 7. Esquema de controladores para LabVIEW

El bus IEEE-488 fue diseñado para conectar y controlar instrumentos programables.

También provee de un interfaz estándar de comunicación entre instrumentos de diferentes
fabricantes.
Desde los inicios de los instrumentos basados en GPIB existía un cierto desorden en
cuanto a la sintaxis y al contenido de las órdenes. Instrumentos de funcionalidad similar de
distinto fabricante, o incluso del mismo fabricante, usaban conjuntos de órdenes totalmente
distintos, lo cual suponía muchas dificultades para el programador. La norma IEEE-488.2-1987
primero y el consorcio SCPI (Standard Commands for Programable Instrumentation) después
racionalizan la situación.
La “norma” SCPI se construye a partir del 488.2 y define los comandos específicos de
dispositivo que estandarizan la forma de acceso a los equipos programables. Su objetivo es la
estandarización del contenido de los mensajes. Mediante SCPI se reduce el número de
comandos que hay que conocer para desarrollar un sistema de medidas, mejorando los costes

- 23 -
involucrados y la capacidad para intercambiar instrumentos. La estructura de comandos es
jerárquica permitiendo la extensión en caso de nuevas innovaciones.
Un driver es por tanto un conjunto de funciones, llamadas desde dentro de una
aplicación y que realizan una o más acciones sobre el instrumento. Estas acciones pueden ir,
desde mandar un mensaje SCPI a través del bus, hasta el tratamiento de los datos recibidos del
instrumento (FFT, series de Fourier, etc.).
Una de las arquitecturas usadas para este fin es VISA (Virtual Instrument Software
Architecture). En esta se definen una serie de tipos de datos utilizados en las distintas funciones
del driver. Un ejemplo de tipo de datos sería ViStatus (Entero sin signo de 32 bits).
Los tipos de datos definidos en VISA permiten la portabilidad de drivers a distintos
sistemas operativos y lenguajes de programación. Cada la función del dispositivo es genérica e
independiente del tipo de interfaz usado (Ej. GPIB, VXI) para controlar el instrumento.
Otra arquitectura para la creación de drivers de instrumentos, es IVI (Interchangeable
Virtual Instrument) que cuenta con las siguientes características:

x Intercambiabilidad: Permite usar el mismo driver con un mismo tipo de

instrumento, independientemente del modelo. Ej.: Fuentes DC, Osciloscopios,
Generadores de funciones.

x Simulación de instrumentos. El driver puede simular la operación de los

instrumentos cuando estos no están disponibles. Esto permite el desarrollo de
código de control aun sin disponer del instrumento.
IVI es una capa que se sitúa por encima de VISA y usa las funcionalidades VISA para
controlar el instrumento. Los drivers IVI permiten a la aplicación que los usa seguir funcionando
aun cuando el instrumento se cambia. En cambio no se garantiza que la respuesta sea la misma
para un instrumento que para otro.
4.1.3.2. Servidor de LabVIEW.
Queremos que nuestro sistema se pueda controlar desde un navegador de Internet, para
conseguir esto debemos generar un archivo html que contenga una referencia al archivo .vi e
instalar en el navegador del cliente un plug-in que National Instruments ofrece gratuitamente.
Con esto, al acceder a este archivo html desde el navegador (colocando en el campo de
direcciones http://nombre del PC/Nombre del archivo .html) conseguimos el mismo
comportamiento que si estuviésemos en un panel remoto pero directamente desde el navegador.

- 24 -
Existen plug-ins disponibles para Microsoft Explorer, Netscape Navigator y para sistemas
operativos Linux.
LabView contiene un editor del archivo html donde podemos elegir varias opciones de
construcción (opción Web Publishing Tool, en el menú Tools). Podremos seleccionar si
queremos ver la imagen estática, la imagen con refresco o el control absoluto del instrumento.
También podemos hacer que, una vez cargada la página, se pida el control automáticamente
(Request Control).

Figura 8. Muestra de la función para crear el archivo HTML

Pero antes de esto lo primero que debemos hacer es activar este servidor, para ello
tomamos el punto Options dentro del menú Tools del LabVIEW. En la pestaña web server
configuration habilitamos el servidor Web. En el espacio Root Directory ponemos la ruta
donde se ubicará nuestro el HTML creado. Se puede ver una captura en la figura para nuestra
configuración.

- 25 -
 Figura 9. Configuración del Web Server

4.2. Detección y corrección de problemas.

Antes de nada hay que aclarar que casi todos los problemas que se han detectado
pertenecen al programa creado en LabVIEW y que hace de conexión entre los instrumentos de
medida y el PC. Este programa esta dividido en varios módulos, cada uno de ellos está
relacionado con un instrumento de medida dando así independencia entre ellos. El panel gráfico
está distribuido según la siguiente figura.

- 26 -
 Figura 10. Interfaz Web del Laboratorio remoto

Y cada módulo tiene en el diagrama de bloques una zona restringida por un bucle con
las condiciones adecuadas para entrar y salir cuando es requerido. Durante la corrección de los
problemas se irán explicando con detalle la mayoría de todos estos módulos junto con sus
bucles asociados.

4.2.1. Direcciones GPIB.

El problema más fácil de detectar es que es posible que al mandar comandos al bus
GPIB los instrumentos de medida conectados no actúen, ello es debido a que este bus trabaja
con direcciones GPIB, cada instrumento tiene asignado un número de dirección y el programa

- 27 -
creado en LabVIEW tiene que comunicarse con ese elemento a través de esa dirección, si éstas
no coinciden, no se entenderán y será imposible mantener una conversación entre el equipo y el
PC. Estas direcciones se tienen que indicar en ambos lados manualmente, tanto dentro del
programa como en los equipos.
Para corregirlo tenemos que cambiar las direcciones GPIB en los equipos, así es más
sencillo ya que de esta forma no hay que cambiar el programa creado en LabVIEW.

4.2.2. DSK.
El principal problema que se encontró en el módulo que maneja el DSK es que no existe
información en el proyecto anterior para configurar el programa Code Composer Studio, sin esta
concreta configuración el instrumento virtual VI no puede conectarse a la placa de desarrollo.
Este problema esta resuelto en el capítulo anterior cuando se instala el programa Code
Composer Studio, allí se explica como se debe hacer la configuración para el DSK6711, que es
el DSP que actualmente se utiliza en las prácticas, si éste es sustituido por otro tendremos que
hacer los cambios oportunos.
Aún resuelto este problema nos dimos cuenta que aunque el programa en LabVIEW era
capaz de comunicarse con el DSP a través del Code Composer Studio la carga del programa en
memoria y su ejecución no se hacía bien, ya que no terminaba de cargarlo y se reiniciaba la
placa. Esto se debía a que la secuencia de órdenes que se daba a la placa a través del
LabVIEW no era la correcta.
Los cambios que se hicieron fueron básicamente de dos tipos, en el primero se cambió
de posición la función que resetea la placa (CCS Reset.vi), y se colocó antes de cerrar el Code
Composer, entre Halt y Close, esto podemos observarlo en la figura anterior. Para el segundo
cambio se tuvo que aumentar el tiempo de carga de programa en memoria ya que el que estaba
puesto era insuficiente. Para ello dentro de CCS Download Code.vi cambiamos varios valores
que se utilizaban para el cálculo del tiempo. Los valores dependen un poco del ordenador donde
se esté ejecutando, por tanto, no me aventuro a dar posibilidades, el método que se ha usado en
nuestro caso ha sido el de prueba y error, al ver que no es suficiente se ha ido aumentado hasta
que se ha llegado a un valor razonable.

- 28 -
 Figura 11. Valores que se utilizan para el cálculo del tiempo de carga

4.2.3. Comandos GPIB del osciloscopio.

Este problema ha sido el más complicado de resolver, ya que ha supuesto un cambio
drástico en el programa creado en LabVIEW. El motivo de este problema es debido a que el
proyecto se realizó con un osciloscopio distinto al que se ha utilizado.
El que se utilizó fue el Hewlett packard 4603B y el que se ha suministrado para la
implementación es un modelo superior a éste, se trata del Agilent DSO3062A.

Figura 12. Diferencia de osciloscopios

En principio no debía existir ningún problema, pues son totalmente compatibles, pero al
intentar comunicarse con el instrumento de medida se observó que el nuevo elemento no
reaccionaba a los comandos.
Vemos que SCPI intenta crear un formato general para cualquier instrumento, ya que
con 488.2 cada fabricante tenía su propio formato y lenguaje para comunicarse a través de
GPIB. El problema que encontramos residía en que SCPI no especifica el lenguaje sino un estilo
de formato, por tanto podemos adaptar cualquier programa creado para controlar un instrumento

- 29 -
de medida específico a otro instrumento de medida haciendo cambios en los comandos que se
mandan al bus GPIB.
Existen guías de programador para cada instrumento donde se pueden ver los
comandos que se utilizan para el Agilent DSO3062A y el Hewlett packard 4603B. Realmente son
comandos muy parecidos pero tienen pequeñas diferencias, por tanto, hay que cambiar todos los
que se crearon ya que solo funcionaban para el osciloscopio anterior. A parte de estos cambios
se comprobó que además de usar el separador punto y coma para separar comandos hay que
utilizar nueva línea para que el nuevo osciloscopio ejecute dicho comando.
La solución consistía en cambiar todas las funciones que mandaran comandos GPIB al
osciloscopio, esto no era un trabajo complicado pero suponía un trabajo engorroso y largo, y
para ello tuvo que hacerse un estudio previo de todas las funciones VI que se habían creado en
el proyecto anterior.

4.2.4. Osciloscopio y DSK juntos.

A parte de los problemas encontrados en los módulos del DSK y del Osciloscopio se
nos presentó un último inconveniente que se tuvo que resolver al final de todos. Éste se trataba
de un problema de compatibilidad entre los dos módulos indicados anteriormente, es decir, si el
osciloscopio estaba encendido el módulo del DSK creado en LabVIEW no hacía nada, era como
si no entrara en el bucle que interactúa con la placa de desarrollo.
Al encontrar el problema no se sabía el motivo de este fallo, pues podrían haber sido
varios pero tras descartar la mayoría, se vio que se debía a las variables generales del programa
creado en LabVIEW y su relación con las condiciones en los bucles donde estaban ubicados los
módulos del DSK y osciloscopio.
La única variable global que se utiliza en todo el sistema es una línea de error que se
utiliza en las condiciones de los bucles, así que supusimos que el problema residía ahí. El
osciloscopio ocasionaba un error cuando estaba encendido (este error no era relevante), y el
bucle del DSK no actuaba si la línea de error estaba activada, así que ambos módulos con esa
configuración no podían estar funcionando a la vez.
Para que esto no ocurriera teníamos que hacer que los errores entre un módulo y otro no
se mezclaran, por tanto se independizaron las líneas de error, es decir se crearon dos, una para
los instrumentos de medida y otro para el DSK, al final de su recorrido se sumaban y se miraba
si hubo error en algunos de los módulos.

- 30 -
 Después de corregir este problema, el Laboratorio remoto funcionó a la perfección, por
tanto, se puso en funcionamiento a la espera de que los alumnos puedan ver pequeños fallos
que se pudieron pasar por alto y hacérnoslo comunicar.
Para poder poner en funcionamiento este laboratorio se necesita crear una página
escrita en PHP para poder subir archivos .out en el servidor para poder cargarlos en el DSP, y
más importante aún todavía, dotar a todo el sistema de seguridad para que nadie pueda entrar
en el sistema. Todo esto se ha explicado en el siguiente capítulo dedicado a la seguridad.

- 31 -