Juan Paulo Robles Balestero Grupo de Investigación en

Memoria de actividades realizadas por
Juan Paulo Robles Balestero
14 de febrero a 14 de Abril de 2002
durante su estancia en el
Grupo de Investigación en
Instrumentación Electrónica Aplicada y
Técnicas de Formación (TIC-168)
(Área de Electrónica)
Escuela Politécnica Superior de Algeciras
Universidad de Cádiz (España)
Escuela Politécnica Superior. Avda. Ramón Puyol
S/N.11202-Algeciras-Cádiz-Andalucía-España
Telf: 00-34-956028020
11 de abril de 2002
AGRADECIMIENTOS
Un agradecimiento especial al Profesor Dr. Juan José González de la
Rosa, mi Tutor, quien me brindó todo su apoyo y dedicación, para que mis
estudios en la Escuela Politécnica de Algeciras, y mi estancia en Algeciras
se realizasen de la forma mas provechosa posible y pudiese así incrementar
mis conocimientos.
Asimismo, agradezco a todas las personas que trabajan en el Grupo de
Investigación en Instrumentación Electrónica Aplicada y Técnicas de
Formación (Área de Electrónica), por brindarse y hacer que mi estancia sea
agradable y con un ambiente muy familiar.
A todos, Gracias.
Juan Paulo Robles Balestero
Universidade Estadual Paulista (UNESP) – Faculdade de Engenharia de Ilha Solteira
Ilha Solteira – SP - Brasil
Algeciras., a 11 de abril de 2002
1
Índice
1.- Introducción
2. - Formación en el manejo de Test Point: Herramienta de diseño
profesional de aplicaciones de adquisición de señales.
2.1.- Aplicaciones de adquisición de señales con Test Point.
3.- Tratamiento de las muestras y Teorema de Nyquist
4.- Conceptos generales sobre instrumentación programable
(GPIB)
4.1 Antecedentes e introducción
4.2 Conceptos generales sobre GPIB
4.3 El estándar IEEE-488. Evolución y situación actual
4.4 Especificaciones técnicas. Propiedades del bus
4.5. Líneas de transmisión de señal
4.5.1 Líneas de datos
4.5.2 Líneas de control de transferencia de datos (handshake)
4.5.3 Líneas de control general de la interfaz
4.6 Funcionamiento. Transferencia de datos y cronograma
4.7 Configuraciones y características físicas y eléctricas
4.8 Instrumentos IEEE 488.2
4.9 Tarjeta controladora y aplicación básica de gobierno del bus
5.- Manejo de diversos instrumentos GPIB y de tarjeta
controladora
5.1
Manejo del Programmable True RMS Multimeter (Multímetro
Programable de verdadero valor eficaz
5.1.1 Comandos generales
5.1.2 Comandos del Display Principal
5.1.3 Comandos de la medida dual.
5.1.4 Comandos del First Level Modifier.
5.2 Manejo de la Programmable Power Supply HM8142 (Fuente de
Alimentación Programable).
6.- Diseño de paneles o interfaces de usuario para control de
instrumentos GPIB.
6.1 Diseño de paneles o interfaces utilizando el Test Point.
2
6.1.1 Diseño del panel para control del Multímetro
6.1.2 Diseño del panel para control de la Fuente de Alimentación Programable
6.2 Diseño de paneles o interfaces utilizando herramienta de programación C++.
6.2.1Diseño del panel para control del Multímetro.
6.2.2 Diseño del panel del Rastreador de Bus
7.- Conclusiones
8.- Referencias Bibliográficas
3
1. Introducción
Este trabajo ha sido desarrollado en el Grupo de Investigación en
Instrumentación Electrónica Aplicada y Técnicas de Formación durante el periodo
desde el 15 de febrero de 2002 al 14 de abril de 2002, bajo la dirección del Prof. Dr.
Juan José González de la Rosa. Se tratan conceptos generales de adquisición de señales
mediante tarjetas de adquisición de datos, utilización y el manejo de la herramienta de
diseño de instrumentos electrónicos de medida y control GPIB, virtuales (Test Point).
Además, se describen los componentes hardware utilizados, que consisten en una tarjeta
de adquisición de señales, una tarjeta controladora GPIB, diversa instrumentación
programable y otros instrumentos de laboratorio.
Inicialmente el trabajo muestra la formación en el manejo de Test Point,
herramienta de diseño profesional de aplicaciones de adquisición de señales. Esta
contiene algunas aplicaciones, de adquisición de diferentes señales con Test Point,
como por ejemplo el sensor de temperatura, que emite una señal analógica. A
continuación se exponen conceptos generales de adquisición de señales, enfocando
principalmente, los aspectos actuales de la instrumentación programable.
El ítem 4 se expone los conceptos generales sobre instrumentación programable
(GPIB), como los antecedentes históricos e introducción, los conceptos generales sobre
GPIB, el estándar IEEE-488 evolución y situación actual, y principalmente las órdenes
y solicitudes (“commands and queries”) comunes a todos los instrumentos de este
estándar, las propiedades del bus, incluyendo las líneas de transmisión de señal. En
este ítem incluí el funcionamiento, transferencia de datos y cronograma, de la Tarjeta
así como configuraciones y características físicas y eléctricas.
En el apartado 5 se expone el manejo de diversos instrumentos GPIB, como el
Multímetro programable de verdadero valor eficaz modelo TTI 1705; centrándose la
exposición en sus comandos. Análogamente se presenta el manejo de la fuente de
alimentación programable, modelo HM8142.
El diseño de paneles o interfaces de usuario para control de instrumentos GPIB
seria indispensable para este trabajo. Fueran diseñados paneles o interfaces utilizando
el Test Point para el Multímetro, y para la fuente de Alimentación Programable.
Utilizando la herramienta de programación C++, se han diseñado paneles para el
Multímetro y el “Rastreador de Bus”.
4
2. - Formación en el manejo de Test Point: Herramienta de
diseño profesional de aplicaciones de adquisición de señales
TestPoint es una herramienta concebida para, test, medida, y adquisición de
datos; y para el control externo de hardware RS232 y GPIB. En el Test Point, el usuario
escoge los objetos que intervienen en la aplicación y asocia a cada objeto un conjunto
de líneas de acción. Test Point tiene mayor flexibilidad que un lenguaje de
programación de alto nivel, y además no es necesario declarar variables.
Para crear un programa basta mover los objetos, como los botones, los displays,
los gráficos, GPIB devices, A/D boards, objetos matemáticos, y otros que se vayan a
utilizar, desde la ventana “stock” hacia el panel de la aplicación: Entonces, arrastra los
objetos hacia la lista de acción, y se elige la acción del menú, tal como indican la figuras
2.1 y 2.2:
Fig. 2.1. Manejo de Test-Point.
Fig. 2.2. Manejo de Test-Point.
5
A continuación se expone el diseño del primer programa con la herramienta Test
Point. Éste realizara la lectura de un señale de la entrada externa a través de un
conversor A/D, de la tensión y frecuencia. Calculó el valor de la tensión en rms y
mostró o gráfico del señale de entrada. El panel juntamente con lo programa se
encuentra en la figura 2.3. El programa es realizado, cuando la llave switch esta en la
posición “on”. En este momento las líneas de hachones del programa que se encuentra
dentro de la llave pasan a ser ejecutadas.
Fig. 2.3. Ejemplo.
2.1.- Aplicaciones de adquisición de señales con Test Point.
Aplicación.1 - Como primera aplicación se ha diseñado un programa que
obtiene el espectro en frecuencia de la señal de entrada, y al lado un display para
mostrar el valor de la frecuencia fundamental. El panel se muestra en la figura 2.4:
6
Fig. 2.4. 1ª Aplicación.
Para la realización de este se emplea un objeto matemático que realiza la
transformada rápida de Fourier (FFT). La FFT (fs, sinal), coge el FFT de una señale
real-estimado (vector). El valor devuelto es una lista de tres vectores: las frecuencias,
las magnitudes, y las fases (en radianes) de cada componente del espectro. Las partes
individuales de este resultado se seleccionan con el comando “select(,)”, separando así
los vectores individuales de la FFT.
En este ejemplo se han utilizado objetos matemáticos que realizan las funciones
de selección de las componentes individuales: select(transformada,0),
select(transformada,1).
Por otra parte el valor de “samples” debe ser una potencia de dos con el fin de
que el algoritmo funcione de forma óptima.
Aplicación.2 - Para esta aplicación se emplea, un sensor de temperatura, que
emite una señale analógica que varia de 0 a 1 Voltees o de -0.25v a 0.25v,
proporcionalmente con la temperatura. El censor puede ser calibrado de forma que
trábale con medidas de –10 a 40ºC o de 0 a 100ºC.
La coleta de los datos fueran realizadas con la tarjeta de adquisición de datos
KPCI-3104. Ha sido desarrollado entonces un programa que transforma los valores de
tensión del conversor A/D en proporcionáis valores de temperatura. Los valores actuáis
son presentados en un display, y en un grafico van sendo almacenados los valores al
largo del tiempo. Los cambios de calibración pueden ser efectuados tamben a través
del painel del termómetro con las llaves “Temp.(ºC)”, Tensión(Voltees) que se
encuentra en la figura 2.5 juntamente con el programa desarrollado.
7
Fig. 2.5. 2ª Aplicación.
3.- Tratamiento de las muestras y Teorema de Nyquist
El procesado digital de señales es una área de la ciencia y ingeniaría que se ha
desarrollado rápidamente durante los últimos 30 años. Este rápido desarrollo es el
resultado de los avances tecnológicos tanto en los ordenadores digitales como en la
fabricación de circuitos integrados.
Se entiende que el procesado de señal digital sea la solución apropiada a todos
los problemas de procesado de señal. Así, para muchas señales de gran ancho de banda,
se requiere procesado en tiempo real. Para tales señales, el procesado analógico o
quizás, óptico, son las únicas soluciones validas. Sin embargo cuando los circuitos
digitales se encuentran disponibles y tienen la velocidad suficiente, son normalmente
preferibles.
Los circuitos digitales no solo dan lugar a sistemas para el procesado de señales
más baratos y fiables sino que también tienen otras ventajas. En particular, el procesado
de señal digital permite operaciones programables. Por medio de software se pueden
modificar fácilmente las funciones de procesado de señal para que sean realizadas por el
8
hardware. Por tanto, el hardware digital y el software asociado proporcionan un mayor
grado de flexibilidad en el diseño de sistemas. Además, normalmente se consigue
mayor precisión con el hardware digital y el software en comparación con los circuitos
analógicos y los sistemas de procesado de señales analógicas. Por todas estas razones,
se han producido un crecimiento explosivo de la teoría del procesado de señales
analógicas. Por todas estas razones, se ha producido un crecimiento explosivo de la
teoría del procesado de señales digitales y sus aplicaciones en las ultimas tres décadas.
Pero, el procesado digital de señales analógicas tiene algunos inconvenientes. El
primero y mas importante, la conversión de una señal analógica en digital, obtenida
muestreando la señal y cuantificando las muestras, produce una distorsión que nos
impide la reconstrucción de la señal analógica original a partir de las muestras
cuantificadas. El control de esta distorsión se logra con la elección apropiada de ala
velocidad de muestreo y la precisión del proceso de cuantificación. El teorema de
Nyquist, prueba que para que la señal sea reconstruida perfectamente la frecuencia de
muestreo debe ser el doble, o mayor que la máxima componente espectral de la señal
muestreada. En segundo lugar, existen efectos debidos a la precisión finita que debe ser
considerados en el procesado digital de las muestras cuantificadas.
la adquisición de datos es realizada a través del conversor A/D, siendo éste la
referencia software de la tarjeta de adquisición de datos modelo KPC-3104, que posee
una frecuencia de muestreo máxima de 400 KHz y una resolución de 12 bits.
El registro de tiempo (Time Span) es la presentación temporal de datos en la
pantalla. En la figura 3.1 se indica la relación entre el registro de tiempo, la frecuencia
de muestreo y el número de muestras.
Ts
Fig. 3.1. Registro de tiempo-Time Span
Registro o tiempo de pantalla = Ts X Número de muestras.
Por ejemplo, para una frecuencia de muestreo Fs = 1000 Hz (Ts= 1ms), entonces
por cada 1 ms tenemos una muestra. Esto significa que si quiero ver 10 ms debo hacer
1ms X 10 muestras.
4 Instrumentación programable (GPIB)
4.1 Antecedentes e introducción
Los equipos de Instrumentación Electrónica Virtual han permitido diseñar
interfaces a medida, definidas por el usuario y orientadas a la aplicación de media o
control para la que se conciben. Esta flexibilidad, junto con el desarrollo de protocolos
de interconexión de instrumentos y el avance microelectrónico aplicado a los PCs,
permite el diseño de redes de instrumentos de medida que operan según los requisitos
9
de un equipo de instrumentación electrónica tradicional, de banco. El bus interfaz de
propósito general (GPIB; General Purpose Interface Bus) y su protocolo de
comunicaciones asociado se han convertido en elementos integradores de la unidad de
instrumentación virtual y los instrumentos tradicionales de banco, originando las redes
de instrumentación electrónica. Estos equipos integrados en red cumplen con las tres
características esenciales de un equipo de medida:
-
posibilidad de control remoto,
aceptación de la transferencia de datos que permita fiabilidad en la operación, y
capacidad de operación en tiempo real.
A continuación se describen los conceptos generales sobre GPIB con el fin de
introducir paulatinamente su funcionamiento.
4.2 Conceptos generales sobre GPIB
El bus GPIB fue inventado por Hewlett Packard a finales de los años 1960. La
intención era crear un bus fiable, especialmente diseñado para conectar computadoras e
instrumentos en una configuración de red que poseyera las características requeridas por
un equipo de medida.
El control remoto de los instrumentos es un aspecto relevante del bus, pero hay otros
más importantes como el reconocimiento de recepción de datos (“data hardware
handshake”), que dota a las operaciones de fiabilidad; o la capacidad de respuesta en
tiempo real.
El principal objetivo del bus GPIB consiste en gestionar la transferencia de
información entre dos o más dispositivos. Antes de enviar los datos hacia los
dispositivos (instrumentos conectados al bus) éstos deben configurarse de acuerdo con
este protocolo de transmisión de información. Entre los parámetros relativos al
protocolo se encuentra la asignación de direcciones a los instrumentos interconectados.
La numeración del dispositivo, o asignación de su dirección, se realiza desde el panel
frontal o alterando la conexión de los puentes de su tarjeta interfaz, que suele ser
accesible desde la parte posterior del instrumento.
El elemento controlador del equipo GPIB es único (generalmente la tarjeta
controladora instalada en un PC, en cuyo caso se le asigna la dirección 0), supervisa
todas las operaciones que se realizan en el bus, y determina el dispositivo que envía la
información y el momento en que se realiza su envío. El controlador puede designar un
sustituto si en un determinado momento no puede atender los requisitos de control. El
nuevo controlador recibe el nombre de controlador activo.
El controlador asegura que no pueden haber dos o más instrumentos enviando
información al bus simultáneamente. Además, establece los dispositivos que
permanecen en estado de recepción o escucha, ya que no todos los instrumentos están
siempre interesados en captar la información del bus. Esta función la realiza
“despertando” a los dispositivos en estado de “latencia” mediante una solicitud de
reafirmación, y mediante órdenes que especifican los nuevos receptores y el nuevo
emisor.
Cuando el proceso de transmisión-recepción ha finalizado, el controlador del equipo
se asegura de que todos los receptores han recibido la información enviada al bus por el
emisor mediante el “data hardware handshake” o control de transferencia de datos. Este
protocolo permite asegurar la recepción de la información por parte de los dispositivos
10
más lentos. Como consecuencia, el dispositivo más lento limita la velocidad de
operación del equipo GPIB.
En resumen, se consideraran los siguientes elementos o conceptos más relevantes y
específicos, involucrados en un equipo red de instrumentación mediante el protocolo
GPIB:
-
Controlador del equipo controlador activo.
Dispositivos conectados al bus.
Dispositivo fuente.
Dispositivos destino.
Comandos y funciones.
4.3 El estándar IEEE-488. Evolución y situación actual
El primer equipo de instrumentación basado en bus fue diseñado en 1965 por
Hewlett Packard (en la actualidad, la división de Test y Medida con el nombre de
“Agilent Technologies”), y recibió el nombre de HP-IB, acrónimo de Hewlett Packard
Interface Bus. Su finalidad consistía en conectar su red de instrumentos programables a
sus ordenadores de laboratorio.
Debido a su elevada velocidad de transferencia (1 Mbyte/s nominal) y a su
fiabilidad, este interfaz adquirió popularidad a pasos agigantados. Así, en 1973 se
convirtió en un estándar, siendo aceptado por la organización IEEE. Entre 1973 y 1975
recibió el nombre de estándar de comunicaciones IEEE-488, y en 1987 adoptó el
nombre de ANSI/IEEE-488.1, como se le conoce en la actualidad, estando más
extendida su designación mediante el acrónimo GPIB. En el mismo año, 1987, la
designación ANSI/IEEE-488.2 supuso una ampliación del protocolo en la línea de
describir con exactitud cómo los controladores y los instrumentos se comunicaban. Se
establece entonces el conjunto de órdenes comunes a todos los instrumentos (SCPI;
Standard Commands for Programmable Instruments).
En paralelo a la evolución del bus GPIB la IEC (International Electronic Comisión),
responsable de la estandarización fuera de los Estados Unidos, aprobó el estándar
IEC625.1. Este protocolo empleaba un conector DSUB de 25 pines, a diferencia del
IEEE-488.1 que empleaba uno similar al Centronics pero de 24 polos. Ésta última
versión es la que se emplea hoy día, pero siguen existiendo adaptadores de 25 a 24
polos, con el fin de evitar la obsolescencia de determinados instrumentos.
4.4 Especificaciones técnicas. Propiedades del bus
•
Direcciones y estructura de la interconexión. Cada dispositivo del equipo GPIB
posee una dirección, codificada como un número entre 0 y 30. Es decir, existen 31
direcciones primarias permitidas para instrumentos transmisores de datos (“talkers”)
conectados al bus interfaz GPIB. A cada instrumento se le asigna una dirección
codificada mediante 7 bits. Pueden haber hasta 15 dispositivos conectados en un bus
contiguo, siendo sólo uno de ellos el controlador. Es decir, a una tarjeta controladora
pueden conectarse hasta 14 dispositivos encadenando cables IEEE-488 de un
11
dispositivo al siguiente. Algunos dispositivos conectados al bus pueden
direccionarse también mediante direcciones secundarias. Éstas hacen referencia a
alguno de sus bloques funcionales. Por ejemplo, un osciloscopio con dirección
primaria 4 puede tener un módulo de acondicionamiento de señal con dirección
secundaria 1.
•
Velocidad de transferencia máxima: 1 Mbyte por segundo en distancias cortas. Es
usual es un valor comprendido entre 250 y 500 kilobytes/segundo.
•
Longitud del cable. La normativa especifica que pueden usarse hasta 20 metros de
cable encadenado en línea, apilando las conexiones; también recomienda no emplear
tramos de cable de más de 4 metros de longitud. Una regla práctica consiste en
multiplicar el número de dispositivos conectados por 2, comparar el resultado con
20 metros y tomar el menor número. Por ejemplo, si conectamos 8 dispositivos, la
línea puede tener hasta 16 metros, y no se puede llegar a 20. Es decir, puede haber
hasta 20 metros de cable entre el controlador y el último dispositivo, y entre cada
dos dispositivos no puede haber más de 2 metros. La alternativa de conexión en
estrella se emplea para aumentar el número de dispositivos interconectados, pero
tiene como inconveniente la mayor capacidad parásita de la red, que introduce
retardos y, en consecuencia, errores de transmisión.
•
Modo de transferencia de datos. 8 bits en paralelo. Se dedican pues 8 líneas a
datos. Estas líneas son bidireccionales.
•
Modo de transferencia de mensajes. Transferencia asíncrona de bytes en serie y
bits en paralelo. Esta transferencia es controlada por las líneas de “handshake”.
•
Funciones de la interfaz. Posee 10: 5 funciones de comunicación primarias y 5
especializadas. La norma no exige a todos los instrumentos poseer todas las
funciones.
•
Handshake. La recepción de cada byte de datos es reconocida mediante el
handshake. Consta de 3 líneas.
•
Líneas de control general para necesidades especiales. 5 líneas controlan el flujo
de señal en el bus.
A continuación se detallan las funciones de las líneas del bus y su funcionamiento, con
el fin de mostrar sus posibilidades de diseño fiable.
4.5. Líneas de transmisión de señal
La interfaz GPIB consta de 16 líneas. Las 8 restantes del bus (hasta 24) corresponden a
líneas de retorno a tierra. De las 16 líneas, 8 son de datos (1 byte) y 8 para mensajes de
control y estados de los dispositivos. De estas últimas 8 líneas, 3 son para el control de
transferencia de datos (handshake) y 5 para el control general de la interfaz. La figura 1
muestra la estructura de las líneas del bus.
12
8 líneas de
datos
3 líneas de
handshake
GPIB
5 líneas de control
de interfaz
8 líneas de
retorno de tierra
Fig. 4.1. Líneas del bus GPIB.
A continuación se describen con detalle las líneas que componen el bus GPIB.
4.5.1 Líneas de datos
Las 8 líneas de datos DIO1-DIO8 pueden transportar tanto datos como órdenes. El
estado de la línea ATN (una de las 5 de control general) determina si son datos u
órdenes. Si está a nivel bajo son órdenes o direcciones y si está a nivel alto son datos.
Todas las órdenes y la mayoría de los datos emplean 7 bits codificados en ASCII o ISO.
En este caso el octavo bit se emplea para paridad o no se emplea.
4.5.2 Líneas de control de transferencia de datos (handshake)
Estas 3 líneas realizan el control asíncrono de las transferencias de los mensajes en
forma de byte entre los dispositivos. Este proceso garantiza que la transmisión y la
recepción se han realizado sin errores, dotando a la transmisión de información de
seguridad. Las líneas son:
•
NRFD (Not Ready For Data): Indica cuándo un dispositivo está preparado para
recibir un byte. La línea es conducida por todos los dispositivos cuando reciben
órdenes (cuando actúan como receptores de datos manteniéndose a la escucha), y
por el orador o transmisor de datos cuando habilita el protocolo HS488.
• NDAC (Not Data Accepted): Indica cuándo un dispositivo ha aceptado un mensaje
(en forma de byte). La línea es conducida por todos los dispositivos al recibir
órdenes y/o datos, cuando reciben la información.
• DAV (Data Valid): Indica cuándo las señales en las líneas de datos se han
estabilizado (se consideran válidas) y pueden ser aceptadas con seguridad por los
dispositivos. El controlador conduce la línea de datos al enviar órdenes. Los
transmisores de datos la conducen cuando envían mensajes de datos.
13
4.5.3 Líneas de control general de la interfaz
•
•
•
SRQ (Service ReQuest): Se emplea para solicitar turno al controlador.
IFC (InterFace Clear): Realiza un “reset” de los parámetros y direcciones del bus.
REN (Remote ENable): Establece el control remoto de un dispositivo
deshabilitando su control a través del panel. Es decir, el usuario ya no podrá realizar
un control manual.
• EOI (End Or Identify): Se emplea como indicador de fin de transferencia de datos.
• ATN (ATtentioN): La emplea el controlador para distinguir entre los datos y los
mensajes de control. Determina el tipo de información presente en las líneas de
datos.
4.6 Funcionamiento. Transferencia de datos y cronograma
El estándar IEEE 488.1 establece un “handshake” de 3 líneas de control de datos. La
introducción de esta lógica negativa permite la implementación de la función lógica OR
mediante cableado. De esta forma, no se transmiten datos hasta que no esté listo el
receptor (listener) más lento y queda asegurado que la transmisión sea lo
suficientemente lenta como para que al receptor más lento le dé tiempo a aceptar el
dato.
La línea NRFD es controlada por cada receptor e indica si cada uno de ellos no está
listo (nivel bajo) o lo está (nivel alto) para recibir datos. La línea DAV es controlada por
el transmisor e indica si los datos en las líneas de datos (DIO) son correctos y, en
consecuencia, pueden ser aceptados por los receptores. Finalmente, la línea NDAC es
controlada por cada receptor para indicar que no ha recibido los datos (nivel bajo) o que
los ha recibido (nivel alto).
La figura 2 muestra el diagrama de tiempos de operación. En principio, el
transmisor comprueba que las líneas NRFD y NDAC están a nivel bajo. La primera
indica que no todos los receptores están listos para recibir datos y la segunda indican
que no han aceptado ningún nuevo byte. Observar que la línea NRFD no pasa a nivel
alto hasta que todos los receptores están listos. Una vez que el transmisor ha detectado
que la línea NRFD está a nivel alto y transcurre cierto retardo, necesario para dar tiempo
a estabilizar los niveles de los datos que envía a los receptores, pone la línea DAV a
nivel bajo indicando que los datos que envía son válidos (instante 3). Se transfiere así
un byte de datos.
El receptor más rápido pone la línea NRFD a nivel bajo con el fin de indicar que no
está listo para recibir otro byte (instante 4). Los demás harán lo mismo cada uno a su
ritmo. Es decir, el receptor más rápido indica al equipo que no mande más información
porque él ha tomado ya la que había y tiene que aceptarla o procesarla (es posible que se
requiera de él una respuesta).
Finalmente, los receptores van aceptando el byte poniendo a nivel alto sus líneas
NDAC. Cuando todos han aceptado los datos (instante 6), la línea pasa a nivel alto, el
transmisor lo detecta y pone la línea DAV a nivel alto para indicar que ya no valen los
datos (instante 7). El primer receptor que detecta que la línea DAV ha pasado a nivel
alto pone la línea NDAC a nivel bajo (instante 8). El transmisor pondrá otros datos
nuevos en las líneas DIO y comienza otro nuevo ciclo.
Un byte pude no transferirse en menos tiempo de la duración de los siguientes eventos:
14
-
Propagación del cambio de estado de la línea NRFD hacia el emisor de datos
(talker).
Propagación de la señal DAV a todos los receptores.
Que los receptores acepten el byte y confirmen la línea NDAC (la pasen a nivel
alto).
Que la señal NDAC regrese al emisor.
Que el emisor permita el tiempo de establecimiento de los datos en el bus antes de
confirmar la línea DAV (pasarla a nivel bajo).
ATN
TS
DIO
Transferencia de 1 byte
DAV
NRFD
Algunos
están
preparado
NDAC
1
2
3
Todos
preparados
4
5 Algunos
han
aceptado
los datos
6
7
8
Todos
aceptaron
datos
Fig. 4.2. Diagrama de tiempos de operación. TS es el tiempo de estabilización de los datos.
4.7 Configuraciones y características físicas y eléctricas
Los dispositivos suelen conectarse mediante un cable apantallado de 24 polos, con la
particularidad que en cada extremo es al mismo tiempo enchufe y receptáculo. Es
posible encadenar dispositivos mediante configuraciones lineales, en estrella o
utilizando una versión híbrida. La figura 3 muestra las conexiones lineal y en estrella.
15
(a)
(b)
Fig. 4.3. Conexiones lineal (a) y en estrella (b) de un equipo de dispositivos GPIB.
La figura 4 muestra la parte trasera de dos instrumentos reales conectado en serie en un
bus GPIB.
Fig. 4.4. Conexiones lineal de dos instrumentos GPIB.
4.8 Instrumentos IEEE 488.2
Los instrumentos de este estándar son más fáciles de programar ya que responden a
órdenes y solicitudes comunes, empleando un protocolo estándar de intercambio de
mensajes. Este protocolo constituye la base del estándar SCPI, que permite la
programación de equipos de test y medida incluso de una forma más sencilla.
16
La tabla 1 muestra las órdenes y solicitudes (“commands and queries”) comunes a
todos los instrumentos de este estándar.
Nemónico
*IDN?
*RST
*TST?
*OPC
*OPC?
*WAI
*CLS
*ESE
*ESE?
*ESR?
*SRE
*SRE?
*STB?
Grupo de órdenes
Datos del equipo
Operaciones internas
Operaciones internas
Sincronización
Sincronización
Sincronización
Estatus y suceso
Estatus y suceso
Estatus y suceso
Estatus y suceso
Estatus y suceso
Estatus y suceso
Estatus y suceso
Descripción
Solicitud de identificación
Reset
Solicitud de autocomprobación
Operación completa
Solicitud de operación completa
Esperar a completar
Borrar estado (estatus)
Habilitación estado suceso
Solicitud de habilitación estado de suceso
Solicitud de registro de estado de suceso
Habilitación de solicitud de servicio
Petición de habilitación de servicio
Solicitud de lectura de byte de estado
Tabla 1. Órdenes y solicitudes comunes a todos los instrumentos IEEE488-2.
4.9 Tarjeta controladora y aplicación básica de gobierno del bus
La figura 4muestra una tarjeta controladora GPIB con conexión PCI al PC. La
figura 5 muestra la ventana MSDOS de la aplicación básica de programación incluida
por el fabricante. En ella se observa el empleo de la función send para enviar a un
instrumento que tiene asignada la dirección 1 la secuencia de órdenes del campo “data”.
Fig. 4. Tarjeta controladora GPIB con conexión PCI.
17
Fig. 4.5. Aplicación “TRTEST” para control GPIB diseñada por CEC.
5.- Manejo de diversos instrumentos GPIB y de tarjeta
controladora.
En principio con el fin de conocer el repertorio de órdenes propio de cada
instrumento, empleamos la aplicación de control asociada a la tarjeta Keithley-488. Esta
aplicación es bajo MS-DOS. Con el MS-DOS , los datos del GPIB son enviados e
recibidos, respectivamente a través de las funciones que se adjuntan en la siguiente
figura 5.1:
18
Fig. 5.1. funciones
Las funciones utilizadas en esto trabajo son las siguientes:
!"I) Initialize: Esta función ira reiniciar la Tarjeta de Adquisición GPI.
myaddr: De 1 a 30, dar la dirección de GPIB para ser usada por su board. Esta
dirección debe ser diferente de la dirección de todos dispositivos conectados en lo
ordenador.
Level: Cuando cero especifica la tarjeta como controlador del equipo, e 2 para
especificar que la tarjeta GPIB, es uno dispositivo.
19
S) Send: Función utilizada para enviar comandos (Data), para uno instrumento,
con la dirección deseada (GPIB address), como muestra la siguiente figura:
E) Enter: Con esta función, lo usuario tendrá una variable string que contendrá los
últimos datos recibidos. La dirección deseada también es definida por lo GPIB address,
En el Maxlen se pone el valor que especifica el numero máximo de los caracteres que lo
usuario desea recibir.
!"SP) Spoll
Result = 00, el bus no esta ocupado
Result distinto de 00, el bus esta ocupado
Será mostrado ahora, el controle con la tarjeta GPIB de los instrumentos Tti
Programmable True RMS Multimeter ( Multímetro Programable), y el Programable
Power Supply HM8142 (Fuente de tensión y Corriente Programable)
20
5.1
Manejo
Programable)
del
Programmable
True
RMS
Multimeter
(Multímetro
Para el manejo del Multímetro programable son enviados los comandos al
Multímetro, a través de la funcione send. Los comandos mas utilizados son mostrados
de abajo:
5.1.1) Comandos Generales
!"*IDN?: Busca la identificación del instrumento.
!"READ?: Realiza la lectura del Display principal.
!"READ2?: Realiza la lectura del Display secundario.
!"EVERY / STOP: Realiza la lectura del Display hasta recibir lo comando STOP.
!"*RST: Reinicia el Multímetro.
5.1.2) Comandos del Display Principal
Estas órdenes predisponen el Display para realizar distintos tipos de medidas Cuando
utilizados estos comandos pone Principal en para.
!"VDC [<string>]:
!"VAC [<string>]:
!"VACDC [<string>]:
!"IDC [<string>]:
!"IAC [<string>]:
!"IACDC [<string>]:
!"OHMS [<string>]:
!"CONT
!"DIODE
!"CAP
!"FREQ
21
!"AUTO / MAN
5.1.3) Comandos de la medida dual.
!"VDC2
!"VAC2
!"IDC2 [<string>]:
!"IAC2 [<string>]:
!"FREQ2
5.1.4) Comandos del First Level Modifier.
!"NULL / NULLOFF: Anula el Display principal, y pasa para el manual, hasta
recibir el comando NULLOFF
!"HOLD / HOLD OFF: Mantiene el Display principal con lo ultimo resultado.
!"DB / DBOFF [<string>]: Pone el Display principal para mostrar lo valor en db.
5.2
Manejo de la Programmable Power Supply HM8142 (Fuente de
Alimentación Programable).
Para el manejo del Fuente de alimentación son enviados los comandos a través
de la funcione send. Los comandos mas utilizados son mostrados de abajo,
respectivamente con sus funciones:
!"RM1/RMO: Remote on/off
!"LK1/LKO: Local on/off
22
!"SU1: Set voltage 1
!"SU2: Set voltage 2
!"SI1: Set corrent 1
!"SI2: Set corrent 2
!"RU1: Recall voltage 1 (hace la lectura de la tensión de la salida)
!"RU2: Recall voltaje 2 (hace la lectura de la tensión de la salida)
!"RI1: Recall current 1 (hace la lectura de la corriente de la salida)
!"RI2: Recall current 2 (hace la lectura de la corriente de la salida)
!"MU1: Measure voltaje 1 (hace la lectura de la tensión del Display)
!"MU2: Measure voltaje 2 (hace la lectura de la tensión del Display)
!"MI1: Measure current 1 (hace la lectura de la corriente del Display)
!"MI2: Measure current 2 (hace la lectura de la corriente del Display)
!"MX1/MXO: Mixed Mode on/off (Modo mixto del comando)
!"OP1/OPO: Output on/off
!"TRU: Track Voltage (envía la misma tensión para las dos salidas)
!"TRI: Track Current (envía la misma corriente para las dos salidas)
!"SR1/SRO: Sevice request on/off
!"ABT / ABX: Arbitrary Wave Forme (Mode/Exit)
!"RUN / STOP: Arbitrary on/off
!"VER: Get Version
!"ID?: Get Identifier
!"STA: Get Status - Utilizando lo comando STA, tendrás una respuesta con la
situación de los comandos: OP1/O SQ1/O ERO/1 CV1/CC1 CV2/CC2 RMO/1
23
6- Diseño de paneles o interfaces de usuario para control de
instrumentos GPIB.
Como ha sido visto, para hacer los diseños de paneles o interfaces de usuario
para control de instrumentos GPIB, son utilizados varias herramientas de control, tais
como BASIC (Visual o Quik-), Pascal o Delph y otras herramientas mas, pero
utilizando los mismos pasos. En este trabajo estos diseño de paneles, ha sido
desarrollado con la herramienta de diseño Test Point, y la herramienta de programación
C++.
6.1
Diseño de paneles o interfaces utilizando el Test Point.
Con el Test Point, los datos del GPIB son enviados e recibidos, respectivamente
a través de los comandos que se adjuntan en la siguiente figura 6.1:
Fig. 6.1. Funciones
Estos comandos realizan las siguientes funciones:
!"Output to : Envia el comando (with) al GPIB
!"Enter From : Recebe el dato enviado por el GPIB
!"Trigger
!"Clear: Borra las operaciones, y reinicia el instrumento.
!"Serial Poll
!"Parallel Poll
!"Local
!"Transmit GPIB commands
24
6.1.1 Diseño del panel para control del Multímetro
Cuando la llave on esta encendida el programa empieza a trabajar, luego a partir
del comando generales el programa realiza sus funciones. Como muestra la figura 6.2 el
comando generales está en READ?, consecuentemente la pantalla read muestra el valor
de la lectura de la pantalla principal del Multímetro, y el grafico muestra el valor
temporal de esta medida. Como anteriormente se tendría hecho una lectura con read2?,
el valor de este se mantuvo en la pantalla.
Fig. 6.2. Panel para control del Multímetro.
6.1.2 Diseño del panel para control de la Fuente de Alimentación
Programable.
Inicialmente el usuario tendrá que elegir el comando que será enviado al
instrumento. En el sitio “Valor”, ira poner el valor de la tensión o corriente que desea
enviar. Al clicar la tecla enter el valor será echado al instrumento. Utilizando la tecla
“send”, el usuario tambiem echará los datos, y además, estará realizando una lectura de
todas pantallas del instrumento.
25
Fig. 6.3. Panel para control de la Fuente de alimentación.
6.2
Diseño de paneles o
programación C++.
interfaces utilizando herramienta de
El C++ contiene varias modificaciones menores sobre el C original. Normalmente se
trata de aumentar la capacidad del lenguaje y la facilidad de programación en un
conjunto de detalles concretos basados en la experiencia de muchos años. En cualquier
caso, se trata de modificaciones que facilitan el uso del lenguaje, pero que no cambian
su naturaleza.
Hay que indicar que el C++ mantiene compatibilidad casi completa con C, de forma
que el viejo estilo de hacer las cosas en C es también permitido en C++, aunque éste
disponga de una mejor forma de realizar esas tareas.
Esta herramienta de programación, foie utilizada, en esto trabajo, para el desarrollo
de programas para, testes, medidas, adquisición e aplicación de datos, incluyendo
principalmente lo programa para el control del Multímetro TTi.
26
Para hacer el programa, debe-se inicialmente adicionar la libraría “ieee-c.h” y en
seguida adicionar lo comando:
#include "ieee-c.h"
Cuándo compilar su programa, necesitará proporcionar la biblioteca
dependiendo de su sistema operativo:
!"
!"
!"
DOS, use:
16-bit con windows, use:
32-bit con windws, use:
!"
16-bit OS/2, use:
apropiada,
IEE488.LIB
WIN488.LIB
IEEE_32M.LIB(Para Microsft),
ou IEEE_32M.LIB(para Borland)
IEEEOS2.LIB
Con el C++, utilizando Initialize, send, and Enter juntos produce un programa completo
para obtener los datos de un dispositivo:
initialize(my.address,level);
!"
!"my.address: De 1 a 30, dar la dirección de GPIB para ser usada por su
board. Esta dirección debe ser diferente de la dirección de todos dispositivos
conectados en lo ordenador.
!"level: Cuando cero especifica la tarjeta como controlador del equipo, e 2
para especificar que la tarjeta GPIB, es uno dispositivo.
Como ejemplo de la función initialize:
initialize(0,0);
send(address,"info",&status);
!"
!"address: Es una cadena que contén los dados recibidos
!"info: Especifica el valor del máximo número del caracteres que usted desea
recibir.
!"status: indica si la transferencia fue buena (0=ok, 8=timeout).
Como ejemplo de la función send:
send(1,"READ?",&status);
send(1,"HOLD",&status);
send(1,"EVERY",&status);
send(1,"*IDN?",&status);
27
enter(recv,maxlength,length,address,&status);
!"
!"recv: Es una cadena que contén los dados recibidos
!"maxlength: Especifica el valor del máximo número del caracteres que usted
desea recibir.
!"Length: Contendrá el número verdadero de caracteres recibidos
!"Address: Dirección de lo GPIB.
!"Status: indica si la transferencia fue buena (0=ok, 8=timeout).
Como ejemplo de la función enter:
enter(r,80,&l,1,&status);
6.2.1
Diseño del panel para control del Multímetro
Ha sido desarrollado un panel para el controle del Multímetro a través del GPIB.
Los comandos básicos del Multímetro fueran puestos en este painel bajo la
programación en C++. La pantalla principal fue extraída cuando el Multímetro se
encontraba en la dirección 10, con una medida de 0.01 mV DC en la pantalla principal,
y 22.20 mV AC en la pantalla secundaria.
Fig. 6.4. Funciones
28
El programa código fuente del Multímetro se muestra a continuación:
#include <vcl\vcl.h>
#pragma hdrstop
#include "uni_mul.h"
#include "ieee-c.h"
//--------------------------------------------------------------------------#pragma resource "*.dfm"
TMultimetro *Multimetro;
//--------------------------------------------------------------------------__fastcall TMultimetro::TMultimetro(TComponent* Owner)
: TForm(Owner)
{
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::InitializeClick(TObject *Sender)
{
initialize(0,0);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::identidadClick(TObject *Sender)
{
STOP->Checked = true;
29
send(i,"*IDN?",&status);
enter(r,80,&l,i,&status);
MAIN->Text = r;
secund->Text = r;
}
//---------------------------------------------------------------------------
void __fastcall TMultimetro::PrincipaleChange(TObject *Sender)
{
STOP->Checked = true;
AnsiString comandoA;
comandoA = Principale->Text;
send(1,comandoA.c_str(),&status); // convierte el contenido de comando a char
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::secChange(TObject *Sender)
{
STOP->Checked = true;
AnsiString comandoB;
comandoB = Principale->Text;
send(1,comandoB.c_str(),&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::READClick(TObject *Sender)
30
{
send(1,"READ?",&status);
enter(r,80,&l,1,&status);
MAIN->Text = r;
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::READ2Click(TObject *Sender)
{
send(1,"READ2?",&status);
enter(r,80,&l,1,&status);
secund->Text = r;
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::ResetClick(TObject *Sender)
{
send(1,"*RST",&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::ONClick(TObject *Sender)
{
send(1,"HOLD",&status);
}
//---------------------------------------------------------------------------
31
void __fastcall TMultimetro::OFFClick(TObject *Sender)
{
send(1,"HOLDOFF",&status);
}
//--- ------------------------------------------------------------------------
void __fastcall TMultimetro::NULLOFFClick(TObject *Sender)
{
send(1,"NULLOFF",&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::NULLONClick(TObject *Sender)
{
send(1,"NULL",&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::STOPClick(TObject *Sender)
{
Timerevery->Enabled = false;
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::EVERYClick(TObject *Sender)
{
Timerevery->Enabled = true;
}
32
//---------------------------------------------------------------------------
void __fastcall TMultimetro::TimereveryTimer(TObject *Sender)
{
send(1,"READ?",&status);
enter(r,80,&l,1,&status);
MAIN->Text = r;
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::DbClick(TObject *Sender)
{
send(1,"DB",&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::DBOFFClick(TObject *Sender)
{
send(1,"DBOFF",&status);
}
//--------------------------------------------------------------------------void __fastcall TMultimetro::DirChange(TObject *Sender)
{
i = StrToFloat(Dir->Text);
}
//--------------------------------------------------------------------------//---------------------------------------------------------------------------
33
#ifndef uni_mulH
#define uni_mulH
//--------------------------------------------------------------------------#include <vcl\Classes.hpp>
#include <vcl\Controls.hpp>
#include <vcl\StdCtrls.hpp>
#include <vcl\Forms.hpp>
#include <vcl\ExtCtrls.hpp>
//--------------------------------------------------------------------------class TMultimetro : public TForm
{
__published: // IDE-managed Components
TButton *Initialize;
TEdit *MAIN;
TButton *identidad;
TEdit *secund;
TComboBox *Principale;
TComboBox *sec;
TButton *READ;
TButton *READ2;
TButton *Reset;
TRadioButton *ON;
TRadioButton *OFF;
TGroupBox *HOLD;
TRadioButton *NULLOFF;
34
TRadioButton *NULLON;
TRadioButton *EVERY;
TRadioButton *STOP;
TGroupBox *EVERY1;
TTimer *Timerevery;
TLabel *Label1;
TLabel *Label2;
TLabel *Label3;
TLabel *Label4;
TGroupBox *GroupBox1;
TRadioButton *Db;
TRadioButton *DBOFF;
TEdit *Dir;
void __fastcall InitializeClick(TObject *Sender);
void __fastcall identidadClick(TObject *Sender);
void __fastcall PrincipaleChange(TObject *Sender);
void __fastcall secChange(TObject *Sender);
void __fastcall READClick(TObject *Sender);
void __fastcall READ2Click(TObject *Sender);
void __fastcall ResetClick(TObject *Sender);
void __fastcall ONClick(TObject *Sender);
void __fastcall OFFClick(TObject *Sender);
void __fastcall NULLOFFClick(TObject *Sender);
void __fastcall NULLONClick(TObject *Sender);
void __fastcall EVERYClick(TObject *Sender);
35
void __fastcall STOPClick(TObject *Sender);
void __fastcall TimereveryTimer(TObject *Sender);
void __fastcall DbClick(TObject *Sender);
void __fastcall DBOFFClick(TObject *Sender);
void __fastcall DirChange(TObject *Sender);
private:
// User declarations
int status,l,i;
char r[80];
public:
// User declarations
__fastcall TMultimetro(TComponent* Owner);
};
//--------------------------------------------------------------------------extern TMultimetro *Multimetro;
//--------------------------------------------------------------------------#endif
36
6.2.2
Diseño del panel del Rastreador de Bus
El Rastreador de Bus, ira hacer una busca en todas las direcciones, y grabar en lo
“direbox”, las direcciones de los instrumentos que eston en el bus. En la caja Dir,
muestra la dirección, y la caja Dispositivo muestra el dispositivo de la dirección. La
figura muestra el painel principal del Rastreador del Bus, en lo momento que la
dirección 10 estaba conectado el Multímetro Tti.
Fig. 6.5. Rastreador de Bus.
El programa código fuente del Rastreador de bus se muestra a continuación:
//-------------------------------------------------------------------------------------------------------
include <vcl\vcl.h>
#pragma hdrstop
37
#include "rasbus.h"
#include "ieee-c.h"
//--------------------------------------------------------------------------#pragma resource "*.dfm"
TBus *Bus;
//--------------------------------------------------------------------------__fastcall TBus::TBus(TComponent* Owner)
: TForm(Owner)
{
}
//--------------------------------------------------------------------------void __fastcall TBus::DirecionClick(TObject *Sender)
{
i=0;
Timerdo->Enabled = true;
ShowMessage("Aguarde");
}
//--------------------------------------------------------------------------void __fastcall TBus::initializeClick(TObject *Sender)
{
initialize(0,0);
}
//--------------------------------------------------------------------------void __fastcall TBus::TimerdoTimer(TObject *Sender)
38
{
if (i < 31)
{ send(i,"*IDN?",&status);
if (status == 0)
{ enter(r,80,&l,i,&status);
direciones->Text = i;
disp->Text = r;
direbox->Items->Add(i);
}
else
{ direciones->Text = i;
disp->Text = "Sin Dispositivo";
}
i+=1;
}
else
{ Timerdo->Enabled = false;
ShowMessage("Fim");
}
}
//--------------------------------------------------------------------------void __fastcall TBus::direboxChange(TObject *Sender)
{
39
AnsiString a;
a=direbox->Text;
direciones->Text = a;
}
//---------------------------------------------------------------------------
void __fastcall TBus::FimClick(TObject *Sender)
{
Timerdo->Enabled = false;
ShowMessage("Fim");
}
//--------------------------------------------------------------------------//--------------------------------------------------------------------------#ifndef rasbusH
#define rasbusH
//--------------------------------------------------------------------------#include <vcl\Classes.hpp>
#include <vcl\Controls.hpp>
#include <vcl\StdCtrls.hpp>
#include <vcl\Forms.hpp>
#include <vcl\ExtCtrls.hpp>
//--------------------------------------------------------------------------class TBus : public TForm
{
__published: // IDE-managed Components
40
TEdit *direciones;
TButton *Direcion;
TTimer *Timerdo;
TButton *initialize;
TEdit *disp;
TLabel *Dir;
TLabel *Dispositivo;
TComboBox *direbox;
TButton *Fim;
void __fastcall DirecionClick(TObject *Sender);
void __fastcall initializeClick(TObject *Sender);
void __fastcall TimerdoTimer(TObject *Sender);
void __fastcall direboxChange(TObject *Sender);
void __fastcall FimClick(TObject *Sender);
private:
// User declarations
int status,i,l;
char r[80], buf[50];
public:
// User declarations
__fastcall TBus(TComponent* Owner);
};
//--------------------------------------------------------------------------extern TBus *Bus;
//--------------------------------------------------------------------------#endif
41
7.- Conclusiones
Con el desarrollo del trabajo se concluye que el procesado digital de señal es la
solución apropiada a todos los problemas de procesado de señal. Los circuitos digitales
no solo dan lugar a sistemas para el procesado de señales más baratos y fiables sino que
también tienen otras ventajas. En particular, el procesado de señal digital permite
operaciones programables. Por medio de software se pueden modificar fácilmente las
funciones de procesado de señal para que sean realizadas por el hardware. Por tanto, el
hardware digital y el software asociado proporcionan un mayor grado de flexibilidad en
el diseño de sistemas. Pero, para muchas señales de gran ancho de banda, se requiere
procesado en tiempo real. Para tales señales, el procesado analógico o quizás, óptico,
son las únicas soluciones validas.
Los equipos de Instrumentación Electrónica Virtual han permitido diseñar
interfaces a medida, definidas por el usuario y orientadas a la aplicación de media o
control para la que se conciben. Teniendo en cuenta que para hacer los diseños de
paneles o interfaces de usuario para control de instrumentos, son utilizados varias
herramientas de control, tais como BASIC (Visual o Quik-), Pascal o Delph y otras
herramientas mas, aún que en este trabajo los diseño de paneles, han sido desarrollado
con la herramienta Test Point, y la herramienta de programación C++. El bus interfaz de
propósito general (GPIB; General Purpose Interface Bus) y su protocolo de
comunicaciones asociado se han convertido en elementos integradores de la unidad de
instrumentación virtual y los instrumentos tradicionales de banco, originando las redes
de instrumentación electrónica. La gran ventaja es que estos equipos integrados en red
cumplen características esenciales de un equipo de medida, como la posibilidad de
control remoto, aceptación de la transferencia de datos que permita fiabilidad en la
operación, y capacidad de operación en tiempo real.
Con el desarrollo del trabajo observase también, que el usuario de
Instrumentación Electrónica Virtual es permitido diseñar interfaces definidas por el,
pero debe atentar a varios problemas que pueden pasar con el proyecto. Por ejemplo, la
elección apropiada de la velocidad de muestreo y la precisión del proceso de
cuantificación al tempo de controle de timeout, para solicitud del srq. Pues puede
haber un grave conflicto de informaciones en el Bus. Además para hacer el programa en
C++, el usuario debe inicialmente adicionar las librerías adecuadas en el programa.
Concluye entonces, que es indispensables la utilización del manual del usuario de los
programas inclusos en este trabajo, de los instrumentos y del GPIB.
42
8.- Referencias Bibliográficas
[1] Keithley Instruments Inc. IEEE-488 Interface Boards. User´s Manual. Cleveland,
Ohio, EE.UU, 2002.
[2] E. Mandado, P. Mariño, y A. Lago. Instrumentación Electrónica. Marcombo,
Boixareu Editores, Barcelona, 1995.
[3] R. Pallás Areny. Instrumentación Electrónica Básica. Marcombo, Boixareu
Editores, Barcelona, 1987.
[4] R. Pallás Areny. Adquisición y Distribución de Señales. Marcombo, Boixareu
Editores, Barcelona, 1993.
[5] S. Wolf. y R.F.M. Smith. Guía para Mediciones Electrónicas y Prácticas de
Laboratorio. Edición ampliada y actualizada. Prentice-Hall Hispanoamericana. México,
etc, 1992.
[6] John G.Proakis, Dimitris G. Manolakis Tratamiento digital de señales : [principios,
algoritmos y aplicaciones] /
43