Sistemas de Instrumentación

Prólogo 7
Prólogo
Un sistema de instrumentación es una estructura compleja que agrupa un conjunto de
instrumentos, un dispositivo o sistema en el que se mide, unas conexiones entre estos elementos y por
último, y más importante, unos programas que se encargan de automatizar el proceso y de garantizar
la repetibilidad de las medidas. El objetivo final, que no debe perderse de vista, del proceso de
automatización de las medidas es el aumento de la calidad. Esta calidad puede entenderse desde el
punto de vista del usuario del producto o del servicio que ha pasado por el proceso de prueba o desde
el punto de vista del ingeniero que desarrolla, pone en marcha y mantiene el sistema de
instrumentación que realiza este proceso de prueba, y que cada vez con mayor insistencia debe
ajustarse a estándares internacionales como la norma ISO 9000.
Este libro se ha escrito pensando especialmente en el tipo de sistemas que se encuentran en

departamentos de investigación y/o desarrollo y para el control de la producción, especialmente en
control de calidad. Los sistemas que consideramos en mayor profundidad son los construidos en base
a instrumentos comerciales que se unen mediante un bus digital que permite la programación de las
funciones de medida, el procesado de los datos y la presentación de los resultados, lo que da lugar a lo
que se ha denominado instrumento virtual.
Para no perder generalidad y para enmarcar adecuadamente los temas centrales del libro
hemos dedicado los dos primeros capítulos a describir los objetivos, las estructuras y las funciones de
los distintos tipos de sistemas de instrumentación existentes. El resto de capítulos se centran ya en
sistemas construidos alrededor de buses estándar, en concreto IEEE-488 (conocido también por GP-
IB o HP-IB) y VXI, describiendo la arquitectura y funcionalidad de los mismos, las formas de
programarlos y la forma genérica de las aplicaciones informáticas que facilitan la tarea de desarrollar
los programas de control y que conocemos habitualmente como instrumentación virtual.
La descripción de los buses estándar de interconexión de instrumentos que suelen hacer los
textos de instrumentación es casi siempre muy somera (muchas veces por limitaciones de espacio),
por lo que se limita a una descripción mecánica y eléctrica y a enumerar las características
funcionales más relevantes. Aquel ingeniero interesado en conocer más profundamente el
funcionamiento del sistema, ya sea como usuario avanzado o como diseñador de aplicaciones, no
tiene otra alternativa que recurrir al texto de las normas. En el presente libro hemos intentado una
descripción rigurosa pero didáctica de los estándares. Aquel que necesite asegurar que su diseño, ya
sea un equipo o una aplicación informática, cumple con el estándar no tendrá otro remedio que acudir
a él, pero el usuario avanzado que necesita comprender las razones del comportamiento de una
determinada aplicación encontrará en este texto el material suficiente para ello o para acudir a la parte
© Los autores, 2000; © Edicions UPC, 2000.

8 Sistemas de instrumentación
del estándar requerida con suficiente base como para leerlo con provecho.
La explicación de los buses de interconexión de instrumentos, igual que la descripción de

buses de microprocesador, es una tarea que no se presta a ser desarrollada en un aula, sino que es
ideal para el laboratorio. Por este motivo hemos desarrollado en paralelo con este libro un curso de
laboratorio de instrumentación virtual. Nuestra sugerencia para la docencia de esta materia es dedicar
poco tiempo (4 a 6 horas) de pizarra para introducir los conceptos de sistemas de instrumentación
expuestos aquí y dedicar mucho más tiempo (25 a 30 horas) al curso de laboratorio. Hecho de esta
forma, el presente libro se deberá usar como material de referencia y como tal se ha desarrollado.
Este texto se ha escrito pensando en estudiantes de ingeniería, de ciclo corto o largo, que
estén cursando materias de instrumentación o cursos de laboratorio con instrumentos controlados de
forma automática. También será útil a aquellos profesionales que trabajen con sistemas automáticos
de medida y que deban desarrollar aplicaciones de bajo nivel, no soportadas o suministradas por los
fabricantes de los equipos o del entorno informático de aplicación.
Los autores
Septiembre de 1995

Índice 9
Índice
1 Automatización de las medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Objetivos de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Estructura general de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Sistemas dedicados y de bastidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Arquitectura de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Estructura del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Estructura del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Sistema de direccionamiento de la señal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Tipos de instrumentos y buses de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Sistemas basados en el bus IEEE-488 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Introducción histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Aspectos eléctricos y mecánicos (IEEE-488.1-1987) . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Aspectos mecánicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Aspectos eléctricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Transferencia de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Funciones de la interfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Funciones bàsicas de transferencia: AH y SH . . . . . . . . . . . . . . . . . . . . . . 36
3.4.2 Funciones de emisión y recepción de información (T, L, TE, LE) . . . . . . . 37
3.4.3 Funciones que afectan al instrumento (DC, DT y RL) . . . . . . . . . . . . . . . . 38
3.4.4 Funciones de petición de servicio (SR y PP) . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.5 Función de controlador (C) y codificación de las órdenes . . . . . . . . . . . . . . 39
3.5 Códigos, formatos, protocolos y comandos comunes (IEEE-488.2-1992) . . . . . . . . . 42
3.5.1 Requerimientos de la interfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.2 Registro de estado y petición de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.3 Sintaxis de los mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.4 Comandos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.5 Procedimientos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 Realización de interfases IEEE-488.1 y .2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Sistemas basados en el bus VME y VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Del VME al VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Especificaciones generales de la norma VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Descripción de los buses VXI y VME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1 El bus VME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.2 Extensión del bus VME, el bus VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Modos de funcionamiento y arquitecturas del bus VXI . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Tipos de dispositivos en un sistema VXI . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.2 Recursos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.3 Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.4 Arquitecturas de un sistema VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 Comandos de medida normalizados. SCPI, ADIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1 Modelo de instrumento según la norma SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 Sintaxis y estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 Formato de datos: ADIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Instrumentación virtual. Programas de ayuda al diseño de sistemas de

instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1 Clases de instrumentos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Lenguajes de control para sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . 78
Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Libros y artículos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Normas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Catálogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Bibliografía 83
Bibliografía
Libros y artículos
[BUC92] BUCHLA, D.; MCLAHAN, W. Applied electronic instrumentation and measurement.

New York, Macmillan, 1992.
[COO95] COOMBS, C.F. JR. Electronic instrument handbook, 2a. Edición, Nueva York,
McGraw-Hill, 1995.
[MAN94] MANUEL, A.; SÁNCHEZ, F,; SÁNCHEZ, J. "Controladores GPIB. Características y

prestaciones". Mundo electrónico, 249, junio-julio 1994, pp. 32-36.
[MER91] MERCADÉ, J. "SCPI normalización de comandos y datos en instrumentación

programable". Mundo electrónico, 220, septiembre 1991, pp. 62-67.
[SYD89] SYDENHAM, P.H.; HANCOCK, N.H.; THORN, R. Introduction to measurement science

and engineering. Chichester, Wiley, 1989.
[JOH94] JOHNSON, G.W. LabVIEW Graphical programming. Practical Applications in

Instrumentation and control, Nueva York, McGraw-Hill, 1994.

Normas
ANSI/IEEE Std 488.1-1987, IEEE Standard Digital Interface for Programmable Instrumentation The
Institute of Electrical and Electronics Engineers, Inc, 1988.
ANSI/IEEE Std 488.2-1992, IEEE Standard Codes, Formats, Protocols and Common Commands;
The Institute of Electrical and Electronics Engineers, Inc, 1988, 1993.
ANSI/IEEE Std 728-1982, IEEE Recomended Practice for Code and Format Conventions for use
with ANSI/IEEE Std 488-1978; The Institute of Electrical and Electronics Engineers, Inc, 1982.
IEEE Std 1014-1987, IEEE Standard for a Verastile Backplane Bus:VMEbus; The Institute of
Electrical and Electronics Engineers, Inc, 1987.
IEEE Std 1155-1992, IEEE Standard VME bus extensions for Instrumentation:VXI; The Institute of
Electrical and Electronics Engineers, Inc, 1992.
Standard Commands for Programmable Instruments:SCPI, SCPI Consortium, La Mesa (CA), 1991.
Catálogos
National Instruments, Instrumentation reference and catalogue 1995, Austin, Texas 1994.
Intelligent Instrumentation, The handbook of personal computer instrumentation, Tucson,

Arizona, 1994.
Data Translation, 1993 Product Handbook: Data Acquisition and Image Procesing,
Massachusetts, 1993.
Keithley, Data acquisition & control, Taunton, MA, 1991.
IOtech, Products for the IEEE-488 BUS, Cleveland, OH, 1992.

Automatización de las medidas 11
1 Automatización de las medidas

La imagen del técnico o del científico, con bata blanca, manejando manualmente uno o varios
instrumentos conectados mediante un amasijo de cables a una tarjeta de circuito impreso u otro
dispositivo es una imagen ciertamente bucólica pero poco representativa de la realidad de la
instrumentación electrónica actual. Con esto no queremos decir que esta imagen sea falsa, sino que
los instrumentos que se usan de esta forma representan un porcentaje pequeño en el mercado global
de la instrumentación.
El concepto básico que subyace detrás del mundo de la instrumentación es el concepto de

calidad. La calidad puede entenderse desde el punto de vista del usuario o desde el punto de vista del
técnico de medida (test engineer). Desde el punto de vista del usuario, la calidad de un producto o
servicio puede descomponerse en tres ámbitos objetivos: la fiabilidad, la facilidad de mantenimiento
y la disponibilidad [SYD89]. La disponibilidad es una cuestión de capacidad de producción y canales
de distribución. La facilidad de mantenimiento es fundamentalmente una cuestión de diseño del
producto y del servicio post-venta. La fiabilidad es la capacidad del producto para realizar una
determinada función durante un intervalo de tiempo especificado. En la fiabilidad de un producto o
servicio intervienen numerosos factores que impiden que ésta pueda calcularse de forma simple. Por
este motivo hay que recurrir a ensayos que nos permitan determinar si el producto es funcionalmente
correcto y estimar estadísticamente la tasa de fallos.
Estos ensayos consisten siempre en la aplicación de estímulos (eléctricos, mecánicos,

entradas del usuario, etc.), la recogida de datos de las respuestas a los estímulos y la generación de los
informes que documentan la prueba. Este proceso no puede realizarse de forma manual. El motivo no
es únicamente la cantidad de productos que deben ensayarse sino el ensayo en sí mismo. Tomemos
como ejemplo un sistema digital basado en microprocesador. Hacer una prueba funcional exhaustiva
del sistema significaría aplicar la totalidad de las entradas distintas posibles para cada uno de los
estados posibles del sistema. La generación de los estímulos (en este contexto se llaman vectores de
prueba) debe hacerse de forma sistemática si no queremos correr el riesgo de olvidar partes
importantes. La comparación de las respuestas recogidas con las respuestas esperadas no puede
hacerse de forma manual, al menos en un tiempo razonable, y el informe no puede mecanografiarse a
mano porque se tardaría semanas en escribirlo. Aunque en la práctica no se prueben todos los
vectores posibles, sino solo algunos considerados significativos, el volumen de información que se
maneja sólo se puede tratar de forma automática.
Hay otros ejemplos donde la cantidad de información no es tan grande pero para poder
asegurar la exactitud o la repetibilidad requerida en las pruebas es necesaria una sistematización de
los ensayos que solo puede asegurarse, con un tiempo y un coste razonable, si se realiza de forma
automática.

Desde el punto de vista del técnico, aumentar la calidad de una medida puede constituir
simplemente en el aumento de la velocidad de adquisición o procesado de los datos, el aumento de la
exactitud o la disminución del coste. Así deberíamos incluir aquellos sistemas destinados a adquirir
conocimiento del mundo físico para contrastar hipótesis sobre el mismo, el uso de los cuales solo
repercutirá en la calidad de un producto o servicio de forma muy indirecta, o bien los sistemas de
control donde, tradicionalmente, se ha dado más importancia a los algoritmos que se usaban para
decidir las acciones a seguir que a la instrumentación usada para adquirir los datos con que se
alimentan estos algoritmos.
1.1 Objetivos de los sistemas de instrumentación
El objetivo básico de un sistema de instrumentación es la adquisición de información del

mundo físico a la máxima velocidad posible, con la mayor exactitud que se pueda obtener y con el
menor coste. Si esto se usa para adquirir conocimiento hablaremos de sistema de instrumentación o
sistema de medida. Si esta adquisición de información se usa para determinar la respuesta a los
ensayos a los que se somete un circuito integrado, un sistema electrónico o mecánico, etc. hablaremos
de sistemas automáticos de prueba (automatic test equipment:ATE). Históricamente el término inglés
ATE se ha reservado a aquellos sistemas destinados a realizar ensayos en circuitos integrados,
componentes electrónicos discretos, placas de circuito impreso o sistemas electrónicos completos,
pero puede generalizarse a otros tipos de ensayo como térmicos o mecánicos.
La diferencia estructural entre los sistemas de medida y los de prueba radicaría en la

existencia en estos últimos de un subsistema destinado a aplicar excitaciones al elemento que se
somete a ensayo. Este subsistema puede sustituirse, a nivel formal, por la existencia de una hipótesis
sobre el comportamiento del sistema físico en el que se mide. Salvado este extremo ambos tipos de
sistema admiten igual tratamiento, por lo que usaremos ambos términos de forma indistinta.
Podemos definir los objetivos de los sistemas de instrumentación según el tipo de

comprobación que realizan en el sistema bajo prueba (SBP):
1. Análisis de defectos: el objetivo de estos sistemas es la realización de ensayos en dispositivos o

elementos complejos, para determinar si las medidas realizadas se
corresponden con un conjunto de medidas de referencia realizadas en un
elemento que se considera correcto. El objeto o sistema que se mide puede
estar o no realizando su función habitual. Las medidas que se realizan no
tienen por qué corresponder a parámetros de algún componente del sistema ni
a salidas funcionales del mismo. Simplemente sirven para determinar si
aquello que se mide es igual o distinto a lo que se esperaba obtener. El
objetivo final es determinar si el objeto presenta defectos, ya sea de
fabricación o ensamblaje o bien debidos al uso o manipulación.
2. Medida de parámetros: en este caso se trata de obtener un conjunto de parámetros de un

elemento del SBP. El elemento o dispositivo puede estar aislado del
sistema o conectado a él. El sistema puede estar funcionando o no.
Por ejemplo podemos medir el valor de un resistor o caracterizar el
tiempo de subida de un elemento lógico al variar las condiciones de
carga. La técnica de medida cambia si el elemento está aislado o
insertado en un sistema [COO95].

3. Pruebas funcionales: el objetivo de estos ensayos es determinar si el SBP realiza la función

para la cual fue diseñado. Es obvio que en este caso el sistema debe
estar funcionando y deben suministrársele las entradas
correspondientes, ya sean de usuario o bien de los subsistemas que le
precedan cuando el sistema opera normalmente. Este tipo de ensayo
es el que requiere un sistema de instrumentación más complejo, ya
que deben simularse todos los modos de operación del SBP y deben
realizarse las medidas a la velocidad real de funcionamiento del
mismo.
1.2 Estructura general de los sistemas de instrumentación
Fig. 1.1 Esquema conceptual de un sistema de instrumentación
En la figura 1.1 se puede ver el esquema conceptual de un sistema de instrumentación

genérico. El sistema bajo prueba (SBP) recibe excitaciones generadas por una serie de dispositivos o
instrumentos que están conectados a un bus. Estas excitaciones se aplican a través a actuadores spara
el caso de un sistema no eléctrico. El SBP además puede recibir entradas directas del usuario, por
ejemplo si se hace una prueba funcional. La respuesta a las excitaciones es recogida por los elementos
de adquisición. Al igual que para los generadores de excitación, estos elementos pueden ser circuitos
diseñados a medida o bien instrumentos comerciales independientes. Los sensores tampoco estarán
presentes si se mide en un sistema eléctrico.

Tanto la parte de generación de la excitación como la de adquisición están unidas a nivel

digital mediante buses de comunicaciones. Puede haber uno o más buses coexistiendo en un mismo
sistema. Estos buses se conectarán a un elemento inteligente, típicamente un ordenador de propósito
general, mediante las correspondientes interfases.
A partir de este punto entramos en el dominio de la programación, que se ha representado

como un estructura jerárquica de capas. Los datos que llegan de los buses van a parar a una capa de
control y gestión de bajo nivel que pasa la información a una capa de procesado y esta, a su vez, la
pasa a una aplicación de presentación y recogida de señales del usuario.
Fig. 1.2 Sistema de prueba dedicado de alta velocidad para entornos de fabricación HP84000 (Hewlett-Packard)
1.3 Sistemas dedicados y de bastidor
Una forma de realizar un sistema de instrumentación consiste en diseñar cada una las partes
que lo componen a medida de la aplicación. Este proceso acaba en un sistema, que tiene la estructura
vista en el apartado anterior, y que normalmente conocemos como instrumento. En el caso de un
sistema de prueba automático (ATE), el instrumento finalmente diseñado (incluido el ordenador)
puede tener un volumen considerable, como el sistema de la figura 1.2. No obstante, se le continúa
considerando un instrumento aislado más que un sistema de instrumentación. La ventaja de esta
aproximación es la adecuación perfecta entre instrumento y aplicación. La desventaja es el coste y la
incapacidad de reconfiguración para cubrir nuevas necesidades. Por este motivo los sistemas
dedicados sólo son factibles económicamente si cubren una necesidad suficientemente amplia que
permita a sus diseñadores/fabricantes producir una cantidad significativa, y aun así su precio puede
resultar muy elevado. Es del dominio público el hecho que durante la década de los 70 los circuitos
integrados digitales estaban limitados a 40 terminales porque los equipos de prueba que se usaban
tenían previsto como máximo este número de entradas y cambiarlos suponía un coste excesivo. Esta

limitación afectó a microprocesadores tan populares como el Z80 o el i8086.
La alternativa a esta aproximación consiste en escoger instrumentos de propósito general,

disponibles comercialmente, colocarlos unos encima de los otros (stack) en un bastidor (rack)
comercial y controlarlos mediante un bus estándar de instrumentación, como IEEE-488 o VXI. A esta
aproximación se le conoce, en terminología inglesa, como rack & stack. Las ventajas son,
esencialmente, el menor coste de adquisición y la posibilidad de reutilización del todo o de las partes
y por tanto la rentabilización de la inversión. Como contrapartida deberemos destinar un cierto
tiempo a configurar las conexiones del sistema y a realizar la aplicación informática de control y
presentación. Esta solución suele adoptarse en laboratorios de investigación/desarrollo donde las
necesidades de los ensayos a realizar cambian rápidamente, o bien en empresas que por la poca
continuidad de la producción deben reconfigurar frecuentemente los sistemas de prueba.
1.4 Aplicaciones
La aplicaciones más importantes de los sistemas de instrumentación las encontramos en los

campos del diseño y desarrollo, de la producción, de las medidas de campo y del control de procesos
[BUC92]. Cada uno de estos campos tiene características especiales que repercuten en la concepción
del sistema de instrumentación, y que comentaremos muy brevemente.
1.4.1 Diseño y desarrollo
Las principales aplicaciones en este campo son la verificación del diseño, las medidas de
prestaciones y los ensayos ambientales. Los sistemas de verificación de diseño son usados por los
ingenieros de diseño para comprobar los primeros prototipos del producto desarrollado. Son sistemas
con vida muy corta y niveles de automatización pequeños, donde los sistemas de tipo bastidor tienen
sus dominios. En estos entornos, la existencia de aplicaciones informáticas que permitan un
desarrollo rápido de la automatización de las medidas es un factor clave.
Las medidas de prestaciones se realizan en prototipos muy parecidos al producto final. Se

usan para determinar las características de funcionamiento general del producto y el resultado suele
utilizarse para redactar las hojas de especificaciones. Es habitual realizar también pruebas de robustez
a base de variar algunos parámetros fuera del margen especificado, como por ejemplo la tensión de
alimentación o la frecuencia de trabajo.
Los ensayos ambientales consisten en someter al producto a cambios en parámetros externos

