Descripción de GPIB. Historia

Transcripción

1 GPIB

2 Descripción de GPIB GPIB es un estándar de conexión que permite la comunicación de un ordenador con instrumentos electrónicos de medida, como pueden ser generadores de funciones, osciloscopios, etc. Las siglas corresponden a General Purpose Interface Bus, pero a pesar de este nombre, fue diseñado específicamente para la conexión de instrumentos de medida. Historia Fue creado en 1965 por la compañía Hewlett-Packard, que lo denominó originalmente HP-IB, y se popularizó con rapidez, debido a sus altas tasas de transferencia de datos (8 Mbytes/s). En 1975, para evitar la dispersión de características, los principales fabricantes acordaron la estandarización del GPIB (IEEE 488.1), centrándose en las características eléctricas y mecánicas del bus. En Europa se acoge con la norma IEC-625.1, que modifica el conector. En 1978 se revisó el documento y terminó siendo adoptado ampliamente en la industria bajo las siguientes denominaciones: - GPIB (General Purpose Interface Bus) - HP-IB (Hewlet-Packard Interface Bus) - IEEE 488 Bus - IEEE (denominación posterior, al definir el IEEE 488.2). En 1987 tuvo lugar una segunda estandarización (IEEE 488.2) que delimitó de forma más concreta la programación del GPIB, definiendo comandos de aparatos, formato de mensajes y estado de los instrumentos. Se pretendía aumentar la compatibilidad entre sistemas. Sin embargo este protocolo no llegó a reemplazar al original. De hecho hoy día sigue habiendo aparatos que responden únicamente al IEEE En 1990 se adoptó el formato de comandos SCPI, incluido en el 488.2, que estructura las órdenes a los aparatos de forma coherente, permitiendo una compatibilidad más extensa. Características físicas El bus de transmisión de datos de GPIB es de 8 bits en paralelo, y lógica negativa con niveles TTL estándar (cierto si el voltaje es 0.8 V y falso si el voltaje es 2.0 V). Los cables y conectores tienen el aspecto típico mostrado en la figura 2. Están apantallados y permiten velocidades de transferencia de 1 MB/s, aunque existen versiones que llegan hasta los 8 MB/s. Los conectores tienen dos lados de conexión (macho y hembra) permitiendo diversas estructuras topológicas (bus, estrella y combinaciones) tal y como se muestra en la figura 2. Los hay de dos tipos: americano (24 pines) y europeo (IEC-625.1, 25 pines).

3 Figura 1: cable de conexión GPIB: aspecto físico y distribución de señales (americano). Figura 1: ejemplo de configuración de un sistema GPIB.

4 El busconsta de 24 pines, repartidos de la siguiente forma - 8 líneas de transmisión de datos (DIO1-DIO8). - 3 líneas para el control asíncrono de la comunicación (NRFD, NDAC y NRDAV). Mediante estas líneas se verifica la correcta transmisión de los datos, que es una de las fortalezas del GPIB. - 5 líneas que gestionan la transmisión de comandos (ATN, IFC, REN, SRQ y EOI). - El resto componen las tierras de las diferentes líneas. Para que el bus GPIB alcance la velocidad de transmisión para la que fue diseñado (hasta 8 Mbytes/s), deben cumplirse los siguientes requisitos: - Puede haber un máximo de 15 dispositivos conectados al bus, y al menos dos tercios de ellos deben estar encendidos. - La separación máxima entre dos dispositivos es 4 m, y la separación promedio en toda la red debe ser menor de 2 m (National Instruments comercializa un extensor de fibra óptica (GPIB 140 y 140/2) que permite alcanzar una longitud de hasta 2 km). - La longitud total de la red no debe exceder los 20 m. Un sistema típico constará de un ordenador con una tarjeta controladora GPIB, más los instrumentos (compatibles con IEEE 488, obviamente). Existen tarjetas GPIB para prácticamente todos los ordenadores presentes en el mercado (PC, Macintosh, estaciones Sun, Silicon Graphics, DEC Alpha, HP RS/6000, etc). En el caso concreto del PC, las controladoras GPIB pueden conectarse al bus ISA, PCI, PCMCIA (portátiles), USB, Ethernet, Firewire, y los puertos serie y paralelo. Existen asimismo adaptadores para los estándares de comunicación RS-232 y RS-485. La figura 4 muestra una tarjeta GPIB.

