PDF de programación - GPIB2_05 - III MODELO OPERATIVO DE LOS EQUIPOS

a) Cuando los equipos están dispuestos a escuchar o a hablar a lo otros equipos.

III MODELO OPERATIVO DE LOS EQUIPOS (IEEE-448.2)

III.1 PROTOCOLOS.

El estándar IEEE-488.2 define los modos de operación básicos de los equipos que lo
satisfacen. Define los protocolos de intercambio de mensajes con el que el equipo y el
controlador se comunican, así como, facilidades básicas de control del instrumento.
Define:



Los equipos que satisfacen los modos operativos definidos en el estándar IEEE-488.2.,
necesariamente satisfacen los niveles de comunicación físicos definidos en el estándar
IEEE-488.1. La implicación inversa no es requerida.

El modelo de intercambio de un equipo que satisface el estándar IEEE-488.2, incluye a los
siguientes componentes:


b) Que ocurre cuando no se cumplen las normas establecidas en el protocolo.

Equipo

Firmware

(Software de control del equipo)

Parser

Buffer salida

Buffer entrada
IEEE 488.2

IEEE 488.1


Buffer de entrada: Es el área de memoria en la que las ordenes y requerimientos de
entrada son almacenadas, antes de que sean interpretadas y ejecutadas por el
Parser. El buffer de entrada, permite que el equipo controlador del instrumento,
almacene en el buffer un string conteniendo una o varias ordenes que llevan un
cierto tiempo ser ejecutada, y mientras esto ocurre pueda realizar otras operaciones
con otros equipo.


Buffer de salida: Es el área de memoria en el que los datos de salida (mensajes de salida)

son almacenadas en espera de que el controlador decida leerlas.


Parser: Es el controlador interno del equipo que interpreta los mensajes completos
almacenados en el buffer de entrada, los ejecuta, y en caso de que sean de
requerimiento, deposita en la cola de salida los datos que resulten.



17

Protocolo básico

- El equipo y el controlador se comunican intercambiando mensajes de ordenes y

mensajes de respuesta.


- Los mensajes de órdenes son enviados por el controlador, y pueden ser de dos tipos:


Ordenes de control: Que requieren un cambio de estado del equipo, pero que no

requieren ninguna respuesta.


Ordenes de requerimiento: Que solicitan información sobre el estado del equipo o

sobre información que posee.



- El equipo solo habla (envía un mensaje de salida) como respuesta de una orden de

requerimiento.


- El controlador solo admite un mensaje de salida (respuesta de una orden de
requerimiento), y lo requiere antes de enviar un nuevo mensaje de ordenes. En caso
contrario se genera una situación de bloqueo.


- La regla básica del protocolo es:

"El equipo solo habla cuando está dispuesto a ello, y en ese caso, tiene que hablar
antes de que se le ordene hacer una cosa nueva"

- Cuando el equipo es encendido, o cuando recibe una orden de inicialización "*CLS"
el buffer de entrada y de salida son inicializada, y el parser es inicializado a la raíz de
su árbol de ordenes.


- El equipo y el controlador se comunican intercambiando mensajes de ordenes y de
respuestas completos. Esto significa que el controlador siempre debe terminar un
mensaje de órdenes, antes de intentar leer una respuesta.


- Si el equipo envía un mensaje de respuesta, el controlador debe siempre leer de
forma completa el mensaje, antes de que envíe un nuevo mensaje de ordenes al
equipo.


- El controlador puede enviar un mensaje conteniendo múltiples ordenes de
requerimientos. A esto se le denomina un "requerimiento compuesto". Los diferentes
requerimientos dentro del mensaje deben estar separados por el delimitador ";". Los
mensajes de respuesta son encolados en la cola de salida, separados entre sí también,
por el delimitador ";".


- Los comandos son ejecutados en el orden en que han sido recibidos.

18

Protocolos de excepción:

Cuando un error ocurre en el intercambio de la información, este no termina en la forma
normal, sino que sigue un protocolo de excepción:

a) Equipo direccionado para hablar sin nada en la cola:

-

Si es consecuencia de que el equipo no haya recibido una orden de requerimiento,
el equipo indicará un error de encolamiento, y no enviará ningún byte por el bus.
Si es como consecuencia de que la orden de requerimiento previa no se ejecutó
como consecuencia de un error, el equipo no indica ningún error de encolamiento,
sino que el equipo espera a recibir el siguiente mensaje del controlador.


b) Equipo direccionado para hablar sin que ningún equipo escuche: En este caso, el
equipo esperará o bien a que algún equipo escuche, o a que el controlador tome el
control.


c) Error de orden: Se genera cuando se detecta un fallo de sintaxis o una orden no