de funcionamiento como pueden ser la temperatura, la humedad, las interferencias electromagnéticas,
etc. Habitualmente existen normativas que obligan a realizar estas medidas de una forma determinada
(p. ej. la directiva europea sobre compatibilidad electromagnética) y por tanto los sistemas de
instrumentación suelen estar altamente automatizados, para asegurar que las medidas se realizan de
acuerdo con aquello que especifica la norma. Habitualmente estos sistemas no están en las empresas
de diseño o producción, sino que se encuentran en laboratorios pseudo-gubernamentales
especializados (p. ej.: Laboratori d'Assaigs de la Generalitat de Catalunya).
1.4.2 Sistemas para medidas en producción
Estos sistemas se usan para asegurar que el producto que se construye cumple con las
especificaciones deseadas. En estos sistemas el factor clave es la velocidad puesto que limita la

velocidad de la cadena de producción. En el mundo de la fabricación de productos electrónicos nos

encontramos con sistemas de prueba de componentes en circuito, que determinan si cada uno de los
componentes de una tarjeta de circuito impreso es correcto una vez los componentes han sido
montados (esto no excluye que las tarjetas y los componentes se hayan podido probar por separado
con anterioridad). El hecho de que los componentes estén montados en la placa impone técnicas
especiales de conexión y guarda para asegurar que se mide sólo el componente deseado [COO95].
En el caso de circuitos digitales complejos (microprocesadores, FPGA, etc.) las pruebas

dentro del circuito son difíciles si se usan técnicas convencionales. Por este motivo se ha desarrollado
un método conocido como Boundary Scan Test (IEEE Std. 1149.1-1990; 1149.1a-1993). Este método
requiere que el circuito a medir se haya diseñado de forma especial, añadiendo un circuito a cada uno
de los terminales de conexión. A estos circuitos (colocados en la periferia:boundary) se accede con un
protocolo serie y pueden configurarse para operación transparente, para fijar un nivel de tensión o
para recoger la tensión de salida del terminal. Este método facilita enormemente la medida en
circuitos digitales complejos puesto que solo hay que acceder a dos puntos de cada tarjeta de circuito
impreso. El sistema de instrumentación requerido es, no obstante, muy complejo a nivel de
generación de vectores de prueba.
Finalmente se suelen realizar pruebas funcionales con el producto ya acabado para determinar
que éste realiza la función para la cual fue diseñado. Es una prueba entrada/salida, es decir,
considerando el producto como una caja negra. Si el producto no supera la prueba no es posible, en
este estadio, saber cuál es el componente defectuoso y debe volverse a alguna de las pruebas
anteriores.
1.4.3 Medidas de campo
Las medidas de campo suelen realizarse para reparar productos que han dejado de funcionar o
no realizan su tarea a satisfacción del cliente. Dado que los sistemas de instrumentación necesarios
han de desplazarse hasta el SBP, el tamaño y el peso son factores muy importantes. Habitualmente
son instrumentos diseñados a medida. También en esta campo la técnica de Boundary Scan ofrece
grandes ventajas.
1.4.4 Sistemas de control
La enseñanza clásica de los sistemas de control se centra en el estudio de los algoritmos

necesarios para llevar al sistema a un estado deseado tomando como información de entrada el estado
actual y la historia. Generalmente se supone que el conocimiento del estado actual es perfecto. Este
conocimiento, sin embargo, se adquiere a través de un sistema de instrumentación, que puede ser muy
simple, en el caso de controlar, por ejemplo, la velocidad de un motor, o muy complejo en el caso de
controlar una refinería. La calidad del control que se puede realizar nunca será mejor que la calidad
de las medidas que se obtengan del estado del SBP [SYD89].
En la mayoría de las aplicaciones se usan tarjetas de adquisición conectadas a un ordenador

de propósito general o bien a controladores especialmente diseñados (PLC: Progammable Logic
Controllers). A estas tarjetas se conectan directamente sensores con salidas estándar (0-5 V o 4-20
mA) y los programas de control son especiales para el PLC. Algunos entornos de instrumentación
virtual basados en ordenadores de propósito general incluyen algoritmos de control, como por
ejemplo LabView de National Instruments.

Arquitectura de los sistemas de instrumentación 17
2 Arquitectura de los sistemas de instrumentación

Entendemos por arquitectura del sistema la estructuración de éste en bloques funcionales y la
definición de las interacciones entre ellos. La estructura que se presenta intenta abarcar todos los
aspectos conceptuales existentes en sistemas de instrumentación para la prueba automática.
Lógicamente, la arquitectura concreta de cada sistema de instrumentación dependerá de la aplicación
de éste, el cual constituido por un subconjunto de los bloques aquí descritos.
El primer objetivo de este capítulo es describir la funcionalidad de los bloques constituyentes

de un sistema de instrumentación, tanto en el aspecto hardware como software. El segundo objetivo
es describir con más profundidad los subsistemas que son más específicos, como son el sistema de
direccionamiento de señal y los diferentes tipos de instrumentos y buses de control existentes en el
mercado actual.
2.1 Estructura del hardware
Desde el punto de vista de la realización física es a partir de donde un sistema de

instrumentación puede tomar estructuras más diferentes. Pensemos, por ejemplo, en un equipo que
integre en una sola caja los circuitos para realizar medidas de impedancias terminales, funciones de
red, análisis espectral y alguna cosa más. Este equipo, un analizador de redes, constituye lo que
hemos llamado un instrumento y en la estructura representada en la figura 2.1 aparecería como uno de
los bloques con este nombre. Sin embargo, podríamos realizar las mismas funciones de este equipo
basándonos en varios equipos independientes (generadores de señal, amplificadores, analizadores de
espectro) estructurados en un sistema de medida automática (que podría estar descrita por el mismo
esquema de bloques). En definitiva, la estructura interna del analizador de redes en realidad se puede
descomponer en un conjunto de bloques (subsistemas) que se ajustarían a toda la estructura
representada en la figura 2.1. Con esto queremos decir que la estructura que presentamos responde a
un modelo funcional de las distintas partes del hardware y no a su apariencia o localización física, con
lo que es útil para describir el funcionamiento tanto de equipos más o menos sencillos como sistemas
complejos de instrumentación.
El funcionamiento y las partes más importantes del sistema de instrumentación de la figura

2.1 son los siguientes: el dispositivo o sistema bajo prueba (DBP o SBP) está conectado a los
instrumentos mediante un sistema de contactos (fijación del SBP) y un encaminamiento
(conmutación) de las señales que permite seleccionar qué señales aplicar a las entradas del SBP y
dónde enviar (a qué instrumentos) las salidas del SBP. Todo el proceso de controlar el
encaminamiento de la señal, las medidas a realizar por los instrumentos, el almacenado de la
información adquirida y su posterior procesado y presentación es realizado por el sistema de control.

Normalmente será un ordenador con todos los periféricos típicos más las interfases necesarias para
controlar el sistema. A continuación pasamos a describir cada bloque en mayor profundidad.
BUS DE CONTROL
CONTROL
INSTRUMENTO INSTRUMENTO INSTRUMENTO
DEL BUS
SISTEMA DE CONTROL
CONEXIONADO DE SEÑAL PLACAS

INSTRUMENTO I/O
CONMUTACIÓN
(ALIMENTACIÓN)
FIJACIÓN SBP USUARIO
COMUNICACIONES
SBP
Fig. 2.1 Arquitectura general de un sistema de instrumentación controlable
- Sistema bajo prueba (SBP)
En inglés se le denomina Device Under Test: DUT o también System Under Test:
SUT. Es el elemento que se mide con el objeto de caracterizar alguna o algunas de sus
cualidades. Puede ser desde un componente electrónico de 2 terminales -resistor,
condensador, etc- a un sistema de N terminales de entrada y M de salida.
Tal como se representa en la figura 2.1, el SBP puede ser un sistema que requiera una
programación o un control. Para ello hay que prever el disponer del bus adecuado para poder
reconfigurar de forma automática el SBP.
- Fijación del SBP
Es el sistema que establece la conexión eléctrica del SBP con el sistema de medida.
Para aplicaciones en control de producción suelen ser conjuntos de puntas de prueba (bed of
nails) contra los que se enfrentan las placas de circuito impreso a examinar. Las puntas de
prueba están constituidas por una parte fija más una móvil que gracias a un muelle tiene un
cierto recorrido y ejerce una presión dada. La parte móvil es la que establece el contacto
eléctrico con las pistas o los pines existentes en las placas de circuito impreso bajo prueba.

Para que el contacto sea estable mecánicamente y de baja resistencia las puntas de prueba
están acabadas normalmente en formas puntiagudas con un baño de oro o de rodio. La ventaja
de estos sistemas es la rapidez con que se establecen los contactos y que se puede acceder a
cualquier punto de la placa de circuito impreso.
En sistemas de laboratorio, usualmente, la conexión se realiza de forma manual a

través de conectores preestablecidos (paneles de conexión) o de sondas conectadas a pines de
la placa o componente bajo prueba.
- Conmutación
Este bloque es el encargado de direccionar las señales entre los instrumentos y los
contactos del sistema de fijación del SBP para excitar o medir, en función de la medida a
realizar, las entradas o salidas correspondientes del SBP. En algunos casos este sistema no
existirá o se reconfigurarán las conexiones de forma manual, reconectando los cables o las
puntas de prueba.
En sistemas automáticos puede estar constituido por un sistema simple basado en

interruptores independientes controlados directamente por el sistema de control, o por un
instrumento específico controlado a alto nivel que pueda establecer cualquier combinación de
conexiones entre sus entradas y salidas.
- Conexionado de señal
El conjunto de cables para conectar los instrumentos con el SBP es una de las partes
imprescindibles en un sistema de medida. Normalmente se realiza de una forma precipitada
utilizando cualquier tipo de cable que tengamos a mano. Sin embargo, este sistema puede
llevarnos a resultados totalmente falsos en algunas situaciones. La problemática del sistema
de conexionado estriba en los problemas que pueden surgir de diafonía, bucles de masa,
atenuaciones, desfases y reflexiones a alta frecuencia. En el apartado 2.3 se verán algunas
directrices para atacar estos problemas.
- Instrumentos
La selección de los instrumentos para realizar el sistema depende de muchos factores.

Para empezar es adecuado hacer una lista de los parámetros a medir y sus márgenes de
variación. Con esta lista se podrán diseñar los tipos de medidas a realizar y, por lo tanto, las
señales a generar y los tipos de medidores necesarios. A partir de este punto ya entran en
juego cuestiones de mercado y logísticas, como pueden ser la disponibilidad o no de equipos
que reúnan las características de medida requeridas y, a su vez, un bus de control adecuado a
nuestro sistema. Otro concepto fundamental a considerar es la flexibilidad que queramos
tener en nuestro sistema para reconfigurarlo y poder realizar otras medidas. Este punto es de
gran importancia ya que el coste del sistema suele ser elevado y las necesidades actuales de
ensayo evolucionan de forma muy rápida lo que hace muy costoso el cambio de todo el
sistema por una falta de previsión. Esta premisa de adaptabilidad es la que está impulsando
los sistemas abiertos de instrumentación frente a lo que serían los sistemas dedicados hechos
a medida.

- Alimentación (distribución de energía)
En muchos casos los SBP tienen que ser examinados bajo unas condiciones
preestablecidas de la alimentación o, incluso, en un margen dado de ésta. Para ello hemos
considerado la alimentación como una señal más a aplicar al SBP. En realidad el bloque de
alimentación de la figura 2.1 puede considerarse como un instrumento más del sistema de
instrumentación.
Además de esta alimentación hay que considerar el diseño de la alimentación de

todos los demás elementos activos del sistema. En equipos comerciales, normalmente, este
aspecto ya estará resuelto con una alimentación directa de la red eléctrica.
- Sistema de control (controlador)
Es el núcleo central del sistema de instrumentación, se encarga de controlar el

funcionamiento general y de gestionar los datos adquiridos. Actualmente están basados en
sistemas con microprocesador y con todos los periféricos típicos de sistemas tipo ordenador
personal.
En algunos casos el controlador es un ordenador personal o una estación de trabajo

(workstation), pero en otros, orientados a aplicaciones industriales, el controlador puede estar
constituido por una sola tarjeta conectable a un bastidor (rack).
En el caso de ordenadores personales existen multitud de placas de entradas y salidas,

tanto analógicas como digitales. Con estas placas, tal como se muestra en la figura 2.1,
pueden generarse y/o medirse señales que vayan al SBP o vengan de él, como si el ordenador
incluyera un instrumento más. Las líneas digitales de I/O también pueden utilizarse para
controlar partes del sistema o del SBP.
En el caso de los PC, para controlar el bus de control, normalmente se utilizan

tarjetas específicas para cada uno de los buses normalizados. De este modo se puede tener
más de un bus de control.
Al igual que en la selección de los instrumentos, para seleccionar el controlador hay

que tener en cuenta aspectos como: fácil desarrollo del software de control y procesado,
facilidad de mantenimiento, requerimientos de velocidad, etc. Otro de los aspectos más
importantes a considerar es la adaptabilidad del sistema a cambios de requerimientos.
- Bus de control
Es el soporte físico para realizar el control y la transferencia de datos entre los

instrumentos y el controlador. Entre otras, las especificaciones más importantes son las
limitaciones en las velocidades de transmisión, las longitudes máximas de cable permitidas y
el número de instrumentos que se pueden conectar.
- Comunicaciones
Cada día es más importante el integrar todos los sistemas que forman parte del

proceso de producción y de gestión de una empresa. Ello permite agilizar la transferencia de

información al reducir costes y dar más flexibilidad a la producción. Para esto es necesario
prever que los sistemas de prueba puedan integrarse en la red de comunicaciones de la
empresa, por ejemplo mediante una conexión a la red de área local.
2.2 Estructura del software
En un sistema de instrumentación para test automático es donde la expresión "el instrumento

es el software" adquiere toda su significación. La idea que subyace en esta expresión es la de hacer el
máximo número de funciones por software, utilizando equipos de propósito general para realizar las
medidas básicas. Esta aproximación permite adaptar el sistema a nuevas situaciones de medida con
sólo modificar el programa, con lo que se consigue alta flexibilidad a bajo coste. Sin embargo, la
decisión del soporte informático de nuestro sistema, desde el nivel de sistema operativo al nivel de
aplicación, puede ser crucial para determinar la flexibilidad final de nuestro sistema y los costes de
mantenimiento y reprogramación.
Fig. 2.2 Estructura en capas del software para el control de un sistema de instrumentación
A continuación revisaremos la estructura del software. En la figura 2.2 puede observarse la

estructura en capas del software, desde el nivel inferior (el sistema operativo) al nivel superior (las
aplicaciones). Para cada nivel se comentará su funcionalidad y los aspectos más importantes a tener
en cuenta.
- Sistema operativo (S.O.)
Es el soporte básico que relaciona las funciones programadas con el hardware

concreto de la máquina. Determina aspectos tan importantes como son la posibilidad de
ejecutar programas simultáneamente (multitarea) y/o poder dar servicio a múltiples usuarios.
En aplicaciones que requieran alta velocidad de adquisición y proceso, por ejemplo sistemas
en tiempo real, los monotarea pueden ser más convenientes. Por otro lado, en sistemas que
tienen que responder a eventos dados que no sean repetitivos, por ejemplo una central de
alarmas, los sistemas multitarea serán más adecuados.
En todos los casos, el utilizar un S.O. de uso general como puede ser UNIX, DOS,
OS/2 o MS-Windows permitirá disponer de más software comercial. Además, facilitará las
comunicaciones con otros ordenadores y su integración en redes locales.

- Controladores para el bus de interconexión
Los controladores (drivers, en inglés) del bus de interconexión son las rutinas que
gestionan los recursos concretos del gestor del bus, normalmente una placa que se instala en
el ordenador de control. En el caso de un software bien estructurado éstas serían las únicas
subrutinas que se deberían modificar en el caso de que se sustituyese el controlador del bus o
incluso el tipo de bus de control.
La programación de los instrumentos puede realizarse utilizando estos drivers pero

para ello necesitamos saber qué códigos específicos hay que enviar a cada instrumento para
cada función a realizar. Esta tarea solo es interesante realizarla en el caso de que no se
dispongan de drivers para un instrumento dado. En este caso lo más apropiado es realizar un
driver de instrumento siguiendo las mismas pautas que sigan los drivers de que disponemos.
- Controladores de instrumentos
Estas son las rutinas (drivers) que controlan los instrumentos conectados al bus de
control. Estas rutinas serán, por lo tanto, dependientes de cada instrumento. Normalmente se
presentan como un conjunto de funciones de alto nivel que permiten programar un
instrumento en concreto. La programación se realiza llamando a rutinas diferentes para cada
función o a una rutina general con un cierto número de parámetros.
Para decidir la compra de drivers de instrumentos conviene considerar los siguientes

puntos:
- desde que lenguaje se pueden usar (C, Basic, Pascal,...)

- extensión de la librería de instrumentos soportados
- posibilidades de modificación de los drivers existentes
- posibilidad de incluir nuevos drivers o funciones
- disponibilidad de herramientas para el desarrollo o la verificación de nuevos
drivers.
- Programas de prueba y diagnóstico
Estos son los algoritmos que realizan la programación de los equipos para cada
medida concreta. Se basan en llamadas a los drivers de instrumento para la programación de
estos. Normalmente se utilizan programas escritos en lenguajes de alto nivel, o también
entornos de programación específicos textuales o gráficos. Idealmente en este nivel se
tendrían un conjunto de funciones que realizarían cada una de las medidas y devolverían los
datos adquiridos por los instrumentos una vez procesados.
Con lo visto hasta este momento se puede entender que, en un sistema automático de
medida, localizar, de forma manual, los posibles fallos puede ser muy costoso. Un mal
funcionamiento puede ser debido a problemas de comunicaciones, problemas en un
instrumento o problemas en el controlador y/o en su software. Por ello, los programas de
diagnóstico se hacen imprescindibles para localizar las causas de un mal funcionamiento del
sistema.

- Programa de aplicación y gestión (elaboración de informes)
Este es el nivel más alto y se encarga de gestionar tanto los programas de prueba
como los datos obtenidos. Puede incluir sistemas de diagnóstico automático y
autoconfiguración. Aspectos clave en este nivel son: la interfase de usuario, la presentación
de datos, la exportación o los enlaces de datos a otros programas y las comunicaciones con
otros sistemas.
2.3 Sistema de direccionamiento de la señal
El soporte físico para el paso de señales entre los instrumentos y el SBP es lo que
denominamos como sistema de direccionamiento de la señal. Está compuesto, como mínimo, por los
cables y sus conectores (conexionado de señal) y también puede incluir etapas de multiplexado o
demultiplexado (conmutación) y sistemas para fijar el SBP.
Como se ha comentado en el apartado anterior, normalmente el cableado se realiza de una

forma precipitada utilizando cualquier tipo de cable que tengamos a mano, lo que puede acarrear
serios problemas de medida. Una de las primeras recomendaciones es marcar todos los cables con
etiquetas identificativas para evitar fallos en la interconexión. Mantener un cierto orden en la
disposición física de los cables y de los instrumentos también ayuda a la detección de posibles fallos
y al mantenimiento.
Aunque se cumplan estos requisitos básicos aún pueden surgir problemas como son: diafonía,
bucles de masa, atenuaciones indeseadas, desfases y reflexiones a alta frecuencia. Para evitar estos
problemas es necesario estudiar el sistema de cableado y prestar atención a los siguientes puntos:
- utilizar en la medida de lo posible cables apantallados

- separar las líneas digitales de las analógicas
- definir un único punto de puesta a tierra
- utilizar sistemas diferenciales
- los cables trenzados pueden ser útiles para evitar interferencias magnéticas
- separar las líneas de alta tensión o de alta corriente de las líneas de señales de bajo nivel
La etapa de conmutación es la que permite encaminar las señales hacia los instrumentos o los
puertos de entrada del SBP de forma adecuada para cada medida. Puede estar constituido desde un
sistema con relés individuales (figura 2.3.a) hasta un sistema basado en una matriz de interconexión
(figura 2.3.b) que permita cualquier combinación de conexiones.
Los conmutadores son los elementos básicos tanto de los multiplexores como de las matrices
de conexiones. Según la tecnología pueden ser de los siguientes tipos:
- relés de armadura
- relés de láminas (reed): secos o de mercurio
- interruptores de estado sólido: FET o CMOS
Las ventajas de los interruptores de estado sólido frente a los mecánicos son: menor volumen,
bajo costo y rapidez de conmutación. El mayor inconveniente es la resistencia serie del interruptor
cuando está cerrado.

Fig. 2.3 Conmutación utilizando un multiplexor (a) o por una matriz de conexión (b)
Según el número de contactos fijos y contactos móviles (polos) los relés se clasifican en:
- 1 polo 1 contacto (SPST: Single Pole Single Throw)

form A por defecto el contacto está abierto
form B por defecto el contacto está cerrado
- 1 polo 2 contactos (SPDT: Single Pole Dual Throw)
form C primero se abre el contacto inicial y luego se establece el contacto con el otro
circuito, en inglés: break before make -bbm-
form D se establece el contacto con el segundo circuito antes de que se abra el
primero, en inglés: make before break -mbb-. No es útil como sistema de
multiplexado porque cortocircuitaría por un momento dos líneas de salida,
pero sí se puede usar para demultiplexado.
- 2 polos 2 contactos (DPDT) y así sucesivamente.
La principal ventaja de disponer de un sistema automático de conmutación es la velocidad

con que se pueden reconfigurar las conexiones. Su principal inconveniente es que todas las señales
confluyen hacia un punto en común, lo que da lugar a los problemas vistos para el sistema de
conexionado. Para evitar estos problemas hay que actuar de forma parecida a lo visto para los cables:
- utilizar conmutadores apantallados

- separar los conmutadores de señales digitales de los analógicos
- utilizar conmutadores independientes separados físicamente para señales de alto y bajo nivel
- estudiar la puesta a tierra. Evitar bucles de tierra
- utilizar multiplexores diferenciales
Otras limitaciones de los conmutadores son:
- la resistencia serie que presentan, especialmente los de estado sólido

- vida útil limitada para los relés
- limitación de velocidad y rebotes del contacto en relés
- la capacidad parásita a tierra
- la diafonía entrada salida

2.4 Tipos de instrumentos y buses de control
Podemos clasificar los instrumentos, definidos como todo sistema que realice una
medida concreta, en dos grandes grupos: los instrumentos modulares y los instrumentos
autónomos (standalone).
Fig. 2.4 'Mainframe' para instrumentos modulares (Natinal Instruments)
Los instrumentos modulares son aquellos que requieren de un soporte físico y

normalmente también de un soporte informático y de alimentación externa. Ejemplos de este
tipo de instrumentos son las placas conectables al bus de un PC o a un sistema basado en
VME o VXI. La principal ventaja de estos sistemas es la posibilidad de configurar un sistema
complejo de medida a base de conectar sobre un recurso común diversas placas. Al compartir
una misma fuente de alimentación, un mismo bus digital y una misma estructura de soporte,
los costos pueden ser menores. Normalmente la estructura de soporte (figura 2.4) es una caja
tipo rack (Mainframe) con una placa posterior que contiene el bus común (Backplane) con
conectores en los que se insertan los instrumentos individuales. La fuente de alimentación
puede estar en la parte posterior o ocupar el espacio de una o varias tarjetas.
Dentro de los instrumentos modulares podemos hacer una subdivisión entre los
instrumentos para ordenadores personales y los sistemas específicamente diseñados para
instrumentación industrial o de laboratorio. Actualmente existen instrumentos modulares para
la mayoría de ordenadores personales y estaciones de trabajo (workstations), como son: IBM
PC/XT/AT, PS/2, Sun, DEC, NeXT, MAC, etc. A todos estos instrumentos se les denomina
en inglés PLUG-IN'. También se dispone de instrumentos conectables al bus de extensión
EISA y PCMCIA.
Entre los sistemas modulares específicos para instrumentación tenemos:
- SCXI: es un producto de National Instruments para configurar sistemas de

instrumentación, de adquisición o de control, basados en PC. Es un sistema
basado en módulos conectables a un rack. La adquisición de datos puede
hacerse con una placa en el propio PC o utilizando una placa específica de

adquisición en el rack. En este caso la transmisión de datos se realiza por el

puerto paralelo estándar del PC.
- CDS: es un producto de Colorado Data System para control industrial. Permite

construir sistemas de hasta 100 placas específicas controladas mediante un
puerto serie, paralelo o IEEE-488.
- VME: es un bus digital estándar para sistemas de 32 bits que ha tenido expansión en
el entorno industrial gracias a disponer de racks con características apropiadas
para entornos industriales y gran número de instrumentos modulares. Su
limitación es que el bus común del backplane es solo digital.
- VXI: es una de las plataformas de sistemas modulares de instrumentación con un

crecimiento más espectacular. Es un sistema basado en el bus digital del VME al que
se han añadido más conectores al backplane. Esto ha permitido añadir más líneas
digitales y, lo que es más importante, líneas analógicas y de sincronización entre
módulos.
A pesar de que estos sistemas incorporan el control digital y permiten realizar sistemas
completos de instrumentación, todos ellos tienen posibilidades de comunicarse o ser incluso
controlados por un sistema distinto. Así, por ejemplo, un rack basado en VXI puede tener un
controlador del bus VXI que actúe controlado a su vez por un bus IEEE-488 al que estén
conectados otros instrumentos o racks y todo a su vez controlado por un PC.
Por último, los instrumentos autónomos son los que disponen de todas las funciones
necesarias para realizar las medidas de forma independiente. Para poder configurar un sistema
de medida utilizando este tipo de instrumentos es imprescindible que sean controlables. La
ventaja evidente de utilizar equipos autónomos es su posible utilización de forma
independiente pero, para especificaciones parecidas, estos equipos serán más caros que sus
equivalentes modulares.
Desde el punto de vista de la instrumentación virtual y de sistema, el aspecto más

importante de estos instrumentos será su posibilidad de ser controlados remotamente. Por ello
estableceremos una clasificación dependiente de los buses de control utilizados.
El bus más utilizado es el IEEE-488; es un bus paralelo de 8 bits más las líneas de
control y de protocolo de comunicación (handshake). Diseñado en 1965 por Hewlett-Packard
bajo el nombre de HP-IB, ganó popularidad gracias a su alta velocidad de transferencia
(1 Mbyte/s), y fue recogido ya en 1975 por el IEEE como el standard IEEE-488. Otro nombre
por el que se conoce es 'General Purpose Interfase Bus' (GPIB). Puede controlar hasta 14
instrumentos con una distancia total de cable de hasta 20 m.

Fig. 2.5 Sistemas de instrumentación integrados en la red de comunicaciones de una empresa (Natinal Instruments)
El MXIbus (Multisystem eXtension Interface bus) es un bus digital multimaster de 32

bits diseñado para interconectar sistemas de instrumentación entre sí (de hecho fue diseñado
para interconectar sistemas basados en VXI). El cable de conexión es parecido al de IEEE-488
con longitudes de hasta 20 m. Permite transmisión de palabras en paralelo de 8, 16 o 32 bits
con velocidades teóricas de 20 Mbytes/s. Su principal aplicación es para la interconexión de
mainframes basados en VXI entre ellos o a otros sistemas, por ejemplo PC.
En entornos industriales son muy utilizados los buses de control serie ya que permiten
distancias mayores entre los equipos. El más utilizado es el RS-232, ya que está incorporado
en la mayoría de ordenadores. Otros buses serie son: RS-422, RS-486, I2C, CAN, LAN, etc.
Otros tipos de equipos son los adaptadores de protocolos entre buses distintos. Por
ejemplo, existen conversores de: RS-232 a IEEE-488, SCSI a IEEE-488, ETHERNET (con
protocolo TCP/IP) a IEEE-488, etc. Para extender la longitud de los enlaces también se
encuentran adaptadores que pasan del cable estándar paralelo de IEEE-488 a una transmisión
serie por cable coaxial o fibra óptica y viceversa.
Utilizando todos los recursos vistos hasta este momento se pueden realizar sistemas
distribuidos de instrumentación basados en redes de área local. En la figura 2.5 podemos ver
un sistema distribuido de una empresa basado en conexiones por internet entre centros,
ethernet dentro de cada edificio y GPIB para el control dentro de cada laboratorio o zona de
producción.

Sistemas basados en el bus IEEE-488 29
3 Sistemas basados en el bus IEEE-488
El bus IEEE-488, conocido también como GP-IB o HP-IB es, con mucho, el más usado de los
sistemas de interconexión de instrumentos presentes en el mercado. Este hecho debe justificarse,
actualmente, más por razones de mercado que por razones tecnológicas. La muerte del bus IEEE-488
(que tiene una antigüedad de jure de 20 años, y de facto de casi 30) ha sido vaticinada varias veces,
pero es previsible que subsista durante mucho más tiempo. Dos son los motivos que podemos aducir.
En primer lugar, disponer de un instrumento que pueda funcionar autónomamente es mucho más
rentable para empresas de tamaño medio/pequeño y para departamentos de investigación o desarrollo
que adquirir instrumentación que deba funcionar en un bastidor o conectada al bus de un ordenador,
por las razones de tiempo de vida y necesidad de reconfiguración comentadas en el capítulo 1. En
segundo lugar, añadir una interfase IEEE-488 a un instrumento supone, actualmente, un coste mínimo
y prácticamente todos los instrumentos de gama media/alta lo llevan de serie.
El bus IEEE-488 es un bus paralelo de 8 bits con una transferencia de información similar a
la de un bus asíncrono de ordenador, mediante el uso de 3 líneas de protocolo (Fig. 3.3). Permite
transferir datos a una velocidad de 1 Mbyte/s, aunque en la práctica el límite suele estar en
2505 kbyte/s. Algunos fabricantes han desarrollado circuitos de interfase que permiten hasta 8
Mbytes/s de velocidad de transmisión. Pueden conectarse un máximo de 14 instrumentos más un
controlador, de forma directa, y se pueden ampliar usando extensores de bus, con una longitud
máxima de 20 m para cada sección. Se pueden configurar estructuras físicas lineales, en estrella o
mixtas, aunque la estructura lógica es tipo bus (todos los instrumentos están conectados en paralelo).
La transmisión de órdenes de programación y datos de medida suele hacerse usando códigos ASCII,
aunque no es obligatorio. Los instrumentos pueden pedir atención al controlador mediante una única
línea de interrupción y se identifican con una dirección de 5 bits.
3.1 Introducción histórica
En septiembre de 1965 la empresa Hewlett-Packard empezó a diseñar lo que debería ser la

interfase digital para "todos los instrumentos HP del futuro". Este trabajo se concretó en la
publicación del General Purpose Interface Bus en el Hewlett Packard Journal en 1972. Esta
publicación fue tomada como documento de referencia por el International Electrotechnical
Committe (IEC) para realizar la norma IEC-625-1, que fue aprobada de forma provisional en 1974 y
de forma definitiva en 1980. Paralelamente el Institute of Electrical and Electronics Engineers
(IEEE) definía una norma que fue publicada en 1975: IEEE Std 488-1975 con idéntico contenido.
Esta norma fue revisada en 1978, y se convirtió en ANSI/IEEE Std 488-1978, IEEE Standard Digital

Interface for Progammable Instrumentation. Esta publicación cubre los aspectos eléctricos y de
protocolo de bajo nivel del bus (se podría asimilar a los niveles 1 y 2 del modelo de referencia OSI de
la ISO), pero deja totalmente libre la estructura de los comandos de programación de los instrumentos
y los formatos de los datos. Dado que existía esta libertad, cada fabricante, e incluso cada instrumento
de un mismo fabricante, usaba estructuras y codificaciones distintas, lo que complicaba el diseño de
sistemas de instrumentación. Un intento de solventar esta dispersión fue la norma ANSI/IEEE Std
728-1982, IEEE Recomended Practice for Code and Format Conventions for use with IEEE Std 488-
1978, que de hecho era similar al estándar internacional IEC-625.2. Este documento define
estructuras sintácticas que permiten la construcción de mensajes y el intercambio de datos, aunque la
difusión y el seguimiento del mismo fueron escasos.
Un salto cualitativo se dio en 1987 cuando se volvió a revisar la norma. Después de esta
revisión aparecieron dos subnormas: ANSI/IEEE Std 488.1-1987 que toma como base el estándar de
1978 con el mismo nombre y ANSI/IEEE Std 488.2-1987, IEEE Standard Codes, Formats, Protocols,
and Common Commands for use with ANSI/IEEE Std 488.1-1987 que toma como base y amplía el
estándar IEEE 728-1982. En la norma 488.2, además de definir la sintaxis, se definen también un
conjunto de comandos comunes, unos códigos de error también comunes y un conjunto de
procedimientos de operación. Sólo el último nivel, los comandos dependientes de cada instrumento,
se dejan a libertad del fabricante. Esta norma ha sido revisada en 1992.
Por lo que respecta a los comandos de programación y los formatos de las estructuras de
datos, un consorcio de fabricantes definió en 1991 los Standard Commands for Programmable
Instruments: (SCPI). Esta "norma" no está recogida, de momento, por ningún órgano oficial.
3.2 Aspectos eléctricos y mecánicos (IEEE-488.1-1987)
Empezaremos definiendo, en este apartado y el siguiente, los aspectos recogidos en la norma

IEEE 488.1, que definen el tipo de conector, el cable, los niveles de tensión, la corriente, el tipo de
salida lógica, la transferencia de datos y las capacidades que pueden tener las interfases de los
instrumentos, así como los tiempos de respuesta a determinadas señalizaciones.
3.2.1 Aspectos mecánicos
Se usa un conector de 24 contactos, dispuestos en 2 filas paralelas de 12 contactos (la norma

IEC 625.1 especificaba inicialmente un conector de 25 contactos tipo D miniatura, como los usados
en los puertos RS-232). Los nombres correspondientes a cada línea están en la tabla 1.1 y la
distribución física de contactos en la figura 3.1. En los instrumentos se usa un conector tipo hembra,
dispuesto preferiblemente de forma horizontal y con el terminal 1 en el lado derecho superior. Los
conectores dispuestos en el cable deben llevar un contacto macho y uno hembra a cada extremo (fig.
3.1), de forma que se puedan apilar, con lo que forman así la arquitectura física del bus.
La longitud máxima de un cable individual es de 4 metros. Para reducir interferencias se usa

un cable apantallado, con una cobertura del 85% como mínimo, aunque se recomienda el 90%, y la
malla, junto con la carcasa metálica del conector, deben conectarse a la carcasa del instrumento y a
tierra. Una forma de realizar el cable es usar pares trenzados para las líneas de control (6 + 2 líneas) y
masa (6 líneas + GND común + pantalla). Las líneas de datos (8 líneas) se colocarán alrededor de los
pares anteriores. Otra solución consiste en usar pares trenzados para todas las líneas de señal, aunque
en este caso se requieren más de 24 hilos en el cable.

Fig. 3.1 Disposición de contactos en un conector hembra y vista esquemática de un

conector situado en el extremo de un cable
El tipo de apantallamiento y la reducción de interferencias, no obstante, deberán diseñarse

para cumplir con las normativas nacionales sobre compatibilidad electromagnética.
Tabla 3.1 Nombres de las líneas y distribución de contactos en un conector IEEE-488
NÚMERO CONTACTO NOMBRE DESCRIPCIÓN
1..4 DIO1..DIO4 Líneas de datos. DIO1 es la de menor peso
5 EOI "End Or Identify". Se usa para señalizar el fin de un mensaje
6 DAV "Data VAlid". Línea del protocolo asíncrono, gestionada por el emisor
7 NRFD "Not Ready For Data". Línea de protocolo, gestionada por el receptor
8 NDAC "No Data ACcepted". Línea de protocolo, gestionada por el receptor
9 IFC "InterFace Clear". Ordena una inicialización de todas las interfases
10 SRQ "Service ReQuest". Petición de servicio de un instrumento
11 ATN "ATeNtion". Indica que los comandos son de programación de interfase
12 Shield Conexión de la malla del cable
13..16 DIO5..DIO8 Líneas de datos. DIO8 es la de mayor peso
17 REN "Remote ENable". Indica a los instrumentos que van a ser programados
18..23 GND Líneas de masa. Apareadas con líneas 6..11 respectivamente
24 GND Línea común de masa

3.2.2 Aspectos eléctricos
Las especificaciones eléctricas están basadas en circuitos con tecnología TTL usando lógica
negada, de forma que un 0 lógico corresponde a un nivel alto (VL > +2.0 V) y un 1 lógico corresponde
a un nivel bajo (VL < +0.8 V).
Las líneas SRQ (Service ReQuest), NRFD (Not Ready For Data) y NDAC (No Data
ACcepted) deberán tener los circuitos de ataque tipo colector abierto. El resto de las líneas, incluidas
las de datos, podrán ser colector abierto o de tres estados. Con circuitos de tres estados se consigue
mayor velocidad. En el caso de querer implementar la función de consulta en paralelo, las líneas de
datos deben ser colector abierto. Los circuitos de ataque deben ser capaces de entregar hasta 5.2 mA
al bus en estado alto y sumir 48 mA en estado bajo.
Para los circuitos de recepción es recomendable usar comparadores con histéresis, con un
ciclo de histéresis de 0.4 V, para aumentar la inmunidad al ruido. Cada una de las líneas de señal, en
cada instrumento conectado al bus, tendrá una carga resistiva, de forma que la tensión de la línea no
sea flotante ni cuando todos los circuitos de ataque estén en estado de alta impedancia. Será
necesario, además, proteger los circuitos de recepción contra tensiones negativas que pudieran
aparecer en la línea. La carga que supone un instrumento conectado al bus debe ser tal que la relación
V/I esté dentro de la zona no sombreada de la figura 3.2(a). Un posible circuito que realiza todo lo
enumerado anteriormente se puede ver en la figura 3.2(b).
+2 mA
Vcc
+2V
+4V
3k
-2 mA
ATAQUE
-4 mA
-6 mA RECEPTOR
-8 mA
6.2 k
-10 mA BUS
-12 mA
(a) (b)
Fig. 3.2 (a) Requerimientos de carga para cada instrumento conectado al bus, (b)
circuito que cumple con los requerimientos de carga. (trazo grueso en (a)).
Se contempla la posibilidad de que exista una capacidad parásita entre cada línea y masa, que
no debe exceder de 100 pF por cada instrumento. La existencia de una capacidad alta puede
comprometer las especificaciones de velocidad.
La máxima resistencia de las líneas de datos y control es de 0.14 S/m, para la línea de masa a

común es de 0.085 S/m y para la malla de apantallamiento 0.0085 S/m. La máxima capacidad entre
cualquier línea de señal y cualquiera de las otras conectada a masa debe ser inferior a 150 pF/m,
medida a 1 kHz. Esta capacidad es la que limita la longitud máxima del cableado. El límite máximo
es de 20 m, pero este límite solo puede alcanzarse si hay más de 10 instrumentos en el sistema, y
considerando que la velocidad máxima que se conseguirá no superará los 500 kbytes/s. Si el número
de instrumentos es menor, el límite es de 2m * número de instrumentos. La razón hay que buscarla en
la impedancia de carga que supone cada instrumento. Al aumentar el número de instrumentos
disminuye la resistencia de carga total de la línea y la constante de tiempo entre la capacidad parásita
de la línea y esta impedancia disminuye también, de forma que la velocidad máxima se mantiene, a
costa de aumentar el consumo. El límite de 4 m para el cable individual, o lo que es lo mismo, la
máxima longitud de cable entre 2 instrumentos, es debida a problemas de retardos de propagación
(hay que distribuir la carga de la línea de forma uniforme).
3.3 Transferencia de información
El nivel siguiente (nivel 2 o de trama en un modelo OSI) hace referencia a cómo se realizan
las transferencia básicas de información entre elementos conectados al bus. Ya hemos comentado que
la transferencia se realiza de forma similar a un bus asíncrono de ordenador. Antes de comentar en
detalle las señales y las temporizaciones comentaremos la estructura genérica que puede tener un bus
IEEE-488.
En la figura 3.3 podemos ver un ejemplo de conexión con 4 instrumentos. En este caso el
dispositivo A es capaz de emitir mensajes de control de la interfase, y es capaz de emitir y recibir
información del bus. El dispositivo B es capaz de emitir y leer información, el dispositivo C solo es
capaz de leer información (p. ej. una impresora) y el dispositivo D solo es capaz de emitir
información (p. ej. un contador). En esta figura, además, se ha puesto de manifiesto la conexión
paralelo de todas las líneas del bus y su agrupación funcional, en líneas de datos, líneas de protocolo
(DAV, NRFD y NDAC) y de control.
Antes de poder realizar una transferencia en el bus es necesario saber quiéen va a emitir la
información y quién va a leerla. Para determinar esto el controlador configurará cada uno de los
instrumentos. Es evidente que solo puede haber un instrumento que emita información, pero puede
haber más de un elemento que la reciba. En el apartado 3.4 se comentarán con más detalle las
funciones en el bus.
Una vez configurados los instrumentos, cuando el que está configurado para emitir
información (talker) tiene la información disponible da comienzo el protocolo de comunicación
(handshake). El momento en que se empieza a emitir depende totalmente del instrumento. La
información a emitir puede ser, por ejemplo, un dato de medida que no se adquiere nunca porque la
condición de disparo no se cumple y por tanto el instrumento, aunque configurado como talker, no
realizará ninguna transferencia. Este tipo de problemas no están contemplados en la norma y suelen
solucionarse con la introducción de timeouts, de forma que si el controlador detecta que ha pasado
mucho tiempo desde que ha configurado el sistema y todavía no se ha realizado la transferencia puede
reinicializar la interfase.
El proceso de intercambio de información puede verse en la figura 3.4. Justo después de ser
configurado, el talker pone la línea DAV (DAta Valid) a nivel alto (0 lógico, falso) (1). En esta
situación los otros instrumentos, configurados como listeners, ponen la línea NDAC (No Data
ACcepted) a nivel bajo indicando que no se ha aceptado ningún dato y la línea NRFD (Not Ready For

DISPOSITIVO A
Capacidad para
EMITIR, RECIBIR y
CONTROLAR
p.e.: ordenador
DATOS
DISPOSITIVO B
Capacidad para
EMITIR y RECIBIR
p.e.: multímetro PROTOCOLO

TRANSFERENCIA
INFORMACIÓN
DISPOSITIVO C
Capacidad para
RECIBIR
p.e.: impresora
CONTROL de la
INTERFÍCIE
DISPOSITIVO D
Capacidad para
EMITIR
p.e.: contador
DIO1..8
DAV
NRFD
NDAC
IFC
ATN
SRQ
REN
EOI
Fig. 3.3 Estructura genérica de un sistema IEEE-488 donde se hace patente la

conexión en paralelo de todas las líneas
Data) también a nivel bajo, indicando que no están listos para aceptar datos (2). En el momento que
los instrumentos estén listos para aceptar datos irán poniendo esta línea a nivel alto. Al ser colector
abierto, hasta que el último de ellos no la haya puesto a nivel alto, la línea del bus estará baja (5).
Cuando el talker detecta NRFD alta, activa DAV (6) si había puesto los datos (3) con antelación
suficiente (4). Al detectar DAV activa, los instrumentos ponen NRFD baja (7) para indicar que no
aceptan más datos y a medida que cada uno lee el dato presente en el bus va desactivando NDAC (8)
hasta que todos la han puesto a nivel alto (9). En este momento el talker sabe que el dato ha sido
leído, desactiva DAV (10) y quita el dato del bus (11) poniendo el siguiente si lo hubiera. Los
listeners van poniendo NRFD alta (14) hasta que todos ellos vuelven a estar listos para aceptar más
datos (15) y recomienza el proceso descrito a partir de (6).
Este procedimiento provoca que el más lento de los instrumentos que intervienen en la
comunicación sea el que fije la velocidad real de transmisión de la información. Los instrumentos que
no han sido configurados ni como talker ni como listener mantienen la interfase en un estado inactivo
(idle), dejando NRFD y NDAC a nivel alto, y por tanto no entorpecen la comunicación.

Fig. 3.4 Proceso de intercambio de información (handshake) en bus IEEE-488
El tiempo de establecimiento de los datos, representado por el estado de espera (4) en la

figura 3.4, debe ser mayor que 2 µs. Con esto se consiguen velocidades de transmisión de hasta
250 kbytes/s. Si se quiere aumentar la velocidad, el dispositivo que actúa como talker debe reducir
este tiempo hasta un mínimo de 350 ns (Fast Handshake), y usar circuitos de tres estados para los
datos y DAV. Si utilizamos un instrumento con estas características, debemos asegurarnos de que la
capacidad total de la línea sea menor que 50 pF por cada instrumento conectado. Esto obliga a usar un
cableado muy corto (1 m/instrumento). Si se violan estas restricciones usando un talker con un
retardo de 350 ns se pueden producir errores.
3.4 Funciones de la interfase
El resumen de funciones que pueden realizar las interfases se ve en la tabla 3.2. En este
apartado veremos con algún detalle cómo se realizan estas funciones, haciendo hincapié en los
aspectos prácticos y en la codificación de algunos mensajes de control de una línea o multilínea.
Para cada una de estas funciones existen diferentes niveles de realización, que se indican con
un número que sigue al símbolo de la función. A veces el conjunto de capacidades de un instrumento
está escrito junto al conector del bus. Otras veces está en el manual, aunque la norma no especifica
que deba suministrarse esta información. Así, un instrumento que tuviera escrito el siguiente conjunto
de símbolos:
AH1, SH1, T5, TE0, L3, LE0, SR0, RL1, PP0, DC0, DT0, C0
debería interpretarse como: el dispositivo realiza las funciones básicas de handshake, puede actuar
como talker de forma completa pero no puede usar direcciones extendidas. Puede actuar como
listener de forma completa pero tampoco puede usar direcciones extendidas. No tiene capacidad de
generar un petición de servicio. Los controles del panel pueden bloquearse mediante órdenes desde el
bus, no puede responder a una consulta en paralelo, el instrumento no puede inicializarse mediante
una orden, no puede iniciarse un medida desde el bus y no tiene capacidad de controlador. Es un
conjunto típico de capacidades para un instrumento de medida, como un osciloscopio digital o un
DMM.

Tabla 3.2 Funciones de la interfase IEEE 488.1
SÍMBOLO NOMBRE DESCRIPCIÓN
SH Source Handshake Capacidad de generar el protocolo de transferencia de información (DAV).
AH Acceptor Handshake Capacidad de responder al protocolo de transferencia de información (NDAC,

NRFD)
T Talker Capacidad de enviar mensajes dependientes del instrumento. Incluye la

capacidad de responder a un Serial Poll. Requiere SH.
L Listener Capacidad de recibir mensajes para el instrumento. Requiere AH.
SR Service Request Capacidad de pedir atención al controlador
RL Remote Local Capacidad de inhibir los controles del panel frontal
PP Parallel Poll Capacidad de responder a una consulta tipo paralelo
DC Device Clear Capacidad del instrumento para ser inicializado remotamente
DT Device Trigger Capacidad de ser iniciada una medida desde el bus
C Controller Capacidad de actuar como controlador
TE Talker Extended Capacidad de usar direcciones extendidas como talker
LE Listener Extended Capacidad de usar direcciones extendidas como listener
3.4.1 Funciones básicas de transferencia: AH y SH
Son las funciones que permiten leer y mandar información multilínea, usando las líneas de
datos. Esto, por si solo, permite recoger comandos de la interfase. Si además van acompañadas de las
funciones L o T podrán leer o generar mensajes que dependan del instrumento (datos de medida, etc).
Para cada función la norma especifica un diagrama de estados donde se indica cuándo debe activarse
o desactivarse una función, etc. En la figura 3.5 puede verse, como ejemplo, el diagrama de estados
de la función AH.
Fig. 3.5 Diagrama de estados de la función Acceptor Handshake (AH)
Después de poner en marcha el instrumento (pon) o bien si la línea ATN (Attention) es falsa y
no está configurado como Listener, la interfase está en un estado inactivo (AIDS: Acceptor Idle

State). De este estado sale si se activa ATN (significa que el controlador va a mandar órdenes a la
interfase) o bien está configurado como listener, y se entra en un estado de no operación (ANRS:
Acceptor Not Ready State). De este se sale cuando la interfase está dispuesta a recibir información,
con lo que pasa a ACRS. Cuando se activa DAV (ver el cronograma del protocolo de comunicación)
se pasa a un estado de aceptación de datos, del que se sale cuando se ha aceptado, y se pasa a un
estado de espera, AWNS, hasta que el elemento talker desactiva DAV.
Junto con el diagrama de estados deberíamos indicar el estado de las líneas que se controlan,
en este caso NRFD y NDAC. Por ejemplo en AIDS las líneas NRFD y NDAC están a nivel alto,
como se ha comentado en 3.3.
3.4.2 Funciones de emisión y recepción de información (T, L, TE, LE)
Las funciones T y L permiten que una interfase envíe o reciba datos dependientes del
instrumento (datos de medida, comandos de programación, etc.). Para que un instrumento actúe como
talker o listener debe haber sido configurado como tal por el controlador. La forma de realizar esta
configuración la veremos al hablar de la función controller. Ya hemos comentado que solo puede
haber un talker pero puede haber varios listeners, aunque en la práctica la mayoría de transferencias
de información se realizan entre un instrumento y el controlador (ordenador de propósito general),
que se encarga de procesarlas.
Alternativamente, en un bus sin controlador, puede haber instrumentos configurados como

talk only o listen only. En este punto no hay que confundir un instrumento con solo capacidad de
recibir mensajes (L1) con un instrumento configurado como listen only. Un instrumento con solo
capacidad de recibir (p. ej. una impresora) no hará caso de los datos hasta que alguien (el controlador)
lo configure como listener. Un instrumento configurado como listen only hará caso de todos los datos
que circulen por el bus. La utilidad de instrumentos que puedan ser configurados como listen only o
talk only está, precisamente, en poder construir buses sin controlador, por ejemplo uniendo un
osciloscopio y una impresora para poder imprimir los resultados que aparecen en la pantalla. Es
evidente que los instrumentos no pueden ser configurados como listen only o talk only a través del
bus. Antiguamente se hacía usando microinterruptores en la parte posterior del instrumento.
Actualmente se hace mediante menús, pero en cualquier caso es el usuario que debe hacerlo
manualmente.
En instrumentos complejos o modulares, cada una de las partes del instrumento puede tener
"personalidad" propia. En este caso el instrumento global tiene una dirección y cada uno de los
módulos tiene una sub-dirección. Se puede configurar como talker o listener a uno de los
submódulos. No se puede configurar a un submódulo como talker y a otro como listener porque la
interfase es única. Esto se usaba p. ej. en los analizadores lógicos HP64000, y actualmente en los
sistemas VXI cuando se conectan a un ordenador mediante una interfase IEEE-488.
Un tema importante es saber cómo se finaliza un mensaje multibyte. Hay dos formas
habituales de hacerlo, aunque la norma no impone ninguna de ellas. Se puede usar la línea EOI (End
Or Identify) o se puede usar un carácter específico, conocido como terminador. Si la transmisión es en
ASCII, el terminador suele ser el carácter LF (Line Feed). De todas formas, al no especificar nada la
norma, esto debe ser un acuerdo entre emisor y receptor. Si este extremo no está bien resuelto suele
haber problemas de comunicación.

3.4.3 Funciones que afectan al instrumento (DC, DT y RL)
Estas tres funciones no afectan al estado de la interfase sino al estado de las funciones de
medida del instrumento. La función RL (Remote Local) permite que el instrumento sea programado
desde la interfase IEEE-488. Hay instrumentos que son capaces de volcar datos de medida al bus pero
no son capaces de ser programados. Cuando un instrumento es programado desde el bus los mandos
locales dejan de funcionar. Suele haber un botón (habitualmente llamado local) que devuelve el
control al operador. Si el instrumento posee la característica de realizar un lockout de los mandos,
entonces incluso el botón de local deja de funcionar y no puede controlarse el instrumento
manualmente hasta que se desbloqueen los mandos desde el bus.
La función DC (Device Clear) permite que el instrumento (no la interfase) sea inicializado
desde el bus. La norma no especifica en qué estado debe quedar el instrumento después de realizar
esta función, por lo que cada fabricante la realiza de la forma que más le conviene.
La función DT (Device Trigger) permite que se inicie una medida mediante una orden desde
el bus. La orden se puede dar a un instrumento de forma selectiva o a un grupo de instrumentos.
Como los tiempos de respuesta desde la orden hasta que la medida se realiza efectivamente no están
especificados, la utilidad de esta función para sincronizar varios instrumentos es muy limitada.
3.4.4 Funciones de petición de servicio (SR y PP)
Cuando se produce un determinado evento en un instrumento, si este ha sido programado

para ello, puede pedir la atención del controlador mediante la activación de la línea de interrupción
(Service Request: SR). El evento causante puede ser una condición de error o la finalización de una
medida y no está especificado en la norma qué eventos pueden o no producir peticiones de servicio y
cómo se codifican estos eventos.
Si el controlador decide hacer caso de la petición tiene dos maneras alternativas de identificar
al elemento causante y la causa de la interrupción. La primera se llama Serial Poll y esta incluida
dentro de la función de talker. En este caso el controlador envía una orden de Serial Poll Enable que
indica a todos los instrumentos que se va a realizar una consulta en serie. Después configura de forma
secuencial a cada uno de los instrumentos como talker. Estos responden con una palabra de estado
donde el bit 7 indica si el instrumento ha causado o no la petición de interrupción. El resto de bits de
la palabra de estado están sin definir y cada instrumento puede codificar aquí información específica.
Una vez identificado al causante o causantes de la interrupción se envía una orden Serial Poll Disable
y se continúa con la actividad normal.
El inconveniente de este método, en un bus con muchos instrumentos, es la lentitud del

mismo. La forma alternativa consiste en realizar un consulta en paralelo (Parallel Poll). El
controlador inicia la consulta con una orden PPE (Parallel Poll Enable). Después de esto todos los
instrumentos con capacidad para ello vuelcan el byte de estado a las líneas de datos. Para que esto
funcione las líneas de datos deben ser tipo colector abierto. Si cada instrumento ha sido configurado
para poner un cero en una línea determinada en el caso de ser el causante de la interrupción y no hay
más de ocho dispositivos, es posible identificar al causante con una sola lectura. Si hay mas de ocho
instrumentos se pueden compartir líneas. En este caso se tendrá que realizar una consulta serie para
acabar de decidir entre dos o mas posibles candidatos.

3.4.5 Función de controlador (C) y codificación de las órdenes
La función de controlador es la más compleja de todas las del bus y no la comentaremos en

detalle. Puede haber más de un instrumento capaz de actuar como controlador, pero solo uno de ellos
puede estar activo en un instante dado (Controller In Charge:CIC). Hay procedimientos que permiten
transferir el control de un dispositivo a otro. El controlador activo es el único que puede enviar
órdenes de configuración de las interfases mediante la activación de la línea ATN (Attention). Si
además puede gestionar las líneas IFC (InterFace Clear), para dejar las interfases en un estado inicial
conocido y REN (REmote eNable) para permitir la programación remota de los instrumentos,
entonces se le llama controlador del sistema (System Controller). Solo puede haber un dispositivo con
la capacidad para actuar como controlador del sistema, ya sea, o no, el controlador activo en un
momento dado.
Una vez el controlador ha configurado las interfases de los instrumentos, puede dejar que la
transferencia de información se realice sola o puede participar en ella, con lo que se configura el
mismo como listener (a no ser que él sea realmente el originador o receptor de la información). En el
caso que no participe en la transferencia de información debe poder monitorizar las líneas del bus
para saber cuando finaliza la misma o bien inicializar la interfase si se detecta algún problema. Estos
procedimientos, no obstante, no están contemplados en la norma.
Para la programación de las interfases se usan órdenes de tipo unilínea (U), como por
ejemplo REN e IFC, u órdenes de tipo multilínea (M), que involucran las líneas de datos o varias
líneas de control. Dependiendo de a quién vayan dirigidas la órdenes se dividen en varias clases:
AC: Addressed Commands. Afecta a aquellos instrumentos configurados como listeners

AD: Address. La orden lleva incorporada la dirección del dispositivo
UC: Universal Commands. Afecta a todos los dispositivos conectados
En las dos páginas siguientes se puede ver la codificación de todos los mensajes posibles en
una interfase IEEE-488.1. Como ejemplo, si quisiésemos configurar al instrumento cuya dirección es
12 como talker deberíamos enviar el byte Y101100 con la línea ATN activada. En esta orden el bit de
mayor peso puede tomar cualquier valor. Los dos siguientes (10) indican que se configura la interfase
como talker y los 5 últimos son la dirección del dispositivo. Desde el punto de vista del controlador
esta orden se llama TAG:Talker Address Group mientras que desde el punto de vista del dispositivo
cuya dirección es la especificada se llama MTA: My Talk Address.
Una vez realizada la transferencia, si quisiéramos reprogramar las interfases deberíamos

enviar los comandos UNL:Unlisten i/o UNT:Untalk para desprogramarlas y volverlas a programar.
Estos comandos son casos especiales de comandos clase AD puesto que, de hecho, no llevan
incorporada la dirección del dispositivo.



3.5 Códigos, formatos, protocolos y comandos comunes (IEEE-488.2-1992)
Para acabar con parte de la dispersión de codificación de información o la indefinición

respecto al contenido de los registros de estado surgió la norma IEEE-488.2 en 1987, que
posteriormente fue modificada en 1992. La interrelación entre esta norma y la IEEE-488.1, con los
aspectos que cubre cada una de ellas, puede verse en la figura 3.6.
Dispositivo X Dispositivo Y
BUS
Mensajes dependientes del dispositivo
Comandos y cuestiones comunes
Sintaxis y estructura de datos
Mensajes de la interfase
Específico
Específico
del IEEE-488.1
IEEE-488.2 IEEE-488.2 del
dispositivo
dispositivo
Fig. 3.6 Capas de protocolos cubiertos por las normas IEEE 488.1 y IEEE 488.2
Vemos que la norma IEEE-488.2 define una sintaxis y unas estructuras de datos por encima
de la codificación de mensajes vista en el apartado anterior. Además define un conjunto de comandos
y preguntas, basados en esta sintaxis, y por tanto multibyte, y las estructuras asociadas. De todas
formas queda un nivel por encima de la norma que no se define y que está constituido por los
mensajes particulares de programación de cada instrumento.
El objetivo de la norma son los sistemas de instrumentación compuestos de un controlador y

unos dispositivos programables. Los sistemas sin controlador, aunque posibles, no están
contemplados de forma explícita.

3.5.1 Requerimientos de la interfase
Para que un dispositivo pueda programarse de acuerdo con lo que especifica la norma IEEE-
488.2, la interfase debe realizar, obligatoriamente, un cierto subconjunto de las funciones definidas en
el apartado 3.4. Las más significativas, y que pueden provocar que un dispositivo no diseñado
específicamente para cumplir la norma IEEE-488.2 no se comporte correctamente, son:
1.- Debe poder generar y aceptar el protocolo de transferencia de información (SH1 y AH1).
Adicionalmente se especifica que se debe entrar en el estado AIDS (ver figura 3.5) como
máximo 1 ms después que la señal ATN se desactive, a no ser que se haya programado como
listener. Esto se hace para asegurar que el protocolo FindListeners funcione correctamente.
2.- Los dispositivos deberán usar la misma dirección como talker que como listener.
Habitualmente esto es así, pero la norma IEEE-488.1, de hecho, no lo especifica. Los
dispositivos deberán tener las capacidades básicas de emitir información y deberán poder
responder a un Serial Poll (T5 o T6). También deberán tener capacidad de recibir
información (L3 o L4). Se supone, además, que un dispositivo configurado como listener se
desconfigura automáticamente si recibe MTA (My Talk Address) y viceversa.
3.- Los dispositivos deben responder a una orden Device Clear de la siguiente forma:
- Limpiar la cola de órdenes de entrada y datos de salida
- Abortar el comando que se estuviese ejecutando (caso de un dispositivo con
procesado en paralelo de comandos)
- Guardando los datos internos de medida que se hubiesen adquirido
- Cambiando sólo el bit indicado en el registro de estado.
4.- Las líneas ATN, EOI y DAV deberán usar circuitos de ataque de tres estados. Las líneas de
datos también excepto que el dispositivo este respondiendo a un consulta en paralelo
(Parallel Poll), en cuyo caso serán colector abierto.
3.5.2 Registro de estado y petición de servicio
Cada dispositivo tendrá, como mínimo, 4 registros en los que se indica su estado y se
configura la posibilidad de pedir atención al controlador. La estructura de estos registros se puede ver
en la figura 3.7. El registro de sucesos habituales (Standard Event Status Register:SESR) contiene el
estado del dispositivo. Es un registro de 16 bits. Los 8 de mayor peso están reservados y deben
ponerse a 0. Cada uno de los restantes tiene asociado un suceso. Este registro tiene asociada una
máscara. Si cualquiera de los bits está a 1 y la máscara lo permite se activara el bit 5 del registro de
estado (Status Register). Este es el registro que se devuelve al controlador como consecuencia de una
consulta en serie. Al igual que el anterior, este registro tiene asociada una máscara. Si cualquiera de
los bits está activado y la máscara lo permite se activará el bit 6 y se generará una petición de
interrupción. De hecho, sólo 3 bits de este registro tienen función definida: el bit 6 indica que se ha
producido una petición de servicio. El bit 5 indica que se ha producido un suceso habitual no
enmascarado y el bit 4 indica que la cola de mensajes de salida no está vacía. El resto de bits pueden
estar asociados a otros registros de estado distintos del SESR, específicos de cada dispositivo

Fig. 3.7 Registros de estado, y sus interrelaciones, definidos en la norma IEEE-488.2
3.5.3 Sintaxis de los mensajes
La norma distingue entre mensajes de programación (generados por el controlador) y

mensajes de dispositivo (generados por los diferentes dispositivos). Las normas sintácticas que se
aplican son comunes, y los mensajes de dispositivo son un subconjunto de los de programación.
Comentaremos sólo la estructura de estos últimos.

Un mensaje consta de un cuerpo, <PROGRAM MESSAGE>, más un terminador,

<PROGRAM MESSAGE TERMINATOR>. Este terminador puede ser, o bien la activación de la
línea EOI con el último carácter transmitido, o bien un carácter NL (New Line, ASCII 0AH) o una
combinación de ambos.
El cuerpo del mensaje puede constar de una o varias unidades, <PROGRAM MESSAGE
UNIT> separadas por el carácter ';'. Hay dos tipos de unidad, los comandos de programación y las
preguntas. Ambas se componen de una cabecera y unos datos, separados por un espacio en blanco.
Las cabeceras de las preguntas llevan un carácter '?' al final, antes de los datos y especifican al
dispositivo que debe devolver un mensaje de respuesta. Los datos pueden ser numéricos o cadenas de
caracteres. Si son numéricos pueden estar representados en ASCII o transmitirse en binario. Si hay
más de un dato, estos se separan con el carácter ','.
Las cabeceras pueden ser de tres tipos: simples, compuestas y comandos comunes (common
command). Una cabecera simple es un mnemotécnico. Una cabecera compuesta es una sucesión de
mnemotécnicos separados por el carácter ':'. Un comando común es un mnemotécnico precedido de
carácter '*'.
Así, por ejemplo:
*IDN? Es un comando común. IDN es un mnemotécnico de IDeNtify. El interrogante indica al

dispositivo que debe devolver una cadena de identificación.
MED:CORR:DC? 1A,0.001A Es una cabecera compuesta. Podría indicar al dispositivo que realice
una medida de corriente continua en la escala de 1 amperio con una
resolución de 0,001 amperios. El interrogante indica que el
dispositivo debe devolver el resultado de la medida.
CONF:REP 10;VOLT:AC AUTO Es un mensaje con dos unidades. La primera podría indicar
que se tienen que hacer 10 medidas. La segunda que debe
medir tensiones alternas en una escala automática.
En los ejemplos anteriores el significado de los mnemotécnicos es inventado. Excepto para

los comandos comunes la norma no especifica ni la forma ni el significado de estos mnemotécnicos.
Cuando los datos numéricos representan magnitudes físicas, el símbolo de la unidad se puede
especificar, acompañado de un multiplicador si fuese necesario. El conjunto de símbolos y
multiplicadores han sido elegidos siguiendo la norma ISO Std 2955-1983 y han sido modificados
adecuadamente para representar unidades que no son del Sistema Internacional y para poder usar un
conjunto restringido de caracteres (solo mayúsculas o solo minúsculas). Así el mnemotécnico que
representa 10-3 es el carácter 'm' o 'M' mientras que para 106 es 'ma' o 'MA'. En el caso de usar
unidades compuestas formadas por el producto o cociente de unidades simples, los símbolos de
producto '.' y cociente '/' se pondrán de forma explícita.
En el caso de mensajes de respuesta de dispositivos, se siguen los mismos criterios expuestos

antes. Hay sólo dos diferencias significativas. Las cabeceras de pregunta no existen y el terminador
de los mensajes debe ser el carácter NL, enviado simultáneamente con la activación de la línea EOI.

3.5.4 Comandos comunes
La norma define 39 comandos comunes. De ellos 13 deben ser implementados por todos los
dispositivos, mientras que los otros son opcionales u obligatorios si el dispositivo tiene capacidades
adicionales a las estrictamente obligatorias (Parallel Poll, Device Trigger, Controller). Los comandos
obligatorios se pueden ver en la siguiente tabla:
Tabla 3.2 Comandos comunes obligatorios definidos en la norma IEEE-488.2-1987
MNEMOTÉCNICO DESCRIPCIÓN
*CLS Clear Status. Borra toda la información de estado del dispositivo y por tanto también la
condición o las condiciones de error presentes.
*ESE Standard Event Status Enable. Fija la máscara de interrupción del registro de sucesos
habituales ("Standard Event Register"). La máscara se pasara como un número decimal entre
0 y 256 en cualquiera de los formatos aceptados en al norma (decimal, hexa, octal, binario,
coma flotante, etc.).
*ESE? Solicita del dispositivo el valor de la máscara del registro de sucesos habituales. La respuesta
debe hacerse como un número entero en cualquiera de los formatos admitidos.
*ESR? Solicita del dispositivo el valor del registro de sucesos habituales. La respuesta se dará como
en el caso anterior.
*IDN? Solicita la identificación del dispositivo. La respuesta es una cadena de caracteres ASCII (7
bits) dividida en 4 campos separados por el carácter ','. Los campos son: fabricante, modelo,
número de serie y versión del firmware. Si los dos últimos no están disponibles se devolverá el
carácter '0'.
*OPC "Operation Complete". Provoca que el dispositivo active el bit correspondiente del registro de
sucesos habituales cuando todas las operaciones pendientes hayan finalizado.
*OPC? "Operation Complete Query". Provoca que el dispositivo mande un carácter '1' cuando todas
las operaciones pendientes finalicen.
*RST "Reset". Provoca una inicialización del dispositivo. No debe afectar al estado de la interfase
ni debe modificar los registros de estado y sus máscaras.
*SRE "Service Request Enable". Fija la máscara de interrupción del registro de estado que habilita
la generación de una petición de servicio. La máscara debe suministrarse con un número
decimal en el margen 0 a 255 en cualquiera de los formatos permitidos.
*SRE? Solicita el valor de la máscara del registro de estado. La respuesta debe darse como en el
comando *ESE?
*STB? Solicita el valor del registro de estado. La respuesta debe ser como en el caso anterior.
*TST? "Self test Query". Provoca que el dispositivo realice un secuencia de prueba interna y envíe un
mensaje con el resultado. EL mensaje de respuesta es un entero en el margen -32767 a 32767.
El valor 0 indica que la prueba interna se superó con exito. Cualquier otro valor indica que la
prueba no se finalizó o se detectó algún error. El significado de los códigos distintos de 0
depende del dispositivo.
*WAI "Wait". Impide que el dispositivo realice ninguna operación hasta que la operación en curso
haya sido completada. Solo tiene sentido en aquellos dispositivos con capacidad de realizar
operaciones en paralelo.
Si un dispositivo recibe un comando común que no puede ejecutar (de los opcionales) debe
activar el bit de error correspondiente en el registro de sucesos habituales.

3.5.5 Procedimientos comunes
Hay tres grupos de procedimientos contemplados en el ámbito de la norma IEEE-488.2: Las

técnicas de sincronización, la configuración automática del sistema y los protocolos comunes del
controlador.
3.5.5.1 Técnicas de sincronización
Las técnicas de sincronización son procedimientos que puede usar el controlador para
asegurar que los comandos de programación que ha enviado a un dispositivo han sido completados.
Los dispositivos pueden ejecutar comandos de forma secuencial o solapada (paralela). Esto depende
del dispositivo y del tipo de comando.
La primera técnica de sincronización consiste en forzar al dispositivo a que ejecute los

comandos de forma secuencial. Esto se consigue con el comando *WAI. Así, por ejemplo la
secuencia de comandos:
MEDIDA1?; MEDIDA2; *WAI; MEDIDA3?; *WAI; MEDIDA4?
provocaría que MEDIDA1 comenzara a realizarse. Si el dispositivo lo permite, MEDIDA2 empezará

en paralelo, o algo más tarde. El comando *WAI se ejecutará en paralelo con ambas y no finalizará
hasta que las dos hayan finalizado. Hasta que el comando *WAI no haya finalizado, no empezará la
ejecución de MEDIDA3. Igual que antes, *WAI se ejecutará en paralelo con MEDIDA3 e impedirá la
ejecución de MEDIDA4 hasta que aquella termine.
La segunda técnica de sincronización consiste en programar al dispositivo para que envíe un

mensaje al finalizar el comando deseado. Esto se consigue con la consulta *OPC? El dispositivo no
responderá a la consulta hasta que el comando precedente haya finalizado. Así, por ejemplo, si
deseamos disponer un generador de funciones para que entregue una señal senoidal de 1 kHz y medir
esta señal con un frecuencímetro, debemos asegurarnos de que el generador ha colocado la señal a la
salida antes de programar el frecuencímetro. Esto se conseguiría con una secuencia de programación:
APPLY:SEN 1V, 1KHZ; *OPC?
El generador no responderá a la consulta *OPC? hasta que la salida de señal sea la programada. Dado
que la respuesta a la consulta *OPC? es la misma para todos los dispositivos, si se necesita
sincronizar varios de ellos debe recurrirse a otra técnica.
Usando el comando *OPC provocamos que el bit de menor peso el registro de sucesos
habituales (SESR) se ponga a 1 cuando el comando que precede a *OPC haya finalizado. Podemos
detectar este evento bien leyendo el registro SERS con el comando *ESR? bien programando el
dispositivo para que genere una petición de servicio al activarse este bit. Generar una petición de
servicio habitualmente provoca una interrupción interna en el controlador, que suele ser un ordenador
de propósito general con una interfase adecuada. Manejar interrupciones en entornos multitarea
(UNIX, MS-Windows, etc) no siempre es una tarea fácil o agradecida, por lo que las técnicas basadas
en peticiones de servicio no suelen usarse excepto en aplicaciones muy consolidadas o si los
requerimientos de velocidad lo aconsejan.

3.5.5.2 Configuración automática del sistema
La configuración automática del sistema se refiere fundamentalmente a la asignación

automática de direcciones en un sistema cuando este es configurado por primera vez o cuando es
reconfigurado. El procedimiento general contempla dos clases de dispositivos: aquellos cuyas
funciones de interfase pueden configurarse remotamente y aquellos cuyas funciones de interfase sólo
pueden configurarse localmente o no pueden configurarse.
En primer lugar se determinarán las direcciones de aquellos dispositivos cuya dirección no es

modificable remotamente (que es el caso habitual). Para hacerlo se utiliza el protocolo FindListeners,
que se comentará más adelante. Este protocolo devuelve las direcciones de todos los dispositivos con
capacidad de listener. Para que solo respondan al protocolo aquellos cuya dirección no es
configurable, antes de ejecutar este protocolo se inhabilita la función listener de los demás mediante
el comando *DLF (opcional). Una vez identificados estos dispositivos se devuelve la capacidad de
listener a los demás mediante un Device Clear y se procede a asignarles las direcciones libres
mediante el comando *AAD.
Una vez asignadas las direcciones se construye una tabla que contiene las direcciones
realmente ocupadas y la identificación del dispositivo obtenida mediante la orden *IDN?. Esta tabla
servirá al usuario para enviar las órdenes de programación de medida adecuadas.
La existencia de dispositivos que no cumplan con la norma IEEE-488.2 debe ser detectada de
forma manual. Estos dispositivos no responderán, por ejemplo, a una orden *IDN? o incluso pueden
no ser detectados con el protocolo Find Listeners si la interfase no pasa a un estado inactivo en un
tiempo máximo de 1 ms después que ATN se ha desactivado.
La experiencia nos enseña que puede haber incluso dispositivos más perversos. Nos hemos
encontrado con dispositivos cuya interfase no funciona correctamente a no ser que se active la línea
REN, lo que permite la programación remota del instrumento. Este hecho puede parecer anecdótico,
aunque provoca que protocolos como Find Listeners no detecten ningún dispositivo conectado. Estos
dispositivos, de hecho, no cumplen siquiera con el estándar IEEE-488.1.
3.5.5.3 Secuencias de control y protocolos comunes
La norma IEEE-488.1 establece los códigos de los comandos para configurar la interfase pero
no especifica en qué orden deben enviarse ni qué secuencias de códigos son necesarias para una
determinada acción. En la norma IEEE-488.2 se establece un conjunto de secuencias de control que
permiten realizar acciones básicas en el sistemas de instrumentación así como protocolos que ayudan,
por ejemplo, a la configuración automática del sistema.
En la tabla 3.3 pueden verse las secuencias de control que debe realizar el controlador.
Adicionalmente se pueden implementar secuencias de control que permiten el paso de control a otro
dispositivo y la configuración de una consulta en paralelo.
En este conjunto de secuencias de comandos se ha previsto sólo que la transferencia de

información se realice a través del controlador. Ya mencionamos anteriormente que éste era el caso
más habitual. No obstante, si fuese necesario realizar una transferencia entre dos dispositivos sin que
el controlador actuase de intermediario (por ejemplo, por motivos de velocidad), deberían
programarse las interfases del sistema usando la secuencia SEND COMMAND. De todas formas, el

controlador debería tomar parte en la transferencia, como listener. Algunos programas de aplicación
tienen prevista esta situación y provocan que el controlador responda únicamente al handshake, sin
almacenar realmente la información, aunque esto escapa un poco del contenido de la norma.
Tabla 3.3 Secuencias de control obligatorias para el controlador
SECUENCIA DE CONTROL DESCRIPCIÓN
SEND COMMAND Permite enviar comandos de programación de la interfase, activando la línea

ATN
SEND SETUP Configura el sistema para que el controlador pueda enviar mensajes de
programación del instrumento a uno o varios dispositivos
SEND DATA BYTES El controlador envía mensajes de programación de instrumento a los

dispositivos configurados como "listeners" con el comando anterior
SEND Realiza las dos secuencias anteriores secuencialmente
RECEIVE SETUP Configura el sistema para que un dispositivo actúe como "talker" y el
controlador pueda recibir la información
RECEIVE RESPONSE MESSAGE El controlador recibe el mensaje del dispositivo previamente configurado
RECEIVE Realiza las dos secuencias anteriores secuencialmente
SEND IFC Pulsa la línea IFC durante un tiempo mayor que 100 µs. Solo puede realizarlo el
controlador del sistema
DEVICE CLEAR Provoca una inicialización de los dispositivos, bien de todos ellos ("Device
Clear") o de un conjunto ("Selected Device Clear") usando órdenes 488.1
ENABLE LOCAL CONTROLS Coloca en estado local los dispositivos seleccionados o todo el sistema,
permitiendo el uso de los controles manuales
ENABLE REMOTE Configura todo el sistema o algunos dispositivos para que puedan recibir
comandos de programación de medida de forma remota, activando la línea REN
SET RWLS Impide que se puedan utilizar los controles locales de los instrumentos
seleccionados ("Local LockOut")
SEND LLO Impide que se puedan usar los controles locales de todos los instrumentos,
aunque de hecho no los dispone en estado de programación remota.
READ STATUS BYTE Realiza una lectura del registro de estado de un dispositivo. De hecho se realiza
una consulta serie ("Serial Poll") a un solo dispositivo
TRIGGER Envía un "Group Execute Trigger" (IEEE-488.1 GET) a todo el sistema o a un

conjunto seleccionado de dispositivos
Los protocolos comunes son algoritmos diseñados para realizar determinadas funciones. La
diferencia con las secuencias de comandos es la existencia de sentencias condicionales. Solo hay dos
protocolos obligatorios: RESET y ALLSPOLL.
RESET esta diseñado para realizar una inicialización completa del sistema. En primer lugar
se envía un mensaje IFC que provoca que todas las interfases queden en un estado inactivo y el
controlador se autoconfigura como controlador activo (CIC) y después se activa una secuencia
ENABLE REMOTE. En segundo lugar se pone en marcha una secuencia DEVICE CLEAR para todo
el sistema y en tercer lugar se envía el comando *RST a todos los dispositivos del sistema usando una

secuencia SEND. Para este último paso el controlador debe conocer las direcciones de los
dispositivos. Si existieran dispositivos que no tuviesen implementada la orden *RST, debería saberse
de antemano cómo reaccionan cuando la reciben, ya que podrían provocar situaciones inesperadas
(errores, peticiones de servicio, etc.).
El protocolo ALLSPOLL realiza una consulta serie de todos los dispositivos en el sistema.
Para poder ejecutarse correctamente el controlador debe saber las direcciones de los dispositivos con
capacidad de responder a una consulta serie (todos los que cumplan IEEE-488.2).
Hay otros protocolos que se pueden realizar de forma opcional y que comentamos
brevemente:
FINDRQS: Determina el dispositivo que ha pedido servicio. Se basa en ALLSPOLL.

FINDLSTN: Determina las direcciones de todos los dispositivos con capacidad de ser
configurados como listener.
TESTSYS: Realiza un autotest de todos los dispositivos del sistema.
SETADD: Configura las direcciones de aquellos dispositivos con esta capacidad.
PASSCTL: Cede el control a un dispositivo con capacidad para ello.
REQUESTCTL: Pide el control a otro dispositivo.
3.6 Realización de interfases IEEE-488.1 y .2
Sería posible emular el funcionamiento de una interfase IEEE-488.1 usando una interfase de
entradas -salidas digitales y realizando los diagramas de estados a través de programas que se
ejecutasen en un microprocesador. Esta solución fue adoptada en alguna máquina basada en i8086
con un puerto de E/S basado en i8255 que se usaba normalmente como interfase CENTRONICS para
una impresora y que, mediante el programa adecuado, se convertía en IEEE-488.1. Si bien es una
solución muy barata, la velocidad de transferencia de información se ve muy comprometida.
Por este motivo han ido apareciendo en el mercado circuitos integrados que realizan en más o
en menos las funciones de una interfase IEEE-488.1 y que se conectan como un periférico de
microprocesador al sistema informático que se usa como controlador.
Los circuitos más significativos comercialmente son el TMS9914 de Texas Instruments, el

i8291A e i8292 de Intel, el µPD7210 de NEC y el conjunto Turbo488, NAT4882 y TNT4882 de
National Instruments [MAN94]. Excepto los circuitos de National Instruments, todos los demás
fueron diseñados antes de la aparición de la norma IEEE-488.2, por lo que no se podrá realizar una
interfase que implemente la totalidad de esta norma con dichos circuitos integrados.
Los chips de Intel realizan las funciones de Talker y Listener en un circuito (8291) y las de
Controller en otro (8292), por lo cual se puede dimensionar mejor la interfase si no se está diseñando
un controlador. Estos dos integrados requiren circuitos de interfase física con las líneas del bus. Si se
quiere realizar una interfase completa se debe recurrir a los circuitos 8293, especialmente diseñados
para ello.
Los integrados de Texas y NEC tienen todas las funciones (T, L, C) en el mismo circuito.
También requiren chips adicionales para la interfase física con el bus, pero en este caso se pueden
usar circuitos 75160/161/162, que son mucho más asequibles que los anteriores.

Las diferencias entre todos estos circuitos son pequeñas por lo que respecta a la funcionalidad
de la interfase IEEE-488 y quizá algo mayores por lo que respecta a la interfase con el
microprocesador que los controla. En cualquier caso, conviene leer detenidamente las hojas de
características de todos ellos antes de realizar la elección.
Por lo que respecta al circuito de National Instruments TNT4882, éste consiste en la unión en
un solo chip de los circuitos NAT4882 (T, L, C), Turbo488 (interfase rápida con el microprocesador)
y unos drivers para el bus, con lo cual se puede hacer una interfase GPIB con un solo circuito.
Además de esto, este integrado tiene algunas características especiales que le permiten realizar
protocolos previstos en la norma IEEE-488.2, como son la monitorización de todas las líneas del bus
o la detección automática del terminador de mensaje. Finalmente, este circuito es capaz de
implementar un protocolo de comunicación llamado HS488 (High Speed 488) que permite alcanzar
velocidades de transferencia de datos de hasta 8 Mbyte/s. Este protocolo se basa en que la mayor
parte de las transferencias de información se realizan hacia o desde el controlador a un dispositivo,
con lo cual el protocolo de tres líneas clásico (handshake) se puede obviar y por tanto evitar los
retardos asociados con el mismo. La revisión de la norma IEEE-488.1 (que fue reafirmada en 1994)
para incluir este protocolo de alta velocidad y la extensión de los mensajes de la interfase que permita
la conmutación dinámica entre el protocolo clasico y el nuevo está actualmente en fase de proyecto.

Sistemas basados en el bus VME y VXI 53
4 Sistemas basados en el bus VME y VXI
4.1 Del VME al VXI
A finales de la década de los setenta, muchos fabricantes diseñaban y construían sus propios
sistemas de instrumentación modulares o en tarjeta. Sin embargo, la mayor parte de estos equipos
utilizaban arquitecturas propias y sólo algunas soportaban los equipos de más de un fabricante.
La aparición previa del estándar del bus VME para sistemas basados en microprocesador,
junto con el deseo del Departamento de Defensa de los Estados Unidos de reducir el tamaño de sus
equipos de prueba automáticos, propiciaron la aparición del bus VXI. Para conseguirlo recurrieron al
bus VME, que en aquel momento, gracias a su estructura modular, y velocidad de transferencia de
datos, tenía un exito comercial importante. Era particularmente útil en el diseño de aplicaciones de
test digital y procesado digital de señal.
No obstante, la limitación más importante del bus VME era que su diseño no estaba orientado
al diseño de sistemas de instrumentación, en especial no incorporaba líneas analógicas ni de
sincronización. Para solventar este problema se creó en abril de 1987 un comite de cinco empresas
fabricantes de instrumentación (Colorado Data Systems, Hewlett Packard, Racal Dana, Tektronix y
Wavetek). Cuatro meses después se definía un nuevo estándar abierto para instrumentación basado en
el bus VME llamado VXI (VME bus Extensions for Instrumentation).
El bus VXI es una arquitectura abierta para todos los fabricantes de instrumentos modulares.
Esta especificación pública de sistema permite la coexistencia y el funcionamiento de un amplio
margen de instrumentos dentro del mismo bastidor. Mientras que el estándar IEEE-488 es
principalmente un estándar de comunicaciones para facilitar la integración del sistema, el bus VXI es
un estándar de sistema. En la norma VXI no se define únicamente el protocolo de comunicaciones y
la conexión física de dichos instrumentos, se definen también aspectos mecánicos, eléctricos, de
compatibilidad electromagnética y tipos de instrumentos.
El bus VXI está orientado a aplicaciones que requieren una capacidad de integración y
velocidad que se encuentran fuera de las capacidades del bus IEEE-488. Sin embargo, la enorme
popularidad de la norma IEEE-488 se tuvo en cuenta en la definición de la norma VXI y se utilizó
como modelo para el protocolo de comunicaciones entre dispositivos e instrumentos.

4.2 Especificaciones generales de la norma VXI
Desde la primera definición de la norma en el año 1987 han ido apareciendo sucesivas
versiones que incorporaban ligeras modificaciones sobre el borrador original, de las cuales la última
versiónha sido la 1.4, correspondiente a abril de 1992, que se ha consolidado con el reconocimiento
por parte del IEEE como estándar IEEE-1155. El consorcio original de cinco empresas se ha
ampliado con nuevos miembros como Bruel & Kjaer, Fluke, GenRad, Keythley y National
Instruments.
Para la definición de la norma se tomó como base el bus VME (IEEE-1014). Su estructura
jerárquica, velocidad, flexibilidad y la existencia de multitud de tarjetas ya disponibles lo hacen ideal
en este contexto. La primera consecuencia es la posibilidad de integrar dispositivos o sistemas VME
ya existentes en futuras aplicaciones basadas en VXI.
La norma VXI define las características mecánicas, eléctricas, los protocolos y los procesos
de inicialización así como las peculiaridades de los posibles interficies IEEE-488 que puedan
emplearse para la comunicación con elementos de control externos.
Dentro de la norma VXI se pueden distinguir un conjunto de nueve especificaciones que

hacen referencia a diferentes aspectos del diseño de sistemas VXI y son:
VXI-0 Visión general de las especificaciones del bus VXI. Revisión 1.0 mayo 1992.
VXI-1 Especificación de un sistema basado en el bus VXI. Revisión 1.4, abril 1992.
VXI-2 Especificación para dispositivos extendidos basados en registros y para dispositivos
VXI de memoria extendidos basados en registros. Revisión 1.0, febrero 1991.
VXI-3 Especificación de comandos de palabra serie para la identificación de la versión y el
número de serie de dispositivos VXI. Revisión 1.0, febrero 1991.
VXI-4 Especificación de mnemotécnicos comunes en la norma VXI. Revisión 1.0, junio
1991.
VXI-5 Especificación de los comandos ASCII comunes del sistema. Revisión 1.0, junio
1991.
VXI-6 Especificación de la interfase estándar para la extensión del bus VXI. Revisión 1.0,
febrero 1991.
VXI-7 Especificación del formato de datos de memoria compartida. Revisión 1.0, marzo
1992.
VXI-9 Especificación del protocolo de memoria compartida para sistemas VXI. Revisión
1.0, mayo 1992.
Todas ellas están recogidas y publicadas dentro de un documento conocido como VXIbus
System Specifications Revision 1.4. El núcleo principal de la norma, donde se comprende la
configuración y el funcionamiento de un sistema VXI, es la especificación VXI-1.
4.3 Descripción de los buses VXI y VME
La norma VXI constituye una extensión del la norma VME. Por tanto, los dispositivos VME
son un subconjunto dentro de los instrumentos VXI.

4.3.1 El bus VME
El bus VME es bus asíncrono formado por cuatro sub-buses: transferencia de datos, arbitraje,
interrupciones y utilidades.
- Bus de transferencia de datos:
Es un bus asíncrono de datos que puede transferir palabras de 8, 16 o 32 bits entre

módulos. Está compuesto de un conjunto de 32 líneas de dirección (A1-A32), 32 líneas de
datos (D1-D32) y líneas de control.
El espacio de direcciones puede configurarse de tres maneras diferentes:

-Direccionamiento corto (A16) 64 kbyte
-Direccionamiento estándar (A24) 16 Mbyte
-Direccionamiento extendido (A32) 4 Gbyte
- Bus de arbitraje de transferencia de datos:
Permite transferir el control del bus de datos entre diferentes dispositivos maestros de
una manera ordenada y garantizando que únicamente un dispositivo maestro controla el bus
de datos en cualquier instante.
- Bus de interrupciones
Dispone de siete líneas de interrupción (IRQ1-IRQ7) con diferentes niveles de

prioridad y un máximo de siete controladores de interrupción. Permite a los dispositivos
realizar sus peticiones de interrupción y que éstas sean reconocidas por el módulo controlador
del sistema.
- Bus de utilidades
Suministra la alimentación, las señales de inicialización del sistema, detección de

fallos en la alimentación, señales de reloj y una línea auxiliar de transmisión de datos serie.
Dentro de la norma VME se definen tarjetas de dos dimensiones estándar diferentes (figura
4.1); Eurocard, tamaño A (100 mm x 160 mm), y doble Eurocard, tamaño B (233 mm x 160 mm),
figura 4.1. Las señales descritas están disponibles en dos conectores denominados P1 y P2 de 96
contactos cada uno. En el primer conector se utilizan las 96 líneas y del segundo (P2) se utilizan las
32 líneas centrales del conector. Las tarjetas de tamaño A incluyen únicamente el conector P1, que es
la configuración mínima de funcionamiento. El espacio de direcciones en la tarjeta de tamaño A
puede ser el A24 (16 Mbytes) o A16 (64 kbytes) con palabras de 8 o 16 bits.
El tamaño B dispone de los dos conectores P1 y P2 y el espacio de direcciones puede ser el

A16, A24 o A32 (4 Gbytes) con palabras de 8, 16 o 32 bits.

VME 100 mm x 160 mm

P1 Tamaño A
P1
VME 233 mm x 160 mm
Tamaño B
P2
P1
VXI Tamaño C 233 mm x 340 mm
P2
P1
VXI Tamaño D 366 mm x 340 mm

P2
P3
Fig. 4.1 Tarjetas estándar VXI y VME
4.3.2 Extensión del bus VME, el bus VXI
La extensión del bus VME, por parte de la norma VXI, a un bus para instrumentación
modular contempla diversos aspectos.
El primero de ellos es el mecánico. Se definen dos nuevos tamaños además de los ya

incorporados en la norma VME, y son el C (233,35 mm x 340 mm) y el D (366,7 mm x 340 mm) a
los que se les añade un nuevo conector P3. El segundo define los sub-buses que se han añadido
utilizando las dos líneas de contactos del conector P2, que quedan libres en la norma VME, y el
conector P3. Los nuevos sub-buses son:
Bus de reloj
Está formado por dos señales de reloj de 10 MHz y 100 MHz y una señal de sincronización
de reloj para esta última. La señal de 10 MHz (CLK10) está disponible en el conector P2 y la señal
de 100 MHz (CLK100) junto con la de sincronización (SYNC100) están ubicadas en el conector P3.
CLK10, CLK100 y SYNC100 son señales diferenciales con niveles ECL y disponen de un
amplificador en el bus para cada módulo para aumentar el aislamiento entre módulos y reducir el
efecto de carga sobre la señal de reloj. El controlador del bus VXI, el módulo 0, puede generar estos
relojes o pueden ser suministrados a partir de un generador de frecuencia patrón a través del panel
frontal del módulo 0. La señal SYNC100 permite sincronizar diferentes módulos con un determinado
flanco de subida de la señal CLK100.
Bus en estrella
Situado en el conector P3, está formado por doce pares de líneas (STARXn y STARYn) que
unen respectivamente cada uno de los módulos con el módulo 0 como muestra la figura 4.2. Además
son líneas bidireccionales diferenciales con niveles ECL.

El bus en estrella ofrece una vía de comunicación de alta velocidad entre módulos para
procesos en los cuales la temporización es extremadamente crítica. La norma VXI fija un retardo
máximo de 5 ns entre cualquier módulo y el módulo 0 y una desviación de 2 ns entre cualquier par de
señales STARXn-STARYn.
Líneas de reloj y sincronismo
Líneas de identificación (MODID)
Bus en estrella
Bus Local
bus VME
Bus de Disparo
Bus Suma
Fig. 4.2 Esquema de la estructura completa de un BUS VXI
Bus de disparo
El bus de disparo puede subdividirse en 8 líneas de disparo con niveles TTL (TTLTRG*) y 6
líneas con niveles ECL (ECLTRG). Todas la líneas TTLTRG* y dos de las ECLTRG están situadas
en el conector P2. Las cuatro restantes ECLTRG están en el conector P3.
Su utilización por un instrumento o grupo de ellos posibilita la implementación de complejos

patrones de disparo y temporización. Se han definido diversos protocolos para la coordinación y
comunicación entre módulos. Además de señales de disparo y reloj es posible el intercambio de
información digital a través de estos buses mediante la agrupación de líneas con el fin de descargar y
complementar al bus VME. La velocidad de transmisión en las líneas TTLTRG* puede llegar a una
frecuencia máxima de 12,5 MHz mientras que en las ECLTRG este límite llega a 62,5 MHz.
Las líneas TTLTRG* son TTL en colector abierto y están terminadas en cada uno de los
extremos del bus con una red pasiva. El nivel lógico alto, 5 V, viene fijado por las terminaciones del
bus. Para la temporización de procesos mediante estas líneas la norma recomienda utilizar los flancos
descendentes de las señales al tener un tiempo de bajada menor por la configuración de colector
abierto.

La norma define seis protocolos para las señales TTLTRG*:

- Disparo síncrono: una única línea transmite una señal de disparo que no requiere una
validación por parte de ningún receptor. La velocidad de repetición máxima es de 12,5 MHz.
- Disparo semisíncrono: una única línea transmite una señal de disparo, nivel bajo, y
múltiples receptores validan la señal poniendo la misma línea a nivel bajo.
- Disparo asíncrono: Se utilizan dos líneas. Hay una única fuente de disparo y un único
receptor para validar la señal de disparo.
- Transmisión de reloj: Cualquier línea TTLTRG* puede utilizarse para la transmisión de una
señal de reloj desde 0 Hz a 12,5 MHz.
- Transmisión de datos: Una o más líneas TTLTRG* pueden agruparse para la transmisión de
datos en paralelo. Una de estas líneas se usa como reloj o disparo.
- Protocolo Start/Stop: Una línea TTLTRG* es controlada por el modulo Slot 0 y su estado
significa el inicio o el final de la operación de otros módulos.
Bus local
Está formado por 36+36 líneas (12+12 en el conector P2 y 24+24 en P3) que comunican cada
módulo únicamente con los inmediatamente adyacentes y con el que se pueden realizar transferencias
de hasta 200 MHz, proporcionando una velocidad de transmisión efectiva de 1 Gbyte/s. Su función es
la de enlazar localmente diferentes tarjetas a gran velocidad, por ejemplo un módulo digitalizador y
un módulo de procesado de señal.
Al no estar ligado al conjunto de los módulos, la definición de las señales transferidas se

realiza según las necesidades de cada dispositivo, estando prevista la transferencia de señales digitales
TTL y ECL y analógicas de bajo, medio y alto nivel (-42 V a 42 V).
Bus de suma analógica
Está presente en el conector P2 y forma un nodo común a todos los módulos del sistema.
Está terminado con una resistencia de 50 S conectada a la masa de señal en cada extremo del bus. La
señal de suma analógica está situada en un extremo del conector P2, alejada de las señales digitales y
apantallada por tres terminales de masa. Está previsto que cualquier módulo pueda enviar o recibir de
esta línea. Cada módulo puede transmitir a esta línea mediante una fuente de corriente con una
impedancia de salida mayor de 10 kS con una capacidad en paralelo menor de 4 pF. El receptor
deberá tener una impedancia equivalente de entrada mayor de 10 kS con una capacidad en paralelo
menor de 3 pF.
Un ejemplo de utilización es la generación de formas de onda complejas a partir de las salidas

de diferentes módulos que se combinaría de forma aditiva en el bus suma. La ventaja de este método
es que permite combinar diferentes módulos de generación de señal para crear una forma de onda
compleja que, de otra forma, requeriría un instrumento de mayor coste.

Bus de identificación de módulos
El bus de identificación de módulos esta formado por 12 líneas de P2 (MODID) conectadas

cada una de ellas a una de las 12 ranuras disponibles en el bus VXI para la conexión de módulos.
Estas líneas se alimentan desde el módulo conectado en la ranura 0 y permiten la detección de la
existencia de los dispositivos conectados al bus, incluso en el caso de fallo de los mismos, ya que se
basa en la detección de un contacto a masa. Es de gran utilidad en el diagnóstico de fallos y en el
proceso de autoconfiguración en los módulos que dispongan del conector P2.
Bus de alimentación
El bus de distribución de la alimentación puede suministrar hasta 268 W a un único módulo

que tenga los conectores P1, P2 y P3. Esta potencia se entrega en siete tensiones reguladas diferentes.
El bus VXI añade con respecto a la norma VME tensiones de +24 V y -24 V para la alimentación de
circuitos analógicos, y -5.2 V y -2 V para circuitos ECL.
En la figuras 4.2 y 4.3 puede verse una esquema de la estructura completa de sub-buses del
bus VXI y la distribución de las diferentes señales en los conectores P1, P2 y P3.
4.4 Modos de funcionamiento y arquitecturas del bus VXI
En el apartado anterior se han descrito los recursos físicos disponibles en la norma VXI que
se basan en un bus específico. La norma también define las relaciones entre los componentes del
sistema y las estructuras que permiten la realización de configuraciones efectivas.
Un sistema VXI puede estar constituido por un máximo de 256 dispositivos incluyendo uno
o más subsistemas VXI. Cada subsistema incluye un módulo central o ranura 0 (SLOT0), que genera
las señales de reloj, temporización y control del sistema, y hasta 12 instrumentos o módulos
adicionales. Todo el subsistema se encuentra ubicado en un bastidor normalizado.
Los dispositivos son los elementos básicos de un sistema VXI; están formados generalmente
por un solo módulo, pero pueden existir varios dispositivos en un solo módulo, o bien un dispositivo
puede ocupar varios módulos. Cada uno de los 256 dispositivos que pueden existir en un sistema VXI
tiene una dirección lógica asociada entre 0 y 255. A cada dispositivo se le adjudican 64 direcciones
absolutas de memoria en el mapa de direcciones A16, de 64 kbytes. La dirección lógica del
dispositivo define la dirección de este segmento de 64 bytes. Estos 64 bytes contienen los registros de
configuración y los registros de comunicación del dispositivo.
4.4.1 Tipos de dispositivos en un sistema VXI
En la norma VXI se ha buscado, ante todo, una gran flexibilidad que facilite su adaptación a
los más variados entornos y aplicaciones. Se han definido cuatro tipos diferentes de dispositivos VXI:
basados en mensajes, basabdos en registros, memoria y extendidos.
Los dispositivos de memoria proporcionan posiciones de almacenamiento de datos en

bloques de memoria RAM o ROM. Permiten mover grandes cantidades de datos. Los dispositivos

Definición del conector P1 del bus VXI; Slot 0-12 Definición del conector P2 del bus VXI; Slot 0
Número de Fila A Fila B Fila C Número de Fila A Fila B Fila C
PIN Señal Señal Señal PIN Señal Señal Señal
1 D00 BBSY* D08 1 ECLTRG0 +5 CLK10+

2 D01 BCLR* D09 2 -2V GND CLK10-
3 D02 ACFAIL* D10 3 ECLTRG1 RSV1 GND
4 D03 BG0IN* D11 4 GND A24 -5,2V
5 D04 BG0OUT* D12 5 MODID12 A25 LBUSC00
6 D05 BG1IN* D13 6 MODID11 A26 LBUSC01
7 D06 BG1OUT* D14 7 -5,2V A27 GND
8 D07 BG2IN* D15 8 MODID10 A28 LBUSC02
9 GND BG2OUT* GND 9 MODID09 A29 LBUSC03
10 SYSCLK BG3IN* SYSFAIL* 10 GND A30 GND
11 GND BG3OUT* BERR* 11 MODID08 A31 LBUSC04
12 DS1* BR0* SYSRESET* 12 MODID07 GND LBUSC05
13 DS0* BR1* LWORD* 13 -5,2V +5V -2V
14 WRITE* BR2* AM5 14 MODID06 D16 LBUSC06
15 GND BR3* A23 15 MODID05 D17 LBUSC07
16 DTACK* AM0 A22 16 GND D18 GND
17 GND AM1 A21 17 MODID04 D19 LBUSC08
18 AS AM2 A20 18 MODID03 D20 LBUSC09
19 GND AM3 A19 19 -5,2V D21 -5,2V
20 IACK* GND A18 20 MODID02 D22 LBUSC10
21 IACKIN* SERCLK(1) A17 21 MODID01 D23 LBUSC11
22 IACKOUT* SERDAT*(1) A16 22 GND GND GND
23 AM4 GND A15 23 TTLTRG0* D24 TTLTRG1*
24 A07 IRQ7* A14 24 TTLTRG2* D25 TTLTRG3*
25 A06 IRQ6* A13 25 +5V D26 GND
28 A03 IRQ3* A10 28 GND D29 GND
29 A02 IRQ2* A9 29 RSV2 D30 RSV3
30 A01 IRQ1* A8 30 MODID00 D31 GND
31 -12V +5VSTDBY +12V 31 GND GND +24V
32 +5V +5 +5V 32 SUMBUS +5V -24V
Definición del conector P3 del bus VXI; Slot 0

Número de Fila A Fila B Fila C
PIN Señal Señal Señal
1 ECLTRG2 +24V +12V

2 GND -24V -12V
3 ECLTRG3 GND RSV4
4 -2V RSV5 +5V
5 ECLTRG4 -5,2V RSV6
6 GND RSV7 GND
7 ECLTRG5 +5V -5,2V
8 -2V GND GND
9 STARY12+ +5V STARX01+
10 STARY12- STARY01- STARX01-
11 STARX12+ STARX12- STARY01+
12 STARY11+ GND STARX02+
18 STARY09+ -2V STARX04+
21 STARY08+ GND STARX05+
27 GND GND GND
28 STARX+ -5,2V STARY+
29 STARX- GND STARY-
30 GND -5,2V -5,2V
31 CLK100+ -2V SYNC100+
Fig. 4.3 Distribución de señales en los conectores P1, P2 y P3 de un bus VXI
basados en registros disponen de una inteligencia limitada. Se comunican con su módulo controlador
por medio de protocolos específicos definidos por el fabricante, en forma de escrituras directas en sus

registros de configuración o comunicación. Su principal desventaja es la dificultad de programación,

y su mayor ventaja es la facilidad de diseño y coste reducido. Los dispositivos extendidos se
encuentran reservados, y permiten la definición de nuevas subclases de dispositivos VXI en futuras
ampliaciones de la norma.
Los dispositivos basados en mensajes, en contraste con los basados en registros, se

comunican mediante mensajes de caracteres ASCII similares a los empleados por los instrumentos
IEEE-488. El protocolo de comunicación está definido en la norma, denominado Word Serial
Protocol (WSP), proporciona un soporte básico para la transmisión serie de los comandos de alto
nivel. Actualmente se tiende a la estandarización de los comandos, de forma que dispositivos
equivalentes de diferentes fabricantes puedan ser perfectamente intercambiables. Esta tendencia se
recoge en la normativa SCPI (Standard Commands for Programmable Instrumentation), que se
describe en el capítulo siguiente.
Un instrumento puede estar compuesto por más de un módulo. Los buses definidos en la
norma son el soporte físico que permite el funcionamiento de los distintos módulos como un único
instrumento. En cuanto al soporte lógico, software, es necesario que la acción de los componentes del
instrumento sea coordinada adecuadamente y que la información se comparta de la forma más natural
y transparente posible. La norma VXI contempla la constitución de estructuras jerárquicas basadas en
dispositivos Servants y Commanders (ver figura 4.4). Varios dispositivos Servants dependen de un
único dispositivo Commander. Un determinado Commander puede a su vez ser un Servant de otro.
Los dispositivos Servants pueden ser de dos tipos, basados en registro o basados en mensajes. Sin
embargo, los Commander ha de ser dispositivos basados en mensajes que permitan controlar a los
Servant.
COMMANDER
SERVANT
SERVANT
COMMANDER
SERVANT SERVANT
Fig. 4.4 Estructura e interrelaciones entre un 'comander' y un 'servant'
4.4.2 Recursos del sistema
Como ya se ha comentado, la arquitectura del bus VXI ofrece un conjunto de recursos

comunes al sistema. Estos recursos o funciones están centralizados en dos entidades conocidas como
Slot 0 y Resource Manager. Normalmente se implementan en un mismo módulo que, además, incluye
la interfase de comunicación (IEEE-488, RS232 o MXI) o control adecuados.
El Slot 0 debe generar las señales de reloj, CLK10, CLK100 y SYNC100 así como las señales
del Bus de Identificación de Módulos (MODID) y comunicación STARXn, STARYn.

El Resource Manager tiene asignadas funciones de mas alto nivel. Es un dispositivo basado
en mensajes con capacidad de Commander que debe estar situado en la dirección lógica 0 y que, al
arrancar el sistema, realiza las siguientes funciones:
-Identificar todos los dispositivos VXI del sistema.

-Gestionar el autotest y la secuencia de inicialización del sistema.
-Configurar el mapa de direcciones A24 y A32 del sistema.
-Configurar las jerarquías Commander/Servant del sistema.
-Iniciar la operación normal del mismo.
4.4.3 Protocolos de comunicación
La comunicación dentro de un sistema VXI se establece entre un Commander y cualquiera de

sus Servants a iniciativa del primero. En el nivel superior de la estructura jerárquica se encuentra el
controlador VXI o el dispositivo de comunicación entre el controlador externo y el bus VXI.
SCPI
PROTOCOLOS ESPECÍFICOS 488.2
488-VXI
MEMORIA
COMPARTIDA WORD SERIAL
COMUNICACIÓN
CONFIGURACIÓN
Fig. 4.5 Jerarquia de comunicación en un bus VXI
La comunicación con los dispositivos basados en registros, que sólo pueden actuar como
Servants, no está especificada por la norma VXI y depende del fabricante del equipo. En este caso el
sistema deberá incluir el dispositivo o los dispositivos Commander adecuados del fabricante para
poder controlar el Servant basado en registros. La comunicación entre Commanders y Servants
basados en mensajes está totalmente definida en la norma. El protocolo empleado es conocido como
Word Serial. Permite el envío y la recepción de información secuencialmente de una forma similar a
la usada en el entorno IEEE-488. Se trata de un protocolo asíncrono cuya velocidad se adapta al
dispositivo más lento en cada momento. La longitud de estas palabras es de 16 bits, aunque existen
variantes de 8, 32 o 48 bits. El protocolo hace uso del contenido de diversos registros en el Servant
normalizados para la coordinación y configuración de las transmisiones.
Un protocolo alternativo es de memoria compartida. En este, zonas de memoria, del espacio

de direcciones VME, pueden ser utilizadas por más de un dispositivo y usarse para la transferencia de
grandes bloques de información. La memoria puede estar físicamente incluida en los propios
dispositivos o estar en tarjetas de memoria conectadas a tal efecto al bus. En la figura 4.5 puede verse
la estructura jerárquica de los diferentes niveles de comunicación para un sistema VXI.

4.4.4 Arquitecturas de un sistema VXI
La norma VXI permite una gran variedad de configuraciones posibles. Las más típicas son:
1.- Un único controlador externo, Host, conectado al sistema a través del SLOT 0 y el
Resource Manager mediante una interfase IEEE-488, RS232 o red local.
2.- Un único controlador interno que realiza además las funciones de SLOT0 y Resource
Manager. Los controladores VXI existentes se basan, en su mayoría, en la
arquitectura PC, con procesadores de la familia INTEL 80x86.
3.- Varios procesadores internos con control distribuido de sistemas.
La primera opción es la más frecuente. La disponibilidad de controladores adecuados, las

velocidades de transferencia posibles y el hecho de que la mayoría de sistemas que incluyen
equipamiento VXI sean mixtos al hacer uso de instrumentación IEEE-488, son las razones que avalan
esta elección. En este caso el controlador se conecta a uno o varios subsistemas a través de un módulo
de interfase adecuado presente en cada uno de ellos. Este dispositivo realiza además las funciones de
SLOT 0 y Resource Manager. La norma especifica cómo ha de ser la traducción de protocolos entre
el bus VXI y el IEEE-488 pero no define nada sobre los esquemas de direccionado, que quedan estos
libres a elección del fabricante o diseñador. Las soluciones adoptadas hasta el momento han sido tres:
a) Múltiples primarias: Cada instrumento VXI se identifica mediante una dirección primaria
válida dentro del bus IEEE-488. Tiene como ventaja la similitud con la programación de
instrumentación IEEE-488, pero el número de direcciones de dispositivos se limita a 30.
b) Múltiples secundarias: Las direcciones secundarias IEEE-488 se utilizan para extender el