5 Figura 4: Tarjeta GPIB-PCI para ordenadores PC. 1. Inicio de conexión El proceso es de tipo three-way-handshake y se desarrolla como sigue. Cuando el regulador o un transmisor desea transmitir datos sobre el GPIB, fija la línea de DAV (Data valid, Dato válido) a nivel alto, y comprueba que las líneas de NRFD (Nor ready for data, Instrumento no preparado para recibir datos) y de NDAC (No data accepted, Dato no aceptado) están a nivel bajo, y entonces pone los datos en las líneas de datos. Cuando todos los dispositivos que pueden recibir los datos están listos, cada uno libera su línea de NRFD. Cuando el receptor anterior libera la NRFD, y pasa a ALTO, el regulador o el transmisor toma el punto bajo de DAV que indica que los datos válidos ahora están en el GPIB. En respuesta, cada receptor pone de nuevo a nivel bajo la línea de NRFD para indicar que está ocupado y libera NDAC cuando ha recibido los datos. Cuando el último receptor ha validado los datos, la línea NDAC pasará a nivel alto y el regulador o el

6 transmisor puede fijar la DAV a nivel alto otra vez para transmitir el siguiente byte de datos. Obsérvese que si después de la activación la línea de DAV está a nivel alto, el controlador o el transmisor entiende que tanto la línea NRFD como la NDAC están a nivel alto, siendo esta circunstancia una posible causa de error. Así mismo, si cualquier dispositivo falla al elaborar su parte del handshake y libera la NDAC o la NRFD, los datos no pueden ser transmitidos por el bus. Es posible que se genere un error por sobrepasar el tiempo asignado. La velocidad de transferencia de datos es controlada por el dispositivo más lento conectado al bus, de ahí la dificultad de estimar el flujo de transmisión de datos en el bus IEEE-488, ya que depende de los dispositivos conectados. 2.Líneas de control del interfaz Las cinco líneas de gestión del interfaz (ATN, EOI, IFC, REN, SRQ) controlan el flujo de las señales de control y datos a través del interfaz. La señal ATN (Attention, Atención) es activada por el controlador para indicar que está colocando un byte de dirección, de control o de datos en el bus. La ATN es liberada para permitir que el transmisor seleccionado ponga sus datos en el bus. El controlador recupera el control reactivando la línea ATN; esto se suele hacer sincronizadamente con el handshake para evitar las confusiones entre los bytes de control y los de datos. La señal EOI (End or Identify, Fin o Identificación) tiene dos funciones. Un transmisor podría activar EOI al mismo tiempo que el último byte de datos para indicar el final de los datos. El controlador podría activar EOI junto con ATN para iniciar un sondeo en paralelo. Como quiera que mucho dispositivos no usan la sondeo en paralelo, todos los dispositivos deberían usar la señal de EOI para indicar el fin de la transmisión (esto es posible en la mayoría de los instrumentos). La señal de IFC (Interfaz Clear, Borrado del interfaz) es activada sólo por el controlador del sistema para colocar los interfaces de todos los dispositivos en un estado conocido. Después de recuperar el IFC, el controlador del sistema pasa a ser el controlador activo. La señal REN (Remote Enable) es activada únicamente por el controlador del sistema. Su activación no coloca a los dispositivos en el modo de control remoto; la señal REN sólo habilita el paso a modo remoto de cierto dispositivo direccionado como receptor. Cuando un dispositivo está funcionando en modo remoto, debe ignorar las órdenes que reciba a través de su panel de control. La línea de SRQ (Service Request, Solicitud de servicio) puede ser activada por cualquier dispositivo para solicitar el acceso al controlador y así realizar cualquier acción. El controlador debe averiguar que dispositivo es el que ha realizado la SRQ, para lo cual utiliza una sondeo en serie o en paralelo. En el sondeo serie, el controlador direcciona los instrumentos uno a uno hasta encontrar al peticionario. En la respuesta se emplea un bit para indicar si solicitó ser consultado, y 7 para indicar la petición. El dispositivo que hace la solicitud libera la línea de SRQ. En el sondeo paralelo cada instrumento indica en uno de los 8 bits de datos si solicitó la consulta. Tiene como ventaja una mayor rapidez de búsqueda pero implica una configuración previa de los equipos y además limita su número a 8.