-

reconocible.


d) Error de ejecución: Se genera si un parámetro está fuera de rango, o si el equipo se

encuentra en un estado que no permita la ejecución del comando requerido.


e) Error específico del equipo: Se produce cuando el equipo es incapaz de ejecutar una
orden, como consecuencia de una razón estrictamente dependiente de él, y no del
protocolo seguido por el bus.


f) Error de encolamiento: Se genera si no se sigue el protocolo de lectura de los datos

de la cola de salida.


g) Condición inconclusa: Si el controlador intenta leer un mensaje de respuesta antes de
que el programa haya concluido de ejecutar la orden que los genera. En este caso el
Parser, se inicializa a si mismo, la respuesta ya elaborada es limpiada de la cola de
salida, y ningún dato es transferido por el bus.


h) Condición interrumpida: Si el controlador no lee completamente el mensaje
generado por un mensaje de requerimiento, y envía otro mensaje de orden, el equipo
genera un error de encolamiento, y el segmento de mensaje de salida no leído es
eliminado. La orden que interrumpe es inafectada.


i) Bloqueo de buffer: El equipo alcanza un estado de bloqueo si el buffer de entrada,
está lleno y también resulta llena la cola e salida. Esta situación ocurre si un mensaje
de orden muy largo que contiene órdenes de requerimiento ha sido enviado, y genera
un mensaje de salida superior al que puede contener la cola. El controlador no puede
terminar de enviar el mensaje de entrada porque no cabe, y el buffer de entrada no se
vacía porque espera que su cola de salida sea vaciada para concluir la orden en
ejecución. En este caso el equipo rompe el bloqueo, limpiando la cola de salida y
generando un error de encolamiento.



19

III.2 Estatus de un equipo por el protocolo IEEE 488.2.

El estándar IEEE 488.2 ofrece un mecanismo estandarizado de presentar y mostrar el
estado interno del equipo. A través de este mecanismo, se puede tener información de si el
equipo tiene un dato dispuesto para transferir, así como si algún tipo de error ha ocurrido.

Power On
Unit Request
Command Error
Execution Error
Device Dependent
Query Error
Request Control
Operation Complete

PON URQ CME EXE DDE QYE RQC OPC
0

7

4

6

5

3

2

1

PON URQ CME EXE DDE QYE RQC OPC

Logical OR

(ESR) Standard Event Status Register
Read by *ESR?
(ESER) Standard Event Status Enable
Register
Read by *ESE? Set by *ESE

Data available on instrument
Ready to be sent across the bus.

xxxxxxx
xxxxxxx

Output Queue

bit 7

-

-

RQS
MSS

ESB MAV

ESB MAV

-

-

-

-

-

-

bit 0

-

-

(SBR) Status Byte Register
Read by *STB

(SRER) Service Request Enable Register
Read by *SRE? Set by *SRE

Logical OR

Status registers


El mecanismo se basa en cuatro registros:

Status Byte Register (SBR): Cada bit está asociado con un tipo de estado específico del
instrumento. Cuando el estado cambia, el instrumento establece el correspondiente bit a 1.
Se puede habilitar e inhibir el efecto de cada bit del SBR a efectos de requerir atención (bit
RQS), con el correspondiente bit del registro SRER. Se puede determinar que eventos han
ocurrido leyendo los establecidos en el registro SBR.



20

Instrument-specific summary messages.

Bit Label Description
0-3 -
4 MAV The Message Available bit indicates if data is available in the
Output Queue. MAV is 1 if the Output Queue contains data.
MAV is 0 if the OutputQueue is empty.

5 ESB The Event Status Bit indicates if one or more enabled events
Have occurred. ESB is 1 if an enabled event occurs. ESB is
0 if no enabled events occur. You enable events with the
Standar Event Status Enabled Register.

6 MSS The Master Sumary Status sunarizes the ESB and MAV bits.
MSS is 1 if either MAV or ESB is 1. MSS is 0 if both MAV
and ESB are 0. This bits are obtained from *STB? Command.



RQS The ReQuest Service bit indicates that the instruments

requests service from the GPIB controller. This bits is obtained
by from a serial poll.
Instrument specific summary message.

7

-



Service Request Enable Register (SRER): Máscara de los bits correspondientes del
registro SBR que va a determinar si se establece el Request Service (bit RQS).

Event Status Register (ESR): Cada bit está asociado con un tipo específico de evento.
Cuando un evento ocurre, el instrumento establece el correspondiente bit a 1. Se puede
habilitar o inhibir los eventos que van a ser proyectados sobre el bit ESB, a través de los
correspondientes bits de máscara de registro ESER. Se puede leer el evento que ha
ocurrido leyendo el contenido d