espacio de direccionamiento. En este caso una única dirección primaria se asignaría al
bastidor y una dirección secundaria a cada dispositivo VXI.
c) Dirección incluida en los comandos, Embeded Addressing. Se envía con cada comando un
identificador antepuesto al mismo indicando qué dispositivo lógico es el destinatario de la
información. Se utiliza una única dirección primaria y el nombre del dispositivo queda a
elección del programador.

Comandos de medida normalizados 65
5 Comandos de medida normalizados. SCPI, ADIF
La norma ANSI/IEEE 488.2 de 1987 (revisada en 1992) introdujo una estandarización de

muchos aspectos que no estaban incluidos en la norma previa de 1975, como son: el formato de datos,
el reporte de estados, el tratamiento de errores, la funcionalidad del controlador y algunos comandos
básicos al que todos los instrumentos deben responder. Así, esta norma establece algunas
especificaciones del software que no estaban incluidas en la norma original. Sin embargo, deja abierto
el formato y tipo de comandos que hay que enviar a los instrumentos (ver la figura 3.6). La norma
SCPI (Standard Commands for Programmable Instruments) aparece en 1991 para conseguir una
estandarización de los comandos de control y el formato de los datos de los instrumentos. El objetivo
es que, independientemente del fabricante, equipos que tienen la misma funcionalidad respondan de
igual forma a un conjunto estándar de comandos.
Fig. 5.1 Jerarquía de las normas para instrumentos controlables
La norma SCPI es el escalón más alto dentro de la jerarquía normativa para el control de
sistemas de instrumentación. Tal como se puede ver en la figura 5.1, la norma SCPI se asienta sobre
la IEEE-488.2 y esta, a su vez, se basa en la IEEE-488.1. A pesar de esta jerarquía los comandos y la
estructura de datos basados en la norma SCPI pueden usarse, y se usan, en sistemas de
instrumentación que no estén basados en IEEE-488, por ejemplo en sistemas basados en VXI, RS-232
o LAN.
El objetivo general de la norma SCPI es reducir los costes de desarrollo y mantenimiento de