7 3.Direccionamiento de los dispositivos El estándar IEEE-488 permite la interconexión de 15 dispositivos a través de un único bus. Cada dispositivo tiene asignada una única dirección primaria, (comprendida entre la 0 y la 30), por medio de la actuación de los microinterruptores de direccionamiento de los que dispone el dispositivo. También es posible hacer un direccionamiento secundario, desde la dirección 0 a la 30, para lo cual es recomendable dirigirse a la documentación que ofrece el fabricante del dispositivo, que podrá darnos más información sobre como direccionar el dispositivo, con la dirección primaria obligatoria o con la secundaria opcional. Modos de operación de un equipo En cada momento, un equipo conectados al bus GPIB pueden estar seleccionado como uno o varios de los siguientes modos de comportamiento: "Controller", con capacidad de establecer quien envía o recibe datos y el modo de operación del bus (solo un equipo puede ser "controller"); Talker", con capacidad de enviar datos a otros equipos; "Listener", con capacidad de recibir datos de otros equipos; "Idler" sin ninguna capacidad respecto del bus. CONTROLLER Entre los equipos conectados al bus existen dos tipos de controladores: el "system controller" y los "active controllers". En un bus, solo puede existir un único "system controller" con capacidad de poder tomar control del bus en todo momento. Este equipo tiene exclusividad en el control de las líneas IFC y REN. Cada sistema debe disponer de uno o mas dispositivos capaces de asumir la función de "active controller", aunque en cada momento, solo uno de esos equipos puede operar como tal. El controlador activo tiene la capacidad de seleccionar los equipos que deben operar como "listener" o como "talker" a efecto de la transferencia de datos, de enviar los comandos de bus, y de supervisar mediante encuestas el status de los equipos. En una situación estándar, es un computador el que actúa a la vez como "system controller" y como único "active controller". Algún sistema diferente, podrá en un momento dado requerir del controlador del sistema su interés en convertirse en controlador activo, a fin de llevar a cabo una operación compleja, tal como transferir unos datos al "plotter", o almacenar un fichero en un disco, etc.. Como respuesta a este requerimiento el controlador de sistema, transferirá el control al equipo que lo ha solicitado, el cual pasa a constituirse en controlador activo del bus. Cuando concluye su operación, retorna de nuevo el control del bus, al controlador de sistema. Obsérvese que las capacidades propias de controlador de sistema no pueden ser transferidas. Un sistema construido sobre el bus GPIB puede ser configurado en uno de los siguientes tres modos: - Sin "controller" : En esta configuración uno de los equipos debe tener sólo capacidad para actuar como "talker", y los restantes sólo como "listener". La transferencia de datos posibles es desde el "talker" a todos los "listener" simultáneamente. - Con "controller" único: En esta configuración las transferencias de datos posibles son: Desde el "controller" a los equipos en modo comando y datos, de un equipo al "controller" solo en modo datos, y de un equipo a otro equipo solo en modo datos. - Con múltiples "controller": En este caso tiene las mismas capacidades que la

