Sistemas de Instrumentacion - Riu Costa, Rosell Ferrer, Ramos Castro - UPC

7

Prólogo

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 GPIB 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, autores, 2000; © Edicions Edicions UPC, 2000. 2000.

Sistemas de instrumentaci ón

8

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

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

Í ndice

9

Índice

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

11

1.1 Objetivos de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Estructura general de los sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Sistemas dedicados y de bastidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 13 14 15

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

17

2.1 Estructura del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Estructura del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Sistema de direccionamiento de la señal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Tipos de instrumentos y buses de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 21 23 25

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

29

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

29 30 30 31 33 35 36 37 38 38 39 42 43 43 44 46 47 50


Sistemas de instrumentaci ón

10

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

53

4.1 Del VME al VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Especificaciones generales de la norma VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Descripción de los buses VXI y VME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 El bus VME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Extensión del bus VME, el bus VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Modos de funcionamiento y arquitecturas del bus VXI . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Tipos de dispositivos en un sistema VXI . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Recursos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Arquitecturas de un sistema VXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 54 54 55 56 59 59 61 62 63

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

65

5.1 Modelo de instrumento según la norma SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Sintaxis y estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Formato de datos: ADIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66 69 70 72

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

75

6.1 Clases de instrumentos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Lenguajes de control para sistemas de instrumentación . . . . . . . . . . . . . . . . . . . . . . .

75 78

Bibliograf í a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

Libros y artí culos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Normas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Catálogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83 84 84


83

Bibliografía

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.


84

Sistemas de instrumentación

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.



12

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:

13

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.



14

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



15

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



16

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.



18

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

INSTRUMENTO

INSTRUMENTO

INSTRUMENTO

CONTROL DEL BUS SISTEMA DE CONTROL

CONEXIONADO DE SEÑAL INSTRUMENTO (ALIMENTACIÓN)

CONMUTACIÓN

PLACAS I/O

USUARIO

FIJACIÓN SBP

SBP

COMUNICACIONES

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.



19

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.



20

- 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



21

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.



22

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



23

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



24

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



25

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



26

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.



27

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



30

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 4881978, 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, Protocol s, 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.



31

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

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

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

Líneas de datos. DIO1 es la de menor peso

Líneas de datos. DIO8 es la de mayor peso



32

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



33

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



34

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.



35

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.



36

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

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

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

C

Controller

TE

Talker Extended

Capacidad de usar direcciones extendidas como talker

LE

Listener Extended

Capacidad de usar direcciones extendidas como listener

Capacidad de responder al protocolo de transferencia de información (NDAC, NRFD)

Capacidad de pedir atención al controlador

Capacidad de ser iniciada una medida desde el bus Capacidad de actuar como controlador

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



37

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.



38

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.



39

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.



40



41



42

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 dependient dependientes es del dispositivo

Comandos y cuestiones comunes

Sintaxis y estructura de datos

Mensajes de la interfase

Especí fico fico del dispositivo

IEEE-488.2

IEEE-488.1

IEEE-488.2

Especí fico fico del 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 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.



43

3.5.1 Requerimientos de la interfase

Para que un dispositivo pueda programarse de acuerdo con lo que especifica la norma IEEE488.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



44

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.



45

Un mensaje consta de un cuerpo, , más un terminador, . 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, 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.



46

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.



47

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.



48

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



49

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



50

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: FINDLSTN: TESTSYS: SETADD: PASSCTL: REQUESTCTL:

Determina el dispositivo que ha pedido servicio. Se basa en ALLSPOLL. Determina las direcciones de todos los dispositivos con capacidad de ser configurados como listener . Realiza un autotest de todos los dispositivos del sistema. Configura las direcciones de aquellos dispositivos con esta capacidad. Cede el control a un dispositivo con capacidad para ello. 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.



51

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.



54

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.



55

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.



56

P1

VME Tamaño A

100 mm x 160 mm

VME Tamaño B

233 mm x 160 mm

P1 P2

P1 VXI Tamaño C

233 mm x 340 mm

VXI Tamaño D

366 mm x 340 mm

P2

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



57

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.



58

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.



59

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



60 De fin ic ió n d el co ne ct or P1 de l b us VX I; Sl ot 0- 12

D ef in ic ió n d el co ne ct or P2 de l b us VX I; Sl ot 0

Número de PIN

Fila A Señal

Fila B Señal

Fila C Señal

Número de PIN

Fila A Señal

Fila B Señal

Fila C Señal

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

D00 D01 D02 D03 D04 D05 D06 D07 GND SYSCLK GND DS1* DS0* WRITE* GND DTACK* GND AS GND IACK* IACKIN* IACKOUT* AM4 A07 A06 A05 A04 A03 A02 A01 -12V +5V

BBSY* BCLR* ACFAIL* BG0IN* BG0OUT* BG1IN* BG1OUT* BG2IN* BG2OUT* BG3IN* BG3OUT* BR0* BR1* BR2* BR3* AM0 AM1 AM2 AM3 GND SERCLK(1) SERDAT*(1) GND IRQ7* IRQ6* IRQ5* IRQ4* IRQ3* IRQ2* IRQ1* +5VSTDBY +5