programas de control de sistemas de instrumentación para prueba automática. Este objetivo se
consigue ya que el cumplimiento de la normativa:
- facilita el aprendizaje y uso de los comandos y los datos.

- facilita el desarrollo y mantenimiento de los programas.
- posibilita la sustitución de equipos con los mínimos cambios de software.
Para conseguir estos objetivos la norma establece la sintaxis y los formatos de los mensajes
para que instrumentos con la misma funcionalidad o instrumentos del mismo tipo utilicen los mismos
comandos. Por ejemplo, los comandos para medir una frecuencia utilizando frecuencímetros de
distintos fabricantes serán los mismos. Además, la medida de la frecuencia con otro instrumento que

lo permita, por ejemplo un osciloscopio digital o un multímetro, también utilizarán los mismos
comandos.
La norma establece tres tipos de compatibilidad entre instrumentos:
1.- Vertical: equipos de un mismo tipo tienen los mismos controles. Ejemplo: en dos multímetros
distintos la selección de escala se realizará de la misma forma.
2.- Horizontal: equipos que realizan la misma medida, aunque sea de formas distintas, utilizarán los
mismos comandos. Ejemplo: un osciloscopio que pueda medir períodos y un frecuencímetro-contador
utilizarán los mismos comandos para medir el período de una señal.
3.- Funcional: dos equipos distintos que puedan realizar la misma función lo harán con los mismos
comandos. Ejemplo: un analizador de espectros que pueda realizar barridos de frecuencia y un
generador de señal serán funcionalmente compatibles si el barrido de frecuencia se programa con los
mismos comandos.
Para conseguir un conjunto de comandos que puedan ser utilizados en cualquier instrumento,
optimizando la compatibilidad, la norma define un modelo de instrumento universal. Este modelo es
el que pasamos a ver de forma más detallada a continuación.
Para facilitar el aprendizaje de los nombres de los comandos, que provienen de abreviaciones
de palabras inglesas, usaremos las denominaciones inglesas para las distintas partes de los
instrumentos.
Fig. 5.2 Modelo de instrumento general definido en la norma SCPI
5.1 Modelo de instrumento según la norma SCPI
El objetivo de establecer un modelo general de instrumento es estandarizar un conjunto de