8 configuración anterior, solo que en ésta también es posible la transferencia entre equipos de la capacidad de operar como "controller" activo. TALKER: En cada configuración pueden existir uno o varios equipos con capacidad de enviar datos a otros equipos. Cuando el "controller" ejecuta un comando "talk" con la dirección de uno de estos equipos, este pasa a ser "active talker", y a partir de ese instante tiene capacidad para enviar datos por el bus, controlando la línea DAV, siempre que todos los equipos que han de recibir los datos ("listener") se encuentren dispuestos a ello (línea NRFD a valor lógico "0"). LISTENER: En cada configuración pueden existir uno o varios equipos con capacidad de recibir datos desde el bus. Cuando el "controller" ejecuta un comando "Listen" utilizando la dirección de uno de estos equipos, este pasa a ser un "active listener", y a partir de este momento recibe y lee cada uno de los datos que cualquier "talker" envíe por el bus. Es frecuente que en una configuración existan múltiples equipos en estado "active listener", y todos ellos reciben en paralelo y simultáneamente todos los datos que sean transferidos por el bus. COMANDOS DEL BUS Los dispositivos conectados al bus GPIB pueden potencialmente enviar o recibir datos de cualquier otro equipo. Antes de que se produzca una transferencia de datos, el "controller" debe establecer cual es el equipo (solo uno) que debe actuar como "talker", y cuales van a actuar como "listener" (uno o varios equipos). Además de esta operación básica relacionada con la transferencia de datos, el "controller" y los otros equipos conectados al bus pueden realizar otras muchas operaciones no específicamente relacionada con el intercambio de datos entre equipos, sino con la gestión y organización de los diferentes equipos. A estas operaciones se las denomina genéricamente Comandos de Bus. En los comandos de bus se envían datos por el bus de datos (si la operación lo requiere) de igual modo en la transferencia de datos, solo que en estos casos la señal ATN es establecida a 1 lógico por el "controller", para indicar que es un comando, y en este caso, todos los equipos con independencia de que sean "talker" o "listener" reciben el comando manteniendo el protocolo con el "controller". El "controller" puede enviar cinco tipos de comandos de bus a los otros equipos: "addressed", "listen", "talk", "universal" y "secondary". Solo los 7 bits menos significativos del bus son utilizados en los comandos de bus. Los tres bit b7, b6 y b5. definen la naturaleza de cada comando: b7 b6 b5 tipo de comando addressed universal 0 1 x listen 1 0 x talk 1 1 x secondary Los equipos conectados al bus GPIB tienen asignado un código o dirección de bus comprendido entre Este código debe ser establecido en cada equipo, bien estableciendo unos conmutadores hardware presentes en su panel trasero, o bien en algunos

9 casos programando el equipo mediante su software interno. Normalmente, los cinco bit menos significativos de la línea de datos b5, b4, b3, b2, b1 se utilizan en un comando para establecer a que equipos hace referencia un comando. COMANDOS TALK/LISTEN Comandos My Talk Address (MTA) o (también llamado TAG Take Address Group): Es un comando destinado a establecer un equipo del bus como "talker". El formato de este comando es (0 1 0 d5 d4 d3 d2 d1). Cuando se ejecuta este comando, todos los equipos reciben el comando, y solo aquel cuya dirección esté presente en el comando, pasa a modo "talker". Tras finalizar este comando, el equipo que ha sido establecido como "talker" puede enviar datos a otros equipos. Comando Untalk (UNT): Es un comando que cuando es establecido por el "controller" requiere de todos los dispositivos que se encuentran en modo "talker", para que abandonen ese estado y pasen a su estado base. El formato de este comando es: Comando My Listen Adrress (MLA) (o también llamada LAG Listener Address Group): Es un comando que establece un equipo del bus como "listener". El formato de este comando es : d5 d4 d3 d2 d1 Cuando se ejecuta este comando, todos los equipos reciben el comando, y solo aquel cuya dirección sea la del comando, pasa a modo "listener". A partir de ese momento, el equipo recibe todos los datos que transmita cualquier "talker". Comando Unlisten (UNL): Es un comando que cuando es establecido por el "controller" requiere de todos los dispositivos que se encuentran en modo "Listener" para que abandonen ese estado y pasen a un estado base. El formato de este comando es: COMANDOS UNIVERSALES (UGC) Es un conjunto de comandos que ejecuta el "controller" con destino a todos los dispositivos del bus. Comando Local Lockout (LLO): Se utiliza para deshabilitar los paneles de control propios de cada uno de los equipos conectados al bus. Con esta deshabilitación, se evita que se produzcan conflictos entre las instrucciones recibidas por el bus, y las realizadas a través de los controles manuales del panel. El formato de esta instrucción es: Comando Device Clear (DCL): Es un comando que resetea todos los equipos disponibles sobre el bus Comando Parallel Poll Unconfigure (PPU): Es un comando que se utiliza para resetear la programación realizada sobre los diferentes equipos a fin de que respondan en las encuestas paralelas ("parallel poll"). El formato de este comando es Comando Serial Poll Enable (SPE): Este comando habilita a todos los equipos para que respondan en modo de encuesta serie ("serial poll"). Cuando se habilita el modo de encuesta serie, cada vez que se envía un comando "talk" a un equipo presente en el bus, este contesta enviando su estatus. El formato de este comando es:

