GPIB

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 488.1 (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 488.1.
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).
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.

 El bus consta 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.
 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
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.
 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
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
0 0 0 addressed
0 0 1 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 0-30. Este código debe ser establecido en cada equipo, bien
estableciendo unos conmutadores hardware presentes en su panel trasero, o bien en algunos
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:
01011111
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 :
0 0 1 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:
00111111

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:
00010001
Comando Device Clear (DCL): Es un comando que resetea todos los equipos
disponibles sobre el bus.
00010100
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
00010101
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:
00011000
 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:
00011001

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:
00000001
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:
00000100
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:
00000101
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 0 0 1 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
00001000
 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:
00001001

IEEE 488.2

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 488.1. 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-488.1
Especificaciones mecánicas, eléctricas.
Funciones básicas de control y handshaking

IEEE-488.2
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 488.1 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 488.2.
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:
 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.
 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
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
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
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 802.11).

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.
 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.