bloques funcionales a los que se les asignará un conjunto de comandos para su programación. De esta
forma cada instrumento concreto podrá ser descrito mediante un subconjunto de estos bloques

funcionales y su programación se realizará utilizando los comandos correspondientes a estos bloques.

El modelo de instrumento es el representado en la figura 5.2. Este modelo describe el flujo de datos
en un instrumento genérico; las líneas de trazo continuo representan flujo de datos y las líneas a
trazos representan controles.
Cada instrumento específico se representa sólo por los bloques que lo constituyen. Por
ejemplo, un multímetro digital puede tener sólo los bloques de función de medida, TRIGger y
FORMat (figura 5.3). En cambio, para un generador de funciones sólo tendríamos: FORMat y Signal
generation (figura 5.4)1.
Fig. 5.3 Modelo para un multímetro digital
Fig. 5.4 Modelo para un generador de funciones
A continuación se describe cada uno de los bloques del modelo de instrumento definido.
- Signal ROUTing
Representa la posibilidad que tienen ciertos instrumentos para direccionar las señales de sus
conectores de entrada a distintos circuitos internos. Es análogo al bloque de direccionamiento
de señal visto en el apartado 5.2. Los comandos que controlan esta sección se denominan
ROUTe.
- MEASurement Function
Este bloque es el que realiza la medida, entendida en su sentido más amplio como una
transformación de una señal en un código que luego podrá ser procesado. Este bloque se
subdivide a su vez en los siguientes (figura 5.5): INPut, SENSe y CALCulate.
La subdivisión del bloque de medida en estas tres partes no se ha incluido en el modelo de