10 Comando Serial Poll Disable (SPD): Deshabilita el modo de encuestaserie en todos los equipos conectados al bus y pasan a modo normal. El formato de este comando es: COMANDOS ADDRESSED (ACG) Los comandos de este grupo van destinados únicamente a aquellos equipos que previamente han sido establecidos en "listener". Comando Go To Local (GTL): Cuando se envía este comando, todos los equipos que se encuentran en modo "listener" vuelven el control a sus paneles locales. Este comando cancela el efecto establecido por el comando universal Local LockOut (LLO). El formato de este comando es: Comando Selected Device Clear (SDC): Este comando resetea de forma selectiva a aquellos equipos que están en modo "listener". El formato de este comando es: Comando Parallel Poll Configure (PPC): Este comando pone a todos los equipos que se encuentran en modo "listener" en modo para ser programados a efecto de responder a una encuesta paralela ("parallel poll"). El formato de este comando es: El "controller" ejecuta una encuesta paralela estableciendo las líneas de control ATN y EOI a 1 lógico. Cuando los equipos conectados al bus reciben este estado de las líneas, responden situando un bit de estatus sobre la línea del bus de datos que se le haya asignado en el comando PPC. El "controller" puede leer el estado del conjunto de las líneas del bus de datos, y obtener información global sobre todos los equipos que fueron programados para la encuesta paralela. El comando PPC se usa para especificar por que líneas del bus de datos debe responder cada equipo, y si el dispositivo debe responder con un "0" o un "1" lógico el requerimiento de servicio. Tras ser transmitido el comando PPC todos los equipos que se encontraba en modo "listener" se ponen a la espera de recibir un comando secundario ("My Secondary Adrees" (MSA) o también llamado "Secondary Address Group (SAD)") con el que queda programada su respuesta a una encuesta paralela. Los cuatro bits más bajos del comando secundario b4 b3 b2 b1 contienen la siguiente información: b4 : Indica la forma como debe responde por la línea asignada. Si b4 =0 indica que el equipo debe indicar durante la encuesta paralela, que requiere servicio estableciendo un "0" lógico en la línea que le ha sido asignada. b4=1 significa que el equipo debe indica el requerimiento de servicio poniendo un "1" lógico sobre la línea. b3b2b1 : Indica la línea entre 0 y 7 por la que deben responder los equipo que están siendo programados. Varios equipos pueden ser programados para que respondan en una encuesta paralela respondiendo sobre una misma línea. Dado la lógica wire-or utilizada para el control de la línea, y las dos posibilidades de modo de respuesta a la encuesta paralela que puede establecerse, caben la posibilidad de determinar si alguno de los equipos que responden pos la misma línea requiere servicio, o si todos esos equipos requieren simultáneamente servicio. Comando Group Trigger (GET): Permite sincronizar la operación de un conjunto de equipo que previamente han sido programados para que se encuentre a la espera del comando. El formato de este comando es