D08 D09 D10 D11 D12 D13 D14 D15 GND SYSFAIL* BERR* SYSRESET* LWORD* AM5 A23 A22 A21 A20 A19 A18 A17 A16 A15 A14 A13 A12 A11 A10 A9 A8 +12V +5V

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

ECLTRG0 -2V ECLTRG1 GND MODID12 MODID11 -5,2V MODID10 MODID09 GND MODID08 MODID07 -5,2V MODID06 MODID05 GND MODID04 MODID03 -5,2V MODID02 MODID01 GND TTLTRG0* TTLTRG2* +5V TTLTRG4* TTLTRG6* GND RSV2 MODID00 GND SUMBUS

+5 GND RSV1 A24 A25 A26 A27 A28 A29 A30 A31 GND +5V D16 D17 D18 D19 D20 D21 D22 D23 GND D24 D25 D26 D27 D28 D29 D30 D31 GND +5V

CLK10+ CLK10GND -5,2V LBUSC00 LBUSC01 GND LBUSC02 LBUSC03 GND LBUSC04 LBUSC05 -2V LBUSC06 LBUSC07 GND LBUSC08 LBUSC09 -5,2V LBUSC10 LBUSC11 GND TTLTRG1* TTLTRG3* GND TTLTRG5* TTLTRG7* GND RSV3 GND +24V -24V

Definición del conector P3 del bus VXI; Slot 0 Número de PIN

Fila A Señal

Fila B Señal

Fila C Señal

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

ECLTRG2 GND ECLTRG3 -2V ECLTRG4 GND ECLTRG5 -2V STARY12+ STARY12STARX12+ STARY11+ STARY11STARX11+ STARY10+ STARY10STARX10+ STARY09+ STARY09STARX09+ STARY08+ STARY08STARX08+ STARY07+ STARY07STARX07+ GND STARX+ STARXGND CLK100+

+24V -24V GND RSV5 -5,2V RSV7 +5V GND +5V STARY01STARX12GND STARY02STARX11+5V STARY03STARX10-2V STARY04STARX09GND STARY05STARX08+5V STARY06STARX07GND -5,2V GND -5,2V -2V

+12V -12V RSV4 +5V RSV6 GND -5,2V GND STARX01+ STARX01STARY01+ STARX02+ STARX02STARY02+ STARX03+ STARX03STARY03+ STARX04+ STARX04STARY04+ STARX05+ STARX05STARY05+ STARX06+ STARX06STARY06+ GND STARY+ STARY-5,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



61

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 COMMANDER

SERVANT

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.



62

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.



63

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



66

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



67

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.



68

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



69

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



70

KEYWORD

PARAMETER FORM

INPut :ATTenuation :AUTO :BIAS [:STATe] :VOLTage [:DC] :AC :TYPE . . . :COUPling :GAIN :AUTO

NOTES

|ONCE

| separa parámetros opcionales

opcional

CURRent|VOLTage

opcional

otras opciones . . AC|DC|GROund |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:



71

*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 - CALCulate - CALibration - DIAGnostic - DISPlay - FORMat

- INPut - INSTrument - MEMory - MMEMory - OUPut - PROGram

- ROUTe - SENSe - SOURce - STATus - SYSTem - TEST

- TRACe|DATA - TRIGger - UNIT - VXI

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



72

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? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :VOLTage:DC:RATio? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :VOLTage:AC? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :CURRent:DC? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :CURRent:AC? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :RESistance? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :FRESistance? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :FREQuency? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :PERiod? {|MIN|MAX|DEF},{|MIN|MAX|DEF} :CONTinuity? :DIODe? CONFigure :VOLTage:DC {|MIN|MAX|DEF},{|MIN|MAX|DEF} :VOLTage:DC:RATio {|MIN|MAX|DEF},{|MIN|MAX|DEF} :VOLTage:AC {|MIN|MAX|DEF},{|MIN|MAX|DEF} :CURRent:DC {|MIN|MAX|DEF},{|MIN|MAX|DEF} :CURRent:AC {|MIN|MAX|DEF},{|MIN|MAX|DEF} :RESistance {|MIN|MAX|DEF},{|MIN|MAX|DEF} :FRESistance {|MIN|MAX|DEF},{|MIN|MAX|DEF} :FREQuency {|MIN|MAX|DEF},{|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.



73

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:



74

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



76

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 Definido por el fabricante Función específica, conectividad limitada

Instrumentos virtuales Definido por el usuario 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 Cambios lentos en la tecnología (5-10 años de ciclo de vida) Constes de desarrollo y mantenimiento grandes

Abierto, funcionalidad flexible utilización de una tecnología familiar Adaptación rápida a los cambios tecnológicos, (1-2 años de ciclo de vida) El software minimiza los costes de 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



77

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

488.2 Mensaje IEEE 488.2

GPIB

VXI Mensaje Registro

VXI

DAQ DSP

Comandos Serie

Registro

Mensaje

Bus Ordenador

RS-232 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



78

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



79

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, RS232 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 MSDOS. 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. 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 HewlettPackard, aunque dispone de un instrumento genérico que permite programar cualquier instrumento con interfase IEEE-488. HPITG II (Hewlett-Packard):

Fig. 6.4 Panel frontal de un instrumento virtual creado con labVIEW



80

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)


Sistemas de Instrumentacion - Riu Costa, Rosell Ferrer, Ramos Castro - UPC

Recommend Documents