instrumento (figura 5.2) porque hay instrumentos que no serían 'horizontalmente compatibles
a este nivel pero sí lo son a nivel del bloque funcional de medida. Por ejemplo, la medida del
valor eficaz de una senoide con un voltímetro y con un osciloscopio digital podrían ser
horizontalmente compatibles utilizando instrucciones al nivel del bloque MEASurement
(utilizarían los mismos comandos), pero los comandos para programar la medida a un nivel
1
La parte de las palabras que está en mayúsculas coincide con el nombre de los comandos estándares abreviados para cada bloque.

más bajo serían distintos. En el voltímetro la medida se realiza con un comando del bloque
SENSe, mientras que en el osciloscopio habría que calcular (utilizando comandos del bloque
CALCulate) el valor eficaz a partir de las muestras adquiridas.
Fig. 5.5 Bloque de medida expandido
- INPut
Representa la etapa de adaptación de la señal de entrada, por ejemplo el acoplo AC,
DC, GND de osciloscopios.
- SENSe
Es propiamente el bloque de medida, que pasa de una señal eléctrica a un código que
luego puede ser procesado digitalmente.
- CALCulate
Su función es pasar los datos adquiridos por el bloque de medida a valores que sean
más apropiados para una aplicación concreta. Por ejemplo, calcular períodos,
frecuencias, tiempos de subida, etc. en un osciloscopio digital.
Fig. 5.6 Bloque de generación expandido