11 Comando Take Control (TCT): Con este comando el "controller" transfiere su función como controlador a otro equipo capacitado para ello. Para ello, primero debe establecer el equipo que va a ser establecido como nuevo "controller" a modo "listener", y posteriormente enviar este comando TCT para convertirlo en el "controller" del bus. El formato de este comando es: IEEE Para permitir una mayor compatibilidad entre instrumentos, se amplió la norma definiendo una serie de funciones sobre el protocolo anterior, dispensadas por el controlador activo. A este nuevo conjunto de normas se le denominó IEEE 488.2, pasando el antiguo IEEE 488, a ser el IEEE Entre las nuevas características se incorporaba la posibilidad de conocer el estado del instrumento y consultar posibles estados de error (Apéndice I). En el apéndice II se muestra una tabla con las funciones agregadas. IEEE Especificaciones mecánicas, eléctricas. Funciones básicas de control y handshaking IEEE Estructura de datos y sintaxis. Ordenes y consultas comunes. Protocolo de mensajes. Secuencias de control SCPI Formato de intercambio de datos. Ordenes jerárquicas normalizadas Posteriormente, se elaboraron nuevas funcionalidades que se recogieron en un protocolo de mayor nivel denominado SCPI SCPI A pesar de los estándares IEEE y 488.2, existía libertad para que cada fabricante eligiera los comandos de sus instrumentos. En 1990 un grupo de empresas fabricantes de instrumentos acordaron crear un conjunto de órdenes con una sintaxis común, que fue llamada SCPI (Comandos Estándar para Instrumentos Programables). Lógicamente, SCPI se construyó respetando los principios del anterior Si dos instrumentos (por ejemplo, dos osciloscopios), de fabricantes distintos, se adhieren al estándar SCPI, es teóricamente posible intercambiarlos con mínimas modificaciones en el programa de control. Los comandos SCPI se escriben como texto ASCII, y tienen una estructura jerárquica por niveles, separados por dos puntos:

12 Los caracteres en mayúsculas son necesarios para especificar la orden, mientras que los que están en minúsculas pueden suprimirse, sirviendo sólo para facilitar la lectura de programas por usuario. Los comandos en sí pueden ser escritos indistintamente en mayúsculas o minúsculas. Así, SCALE, sca y scale representan todos al mismo comando. Por ejemplo: HOR:MAIN:SCA 5.0E-4 establece la escala de la base de tiempos en 500 µs/división. El signo de dos puntos (:) separa los niveles de la jerarquía. Si quisiéramos preguntar al osciloscopio por la escala actual de la base de tiempos habría que escribir: HOR:MAIN:SCA? Los comandos se pueden concatenar utilizando un punto y coma (;). Por ejemplo, se puede escribir la orden: ACQuire:MODe AVE; NUMAVg 16 que indica al osciloscopio que la adquisición va a ser en modo promedio (average) y que va a constar de 16 muestras. Nótese que los niveles jerárquicos ACQuire:MODe, al ser comunes, sólo necesitan ser indicados una vez; es decir, la orden anterior equivale a: ACQuire:MODe AVE; ACQuire:MODe NUMAVg 16 Una ventaja del estándar SCPI es la definición homogénea de comandos para todos los aparatos de una misma clase; por ejemplo, para un osciloscopio, las principales categorías de raíz se muestran en la tabla 1.

13 Tabla 1: Principales apartados de la jerarquía de comandos de un osciloscopio en SCPI. VISA e IVI Como se ha podido ver, la programación de un sistema GPIB a base de comandos SCPI es bastante laboriosa. Aunque hace años era la única opción disponible; hoy en día disponemos de drivers para los principales entornos de programación que permiten el acceso a los instrumentos a más alto nivel. Históricamente, el primer paso hacia la estandarización fue VISA (Virtual Instruments Software Architecture), un convenio de Agilent y NI para acceder a los instrumentos de la misma forma independientemente de la interfaz física (GPIB, puerto serie, etc). En 1998 surgió el consorcio IVI (Interchangeable Virtual Instruments) entre una treintena de compañías, incluyendo usuarios de sistemas como Boeing, y fabricantes de hardware como Agilent, Tektronix, NI, etc, con el objetivo de alcanzar una estandarización de los drivers de los instrumentos. En concreto, IVI aporta las siguientes novedades: -Adopción de VISA (independizando la programación respecto al bus de interfaz). -Posibilidad del intercambio de instrumentos, incluso de distintos fabricantes. -Posibilidad de trabajar con instrumentos simulados durante el desarrollo de aplicaciones, cuando la disponibilidad de los equipos está restringida. -Acceso a los instrumentos mediante una caché de estado, que optimiza el tráfico del bus cambiando el estado del instrumento sólo de forma incremental. -Posibilidad de programación multihilo. Los drivers IVI están clasificados en ocho clases o plantillas, correspondientes a los siguientes instrumentos de medida: - Fuentes DC - Multímetros digitales - Generadores de funciones - Osciloscopios - Medidores de potencia - Generadores de RF - Analizadores de espectros - Conmutadores de señales (switches) Con una librería IVI, el programador de C puede emplear rutinas de alto nivel sin necesidad de conocer el conjunto de comandos SCPI que el instrumento entiende. Como consecuencia, el desarrollo de aplicaciones de esta forma se ha