- Signal Generation
Este bloque también esta subdividido al igual que el de medida (figura 5.6). Su función es la
de pasar datos a una señal eléctrica. Para ello se pueden distinguir los siguientes sub-bloques:
- CALCulate
Su función es modificar el flujo de datos recibido para generar la señal deseada a la
salida.
- SOURce
La función de este bloque es determinar las características de la señal generada a
partir del flujo de datos suministrado.
- OUTput
Es la parte que determina cómo se aplica la señal generada. Incluye las funciones de
atenuación, filtrado, suma de tensiones continuas, etc.
- TRIGger
Su función es proveer al instrumento de medios para sincronizarse con eventos de las
señales, tanto internas como externas.
- MEMory
Es el almacén de datos interno al instrumento. Según sea el caso pueden realizarse
lecturas de datos, escrituras o guardarse parámetros de calibración internos.
- FORMat
Es el encargado de transformar el formato de los datos digitales internos al
instrumento a otros que sean transferibles a través del bus de control.
5.2 Sintaxis y estilo
Los comandos en la norma SCPI se agrupan jerárquicamente en forma de árbol. En la raíz del
árbol se encuentran los comandos que hacen referencia a los bloques que aparecen en el modelo de
instrumento visto en la sección anterior. Cada uno de estos comandos se divide en un conjunto de
ramas identificadas por palabras clave que a su vez identifican a funciones subordinadas al bloque
raíz y así sucesivamente.
En la figura 5.7 se representa el arbol del bloque de INPut. La notación que se sigue es la
siguiente:
: indican el paso a un nivel jerarquico inferior. Para clarificar la notación también se ha
utilizado identación de los niveles inferiores.
[] palabras clave opcionales
<> encierran el tipo de parámetro
| separa parámetros opcionales (solo se puede poner uno de ellos)
; separa comandos que están en la misma línea (no cambia el nivel del último comando)
, se usa para separar distintos parámetros dentro de un mismo nivel
? indica que es un comando de consulta y que se espera una respuesta del equipo al que se
envía. Es muy importante leer el dato solicitado; de no ser así al enviar otro comando se crea
una situación de error en el instrumento.

KEYWORD PARAMETER FORM NOTES
INPut
:ATTenuation <numeric_value> <tipo de variable>
:AUTO <Boolean>|ONCE | separa parámetros opcionales
:BIAS
[:STATe] <Boolean> opcional
:VOLTage
[:DC] <numeric_value> opcional
:AC <numeric_value>
:TYPE CURRent|VOLTage
. otras opciones
. .
. .
:COUPling AC|DC|GROund
:GAIN <numeric_value>
:AUTO <Boolean>|ONCE
. otras opciones
. .
. .
Fig. 5.7 Estructura jerárquica de comandos para el bloque de INPut de un instrumento.
Comandos SCPI correctos para este bloque son:
INPut:BIAS:STATe OFF
INP:COUPling ?
INP:ATT 20
INPut:ATTenuation:AUTO; INPut:BIAS:STATe ON; INPut:BIAS:VOLTage:DC 0.1 V
INP:ATT:AUTO; INP:BIAS:STAT ON; VOLT:DC 0.1 V (esta línea realiza la misma programación
del instrumento que la anterior)
La sintaxis para los valores numéricos, las unidades y sus prefijos es la definida en los
apartados 7.2 y 7.3 de la norma IEEE-488.2. Los parámetros numerícos pueden ser en cualquier tipo
de notación: entera, decimal o científica. Entre los sufijos numerícos aceptados están: MA (106), k o
K (103), m o M (10-3), u o U (por µ: 10-6). También pueden enviarse las palabras MAXimum,
MINimum y DEFault.
Los parámetros booleanos pueden escribirse como ON y OFF o como 0 y 1. Los instrumentos
siempre responderán con 0 o 1.
Existen dos grupos de comandos definidos en la norma: comunes y específicos de

instrumento. Los comandos comunes son los mismos comandos que se definen como obligatorios en
la norma IEEE 488.2. Éstos sirven para funciones tales como: reinicialización, autocomprobación y
operaciones de estado. Los comandos específicos de instrumento son los propios que define la norma
SCPI. La sintaxis de cada grupo puede verse en la figura 5.8.
5.3 Comandos
Los comandos comunes definidos en la norma IEEE-488.2 que deben estar implementados
para cumplir la norma SCPI son:

*CLS Clear Status Command

*ESE Standard Event Status Enable Command
Fig. 5.8 Sintaxis para los comandos comunes y específicos.
*ESE? Standard Event Status Enable Query

*ESR? Standard Event Status Register Query
*IDN? Identification Query
*OPC Operation Complete Command
*OPC? Operation Complete Query
*RST Rest Command
*SRE Service Request Enable Command
*SRE? Service Request Enable Query
*STB? Read Status Byte Query
*TST? Self Test Query
*WAI Wait-to-Continue Command
Para una explicación de estos comandos véase el apartado 3.5.4.
Los comandos específicos definidos en la norma SCPI se dividen a su vez en dos grupos, los
obligatorios y los opcionales. Los únicos bloques que son obligatorios son el de SYSTem y el de
STATus.
Los comandos específicos definidos en la norma SCPI son los siguientes:
- MEASure - INPut - ROUTe - TRACe|DATA

- CALCulate - INSTrument - SENSe - TRIGger
- CALibration - MEMory - SOURce - UNIT
- DIAGnostic - MMEMory - STATus - VXI
- DISPlay - OUPut - SYSTem
- FORMat - PROGram - TEST
En la norma se estipulan todos los niveles inferiores posibles para cada uno de estos bloques.
En un instrumento en particular sólo se utilizarán aquellos comandos que tengan una función
definida. En la figura 5.9 pueden verse los comandos que son funcionales en un multímetro digital