14 agilizado considerablemente respecto al uso de comandos SCPI. Software existente para GPIB La primera alternativa (y, en ocasiones, la más práctica), es el uso de software propietario desarrollado por los mismos fabricantes del instrumento. Por ejemplo, el programa gratuito Intuilink de Agilent Technologies, o el programa de pago Wavestar para los osciloscopios de Tektronix Inc. La ventaja evidente de estos programas es que pueden ser empleados nada más conectar los instrumentos, y proporcionan ya hechas las funciones más comunes que uno puede desear realizar, sin necesidad de programar. Las desventajas son también claras: por tratarse de software cerrado, sólo puede ser usado para la tarea para la que fue diseñado, y además son imposibles de integrar con otros programas. A) Labwindows/CVI y LabVIEW de National Instruments LabWindows/CVI es un entorno de desarrollo completo basado en ANSI C (el nombre significa C para Instrumentación Virtual). Los aspectos más destacables de este producto son: - Completas librerías para la comunicación entre dispositivos (puerto serie, paralelo, GPIB, TCP/IP, etc). - Especial facilidad para el desarrollo de interfaces gráficas adaptadas a los instrumentos de medida (dispone de elementos para mostrar formas de onda, conmutadores, potenciómetros, etc) - Soporte para los drivers IVI de numerosos instrumentos (extensión.fp). - Posibilidad de ofrecer el programa final desarrollado mediante una aplicación de instalación. National Instruments, creadores de LabWindows/CVI, ofrecen también LabVIEW, que, con la misma funcionalidad, está orientado a programación gráfica en vez de al desarrollo de código C. NI mantiene la compatibilidad con otros compiladores de propósito general, como las distintas suites de Microsoft Visual Studio (Visual Basic, Visual C++,.NET, etc), a través de su producto Measurement Studio. B) Matlab con Instrument Control Toolbox Matlab, que fue en origen un conjunto de rutinas para manipulación de matrices, ha evolucionado con el tiempo para convertirse en un entorno de programación de propósito general con gran potencia matemática y aplicabilidad en muchos ámbitos de la ciencia y la ingeniería, gracias a sus módulos de extensión (toolboxes) de procesamiento de señales, control, ecuaciones diferenciales, y un largo etcétera. En muchos casos las toolboxes representan el estado del arte en programación numérica en sus respectivos campos. Recientemente, los creadores de Matlab, Mathworks, emprendieron una línea clara de ampliación de su mercado hacia la conexión de hardware con el PC, distribuyendo toolboxes para el control de tarjetas de adquisición, generación de código y emulación de DSPs, xpc (control remoto de PCs para operación en tiempo real), adquisición de imágenes, etc. La primera versión de la toolbox específica de control de instrumentos de medida apareció en 2001, y la versión 2.1 disponible en la actualidad (2004) está suficientemente depurada para ser competitiva con productos más maduros como CVI. Existe también una toolbox de adquisición de datos con soporte para