para los bloques de medida y configuración. Se debe notar que si se envía un comando de medida, por
ejemplo:
MEASure
:VOLTage:DC? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:VOLTage:DC:RATio? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:VOLTage:AC? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:CURRent:DC? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:CURRent:AC? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:RESistance? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:FRESistance? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:FREQuency? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:PERiod? {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:CONTinuity?
:DIODe?
CONFigure
:VOLTage:DC {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:VOLTage:DC:RATio {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:VOLTage:AC {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:CURRent:DC {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:CURRent:AC {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:RESistance {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:FRESistance {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
:FREQuency {<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF}
Fig. 5.9 Ejemplo de comandos posibles en un multímetro digital para los bloques de medida y configuración
MEAS:VOLT:DC? 10, 0.003
el multímetro automáticamente realizará una medida y esperará a que se lea su registro de salida. En
cambio, con la instrucción:
CONF:VOLT:DC 10, 0.003
solo se configurará el instrumento pero la medida no se realizará hasta que se envíe una instrucción
adecuada, por ejemplo:
TRIG:SOUR EXT; READ?
en este caso el multímetro esperará a recibir un sincronismo de reloj externo para realizar la medida y
ponerla en su registro de salida.
5.4 Formato de datos: ADIF
El objetivo de este formato de datos es el de disponer de un estándar para el intercambio de

datos entre instrumentos o sistemas de forma automática. El formato ADIF está diseñado para que la
información de cada bloque de datos sea autosuficiente. La estructura está diseñada para que sea muy
flexible y extensible, y puede almacenar desde datos sencillos como un vector unidimensional a
estructuras complejas multidimensionales.
El formato de datos está estructurado en bloques. De forma general, un conjunto de datos

consiste en varios bloques de descripción y un bloque de datos. Los bloques de descripción contienen
palabras claves que identifican sub-bloques en los que otras palabras clave seguidas de variables
definen las características de la información contenida en el bloque de datos.

Los bloques definidos por la norma son 10; entre corchetes [] se incluyen los bloques que son
opcionales:
ADIF: define el bloque general en el que se incluyen los demás, asignándole una etiqueta.
STD: define la versión de ADIF usada.
[REMark]: es un texto libre que contiene comentarios generales sobre los datos.
[IDENtify]: da nombre al bloque de datos, describe de dónde proviene y contiene identificadores

como número de prueba, fecha y hora de captura, etc.
[ENCode]: especifica la codificación de todos los datos numéricos del bloque y, opcionalmente,
su valor máximo y mínimo o su resolución.
DIMension: este bloque puede repetirse varias veces y especifica la estructura y el formato de
cada bloque de datos. Los datos pueden ser implícitos, y en este este caso se incluirán
en el bloque DATA, o explícitos estando definidos en este bloque. Contiene otras
características como son: escala, offset y unidades de medida.
[ORDer]: especifica el orden dentro del bloque de datos para cada una de las dimensiones
implícitas que tenga. Los datos pueden estar ordenados por dimensiones (DIM) o de
forma alternada con un dato de cada dimensión (TUPLe).
[TRACe]: agrupa lógicamente las variables en forma de arrays, superficies o conjuntos

arbitrarios. Da nombres a las trazas y puede dar información sobre posibles simetrías
de éstas.
[VIEW]: define relaciones entre los distintos grupos de trazas (TRACe), por ejemplo puede
identificar a una dimensión como parte real y a otra como parte imaginaria de un
número complejo.
DATA: contiene los datos propiamente dichos en el orden indicado por ORDer y en el
número indicado por las dimensiones implícitas y su longitud. Normalmente incluye
una comprobación de errores basada en una suma (CSUM)
El formato está estructurado en bloques; en la figura 5.10 puede verse un ejemplo. Cada nivel
jerárquico está definido por un nombre de bloque seguido de un paréntesis que incluye a los bloques
subordinados. Dentro de cada sub-bloque hay palabras clave seguidas de uno o más valores
numéricos. Los valores numéricos están separados por comas. Esta estructura de datos es compatible
con lo definido por la norma IEEE 488.2.
Todos los carácteres usados son ASCII de 7 bits (ANSI X3.4-1977). Los datos en el bloque
DATA pueden ir codificados en otros códigos distintos de ASCII. La norma especifica 11 tipos
distintos de codificación, desde números enteros en ASCII a bloques de datos en binario con distintas
longitudes (8, 16, 32 o 64 bits) pasando por formatos especiales para cadenas de caracteres, tiempo y
fecha.
El ejemplo de la figura 5.10 es bastante complejo; para mostrar el caso más simple podemos
poner parte de la misma información de la siguiente forma:

ADIF = datos1 (
STD (1.0)
DIM = amplitud (
TYPE EXP
UNIT "V")
DATA ( CURV ( VAL 233, -134, ... 389 ) ) )
ADIF = canal1 (
STD (VERSion 1.0)
REMARK (
NOTE "array opcional de un máximo de 255 caracteres")
IDENtify (
NAME "Ejemplo de formato"
DATE 1995-08-22
TIME 13:15:10.55
TEST (NUMBer "AD1","3.1"))
ENCode (
NOTE "array opcional de caracteres"
FORMat INT16
HRANge 1000
LRANge -1000)
DIMension = amplitud (
TYPE EXPLicit
SCALe 3.2E-6
OFFSet 1.0E-5
UNITs "V")
DIMension = tiempo (
TYPE IMPLicit
SCALe 1E-6
SIZE 1024
UNITs "S")
ORDer (
BY DIMension)
TRACE = respuesta_impulsional (
SYMMetry NONE
INDependent (LABel tiempo)
DEPendent (LABel amplitud))
DATA (
CURVe (
VALue 233,-134,...389
CSUM 67)))
Fig. 5.10 Ejemplo de formato de datos ADIF
La estructura se ha simplificado mucho pero a costa de perder información (en este caso la escala
temporal y otros datos identificativos), lo que está en contra de la filosofía básica de la norma, que es
el contener los datos en una estructura que sea autosuficiente para reconstruir toda la información
adquirida por los instrumentos de medida.

Instrumentación virtual 75
6 Instrumentación virtual. Programas de ayuda al diseño de sistemas

de instrumentación
6.1 Clases de instrumentos virtuales
Un instrumento virtual es simplemente un conjunto de programas y equipos con una interfase

gráfica que tiene la apariencia y el aspecto de un instrumento físico. El usuario puede manejar el
instrumento a través del panel gráfico como si fuera un instrumento real.
Los instrumentos tradicionales son autocontenidos, tanto las capacidades de entrada salida
como la interfase de usuario, botones, pulsadores, pantallas, etc., y otras características adicionales
son fijas. Dentro de la caja del instrumento convertidores A/D, circuitos acondiconadores de señal,
microprocesadores, memoria y un bus interno convierten señales del mundo real, las analizan, y las
presentan como resultados al usuario. El fabricante define completamente la funcionalidad del
instrumento, sin la posibilidad de ser cambiada por el usuario.
La tendencia actual en instrumentación es utilizar el ordenador como un elemento más. Los

instrumentos virtuales se benefician de la arquitectura abierta de los estándares de ordenadores para
ofrecer las capacidades de procesado, memoria y visualización; mientras que las tarjetas de
adquisición, de bajo coste, y las tarjetas de interfase IEEE-488 y VXI conectadas en el bus del
ordenador sirven de vehículo para las capacidades del instrumento virtual. La funcionalidad del
instrumento la define el propio usuario y la potencia de procesado puede ser incluso mucho mayor
que en los instrumentos convencionales.
El instrumento virtual simula cada una de las partes descritas anteriormente, apoyándose en
elementos hardware accesibles por el ordenador (tarjetas de adquisición, instrumentos IEEE-488,
VXI, RS-232).
Cuando se ejecuta un programa que funciona como instrumento virtual, el usuario ve en la

pantalla de su ordenador un panel cuya función es idéntica a la de un instrumento físico, lo que
facilita la visualización y el control del aparato. A partir de los datos reflejados en el panel frontal, el
instrumento virtual debe actuar recogiendo o generando señales, como lo haría su homólogo físico.
El usuario, y no el fabricante, define la funcionalidad final del instrumento. El software es la

clave en los instrumentos virtuales; ofrece al usuario las herramientas necesarias para construir
instrumentos virtuales y expandir su funcionalidad ofreciendo una conectividad con las enormes
posibilidades de los PC y las estaciones de trabajo, y otras aplicaciones. Esta flexibilidad que permite

el software puede, sin embargo, llevar un coste asociado mayor que el del instrumento tradicional. Si
el usuario no dispone de las herramientas adecuadas de programación para el desarrollo de la
aplicación, las horas invertidas en la realización de los programas encarecerán el valor real del
instrumento final.
Las diferencias entre intrumentos tradicionales y virtuales se pueden resumir en la siguiente

tabla:
Instrumentos tradicionales Instrumentos virtuales
Definido por el fabricante Definido por el usuario
Función específica, conectividad limitada Sistema orientado a la aplicacion con

conectividad a redes, periféricos y
aplicaciones
El hardware es la clave El software es la clave
Caro Bajo coste, reutilizable
Cerrado, funcionalidad fija Abierto, funcionalidad flexible

utilización de una tecnología familiar
Cambios lentos en la tecnología Adaptación rápida a los cambios

(5-10 años de ciclo de vida) tecnológicos, (1-2 años de ciclo de vida)
Constes de desarrollo y mantenimiento El software minimiza los costes de

grandes desarrollo y mantenimiento
Tal como se ha visto, un instrumento virtual está formado por tres elementos principales:
adquisición de datos, análisis y presentación, tal como muestra la figura 6.1. Junto al gran crecimiento
de la microinformática han ido apareciendo en el mercado diversas herramientas de programación
para el desarrollo de sistemas de instrumentación virtual, que se centran en alguno o en todos los
elementos del sistema. La elección del entorno de programación vendrá condicionada por la
aplicación final del usuario.
El software que realiza el instrumento virtual y que se ejecuta sobre el controlador, en este
caso el ordenador, ha evolucionado con el tiempo. Los primeros entornos de programación permitían
el control de instrumentos o dispositivos externos al ordenador, un ejemplo es el Basic de la familia
HP9000 (la mayor parte de los instrumentos de HP programables mediante el bus IEEE-488 todavía
incluyen ejemplos de programación en Basic). Otros fabricantes de interfases para ordenador
suministraban, primero, un conjunto de funciones (funciones de nivel 0 o de registro) que se dejaban
residentes en memoria y a las que se accedía mediante interrupciones software. Posteriormente
suministraban librerías de funciones (funciones de nivel 1) que se podían llamar desde lenguajes de
alto nivel, ( C, Basic o Pascal) que ejecutaban las interrupciones software. Estas primeras
herramientas facilitaban el control de la interfase de comunicaciones con instrumentos externos y
eran independientes del instrumento a controlar. No obstante, éstas no incluían utilidades para el
análisis de datos ni la presentación de los mismos. La creación de instrumentos virtuales, con

interfases gráficas de usuario, requerían un gran esfuerzo de programación y adolecían de flexibilidad

de adaptación o modificaciones.
Fig. 6.1 Partes integrantes de un instrumento virtual
Programación gráfica
Programación linguística
Adquisición Análisis Presentación
Drivers de instrumentos
Comandos
488.2 VXI DAQ
Serie
DSP
Mensaje Mensaje
IEEE 488.2 Registro Registro Mensaje
Bus RS-232
GPIB VXI
Ordenador Serie
Fig. 6.2 Arquitectura del entorno de programación para instrumentación virtual
El siguiente paso fue crear librerías de funciones específicas para un determinado instrumento
o conjunto de instrumentos de un fabricante. Evitan la necesidad de aprender los comandos o las
instrucciones del instrumento por parte del programador. Cada una de estas funciones (de nivel 2)
suele hacer uso de una serie más o menos compleja de funciones de nivel 1 y 0. A este conjunto de
funciones se le denomina driver de instrumento y pueden encontrarse en forma de librerías enlazables
a un lenguaje de programación (C, Basic, Pascal), o bien en formato DLL (Dyamic Link Library) para

MS-Windows de manera que se pueden llamar desde cualquier entorno de programación (figura 6.2).
Al igual que las funciones de nivel 1 y 0, las de nivel 2 siguen abarcando únicamente la
adquisición de datos, bien sea a través de instrumentos convencionales provistos de interfase GPIB,
RS-232 o VXI, o con tarjetas de adquisición de datos incorporadas al bus del propio ordenador.
No obstante, los mismos fabricantes de software ofrecen entornos programación propios para
el desarrolo de aplicaciones que permiten acceder a estas librerías de una forma mas fácil. Estos
entornos ya incluyen herramientas para el análisis y presentación de datos más o menos elaboradas.
6.2 Lenguajes de control para sistemas de instrumentación
Los entornos de programación para el control de sistemas de instrumentación virtual pueden

clasificarse en diversas categorías o clases según el grado de flexibilidad y facilidad de uso.
El primer grupo lo comprenden aquellos entornos que han sido desarrollados para el control
de un instrumento específico o tarjeta de adquisición de datos. Permiten, mediante una interfase de
menús desplegables, configurar y programar el dispositivo para la adquisición de una señal y su
visualización. Un ejemplo de estos entornos es el software DAQ-Ware de National Instruments que
ofrece con sus tarjetas de adquisición datos. Permite configurar el número de canales, la ganancia y la
frecuencia de muestreo de sus tarjetas y visualizar en pantalla las señales adquiridas así como
salvarlas a fichero.
En el segundo grupo están los entornos de programación lingüísticos. El acceso a las

funciones de nivel 2, para la adquisición de datos, se hace a través de un terminado lenguaje de
programación, este puede ser estándar (C, BASIC, etc.) o propio del entorno. Además se dispone de
librerías de funciones para el análisis y la presentación de datos. Algunos de estos entornos
incorporan una interfase gráfica de menús desplegables que permite el acceso a estas funciones para
facilitar la generación del programa. Otro parámetro importante es el modo de ejecución de la
aplicación final. Algunos entornos permiten únicamente la ejecución de la aplicación dentro del
mismo. Tienen como ventaja las facilidades de depuración que incluyen y la simplificanción de la
interfase con el hardaware del controlador. Sin embargo, la velocidad de ejecución es mucho menor y
requiere el pago, en la mayoría de los casos, de una licencia run-time para su distribución o venta.
Algunos de los entornos más utilizados son:
LabWindows y LabWindows/CVI (National Instruments): Son entornos de programación

propios en C y Basic, con menús de ayuda para la generación de código de forma interactiva, para
aplicaciones MS-DOS y MS-Windows, respectivamente, de test, medida y control. Incluyen
compiladores de ANSI-C, linker, debugger y librerías para adquisición de datos, análisis y
presentación. Se pueden incorporar ficheros fuente externos, módulos objeto y DLL (en la versión
MS-Windows). Ambas versiones pueden generar aplicaciones ejecutables fuera del entorno aunque

en la versión MS-DOS es necesario un compilador C estándar externo al entorno, no suministrado con

el paquete. Una característica importante de estos paquetes de programación es la inclusión de
librerías de instrumentos, drivers, dentro del mismo entorno y que el fabricante suministra de forma
gratuita para una gran diversidad de fabricantes de instrumentos controlables: IEEE-488, VXI, RS-
232 y CAMAC.
VisuaLab (IOtech): Es una extensión del entorno Visual Basic para el desarrollo de
aplicaciones de adquisición de datos.
Asyst (Keithley-MetraByte): Entorno de programación en un lenguaje propio para MS-

DOS. Aplicaciones de adquisición de datos y análisis. Incluye librerías de análisis y drivers para
tarjetas de adquisición de varios fabricantes. Los programas corren únicamente dentro del entorno.
HPITG II (Hewlett-Packard): Es un entorno de programación con una interfase gráfica que

permite mediante menús generar secuencias sencillas de medida y análisis. Estas pueden grabarse en
un fichero y convertirse posteriormente a una secuencia de llamadas de funciones en C para
incorporar dentro de la aplicación final. Incluye únicamente librerías para instrumentos de Hewlett-
Packard, aunque dispone de un instrumento genérico que permite programar cualquier instrumento
con interfase IEEE-488.
Fig. 6.4 Panel frontal de un instrumento virtual creado con labVIEW

Los entornos de programación gráficos forman el tercer grupo. Su aparición en el mercado es

más reciente. El desarrollo de aplicaciones es totalmente diferente. Permiten crear al usuario
soluciones completas uniendo iconos de una forma totalmente gráfica y según una estructura
jerárquica; véase la figura 6.5. Los bloques son módulos software preprogramados que aparecen
como iconos en la pantalla. Algunos iconos son estándares para cualquier aplicación, pero otros
corresponden a un hardware específico del sistema de medida. Pulsando sobre cualquier icono se abre
una ventana de diálogo que contiene un listado de propiedades para su funcionamiento. Una de las
características más importantes de la programación gráfica es que se dispone de iconos para crear
interfases de usuario muy similares a las de cualquier instrumento convencional. Al igual que los
lenguajes de programación clásicos se dispone de múltiples tipos de datos y estructuras de
programación (bucles, condiciones, E/S, etc.) incluyendo algunos entornos un compilador gráfico
para aumentar la velocidad de ejecución.
El ciclo de aprendizaje y programacion se reduce drásticamente al ser entornos que imitan

una forma de programación muy parecida a un diagrama de flujo o bloques. Esta simplificación en la
forma de programación lleva asociada algunas limitaciones. La velocidad final de la aplicación será
mucho menor que su versión en lenguaje C y la utilización de muchos elementos gráficos e iconos
requiere grandes cantidades de memoria y potencia de cálculo.
Existen en el mercado diversos paquetes de programación gráfica; no todos son iguales y

deben hacerse algunas distinciones. Una diferencia básica es que algunos, como LabView, son
entornos que funcionan por sí solos y otros, como el Visual DAS de Keithley, son adaptaciones de
entornos de programación de uso común como el Visual Basic. Otra diferencia importante a
considerar a la hora de la adquisición del paquete de programación son los drivers para dispositivos,
instrumentos, tarjetas de adquisición, etc.., que incluyen. Algunos paquetes únicamente cubren los del
propio fabricante , por lo que obligan prácticamente a utilizar su hardware.
Fig. 6.5 Ejemplo de un programa gráfico para un instrumento virtual (LabVIEW)

Uno de los primeros y más conocido de los entornos de programación gráfica es el LabView
(National Instruments), que apareció en el año 1986. Las primeras versiones funcionaban sólo sobre
Macintosh, que eran entonces los únicos que disponían de memoria suficiente, 1 Mbyte, y de un
sistema operativo avanzado. Actualmente está disponible en versiones Macintosh, PC MS-Windows y
para estaciones de trabajo Sun SPARC.
El usuario dispone de una completa gama de librerías de iconos para la manipulación de

datos, control de flujo, interfase de usuario (botones, gráficos, menús, etc..), tarjetas de adquisición de
datos del propio fabricante y drivers de la mayoría de instrumentos controlables (IEEE-488, VXI, RS-
232, CAMAC) disponibles en el mercado. También pueden incluirse rutinas en lenguaje C como
iconos y llamadas a funciones de librerías externas, por ejemplo DLL de MS-Windows.
El editor gráfico incluye un compilador para aumentar la velocidad de la aplicación. La

aplicación final corre dentro del entorno y es necesario el pago de una licencia run-time para
aplicaciones comerciales.
VEE (Hewlett-Packard): Es un entorno de programación gráfica propio que funciona sobre

diferentes plataformas: Macintosh, PC (MS-Windows, Windows NT), y estaciones de trabajo HP y
SUN.
Dispone de librerías para la manipulación de datos, control de flujo, interfases de usuario y
drivers de instrumento controlables de HP (IEEE-488, VXI, RS-232). No dispone, sin embargo, de
librerías de drivers para el control de tarjetas de adquisición. También permite el uso de librerías
externas. El editor gráfico no incluye compilador y existe una versión run-time para la aplicación
final.
DT VEE (Data Translation): Es un entorno propio, disponible únicamente en la versión PC

(MS-Windows). Está orientado a la programación de sus tarjetas de adquisición y presentación de
datos. No dispone de drivers para instrumentos controlables.

Sistemas de Instrumentación

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistemas de Instrumentación

Caricato da

Copyright:

Formati disponibili

Prólogo 7

Este libro se ha escrito pensando especialmente en el tipo de sistemas que se encuentran en

© Los autores, 2000; © Edicions UPC, 2000.

La explicación de los buses de interconexión de instrumentos, igual que la descripción de

© Los autores, 2000; © Edicions UPC, 2000.

1 Automatización de las medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 Objetivos de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Arquitectura de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Estructura del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Sistemas basados en el bus IEEE-488 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Introducción histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

© Los autores, 2000; © Edicions UPC, 2000.

4 Sistemas basados en el bus VME y VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1 Del VME al VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Comandos de medida normalizados. SCPI, ADIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Modelo de instrumento según la norma SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Instrumentación virtual. Programas de ayuda al diseño de sistemas de

6.1 Clases de instrumentos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

© Los autores, 2000; © Edicions UPC, 2000.

[BUC92] BUCHLA, D.; MCLAHAN, W. Applied electronic instrumentation and measurement.

[MAN94] MANUEL, A.; SÁNCHEZ, F,; SÁNCHEZ, J. "Controladores GPIB. Características y

[MER91] MERCADÉ, J. "SCPI normalización de comandos y datos en instrumentación

[SYD89] SYDENHAM, P.H.; HANCOCK, N.H.; THORN, R. Introduction to measurement science

[JOH94] JOHNSON, G.W. LabVIEW Graphical programming. Practical Applications in

© Los autores, 2000; © Edicions UPC, 2000.

Intelligent Instrumentation, The handbook of personal computer instrumentation, Tucson,

Keithley, Data acquisition & control, Taunton, MA, 1991.

IOtech, Products for the IEEE-488 BUS, Cleveland, OH, 1992.

© Los autores, 2000; © Edicions UPC, 2000.

1 Automatización de las medidas

El concepto básico que subyace detrás del mundo de la instrumentación es el concepto de

Estos ensayos consisten siempre en la aplicación de estímulos (eléctricos, mecánicos,

© Los autores, 2000; © Edicions UPC, 2000.

1.1 Objetivos de los sistemas de instrumentación

El objetivo básico de un sistema de instrumentación es la adquisición de información del

La diferencia estructural entre los sistemas de medida y los de prueba radicaría en la

Podemos definir los objetivos de los sistemas de instrumentación según el tipo de

1. Análisis de defectos: el objetivo de estos sistemas es la realización de ensayos en dispositivos o

2. Medida de parámetros: en este caso se trata de obtener un conjunto de parámetros de un

© Los autores, 2000; © Edicions UPC, 2000.

3. Pruebas funcionales: el objetivo de estos ensayos es determinar si el SBP realiza la función

1.2 Estructura general de los sistemas de instrumentación

Fig. 1.1 Esquema conceptual de un sistema de instrumentación

En la figura 1.1 se puede ver el esquema conceptual de un sistema de instrumentación

© Los autores, 2000; © Edicions UPC, 2000.

Tanto la parte de generación de la excitación como la de adquisición están unidas a nivel

A partir de este punto entramos en el dominio de la programación, que se ha representado

1.3 Sistemas dedicados y de bastidor

© Los autores, 2000; © Edicions UPC, 2000.

limitación afectó a microprocesadores tan populares como el Z80 o el i8086.

La alternativa a esta aproximación consiste en escoger instrumentos de propósito general,

La aplicaciones más importantes de los sistemas de instrumentación las encontramos en los

1.4.1 Diseño y desarrollo

Las medidas de prestaciones se realizan en prototipos muy parecidos al producto final. Se

Los ensayos ambientales consisten en someter al producto a cambios en parámetros externos

1.4.2 Sistemas para medidas en producción

© Los autores, 2000; © Edicions UPC, 2000.

velocidad de la cadena de producción. En el mundo de la fabricación de productos electrónicos nos

En el caso de circuitos digitales complejos (microprocesadores, FPGA, etc.) las pruebas

1.4.3 Medidas de campo

1.4.4 Sistemas de control

La enseñanza clásica de los sistemas de control se centra en el estudio de los algoritmos

En la mayoría de las aplicaciones se usan tarjetas de adquisición conectadas a un ordenador