15 tarjetas de entrada y salida de señales analógicas y digitales, dentro de esta misma línea de productos. La toolbox ha sido diseñada de forma que el acceso a los instrumentos de medida se realiza mediante objetos, que pueden ser de dos clases: interfaz o de dispositivo. Mientras que el primer método equivale a la programación con comandos SCPI, el segundo enfoque permite explotar toda la potencia de IVI. Para ello es preciso disponer del driver de Matlab correspondiente (extensión.mdd), obtenible en la página de Mathworks o bien usar una utilidad llamada makemid para convertir (o envolver ) el driver IVI ya instalado en el sistema. La utilidad midedit permite ver y modificar todas los objetos definidos en los aparatos, sus propiedades, y las funciones ejecutables. El futuro de la conexión de instrumentos de medida Las dos tecnologías de comunicación con instrumentos más comunes en la industria, GPIB y el puerto serie, provienen de los años 70; está claro que desde entonces la industria informática ha experimentado cambios radicales. Existe alguna tecnología que pueda desbancar al GPIB en el futuro? USB: Universal Serial Bus El USB fue creado como puerto para la conexión de periféricos (impresoras, cámaras digitales, unidades de disco, escáners, etc) a los PCs. En el diseño de USB se optó por plug and play, de forma que el PC reconozca y configure los dispositivos en el momento de su conexión. Permite la conexión simultánea de hasta 127 dispositivos en un puerto, con una velocidad de transferencia de datos de hasta 60 Mbytes/s (estándar USB 2.0). USB es un sistema de comunicación barato y está implementado en cualquier PC moderno. Sin embargo, los cables USB no están preparados para entornos industriales (con

16 posible pérdida de datos ante el ruido electromagnético), carecen de un mecanismo de enganche al PC, y la distancia de conexión está limitada a 30 m. Además, no existe un protocolo estándar sobre USB: cada fabricante debería desarrollar el suyo propio. Ethernet Ethernet es una tecnología de conexión de ordenadores madura y de amplia implantación. Las ventajas son su ubicuidad, la posibilidad de control remoto, y la facilidad para compartir los instrumentos entre varios usuarios. La velocidad de transmisión de datos tiene un máximo teórico entre 10, 100 o 1000 Mbits/s (estándar Ethernet Gigabit), aunque hay que considerar que raramente es alcanzable en condiciones normales, siendo muy dependiente del tráfico de la red. Una desventaja importante inherente al diseño de Ethernet es que no es determinista. También se puede plantear la seguridad global del sistema, y, como factor psicológico en contra el que los ingenieros tuvieran que recurrir a los administradores de red para montar su sistema. Otra alternativa interesante es la Ethernet inalámbrica (IEEE ). Firewire (IEEE 1394) Diseñado por Apple, y estandarizado por el IEEE 1394 en 1995, Firewire fue concebido para la transmisión masiva de datos en entornos multimedia (por ejemplo, cámaras de vídeo digitales), alcanzando velocidades de 400 Mbits/s (el siguiente estándar establecerá velocidades de hasta 3.2 Gbits/s). Firewire soporta hasta 16 dispositivos en cadena, pudiendo estar separados mutuamente un máximo de 4.5 m de distancia. Al contrario que USB, existe un protocolo definido para el control de instrumentos sobre IEEE 1394; sin embargo, pocos instrumentos de medida lo reconocen. Dos inconvenientes para la implantación de este estándar son la ausencia de los chipsets correspondientes en las placas base de los PCs, por lo que el usuario debe adquirir una tarjeta PCI por separado (Macintosh la incorporan de fábrica) y que los cables Firewire no están inmunizados al ruido, siendo por tanto no aptos para entornos industriales. Conclusión A pesar de su enorme potencial, ninguna de las tres tecnologías discutidas ha conseguido una penetración apreciable en el sector del control de instrumentos de medida, donde GPIB sigue siendo el estándar dominante. Esto se debe a: (a) el hecho de que ninguno de los competidores se haya impuesto como predominante; (b) la rapidez con la que cambia la tecnología PC, en contraste con la de los instrumentos de medida, que tienen un tiempo de vida más largo; (c) el elevado coste de dichos instrumentos, que les confiere una gran inercia para actualizarse. Muchos fabricantes ofrecen adaptadores que permiten conectar instrumentos GPIB a otros como Ethernet, operando de una forma más o menos transparente para el programador. Asimismo, el estándar VISA ha simplificado considerablemente el desarrollo de software al hacer bastante transparente el bus físico de conexión. Los instrumentos de medida de gama alta mantienen abiertas todas las puertas para la conexión. Es el caso por ejemplo de los osciloscopios de la serie Infiniuum de Agilent, que incorporan de serie dos puertos USB, dos puertos PS/2, GPIB y conexión a Ethernet. El inconveniente: su precio, más parecido al de un coche que a un osciloscopio.

17

18 Fuentes Instrumentación Electrónica. Miguel A. Pérez García, Juan C. Álvarez Antón, Juan C. Campo Rodríguez, F. Javier Ferrero Martín, Gustavo J. Grillo Ortega. Universidad de Oviedo. Conexión de Instrumentos de Medida con GPIB, Fernando Seco Granja. CSIC. Instrument Control Toolbox, Matlab.