Вы находитесь на странице: 1из 88

UNIVERSIDAD SIMÓN BOLIÍVAR

INGENIERÍA ELECTRÓNICA

PROTOCOLO DE COMUNICACION HART


Para los instrumentos de FLOTECH S.A.

POR
Erika Febres Urdaneta

Proyecto de Pasantía
Presentado ante la Ilustre Universidad Simón Bolívar
Como requisito Parcial para Optar al Titulo de
Ingeniero Electrónico

Sartenejas, Febrero 2001

i
PROTOCOLO DE COMUNICACION HART
Para los instrumentos de FLOTECH S.A.
por
Erika Febres Urdaneta
Tutor Académico: Guillermo Villegas.
Tutor Industrial: Gerardo Febres.

RESUMEN

El actual proceso de digitalización de la información hace necesaria la existencia de equipos de


campo para industrias que sean capaces de transmitir y recibir datos. En la era analógica una de las
opciones eran lazos de corriente de 4 – 20 mA que indicaban el valor de la única variable que era
posible transmitir. Pero en la actualidad se hace indispensable la comunicación digital; para ello
Fisher Rosemount ideó el protocolo HART, que no solo permite la comunicación de los dispositivos
de modo digital, sino también utiliza la instalación de cables de la antigua configuración. Este
protocolo se basa en la transmisión de una señal de corrimiento en frecuencia de 1200Hz y 2200Hz,
superpuesta en la señal analógica, que viaja del maestro hacia el esclavo y viceversa mediante una
estructura de mensajes digitales estándar, lo que permite interconectar equipos de diversos fabricantes
a un mismo dispositivo maestro.

La empresa Flotech S.A., fabricante de equipos medidores de flujo y de nivel desea


implementar el protocolo de comunicación Hart. Para poder implementar ésta capacidad a sus
equipos, es necesario el diseño de un módulo de digital que se conecte al módulo analógico (sensor).
Este módulo consta de una parte física (hardware) y de una parte no tangible (software), que se
integran al utilizar el microcontrolador TIGER de Wilke Technologies (firmware). En este
microcontrolador se almacenan todos los datos que el protocolo Hart requiere, además de ser utilizado
para controlar el módem, el generador del lazo de corriente, el conversor analógico digital y múltiples
interruptores que regulan o calibran los instrumentos. El resultado, un instrumento que se comunica a
un PC mediante un programa que genera y recibe mensajes de acuerdo al formato Hart.

ii
A mi Familia
Gabriel, Lia, Yuribé y Deborah
Mi hermano Pedro Rondón

iii
AGRADECIMIENTOS
A mi Tutor Académico Guillermo Villegas, por sus enseñanzas y diferentes propuestas de
solución a mis problemas, no solo durante la pasantía, sino a lo largo de mis años de estudios.

A mi Padre Gabriel Febres, por el apoyo y ayuda en el diseño del circuito e implementación
del proyecto en todo momento, a pesar de la distancia.

A mi familia en general, por darme fuerzas para culminar mis estudios y el proyecto de
pasantía, al recordarme cada día que debía esforzarme y concentrarme en mi trabajo, obviando todo
aquello ajeno a éste.

A mi hermano Pedro, ya que sin él no lo hubiese logrado. Por todo su ingenio, del cual durante
años e aprendido miles de cosas útiles al momento de diseñar y ensamblar tanto programas como
circuitos.

A mi novio Jonathan Bartolotta, por toda su ayuda cuando el programa no quería funcionar, el
apoyo moral en las noches sin fin y su cariño siempre presente.

iv
INDICE GENERAL

CAPITULO 1.- INTRODUCCIÓN……………………………………………...1

1.1.-Objetivo general…………………………………………………………………2

1.2.-Objetivos específicos…………………………………………………………..2

1.3.- Descripción de los capítulos…………………………………………………3

CAPITULO 2.- PROTOCOLO HART…………………………………………5

2.1- Breve introducción al protocolo Hart………………………………………..5

2.1.1.- ¿Qué es un dispositivo inteligente?………………………………….5

2.1.2.- Leyendo información mediante comunicación digital………………7

2.1.3.- Comunicación multipunto……………………………………………..7

2.1.4.- El protocolo Hart……………………………………………………….8

2.1.5.- Los comandos del protocolo Hart…………………………………….10

2.2- La señal física……………………...…………………………………………….10

2.2.1.- Codificación por desplazamiento en frecuencia……………………11

2.2.2.- Los niveles de la señal………………………………………………...11

2.2.3.- El lazo de conexión…………………………………………………….12

2.2.4.- Conexión de múltiples dispositivos…………………………………..13

v
2.3- Procedimiento de transacciones, código y estructura del mensaje…...13

2.3.1.- Procedimiento de transacción………………………………………..14

2.3.2.- El modo de ráfagas (BURST Mode)…………………………………14

2.3.3.- Codificación de caracteres……………………………………………15

2.3.4.- Formato de mensaje…………………………………………………..15

2.3.5.- Ejemplo de transacciones………………………………………….…19

2.4- Comandos y datos respectivos, bytes de estado…………………………22

2.4.1.- Comandos universales………………………………………………..22

2.4.2.- Comandos de practica común………………………………………..24

2.4.3.- Comandos específicos de dispositivo……………………………….25

2.4.4.- Elementos enumerados……………………………………………….25

2.4.5.- Bytes de estado………………………………………………………..26

CAPITULO 3.- DESCRIPCIÓN DEL SISTEMA……………………………..28

3.1- ¿ Cómo diseñar e implementar el protocolo HART?……………………..28

3.2- Hardware, materiales y fabricación………………………………………….29

3.2.1.- Microcontrolador ………………………………………………………30

3.2.2.- Desarrollo de la tarjeta digital ………………………………………..33

3.2.3.- El Módem Hart ……………………..………………………………….36

3.2.4.- Descripción del modulador HT2012………………………………….39

vi
3.3.- Programas del microcontrolador ( firmware)……………………………..42

3.3.1.- Recepción y Análisis de Datos……………………………………….43

3.3.2.- Respuesta al Comando……………………………………………….44

3.3.3- Transformación de valores…………………………………………….45

3.3.4- Codificación o compresión de caracteres……………………………45

3.3.5- Conversión Analógico a Digital………………………………………..45

3.4.- Programa para el maestro o interfaz para el usuario…………………….47

CAPITULO 4.- PRUEBAS Y RESULTADOS………………………………..52

4.1.- Tarjeta digital…………………………………………………………………….52

4.2.- Interfaz para el usuario ………………………………………………………..53

4.3- Sistema interconectado……………..…………………………………………56

CAPITULO 5.- CONCLUSIONES Y RECOMENDACIONES………………59

5.1.- Conclusiones……………………………………………………………………59

5.2.- Recomendaciones……………………………………………………………...60

REFERENCIAS BIBLIOGRÁFICAS………………………………………….61

ANEXOS…………………………………………………………………………62

vii
INDICE DE FIGURAS

Figura 1.1 Sistema de comunicación mediante protocolo Hart……………………………………….2

Figura 2.1 Conexión punto a punto……………………………………………………………….…...6

Figura 2.2 Conexión multipunto……………………………………………………………………….8

Figura 2.3 La señal HART……………………………………………………………………………9

Figura 2.4 Estructura del mensaje HART……………………………………………………………10

Figura 2.5 Lazo de conexión simple…………………………………………………………………12

Figura 2.6 Cadena de bits de caracteres……………………………………………………………...15

Figura 2.7 Formato de los mensajes Hart…………………………………………………………….15

Figura 2.8 Estructura del formato corto………………………………………………………………17

Figura 2.9 Estructura del formato largo……………………………………………………………...18

Figura 2.10 Transacción en formato corto…………………………………………………………...20

Figura 2.11 Transacción en formato largo……………………………………………………………21

Figura 3.1 Diagrama del sistema a realizar…………………………………………………………..28

Figura 3.2 Diagrama de la tarjeta digital……………………………………………………………..30

Figura 3.3 Microcontrolador TIGRE…………………………………………………………………30

Figura 3.4 Bloque interno del LTC1298……………………………………………………………..34

Figura 3.5 Conexión del generador del lazo de corriente AD694……………………………………35

Figura 3.6 Elementos de la tarjeta impresa del circuito digital………………………………………36

Figura 3.7 Circuito completo del Módem Hart………………………………………………………37

Figura 3.8 Filtro de Entrada del Módem……………………………………………………………..38


viii
Figura 3.9 Filtro de Salida del Módem……………………………………………………………….38

Figura 3.10 Reloj del módem………………………………………………………………………...39

Figura 3.11 Módem Hart HT2012……………………………………..……….………………….…40

Figura 3.12 Primeros circuitos impresos para el módem……………….……………………………41

Figura 3.13 Conexión del módem Hart a la tarjeta digital…………………………………………...41

Figura 3.14 Estructura del firmware………………………………………………………………….42

Figura 3.15 Interfaz gráfica del programa maestro…………………………………………………..48

Figura 4.1 Tarjeta digital con todos sus elementos………………………………………………..…52

Figura 4.2 Interfaz gráfica del maestro……………………………………………………………….53

Figura 4.3 Interfaz una vez presionado COMPONER……………………………………………….54

Figura 4.4 Interfaz después de presionar SEND……………………………………….……………..55

Figura 4.5 Interfaz con los resultados del proceso de comunicación………………………………...56

Figura 4.6 Sistema con capacidad de manejar el protocolo Hart………………...………………58

ix
INDICE DE TABLAS

Tabla 2.1 Niveles de la señal Hart…………………………………………………………………...11

Tabla 2.2 Especificaciones de tiempo en modo de ráfaga. …………………………………………..15

Tabla 2.3 Valores del byte de inicio………………………………………………………………….17

Tabla 2.4 Comandos universales……………………………………………………………………..22

Tabla 2.5 Comandos de práctica común……………………………………………………………...24

Tabla 2.6 Variables enumeradas……………………………………………………………………...26

Tabla 3.1 Especificaciones de los pines del microcontrolador………………………………….32

x
CAPITULO 1.-INTRODUCCIÓN

En las industrias con equipos de campo, como las petroleras y procesadoras, es necesaria la
lectura permanente de variables diversas de sus estanques, tuberías o máquinas para evitar pérdidas
del producto, accidentes o simplemente una falta de eficiencia en la producción. Estas mediciones en
un principio eran manuales, y se requería de un vasto personal para poder controlar toda la fabrica,
planta de producción o campo de extracción. Con el tiempo, y el desarrollo de la tecnología se
crearon sensores electrónicos que permitían la lectura de las variables de un modo más conveniente, e
incluso la transmisión de las mismas a un equipo central. Una de estas formas de comunicación es el
lazo de 4 a 20 mA, un lazo de corriente que al cual dependiendo del valor medido por el sensor, se le
asigna un nivel de corriente en mA, es decir, 4 mA equivaldría al menor valor posible de la variable
medida y 20 mA al máximo. En la actualidad, el mundo se ve afectado por la digitalización de la
información y estos procedimientos y medios de medición no se ven excluidos de la misma. Con el
tiempo se han implementado en el campo e industrias otros métodos para poder realizar las
mediciones de modo remoto, sin la necesidad de ir al campo, y que a su vez permitan la transmisión
de una información detallada del equipo y sus funciones. Una de las actuales formas de comunicar
dispositivos es mediante el protocolo Hart, ideado por Fisher Rosemount.

El protocolo HART es actualmente propiedad de la Fundación HART, y se basa en la parte


física, en una señal digital de 0’s y 1’s , modulada en codificación por desplazamiento en frecuencia
de 2200Hz y 1200Hz respectivamente, y en la parte no tangible, en un mensaje de bytes o
información estructurado de modo que pueda ser comprendido e implementado por diversos
fabricantes de equipos de medición. Este protocolo fue diseñado tomando como referencia el modelo
OSI.

La empresa Flotech S.A., es una empresa venezolana con años de funcionamiento, que presta
servicios a una de las principales extractoras de petróleo del país, PDVSA (Petróleos de Venezuela
S.A.). Siendo Flotech S.A. una empresa que pretende implementar en sus equipos todos los avances
tecnológicos posibles, y bajo petición de PDVSA, de equipos que trabajaran con el protocolo; se hace
necesaria la creación de un nuevo equipo digital con capacidad HART.

Los dispositivos de la empresa se fabricaran de modo que el sensor contenga dos tarjetas
impresas, una de ellas analógica (que no ha sido aún diseñada) y la otra digital. El diseño de la tarjeta
digital es el objetivo principal de este proyecto, sin embargo no es el único, ya que para poder realizar
pruebas e incluso para llevar acabo el proceso de diseño es necesaria una interfaz (software) para el
terminal maestro, que en este caso será un computador personal. Para ilustrar esto el sistema se
muestra en la figura 1.1.

Figura 1.1 Sistema de comunicación mediante protocolo Hart

Para poder desarrollar este proyecto se requieren conocimientos a fondo del protocolo HART
y de los materiales o equipos que la empresa pretende utilizar para la implementación de esta
capacidad de comunicación. En el siguiente libro, encontrará toda la información necesaria, además
de las diferentes actividades realizadas para llevar acabo este proyecto: Implementar el Protocolo de
Comunicación HART en los instrumentos de FLOTECH S.A.

Sección 1.1.- Objetivo general.

Realizar el diseño de la tarjeta digital y la interfaz de usuario del maestro para introducir el
protocolo de comunicación HART en los dispositivos o medidores de nivel y flujo de la empresa
venezolana Flotech S.A.

Sección 1.2.- Objetivos específicos


• Diseñar e implementar un circuito que module la señal por desplazamiento en
frecuencia que establece el protocolo Hart para ser incluido en los equipos o en el
circuito impreso digital, en su defecto, diseñar un circuito impreso que integre todos los
componentes digitales de los sensores (hardware).

• Diseñar un programa (firmware) para el microcontrolador TIGER de Wilke


Technologies, utilizado en los equipos de Flotech S.A. que se encargue de procesar los
mensajes de un dispositivo maestro mediante el uso del protocolo Hart.

2
• Diseñar un programa (software) para el maestro, en este caso un computador personal,
que se utilice en la empresa para calibrar y probar los equipos que se venderán.

Sección 1.3.- Descripción de los Capítulos


• El capítulo 2 se basa en una visión a fondo de lo que es el protocolo HART. Este se
estructura en secciones que van de descripciones generales del protocolo, como modo
de conexión, tipo de transmisión, que tipo de dispositivos pueden hacer uso del
protocolo, hasta especificaciones de la estructura de los mensajes para cada comando
que transmite el maestro, especificaciones de tiempo de retardo de las respuestas,
definición del significado de cada bit en campos de la estructura como el de dirección,
etc. La primera sección es un resumen general de las ventajas que presenta el protocolo,
y las siguientes se presentan de acuerdo al orden de las capas del modelo de referencia,
el modelo OSI. La segunda sección corresponde a la capa física, capa 1. La tercera
sección corresponde a la capa 2 del modelo OSI, la capa de enlace y finalmente la
última sección se referiría a la capa 7 del modelo OSI o la capa de aplicación, en la cual
se describe en detalle la estructura de los datos.

• El capítulo 3 describe el diseño del circuito digital, del programa del microcontrolador o
el firmware, y del programa del computador. La primera sección describe el hardware:
los circuitos integrados utilizados, el diseño del circuito modulador, el circuito
generador del lazo de corriente, el conversor análogo digital y la interconexión con el
microcontrolador y el computador personal. Luego, en la segunda sección, se menciona
las diferentes rutinas del microcontrolador o firmware, se describe el método de
desarrollo y las funciones de cada una de estas. Finalmente, la creación y el
funcionamiento de la interfaz gráfica para el terminal maestro en el PC (personal
computer ,computador personal).

• En el capítulo 4 encontrará los resultados del proyecto, una descripción general del
producto final obtenido al haber concluido el diseño y las pruebas que se realizaron para
verificar su funcionamiento. Se observa el sistema, con las conexiones pertinentes y las
respuestas que se visualizan en la interfaz del terminal maestro.

3
• El capítulo 5 incluye las conclusiones y recomendaciones, las cuales sirven para informar
al lector de mejoras futuras sobre el diseño, dado que el producto final es un prototipo y
no un diseño para producción masiva.

4
CAPITULO 2.- PROTOCOLO HART
En el siguiente capítulo encontrará toda la información necesaria, en el ámbito de diseño,
sobre el protocolo HART. En el ámbito de diseño implica que algunas de las secciones son muy
específicas.

Sección 2.1.- Instrumentos Inteligentes y el protocolo HART.


En la presente sección encontrará los conceptos principales de comunicación digital en los
dispositivos de campo, del modo implementado por Fisher-Rosemount en su familia inteligente de
transmisores utilizando el protocolo HART (Highway Addressable Remote Transducer). Se basa en
una vista general del protocolo, en que tipo de dispositivos se implementa, como mejora la lectura de
las variables de los sensores el uso de este protocolo, que tipos de conexiones pueden ser utilizadas,
que es el protocolo en sí (descripción general) y cuales son los comandos de los que se dispone al
utilizar HART.

2.1.1.-¿Qué es un dispositivo Inteligente?


El adjetivo inteligente, aplicado a un dispositivo de campo, se utiliza para describir cualquier
dispositivo que incluye un microprocesador. Típicamente esto implicaría funcionalidad extra, por
encima de lo que proveen dispositivos similares pero no basados en microprocesadores. Por ejemplo,
un transmisor inteligente puede proporcionar mayor precisión al compensar mediante cálculos la no-
linealidad, o la dependencia de temperatura de un sensor. Podría operar con una variedad de sensores
de diferentes tipos. Puede combinar dos medidas en una sola (por ejemplo volumen de flujo y
temperatura entre flujo de masa). O hasta podría permitir calibración y re-establecimiento de rangos.
Frecuentemente proveería diagnósticos internos, y pruebas automáticas, para simplificar los
procedimientos de mantenimiento. Para mayor información sobre las ventajas y aplicaciones del
protocolo refiérase al anexo 1.

Además de ofrecer un mejor rendimiento, ésta extra funcionalidad puede reducir el


procesamiento requerido por el sistema de control, y también puede resultar en la reducción de varios
instrumentos a un simple modelo, con ventajas de fabricación y manejo de inventario.

5
Para hacer uso de estas ventajas, los dispositivos inteligentes requieren de un plug-in o
configurador, una caja con una cantidad de botones y una pantalla LCD (liquid cristal display) para
que el usuario pueda instalar y controlar el instrumento.

El próximo paso por lógica sería permitir que el instrumento y el panel de configuración
estuviesen separados por largas distancias, utilizando comunicaciones digitales seriales bien definidas
entre ellos. Luego se necesitaría incluir esta comunicación en los dos cables ya existentes para
controlar el dispositivo desde el cuarto de control. Esto es lo que nos lleva al uso actual de la palabra
inteligente según Fisher Rosemount, para describir dispositivos de campo en los cuales la señal
analógica, la señal digital y la alimentación del equipo, son transmitidas por el mismo par de cables.

Con tales instrumentos, se obtienen las ventajas de las comunicaciones digitales, mientras se
mantiene la compatibilidad con la señal analógica de entrada requerida por los sistemas actuales.
Ahora, utilizando comunicación digital, además de instalar y controlar de un modo más sencillo el
dispositivo de campo, es posible leer la variable medida y muchos otros parámetros a través de
conexiones punto a punto, como la que se presenta en la figura 2.1.

Figura 2.1 Conexión punto a punto

Conexión punto a punto se utiliza para referirse a casos en los que solo existe un maestro y un
esclavo, o un transmisor y un receptor. Entre los demás parámetros que se pueden incluir, se
encuentra la posibilidad de transmitir hasta cuatro variables, lo cual representa una ventaja ante
sistemas de transmisión de una única variable, entremos más en detalle en cuanto a este aspecto.

6
2.1.2.-Leyendo información mediante comunicación digital

Al utilizar comunicación digital se vuelve posible, para un simple instrumento, proporcionar


más de una medición o una variable (por ejemplo un medidor de flujo másico tipo Coriolis puede
transmitir taza de flujo másico, temperatura del proceso, densidad y flujo total en un simple mensaje).

La comunicación digital también hace que valga la pena mantener información adicional en el
instrumento de campo, para ser leída cuando sea necesario. Esto conlleva a una serie de posibilidades.
Nos puede dar información relativa al proceso como el identificador o etiqueta del dispositivo (tag),
una descripción de la medición, las unidades asociadas y rango de calibración del instrumento. O
puede dar información sobre el dispositivo como tal, actuando como una etiqueta electrónica. Más
allá, puede ser utilizado para mantener historias de actividades relacionadas con mantenimiento como
la última fecha de calibración. La administración del sistema de instrumentos automatizados se hace
posible, utilizando información al día del dispositivo mismo.

Una manera más eficaz o eficiente de transmitir los datos sería aumentar el número de
dispositivos de campo conectados a un maestro, de modo que transite mayor información por el lazo.
Sin embargo, al conservar la medición en mA de la variable primaria, la conexión punto a punto es la
única solución , pero si se desea múltiples dispositivos se puede utilizar la conexión multipunto.

2.1.3.-Comunicación multipunto

Si una variable medida va a ser leída por comunicación digital, la señal analógica de 4-20mA
ya no es requerida. Se hace posible conectar múltiples dispositivos de campo en paralelo a un simple
par de cables, y comunicarse con cada uno por turnos para leer sus variables (u otros datos). Para
hacer esto, cada dispositivo debe tener una dirección, a la cual responderá, y cada petición del sistema
de control o maestro debe incluir dicha dirección. Un esquema de este tipo de conexión se puede
observar en la figura 2.2.

Esta conexión multipunto puede reducir de modo significativo los costos de instalación de
cableado de los equipos, y puede ser de valor en sistemas de monitoreo. Note, sin embargo, que el
tiempo entre mediciones de las variables de un mismo equipo aumentará. Ya que antes por un solo
par de cables transitaba la señal de un sensor, pero en el caso de multipunto de 2 a 15 señales
diferentes deberán turnarse el medio.

7
Figura 2.2 Conexión multipunto

2.1.4.-El protocolo HART

La aplicación de estas mejoras a la gran gama de instrumentos y dispositivos de campo


existentes, hacen que sea necesaria la implementación o definición de un estándar. Esto incluye
especificaciones desde la parte física hasta la forma de transmisión, procedimientos de transacciones,
estructura del mensaje, formato de los datos, y un conjunto de comandos que realicen dichas
funciones.

El protocolo HART fue desarrollado por Rosemount INC. Con este propósito. HART es un
acrónimo para Highway Addressable Remote Transducer. Para difundir el uso de comunicación
digital en los dispositivos de campo, Rosemount Inc. a transferido todos sus derechos sobre el
protocolo HART a la Fundación de Comunicación HART (HCF, siglas en ingles) y está disponible
para el uso de cualquier compañía o persona.

A modo de resumen, HART utiliza una señal estándar de BELL, 202 codificada por
desplazamiento en frecuencia, para comunicar a 1200 baudios, superpuesta sobre la señal de medición
de 4-20mA. Teniendo un promedio de cero, la señal codificada por desplazamiento en frecuencia no
interfiere con la señal analógica. Para ilustrar esto observe la siguiente figura 2.3.

8
Figura 2.3 La señal HART.

Hart es un protocolo maestro-esclavo (un dispositivo de campo solo responde cuando se le a


pedido algo previamente). Puede haber hasta dos maestros. Hasta 15 dispositivos esclavos se pueden
conectar en configuración multipunto.

Cada mensaje incluye las direcciones de su fuente y destino, para asegurarse de que es recibido
por el dispositivo correcto, y tiene una suma de verificación (checksum) para poder detectar cualquier
corrupción del mensaje. El estado del dispositivo de campo está incluido en cada mensaje de
respuesta, indicando su estado de operación correcto. Puede o no haber información o datos incluidos
en el mensaje, dependiendo del comando en particular. Dos o tres transacciones de mensajes se
pueden realizar cada segundo.

9
Figura 2.4 Estructura del mensaje HART

2.1.5.- Los comandos del protocolo HART:

Para llevar a cabo diferentes funciones preestablecidas en un sensor, el protocolo hart utiliza los
comandos, el identificador de la función que se pretende realizar. Los comandos del protocolo HART
se definen en tres grupos. El primer grupo es el de comandos universales, y provee funciones que
están implementadas en todos los dispositivos de campo. El segundo grupo, comandos de práctica
común, provee funciones comunes a muchos dispositivos de campo, pero no todos. Si un dispositivo
implementa funciones que estos comandos describen, deberán ser invocadas mediante el número de
comando asignado por la Fundación Hart . El tercer grupo, comandos específicos de dispositivo
(anteriormente llamados específicos de transmisor), provee funciones que son mas o menos únicas
para un dispositivo particular.

Sección 2.2.- La Señal Física.


La siguiente sección se refiere a la capa 1 del modelo de protocolos OSI, la capa física. Se basa
en el procedimiento de transacción de datos (entre los cuales existe un modo exclusivo de operación
que es el modo de ráfagas), a la estructura de los mensajes, describiendo con lujo de detalle el
contenido de cada byte. El preámbulo, el byte de inicio, el o los bytes de dirección (ya que se utilizan
dos formatos diferentes de acuerdo a las distintas revisiones de HART), el byte de comando, el byte
de cuenta de bytes (valga la redundancia), los bytes de datos, los bytes de estado y el de suma de
verificación o checksum; además de las distintas codificaciones o compresiones que se realizan para
poder transmitir mayor cantidad de información por mensaje.

10
2.2.1.-Modulación por desplazamiento o corrimiento en frecuencia:
Como ya se mencionó en la introducción (capítulo 1), HART utiliza modulación por
desplazamiento en frecuencia para superponer la señal digital al lazo de corriente analógica de 4-20
mA que conecta la central al dispositivo en el campo.

Estas señales sinusoidales son superpuestas en la señal DC a un nivel bajo. El promedio de las
señales sinusoidales es cero, por lo que al ser incluida en la señal analógica 4-20mA no altera la
misma, sin importar lo que la señal digital pueda contener. La tasa de transmisión de datos es de
1200baudios. Eso quiere decir, que los dígitos binarios se transmiten a una tasa de 1200 bits por
segundo. Esto significa que el 1 es representado por un ciclo de 1200Hz, mientras que el cero es
representado por aproximadamente dos ciclos de 2200Hz.

Dichas frecuencias cumplen con el estándar “Bell 202”, uno de los muchos utilizados para
transmitir información digital vía telefónica.

2.2.2.-Los niveles de la señal


El protocolo Hart tiene como especificación, que los maestros deben transmitir una señal de
voltaje, sin embargo el esclavo debe transmitir una señal de corriente. La señal de corriente se
convierte a señal de voltaje mediante una pequeña resistencia de carga, de modo que todos los
dispositivos utilizan receptores pasivos. Los niveles pico-pico de la señal se muestran en la tabla 2.1.
La forma de onda es idealmente sinusoidal, sin embargo se acepta de forma trapezoidal, pero no una
señal cuadrada.

Señal transmitida por el maestro min 400mV p-p


max 600mV p-p
Señal transmitida por el esclavo min 0.8mA p-p
max 1.2mA p-p
Señal mínima del esclavo, convertida por una carga de 230 ohms 180mV p-p
Señal mínima del esclavo, convertida por una carga de 1100 ohms 1320mV p-p
Sensitividad del receptor(debe recibir correctamente) 120 mV to 2.0 V p-p
Sensitividad del receptor(debe omitir) 80 mV p-p

Tabla 2.1 Niveles de la señal HART

La especificación de sensitividad del dispositivo permite cierta atenuación debida a la


resistividad del cable u otros efectos. Las especificaciones de umbral dependen de la ocurrencia de
interferencia de señales externas, y previene la interferencia entre canal (crosstalk), de otras señales

11
HART que se transmitan por cables adyacentes, o sistemas que no se encuentren bien conectados a
tierra o sistemas de alimentación.

2.2.3.-El lazo de conexión


La conexión convencional para un transmisor alimentado por lazo de corriente de dos hilos se
muestra en la figura 2.5. En la practica, los tres elementos (la fuente de poder, el transmisor TX y la
resistencia de carga, RL) se pueden conectar en cualquier orden, ya que se conectan en serie, y
cualquier punto del circuito puede ir a tierra. Las especificaciones de Hart permiten resistencias de
carga de 230 a 1100 ohms.

Figura 2.5 Lazo de conexión simple

La señal HART debe ser introducida y leída del lazo de corriente. La fuente de poder está casi
en corto circuito para las frecuencias de la señal Hart, por lo que dispositivos secundarios (como el
segundo maestro) no pueden ser conectados directamente al lazo, se deben conectar en paralelo al
transmisor o a la resistencia de carga, en la figura 2.5, entre los puntos A y B. Un equipo con
protocolo de comunicación Hart no debe introducir ninguna carga DC a la línea. Para asegurarse de
que así sea se debe conectar al lazo mediante un condensador de 5µF o más.

Algunos de los dispositivos de campo con lazo de 4-20mA son activos, es decir, estos son los
que alimentan el lazo. Con este tipo de dispositivos no hace falta la fuente de poder. En este caso en la
conexión se elimina la fuente.
12
2.2.4.-Conexión de múltiples dispositivos
Múltiples dispositivos pueden ser conectados al mismo maestro, ya que en los mensajes se
incluye la dirección de los dispositivos que se comunican. Al asignarle a los dispositivos direcciones
diferentes, una cantidad máxima de 15 dispositivos pueden ser conectados a un solo lazo. Las
consecuencias de este tipo de conexión son dos principalmente, retardo en la comunicación entre
maestro y dispositivo y pérdida de la señal analógica. Debido a la existencia de este tipo de
conexiones, existe la dirección de multipunto, que se asigna a cada dispositivo que este conectado en
paralelo, comenzando del cero al quince.

Entre otras de las especificaciones que requiere el protocolo Hart se encuentra la definición de
las cargas respectivas de los equipos (maestro primario resistencia de recepción 230-1100ohm,
resistencia de transmisión 700 ohms máximo). El límite de los 65ms, que hace que la frecuencia de
corte sea de 2500Hz (para 3dB de atenuación). Con lo anterior se impide retardos de la señal y de las
frecuencias que la componen. Especificaciones para el cableado, puestas a tierra, fuente de poder,
ancho de banda de la señal analógica, y más.

Sin embargo, estas especificaciones no son necesarias para el desarrollo del proyecto, puesto
que el equipo al que se incluirá el protocolo HART será incluido en una red ya existente, por
supuesto, deberá cumplir con las normas para esclavos que establezca el protocolo.

Sección 2.3.- Procedimiento de transacciones, código y estructura del mensaje

En esta sección se describe de modo más detallado los comandos del protocolo, los comandos
universales, los comandos de práctica común y los comandos de dispositivo específico. Incluyendo
los tipos de datos que corresponden a cada uno de estos. Los bytes de estado son aquellos que indican
errores en la comunicación, en esta sección se da a conocer el valor de estos y su significado.

Se profundiza sobre la transacción de datos entre dispositivos Hart y la estructura de los


mensajes, esto corresponde a la capa 2 o nivel 2 del protocolo de referencia o modelo OSI.

Hart, como se ha mencionado a lo largo de los capítulos anteriores, es un protocolo de maestro-


esclavo. Esto significa que cada transacción es originada por el maestro, el dispositivo de campo o
esclavo solo responde cuando recibe un comando con su dirección. En la respuesta del esclavo se
incluye un comando recibido, y puede que contenga los datos requeridos por el maestro. En el caso de

13
que exista un maestro secundario, estos tiene direcciones diferentes, por lo cual pueden distinguir si la
respuesta es para el principal o secundario.

2.3.1.- Procedimiento de transacción:

HART es un protocolo Half-Duplex, con lo cual se quiere decir que al terminar cada mensaje,
la portadora debe ser desactivada para permitir que la otra estación transmita. Las reglas de tiempo de
la portadora establecen que la portadora debe ser activada no más del tiempo de 5 bits antes del inicio
del mensaje (preámbulo) y ser desactivada no más del mismo tiempo después de la transmisión del
último byte del mensaje (la suma de verificación).

El maestro es el responsable de las transacciones de mensajes. Si no hay respuesta a un


comando dentro de cierto tiempo, el maestro debe retransmitir el mensaje. Después de unos cuantos
intentos debe abandonar la transacción y notificar el problema. La longitud y retardo típicos de los
mensajes, permiten dos transacciones por segundo.

2.3.2.-El modo ráfaga

Para lograr una tasa de transmisión de datos mayor, algunos dispositivos utilizan el modo
ráfaga. Cuando un dispositivo se encuentra en este modo envía un mensaje repetidas veces. Este
modo se activa y desactiva mediante los comandos especiales #107, #108 y #109 (si se implementa el
modo ráfaga, los comandos básicos son #1 y #3, los demás son opcionales). Existe una pequeña pausa
entre mensaje y mensaje, para permitir que el maestro envíe la señal de desactivación, o para iniciar
cualquier otra transacción simple.

Este modo solo funciona para la configuración punto a punto, y se pueden enviar más de tres
mensajes por segundo. En la tabla 2.2 se encuentran las especificaciones de tiempo para los mensajes
en modo de ráfaga.

14
Dispositivo y tipo del mensaje Intervalo t
El maestro primario envía un comando >= 305 ms
El maestro secundario envía un comando >= 380 ms después de que la línea está desocupada
Esclavo en modo BURST envía mensaje >= 305 ms
Maestro sincronizado envía comando 20* - 75 ms después de la respuesta al otro maestro
>= 75 ms después de la respuesta a si mismo
Esclavo, modo normal, responde comando 0-256 ms después del comando
Esclavo en modo BURST envía mensaje 75-256 ms después de su mensaje anterior
0-20 ms después de que responde al comando
inicial "activar el modo BURST", después
de la respuesta a otro comando.
Tabla 2.2 Especificaciones de tiempo en modo de ráfaga

2.3.3.-Codificación de caracteres:

Los mensajes de Hart son codificados como series de 8 bits, es decir bytes. Estos se transmiten
de modo serial, utilizando una UART convencional (Universal Asynchronous Receiver/Transmitter)
para serializar cada byte, añadiendo un bit de inicio, un bit de paridad impar y un bit de fin, esto
permite que la UART receptora identifique el inicio de cada caracter, y para detectar errores en la
transmisión debidos a ruido u otro tipo de interferencia. La cadena completa de bits se muestra en la
siguiente figura 2.6.

Figura 2.6 Cadena de bits de caracteres

El bit menos significativo, D0 se envía primero. La mayoría de los protocolos seriales permiten
pausas entre los caracteres, debido a las especificaciones de tiempo de Hart esto no es posible, de
ocurrir dicho retraso se asume que la comunicación no fue establecida.

2.3.4.- Formato del mensaje:


El mensaje tiene un formato como el observado en la figura 2.7.

Figura 2.7 Formato de los mensajes Hart

15
Existen el formato largo y el formato corto. Los primeros instrumentos Hart (inclusive la
revisión 4) siempre utilizaron el formato corto. En este formato, la dirección del esclavo un byte, de
valor cero, para configuración punto-punto o del 0 al 15 para configuración multipunto. Esta corta
dirección se denomina dirección multipunto. La revisión 5 introduce el formato largo. En este, la
dirección del esclavo es un número de identificación único, un número de 38 bits derivado del código
del fabricante, el código del tipo de dispositivo y el número de identificación del dispositivo. Este
formato impide que los esclavos tomen mensajes que no le corresponden. De un modo estricto, el
identificador único, no es único, pueden haber hasta cuatro veces el mismo número, ya que del código
del fabricante solo se toman 6 bits, cuando el número en realidad consta de 8 bits.

La mayoría de los dispositivos maestros deben incluir ambos formatos en su totalidad, de modo
que puedan trabajar correctamente con los dispositivos ya existentes así como con los nuevos. La
revisión 5 establece que todos los dispositivos deben implementar el comando #0 ( leer identificación
única) en ambos formatos del mensaje. Un maestro normalmente utilizará el comando # 0 para la
primera conexión con el dispositivo, ya que en ese momento el número único de identificación no se
conoce, sin embargo como el mensaje también incluye el nivel de revisión de HART, el maestro sabrá
que formato deberá utilizar.

El preámbulo:

El preámbulo consiste de 5 a 20 bytes con caracteres hexadecimales FF (todos 1’s). Esto


permite que el receptor sincronice la frecuencia de la señal y la cadena de caracteres que recibe,
después de la detección inicial del mensaje Hart. Para el primer intento y cualquier intento sucesivo
de comunicación, se deberían utilizar 20 bytes de preámbulo , para tener la mayor probabilidad de
éxito. La respuesta al comando #0 le dice al maestro cuantos caracteres de preámbulo le gustaría
recibir al dispositivo; el maestro puede utilizar el comando #59 para indicarle cuantos bytes de
preámbulo debe incluir en la respuesta.

El caracter de inicio (start byte):

El caracter de inicio en Hart tiene diversos valores posibles, indicando cual formato está siendo
utilizado, la fuente del mensaje, y si es o no un mensaje tipo ráfaga. Estos se muestran en la tabla 2.3.

16
Tipo de mensaje Formato corto Formato largo
Maestro a esclavo 2 82
Esclavo a maestro 6 86
Mensaje BURST del esclavo 1 81

Tabla 2.3 Valores del byte de inicio

Cuando están en espera de un mensaje, los receptores se encuentran en la búsqueda de estos


caracteres , como el primer caracter después de por lo menos dos caracteres FF, para indicar el inicio
del mensaje. Estos mensajes se pueden identificar completamente con el contenido de los bits 0,1,2 y
7. Se ha propuesto que para mejoras futuras se utilicen los bits 5 y 6 del caracter de inicio para
indicar la presencia de bytes extra entre la dirección y el comando.

La dirección (address bytes):

El campo de dirección contiene tanto la dirección del maestro como la del esclavo del mensaje
enviado. Esta contenida en un byte, para el formato corto y en 5 bytes para el formato largo. El bit
más significativo de la dirección, indica si el maestro es el primario (1) o el secundario (0) . Los
mensajes de tipo ráfaga son una excepción, en la cual el dispositivo alterna ambas direcciones, lo que
le da oportunidad a ambos maestros de interrumpir.

También en ambos formatos, el bit que le sigue al más significativo indica si el mensaje
proviene de un dispositivo en modo ráfaga, lo que no implica que el mensaje sea de tipo ráfaga. En el
formato corto, los dispositivos esclavos tienen direcciones de la cero a la quince. Este número se
incluye de modo binario en los 4 bits menos significativos del byte de dirección. En el formato largo,
la dirección de multipunto no es utilizada, en cambio, los 38 bits restantes de los cinco bytes del
campo de direcciones contienen el identificador único como una dirección. En las siguientes se puede
observar la estructura de las direcciones.

Figura 2.8 Estructura del formato corto

17
Figura 2.9 Estructura del formato largo

En la estructura de formato largo, si se asigna cero a todos los bits, se puede utilizar como un
mensaje de transmisión sin destinatario específico, un mensaje que sea aceptado por todos los
dispositivos; esto es solo posible si los datos en el mensaje determinan cual de los dispositivos debe
responder. Por ejemplo, el comando #11 (leer el identificador único asociado a la etiqueta)
normalmente utiliza direcciones de transmisión sin destinatario específico con una etiqueta en el
campo de datos, de modo que todos los dispositivos conectados reciben el mensaje pero solo uno de
ellos responde.

Comando:

El campo de comando contiene un entero del 0 al hexadecimal FD o al decimal 253, como su


nombre lo indica representa el comando HART. El comando recibido se incluye en la respuesta del
esclavo al ser enviada. Ya que para cada comando se define una estructura específica para el campo
de datos, y una respuesta en particular, se dedica una sección a éste campo.

Cuenta de bytes:

Este campo contiene un entero, que indica el número de bytes que forman el resto del mensaje
(eso es los campos de estado y de datos, la suma de verificación no se incluye). El dispositivo
receptor utiliza esto para identificar el byte de suma de verificación y saber cuando el mensaje está
completo. Como el campo de datos esta limitado a 25 bytes máximo, esta cuenta puede ser cualquier
número entre 0 y 27.

18
Estado:

El campo de estado también es llamado el “código de respuesta”, solo se incluye en el mensaje


de respuesta de un esclavo. Consta de dos bytes, que reportan cualquier error de comunicación, el
estado del comando recibido (como por ejemplo dispositivo ocupado o que no reconoce dicho
comando), y el estado de operación del esclavo.

Datos:

No todas las respuestas contienen datos. Para aquellas que si lo hacen, y de modo que cumplan
con las reglas de tiempo, el campo de datos no puede exceder los 25 bytes. Los datos pueden estar en
forma de enteros sin signo, números de punto flotante o cadenas de caracteres ASCII. El número de
bytes del campo de datos, y el formato de datos utilizado para cada ítem se especifican de acuerdo al
comando recibido.

Suma de verificación (checksum):

El byte de suma de verificación contiene el OR exclusivo (paridad longitudinal) de todos los


bytes que le preceden en el mensaje, comenzando con el caracter de inicio. Esto provee un segundo
chequeo para la integridad de la transmisión después del de paridad por byte. La combinación de estos
dos garantiza la detección de hasta tres errores en un mensaje y tiene buenas probabilidades de
detectar errores en más bits.

2.3.5.- Ejemplo de transacciones:


En las figuras siguientes se observan ambos formatos. En cada mensaje, los valores de los bytes
se muestran en hexadecimal, con los campos de dirección escrito de modo binario para mostrar
claramente su composición. Los nombres de cada campo se encuentran indicados con sus siglas en
ingles. START es el byte de inicio, ADDR es el byte de dirección, COM es el byte de comando,
BCNT es el byte de cuenta de bytes y el CHKS es el byte de suma de verificación.

19
Maestro a Esclavo:

Esclavo a Maestro:

Figura 2.10 Transacción en formato corto

20
Maestro a Esclavo:

Esclavo a Maestro:

Figura 2.11 Transacción en formato largo

21
Sección 2.4.- Comandos y datos respectivos, bytes de estado.

En este capítulo se describe la clasificación de los comandos de HART, y se da detalles en


cuanto a la estructura de datos utilizados en la mayoría de ellos. La codificación y significado del
campo de estado también se describe. Esto corresponde al nivel número 7 del modelo OSI, el nivel de
aplicación.

El campo de comandos como ya se mencionó en la sección anterior, contiene un entero entre 0


y 253, en decimal, que representa los comandos de Hart. Los números 31, 127, 254 y 255 se
encuentran reservados. Además, los comandos se dividen en tres grupos específicos, a saber, los
comandos universales, los comandos de práctica común y los comandos específicos del dispositivo.

2.4.1.-Los comandos universales:

Los comandos universales se encuentran entre 0 y 30. Estos proveen funciones que son
implementadas en todos los dispositivos Hart. La tabla 2.4 contiene un resumen de estas funciones, la
tabla que se encuentra en el anexo 2 los describe de un modo mucho más detallado.

Comandos Función
0,11 Identificar dispositivo (fabricante, tipo de dispositivo, etiqueta de revisión)
1,2,3 Leer variables medidas
6 Establecer dirección de escaneo.(y modo multipunto).
12,13,17,18 Leer y escribir información introducida por el usuario (tag, fecha,mensaje)
14,15 Leer información del dispositivo (numero serial del sensor, límites del sensor,
operación de alarma, valores del rango, función de transferencia,
constante de tiempo de muestreo)
16,19 Leer y escribir número final de ensamble.

Tabla 2.4 Comando universales

Los comandos #0 y #11 (comandos universales):

Los comandos #0 y #11, son utilizados para identificar un dispositivo de campo. Desde la
revisión 5, todos los equipos utilizan el formato largo, pero el comando #0 debe ser también aceptado.
Esto permite que el maestro Hart identifique un dispositivo nuevo, sin antes saber su número de
identificación único. Los datos en la respuesta al comando #0 incluyen el código de identificación del

22
fabricante, el código del tipo de dispositivo, y el número de identificación del mismo. De estos, el
maestro puede construir el número de identificación única para ser utilizado en los mensajes
siguientes.

Los comandos #1,#2 y #3 (comandos universales):

Estos se utilizan para leer las variables medidas de diversas formas. Los comandos #2 y #3
incluyen la actual corriente de salida en mA. Como la verdadera salida analógica, estos valores en mA
representan la variable primaria (VP) solo cuando está dentro del rango configurado. No cuando el
dispositivo se encuentra en operación multipunto ni tampoco cuando la salida tiene un valor fijo,
saturado o un valor fuera del rango. Sin embargo, la VP y otras variables dinámicas retornadas con
sus respectivas unidades a través de estos comandos, no son limitadas por el rango establecido, sino
que siguen la medición del sensor. El porcentaje del rango indicado por el comando #2 también sigue
la salida del sensor fuera de los limites, de modo que se puede ir del 0 al 100 % y por encima de esto.

El comando de práctica común #61 es equivalente al comando #3, para instrumentos similares
con salidas analógicas diferentes a corriente. El comando #110 también devuelve variables dinámicas
(sin el nivel de salida de la señal analógica). El comando #33 provee una selección de hasta cuatro
variables del transmisor. Para múltiples dispositivos de salida, el comando #60 lee cualquier nivel de
señal analógica de salida seleccionada y el porcentaje del rango, y finalmente el comando #62 provee
la selección de hasta 4 niveles de salida.

El comando #6:

Este comando establece la dirección de escáner del dispositivo. Cuando se establece en cero, el
dispositivo funciona en modo punto a punto, generando una señal analógica de salida. Para cualquier
valor entre 1 y 15, el dispositivo se cambia al modo multipunto y su salida analógica se fija en 4 mA.

Los comandos #12 y #19:

Estos se utilizan para leer y escribir una selección de la información del dispositivo. Para las
revisiones menores e igual a 4, los comandos eran #4 y #5, con números de bloques utilizados para
seleccionar una particular sección de la información.

23
2.4.2.-Comandos de práctica común:

Estos se encuentran en el rango 32 a 126. Proveen funciones comunes a muchos dispositivos de


campo. Si estas funciones son implementadas en el dispositivo, estos comandos deben ser utilizados
para invocarlas. En la tabla 2.5 se observa un resumen de dichos comandos.

Los comandos de práctica común #123 y #126 no son “públicos”. Típicamente son utilizados
por los fabricantes para insertar información específica del dispositivo durante su instalación, por
ejemplo el número de identificación del dispositivo, que nunca será alterado por los usuarios, o para
comandos de lectura y escritura directa a la memoria. Frecuentemente se necesita de una clave para
acceder estos comandos.

Comandos Función
33,61,110 Leer variables medidas
34-37,44,47 Establecer parámetros de operación (rango, unidades, función de transferencia)
38 Reiniciar la bandera de "Configuración modificada".
39 Control de la EEPROM
40-42 Funciones de diagnóstico (modo de corriente fija, auto prueba, reset)
43,45-46 Ajuste de la entrada y salida analógica.
48 Leer estados adicionales.
49 Escribir el número serial del sensor.
50-56 Uso de variable del transmisor.
57-58 Información de la unidad (tag, descriptor, fecha).
59 Escribir el número de bytes de preámbulo necesitados.
60,62-70 Uso de múltiples salidas analógicas.
107-109 Control del modo ráfaga.

Tabla 2.5 Comandos de práctica común

Los comandos de práctica común, del #50 al #56 están relacionados a estas variables del
transmisor, sus sensores y rangos. En particular, en dispositivos que lo implementan, el comando #51
permite la selección de las variables del transmisor para las primeras cuatro variables. Estas pueden
ser leídas utilizando el comando #3. De otro modo, el comando #33 específica cuatro variables para
ser enviadas en un mismo mensaje.

Los transmisores multi-variables también tienen la posibilidad de más de una salida analógica.
Por definición, las salidas enumeradas 1 a 4 representan las variables dinámicas de Hart (VP, VS, VT

24
y VC) respectivamente. Los comandos de práctica común #60 y # 62 al #70 tienen que ver con la
configuración y control de estas salidas.

2.4.3.-Comandos específicos de dispositivo:

Los comandos específicos de dispositivo se encuentran en el rango 128 a 253. Sus funciones
son más o menos únicas para cada dispositivo. En la tabla del anexo 2 se muestran algunos ejemplos
de estos. En la revisión 4 y anteriores, los comandos específicos de dispositivo siempre incluían el
código del tipo de dispositivo como el primer byte del campo de datos, para asegurarse de que un
comando nunca llegara a un dispositivo no compatible. Esto fue abandonado en la revisión 5, cuando
se incluyó el número identificador único, que cumple con la misma función.

Datos:

No todas las respuestas a comandos contienen datos. Para esos que si lo hacen, se pueden
incluir un máximo de 25 bytes. Los datos pueden ser representados como:

• Enteros 8,16,24 o 32 bits sin signo.

• Números de punto flotante- Formato de IEEE 754 de punto flotante de precisión .

• Cadenas de caracteres ASCII-usualmente 4 caracteres por cada 3 bytes.

• Ítem enumerados para una lista estándar.

Si un comando no tiene éxito (indicado por error en el campo de estado), las respuestas no
deben contener datos. La respuesta a un comando exitoso siempre incluye el mismo set de variables
como las contenía el mensaje de comando; sin embargo, los valores en la respuesta son los
actualmente utilizados, tomados de la memoria del dispositivo de campo, al igual que cualquier
aproximación involucrada. El número de bytes de datos, y el formato de los mismos (de cada
elemento) son especificados para cada comando.

2.4.4.-Elementos (ítem) enumerados:


Los elementos de datos para los cuales se permite seleccionar de una lista de alternativas se
codifican como números que corresponden a cada alternativa. La tabla 2.6 muestra algunas de las
listas enumeradas estándar. Existen también muchas listas específicas para cada dispositivo.
25
Variable Valores
Identificación del fabricante 1-249, establecidos por la fundación HART
Tipo de dispositivo 0-249, establecidos por cada fabricante
Unidades 0-249: 6 = psi, 7 = bar, 32 = C, 33 = F, etc.
Función de transferencia 0 = lineal, 1= raíz cuadrada, etc.
Material 0-249 : 2 =316 acero inoxidable, 10 = PTFE, 18 = cerámica, etc.
Selección de alarma 0 = bajo, 1 = alto, 239 = mantener el último valor de la salida.
Protección a escritura 0 = no protegido contra escritura, 1 = protegido.
Control del modo RAFAGA 0 = salir del modo RAFAGA, 1 = activar el modo RÁFAGA.
Señalización física 0 = corriente BELL 202, 1 = voltaje BELL 202, 2 = RS-485.

Tabla 2.6 Variables enumeradas

Resumen de comandos:

La tabla 1 del anexo 2 contiene un listado de la estructura de los datos de los comandos
universales. Además contiene las diferencias entre los comandos para las distintas revisiones de Hart.
La tabla 2 del anexo 2 contiene los comandos de práctica común de la revisión 5.

Nota: en estas tablas los tipos de los datos se indican como sigue.

A Cadena de caracteres ASCII (empacados 4 caracteres en 3 bytes);

B Bits de banderas

D Fecha (3 bytes, día, mes, año-1900)

F Número de punto flotante (4 bytes IEEE 754)

H Enteros xxxxx yyy (xxxxx = revisión del hardware, yyy = código de señalización física)

2.4.5.-Bytes de estado:
Dos bytes de estados, también conocidos como “código de respuesta”, están incluidos en cada
mensaje de los dispositivos de campo. Entre ellos, estos dos bytes guardan tres tipos de información
diferente: errores de comunicación, respuestas a comandos, y estado del dispositivo de campo. La
tabla muestra como se hace esto con solo dos bytes. Si se detecta un error en un mensaje de salida , el
bit más significativo (bit 7) del primer byte se fija en 1, y los demás detalles del error se indican en los
bits siguientes; el segundo byte contiene puros ceros. De otra forma, si la comunicación fue exitosa, el
26
bit 7 del primer byte es cero, el resto del byte contiene la respuesta al comando, indicando cualquier
problema con el comando recibido, y el segundo byte contiene el estado del dispositivo de campo,
indicando el estado operacional del; dispositivo.

Los errores de comunicación son aquellos que podrían ser detectados por la UART. Además
informa cualquier incongruencia entre el registro de recepción y la suma de verificación. Los
comandos de respuesta (enteros en el rango de 0 a 127) se categorizan como errores o advertencias. Y
teniendo múltiples o un simple significado. La tabla muestra los rangos específicos para cada tipo.
La tabla muestra aquellos que tienen múltiples significados específicos para cada comando universal
o de práctica común.

El campo de estado de los dispositivos de campo incluye ambos, condición de falla o de


operación anormal, por lo que no implica que el dispositivo esté fallando. Muchos dispositivos
ofrecen más información de estado de la que se puede codificar en un solo byte. Para esto, el bit 4 del
campo de estado se puede colocar en 1, indicando que existe mayor información disponible; el
comando #48 puede ser entonces utilizado para leer la información adicional. Originalmente, el uso
de los bytes de datos en el comando #48 estaba libre para ser implementado por el diseñador, pero
desde la revisión 5.1 de Hart, los bytes 6 al 13 deben tener significado específico, indicando los
modos de operación y el estado de las múltiples salidas analógicas.

27
CAPITULO 3 .- DESCRIPCION DEL SISTEMA

El siguiente capítulo se refiere al sistema. Las partes que integran el sistema se tratan como
puntos apartes, comenzando con el circuito digital o hardware, del cual se describe los integrados
utilizados y las partes que conforman cada uno de estos, comenzando por el módem Hart HT2012 y
todos los circuitos externos que requiere, el circuito integrado de conversión TTL - RS 232, el circuito
de generación del lazo de corriente, el conversor analógico digital, y el microcontrolador. En cuanto
al programa del microcontrolador o firmware se describe las rutinas implementadas y la forma en la
que las mismas se relacionan y finalmente se trata el software o programa de interfaz para el usuario
del maestro, que en este caso es el computador personal.

Sin embargo, antes de entrar en los detalles del diseño, se menciona los implementos necesarios
para llevar acabo el proyecto en el cual se diseña el sistema de la figura 3.1.

Figura 3.1 Diagrama del sistema a realizar

3.1.- ¿ Cómo implementar el protocolo HART en los medidores de flujo?

Para poder implementar un protocolo en cualquier dispositivo remoto o esclavo, se necesita un


microprocesador, en especial si el protocolo de comunicación es el protocolo Hart, ya que como se
vio en el capítulo 2 , el protocolo requiere dispositivos inteligentes, refiriéndose con este adjetivo al
hecho de contener un microcontrolador. El microcontrolador que la compañía Flotech S.A. utiliza en
sus instrumentos medidores de flujo es el Basic TIGER, de Wilke Technology. Este microcontrolador
posee una gran capacidad de memoria y un puerto serial que se utiliza al momento de conectar el
módem Hart. Para que el microcontrolador sea capaz de responder a los mensajes Hart, se debe

28
realizar un programa que reciba y decodifique el mensaje, para luego ensamblar una respuesta al
mismo tomando los valores necesarios desde el sensor (firmware).

El módem Hart es la parte física del protocolo en sí, es el que se encarga de transformar la señal
digital del microprocesador en una señal analógica con codificación por desplazamiento en
frecuencia, que viaja por un par de cables hasta el módem del maestro. Este módem se describirá con
más detalle en el capítulo de hardware y materiales.

El microprocesador, el TIGER, se programa en Basic, un lenguaje de alto nivel bastante


sencillo. El microprocesador en si, incluye un software que maneja periféricos, como pantallas LCD y
también puertos seriales. Luego, con simples comandos se puede enviar la información a la pantalla
de visualización y al módem. Lo complicado de la programación del TIGER es saber ¿Cuándo es
correcta la información que recibe?, ¿Cómo decodificar o desensamblar el mensaje una vez recibido?
y ¿Qué se debe responder a dicho mensaje?.

Para la realización del proyecto no se disponía de un maestro, de un dispositivo que


estructurase los mensajes y los enviase al microcontrolador; de modo que también hubo que diseñar
un software que se pudiese utilizar en un PC y que cumpliese el papel de maestro. Luego, para el
programa en el PC, se utilizó el reciente lenguaje de programación de alto nivel, JAVA. Y para
asegurar que el protocolo estuviese implementado de acuerdo al estándar de la Fundación Hart, se
realizarán pruebas con PDVSA que posee un maestro aprobado por la fundación.

Detalles sobre los programas tanto del microprocesador TIGER, como del PC, los encontrará en
el capítulo de programas del microcontrolador (firmware) y programas en lenguaje Java para el PC
(software), en donde se da respuesta a las preguntas anteriores. Cabe destacar que no se presentan las
rutinas como tal (ya que explicar cada comando o instrucción dentro de la rutina no es objetivo de
este libro), se muestra mediante un diagrama de flujo la conexión entre las diferentes rutinas o
programas que ejecutan funciones diferentes, desde capturar datos hasta ensamblar el mensaje de
respuesta hacia el dispositivo maestro.

Sección 3.2.- Hardware y materiales

A continuación se procederá a describir en detalle la parte física del instrumento o dispositivo


de campo, esta se basa en la tarjeta digital del circuito que se diseño, dicha tarjeta posee la siguiente
estructura (figura 3.2):
29
Figura 3.2 Diagrama de la tarjeta digital

3.2.1.-Microcontrolador

Los sensores de flujo de la compañía Flotech S.A., a los que se les desea instalar el protocolo
Hart, funcionan con el microcontrolador Basic TIGER, de Wilke Technologies (figura 3.3 ). Este
microprocesador tiene las siguientes especificaciones:

Figura 3.3 Microcontrolador TIGER

• Es un procesador multitareas, con la capacidad de ejecutar hasta 32 tareas por separado.

• La velocidad en instrucciones por segundo que ejecuta es de hasta 100.000, las


operaciones con dispositivos I/O son más lentas, dependiendo de su complejidad.

30
• Capacidad de memoria: aproximada de 2000 a 5000 instrucciones de Basic con la
memoria FLASH de 128Kb y de 10000 a 30000 instrucciones, con la memoria FLASH
de 512Kb, el máximo en memoria Flash en venta es de 4Mb.

• La arquitectura de los pines de I/O del Basic TIGER se diseña para otorgar flexibilidad y
expansión sencilla. El modulo tiene 38 pines I/O que pueden ser utilizados en una gran
variedad de formas. Se pueden asignar otras funciones a los pines de I/O con la
programación apropiada en Basic.

• Dos puertos seriales, puerto serial 1 que tiene las respectivas entradas RxD y TxD, y el
puerto serial cero, que además de TxD y RxD tiene unos pines de RTS y CTS, con la
posible elección entre TTL o drivers de V24 (pines 24-29) que se pueden configurar
mediante el software.

• Los parámetros de comunicación son de 300, 600, 2400, 4800, 9600, 19200, 38400,
76800, 153600 Baudios; con 7 u 8 bits de datos; paridad O/E o N y un bus RS-485.

• Posee convertidores análogo a digital de 8, 10 o 12 bits que poseen una tasa de muestreo
de hasta 50000 muestras por segundo.

• Posee un controlador interno de pantalla LCD 15, con sets de caracteres definibles, con 8
caracteres cada uno. Control del cursor, secuencias de ESC, selección de menú,
símbolos en movimiento etc.

• Fuente de alimentación o de poder de 4.7voltios a 5.5 voltios y corriente de 45mA a


80mA (en modo inactivo de 50 a 100 micro amperios)

• Capacidad de memoria de 128Kb a 2 Mb en memoria SRAM y 128Kb a 4Mb de


memoria FLASH.

• RESET, tiene una entrada o pin para reiniciar el modulo.

• Reloj de tiempo real con calendario y alarmas, se requiere de una batería externa para
instalar esta aplicación.

31
• Salidas digital análogas de PWM, 2 canales, con resolución de 6 a 8 bits y frecuencias
desde 0.6kHz a 39kHz.

En la siguiente tabla se encuentra la especificación de cada pin:

Pin No. Nombre Descripción

1 VCC Voltaje de alimentación


2 L60 Puerto 6 - Pin 0
3 L61 Puerto 6 - Pin 1
4 L62 Puerto 6 - Pin 2
5 L63 Puerto 6 - Pin 3
7 L64 Puerto 6 - Pin 4
8 L65 Puerto 6 - Pin 5
9 L66 Puerto 6 - Pin 6
1 L67 Puerto 6 - Pin 7
10 L70 Puerto 7 - Pin 0
11 L71 Puerto 7 - Pin 1
12 L72/PWM Puerto 7 - Pin 2 o PWM – salida
13 L73/PWM Puerto 7 - Pin 3 o PWM – salida
14 L80 Puerto 8 - Pin 0
15 L81 Puerto 8 - Pin 1
16 L82 Puerto 8 - Pin 2
17 L83 Puerto 8 - Pin 3
18 L84 Puerto 8 - Pin 4
20 L86 Puerto 8 - Pin 6
21 L87 Puerto 8 – Pin 7
22 Reset in Entrada de reset
23 GND Tierra

Tabla 3.1 Especificaciones de pines del microcontrolador

32
Pin No. Name Description

24 L90/TxD0 Puerto 9 - Pin 0 o línea RxD del puerto serial 0


25 L91/RxD0 Puerto 9 - Pin 1 o línea TxD del puerto serial 0
26 L92/CTS0 Puerto 9 - Pin 2 or CTS0
27 L93/TxD1 Puerto 9 - Pin 3 o línea RxD puerto serial 1
28 L94/RxD1 Puerto 9 - Pin 4 o línea TxD puerto serial 1
29 L95/RTS0 Puerto 9 - Pin 5 o RTS0
30 L33 Puerto 3 - Pin 3
31 L34 Puerto 3 - Pin 4
32 L35 Puerto 3 - Pin 5
33 L36 Puerto 3 - Pin 6
34 L37 Puerto 3 - Pin 7
35 L42/I2C-clock Puerto 4 - Pin 2 o I2C-BUS puerto 3 – línea de reloj
36 L40/I2C-Data Puerto 4 – Pin 0 or I2C-BUS data Line
37 L41/PC Pin de modo PC
38 Alarm out Salida de la alarma (con reloj, en otro caso NC)
39 Analog in 0 Entrada analógica 0 (0 -> VCC)
40 Analog in 1 Entrada analógica 1 (0 -> VCC)
41 Analog in 2 Entrada analógica 2 (0 -> VCC)
42 Analog in 3 Entrada analógica 3 (0 -> VCC)
43 A/D-Ref-in A/D referencia de voltaje : 3,5 -> 5,0 volts
44 Analog GND Tierra analógica
45 Battery in Conexión para batería externa
46 VCC (5V) Fuente de alimentación o poder

Tabla 3.1 (Cont.) Especificaciones de pines del microcontrolador

3.2.2.- Desarrollo de la tarjeta digital

Al principio del proyecto se utilizó la tarjeta que incluía el Basic TIGER, cuando la
computadora y el microcontrolador se conectaban directamente por el puerto serial para comenzar a
programar las rutinas de comunicación, recepción y análisis. Una vez que se disponía de las demás
partes del dispositivo, se instaló el microcontrolador en una tarjeta diferente, en la que pude elegir que
era necesario de lo que contenía el kit y añadir las cosas que el mismo no incluía y eran necesarias.

La tarjeta desarrollada durante el proyecto, contenía lo siguiente:

33
Un conversor analógico digital, para convertir la entrada del sensor de nivel o flujo a un valor
digital de 12 bits. Este se conecta al microcontrolador mediante los pines 20 (Puerto 8 pin 6) y 21
(Puerto 8 pin7), que son puertos controlables mediante software. El conversor ADC utilizado fue el
LTC1298, cuyo circuito interno se muestra en la figura 3.4:

Figura 3.4 Bloque interno del LTC1298

Extraído de las hojas de datos de Analog Devices AD694

Para mayor información sobre éste integrado y el modo de conexión del mismo, refiérase al
anexo 6 , este contiene algunas de las hojas de datos de este integrado.

Un circuito que genera el lazo de corriente en mA, ya que el dispositivo que estamos creando es
de tipo activo lo cual implica que este debe generar su propio lazo. Luego este circuito se basa en el
integrado AD694 de Analog Devices. Este integrado se coloca en la tarjeta digital mediante el
siguiente montaje (figura 3.5):

34
Figura 3.5 Conexión del generador del lazo de corriente AD694

Extraído de las hojas de datos de Analog Devices AD694

Para mayor información sobre éste integrado y el modo de conexión del mismo, refiérase al
anexo 5 , este contiene algunas de las hojas de datos de este integrado.

Esto, junto con conectores DB-9 para ambos puertos seriales, conectadores para alimentación
(ya que la fuente no está incluida en esta tarjeta) y un interruptor que se utiliza en el microcontrolador
para elegir entre modo de programación y modo de corrida; además unos leds para indicar en que
modo se encuentra y si el circuito está encendido o no.

Esto es lo que contiene la tarjeta digital, no se incluye el diseño del módem Hart ya que para
este se diseña un circuito impreso individual que se conecta a la tarjeta digital

Para ilustrar lo anterior observe el siguiente diagrama de bloques en la figura 3.6, en el que se
muestra los módulos de la tarjeta digital:

35
Figura 3.6 Elementos de la tarjeta impresa del circuito digital

3.2.3.-El Módem HART

Al iniciar el proyecto de pasantía, la empresa disponía de 3 integrados SYM20C15, módems


para transmitir en protocolo Hart. Estos integrados eran de montaje superficial, luego para poder
conectarlos en el protoboard, donde inicialmente se ensambló el circuito hasta hacerlo funcionar, eran
necesarias unas bases especiales. Se hizo un listado de los componentes para ensamblar el circuito y
realizar las pruebas pertinentes, sin embargo, uno de los integrados necesarios para hacer funcionar el
circuito era el AD421, que en el momento de pedirlo a la empresa NEWARK, no notificó la
disponibilidad del mismo, el integrado estaba agotado y no se fabricaba otro lote hasta marzo del
2001; luego fue necesario cambiar el módem a utilizar.

De todos modos sería necesario el cambio, ya que la empresa que en un principio vendió estos
módems a Flotech S.A., Symbios Logic, había sido comprada y no venderían mas de los circuitos
integrados fabricados por la misma. Ya que no tenía sentido diseñar un producto que no se podría
fabricar porque los componentes al momento del diseño ya estaban obsoletos, se realizó una rápida
investigación (utilizando Internet), sobre la disponibilidad de algún otro módem, y se encontró la
empresa SMAR RESEARCH CORP. Esta es una empresa que vende equipos industriales con
protocolo de comunicación Hart y además algunos integrados, entre ellos el módem que se requería.
También disponían de circuito con el módem incluido que bastaba con conectarlo al puerto serial y
luego al lazo de corriente, sin embargo, este costaba $300 y el módem como integrado solo $5,

36
además, para poderlo conectar al micro esta interfaz Hart, que es el nombre de su producto (para
mayor detalle refiérase al anexo 4), requeriría de todas las conexiones que tiene la computadora hacia
el puerto serial, y que como ya se mencionó en la parte del microcontrolador, este no dispone de todos
los pines de conexión serial estándar. Finalmente, adquirimos el circuito integrado HART2012
(anexo 3) . Este Integrado requería un filtro de entrada y filtro de salida, además de un circuito
integrado MAX232 o MAX202, para compatibilidad con el puerto serial del microcontrolador. Cabe
destacar que los microcontroladores tienen la posibilidad de ser adquiridos sin el conversor RS232
interno, y de ese modo no haría falta este integrado en el diseño del impreso del módem HART, sin
embargo, la empresa adquirió éstos, para poder realizar la programación de los mismos de modo
directo, de modo que la redundancia (TTL a RS 232 y RS 232 a TTL de nuevo) es necesaria y no se
modificará en ningún momento.

Una vez que se dispone de los circuitos integrados y componentes necesarios, se ensamblo el
circuito en el protoboard , para realizar pruebas hasta que funcionase correctamente. Se montó según
el siguiente esquema (figura 3.7):

Figura 3.7 Circuito completo del Módem Hart

Aquí, como podemos observar, el circuito dispone de un filtro de entrada, un filtro de salida, el
módem HART 20 12, y un conversor TTL – RS 232.

37
El filtro de entrada, consiste en un amplificador operacional, que en este caso es el LM2904,
que envía su salida a un comparador, el TLC71, luego la salida del comparador es una señal 0 – 5
voltios que entra al módem HART. En la siguiente figura 3.8 se puede observar en detalle el circuito
del filtro de entrada.

Figura 3.8 Filtro de Entrada del Módem

El filtro de salida, se basa en un filtro pasa banda RC, con frecuencias de corte 1000Hz y
2500Hz, además un condensador en serie para eliminar el DC de la señal. Observe la figura 3.9, en
esta se incluyen los tres estados que controlan el medio:

Figura 3.9 Filtro de Salida del Módem

Para poder controlar lo que recibe el módem y lo que envía, ya que la comunicación es half-
duplex (la señal transmitida y la recibida comparten el canal o medio de transmisión, por lo que no se
puede hacer ambas cosas al mismo tiempo), se requiere de unas compuertas de tres estados 74HC126,
que se controlan con la señal de RTS.
38
Para la señal de reloj del módem, se requería de un cristal de 460.8kHz, se utilizó la siguiente
configuración de circuito oscilador (figura 3.10):

Figura 3.10 Reloj del módem

3.2.4.-Descripción del modulador HT2012


El módem posee las siguientes características:

• Funciona bajo el estándar Bell 202 con una tasa de baudios de 1200 bits por segundo.

• Utiliza las frecuencias de 1200 Hz y 2200 Hz del estándar Bell 202.

• Bajo consumo de potencia (consumo típico 40 µA).

• Detección de portadora (Carrier Detect) mejorado.

• Modulación por desplazamiento en frecuencia en un solo integrado.

• Recepción y transmisión de datos a 1200 baudios

• Fuente de alimentación requerida de 3 a 5 voltios.

• Compatible con CMOS y TTL.

• Se optimiza para aplicaciones intrínsecamente seguras.

• Utiliza tecnología CMOS de confianza.

• Soporta el rango de temperaturas industrial (-40ºC to 85ºC)

A continuación, en la figura 3.11, podrá observar los pines del integrado HT2012:

39
Figura 3.11 Módem Hart HT2012

El módem funciona del siguiente modo:

La señal RTS (ready to send) se encuentra siempre activa de modo que ninguno de los dos, ni el
maestro ni el esclavo, ocupe la línea. Las salidas TTL del MAX 232 van directamente a los pines
respectivos del módem, IRxD (input receive signal) y OtxD (output receive signal). Al bajar la señal
de RTS, el módem comienza a modular con desplazamiento en frecuencia, dependiendo del valor del
pin IRxD, la frecuencia será de 2200Hz o 1200Hz, como lo establece el estándar Bell 202.

Las pruebas que se realizaban eran en un principio con los terminales de dos computadoras, si
el puerto serial se conectaba a los respectivos módems (se requirió de la fabricación de dos de ellos
como mínimo) y se comunicaban entre ellos a una tasa de bits de 1200bps, como se encuentra en los
parámetros del protocolo Hart y del módem en sí.

En cuanto al montaje, para llegar al actual diseño de la tarjeta del módem, se fabricaron dos
prototipos. Los primeros eran circuitos con pistas de cobre de un solo lado, lo cual hacía necesaria la
conexión mediante cables, estos primeros prototipos los puede observar en la figura 3.12 y en el
anexo 8 encontrará el diseño del circuito impreso.

40
Figura 3.12 Primeros circuitos impresos para el módem

Luego se realizó un segundo diseño con correcciones de errores del primero y de doble cara, es
decir, con pistas de cobre por ambos lados de la tarjeta; este es el diseño final del impreso del módem.
Este se conecta a la tarjeta en la cual se encuentra el microcontrolador mediante un conectador de 10
pines, como se observa en la siguiente figura 3.13:

Figura 3.13 Conexión del módem Hart a la tarjeta digital

41
Esto concluye la descripción de la parte física del sistema, la tarjeta digital que se incluirá en el
dispositivo, sin embargo este no es un diseño que pueda ser fabricado en cantidad, ya que el circuito
se ensambló en una lámina perforada sin conectadores de cobre de ningún tipo, se debe diseñar un
circuito impreso para colocar todos los módulos de un modo más eficiente, que reduzca el espacio.
Ahora procedemos a describir el firmware del equipo, el programa del microcontrolador que se
encarga del procesamiento de los mensajes en el dispositivo remoto o sensor.

3.3.- Programas del microcontrolador ( firmware)

El programa del microcontrolador se define mediante la siguiente estructura (figura 3.14):

Figura 3.14 Estructura del firmware

A continuación se describe brevemente cada una de las partes del programa o rutinas y las
funciones que llevan a cabo, se mencionan los nombres utilizados para cada una durante la
programación, de modo que en caso de observar el anexo 10 el lector pueda comprender con mayor
facilidad el fragmento del programa.

42
3.3.1.-Recepción y análisis

Para iniciar el desarrollo del firmware era necesario crear una rutina que recibiese el mensaje.
Para ello se trabajó conectando los puertos seriales del PC y del TIGER directamente. La rutina toma
los caracteres o bytes y los imprime en el LCD. Una vez que se verificó que la rutina recibiera
correctamente los bytes, se procedía a un nivel superior de complejidad, ya que era necesaria una
rutina que analizará lo que recibía como si fuese un mensaje Hart, para este momento fue necesario
realizar un pequeño programa en JAVA que transmitiese un mensaje fijo pero con la estructura
HART, es decir, 20 bytes de preámbulo, dirección, comando y otros. Luego, el TIGER recibe el
mensaje y asignando a un arreglo de bytes lo que se recibe del puerto, divide el mensaje en sus
respectivas partes, e imprime en el LCD el comando (número del comando). Sin embargo, esto no
requería mayor esfuerzo, ya que el mensaje era fijo y se conocía exactamente que longitud, en bytes,
tiene cada parte del mensaje. En el protocolo Hart, como se vio en el capítulo 2, el mensaje puede
variar su longitud, y además puede tener dos formatos diferentes. De modo que, para poder recibir el
mensaje, debía ser analizado a medida que llegaba al puerto serial, por lo que hubo que integrar la
rutina de recepción con la de análisis.

La rutina de recepción y análisis revisa el puerto constantemente en busca de información o


bytes de datos, al momento de recibir alguno de ellos, lo compara con FF hex (que son los primeros
20 bytes de un mensaje HART) para poder sincronizar, detectar la existencia de un mensaje en la
línea y además eliminar ruido de modo digital. Si la cantidad de bytes con valor FF era igual a la
cantidad de bytes de preámbulo asignados al dispositivo, el mensaje continúa siendo almacenado en el
arreglo de bytes, siendo el siguiente byte, el byte de inicio o como se denomina el arreglo en el
programa, byte de START.

El byte de inicio indica el formato del mensaje, si es de formato corto o de formato largo, esto
se implementó en el programa mediante un IF, y el valor por descarte es un mensaje de respuesta que
indica que el mensaje es errado. De modo que si el byte de inicio es 2 o 186 (02 hex y 82 hex
respectivamente) se descifra el largo del campo de dirección o address, que en un caso es de 5 bytes y
en otro de un solo byte. Luego, si el formato es largo, se reciben los cinco bytes siguientes y son
almacenados en un arreglo denominado ADRESSA, si es un byte se almacena en ADDRESSB.

La dirección debe ser también analizada en el momento en que se recibe, ya que si no es la


dirección del dispositivo éste no debe emitir respuesta alguna. Esto corresponde al primer rombo de la

43
figura de la estructura del programa que se presenta al principio de esta sección. Una vez que se sabe
que el mensaje es para el dispositivo, se continúa la recepción de bytes. El siguiente es el byte de
comando (COMMAND), de modo que de acuerdo a lo establecido por la fundación Hart, ya se conoce
lo que se encuentra en el mensaje, más sin embargo aún no se conoce su longitud. Un breve ejemplo
podrá aclarar lo antes mencionado. El comando número 17 es un mensaje de máximo 32 caracteres,
pero pueden ser menos, de modo que se debe saber cuantos bytes de información han sido enviados.
Para ello, se incluye el byte de cuenta de bytes (BYTECOUNTBYTE), el cual es un entero del 0 al 25
que facilita ese dato y viene inmediatamente después del byte de comando. Luego, se recibe la
cantidad de bytes que este BYTECOUNTBYTE indica y se almacenan en un arreglo denominado
DATAS. Finalmente, en el byte de verificación de suma, que en el programa es CHECKSUM, se
guarda el XOR de todos los bytes desde el de inicio hasta el último dato, para verificar que no hubo
errores de transmisión y que el mensaje está intacto.

3.3.2.-Respuesta al comando

Una vez que se dispone de cada una de las partes del mensaje en arreglos, se procede a realizar
lo que el maestro indica mediante el número del comando. Según el número de comando recibido se
debe realizar o invocar rutinas diversas. La que la mayoría de las veces se ejecuta (la mayoría de los
comandos incluyen este dato) es la medición de la variable primaria, para lo cual se realizó una rutina
aparte.

Para separar estas rutinas, se utiliza un SWITCH con los posibles casos o comandos disponibles
en el dispositivo(para este proyecto, solo fueron incluidos los comandos universales).

En la mayoría de los comandos, los datos enviados son fijos, son parámetros del dispositivo o
de las pocas variables que el mismo mide (variable transmitida en mA). De modo que estas se
almacenan en la memoria del TIGER para ser invocadas y/o modificadas en cuanto sea necesario. En
el anexo 2 se incluye una tabla con todos los parámetros necesarios para satisfacer los requerimientos
de información de los comandos universales.

No se detallará cada uno de los 13 comandos disponibles (los comandos universales), pero más
adelante se incluirá un ejemplo de aquellos que sirvan para describir las demás rutinas del programa.

44
3.3.3.-Transformación de valores

El mensaje recibido se almacena como bytes, de modo que los números decimales negativos y/o
mayores a un byte deben ser incluidos en una rutina de conversión. Esta rutina se denomina en la
estructura del programa ByteToFloat, ya que en el mensaje los números son enteros (un byte máximo)
o de tipo flotante. Siendo de tipo flotante (según el protocolo Hart), cuatro bytes, que representan el
número en dos partes, la mantisa M y el exponente E, siendo el número decimal igual a M x 2E . La
mantisa ocupa los dos primeros bytes más 7 bits del tercero, el exponente ocupa el cuarto byte sin el
bit superior más el bit restante del tercer byte y el último bit indica el signo de la cantidad decimal.
En el momento de transmitir la respuesta se invoca una rutina que hace lo opuesto, pasar del número
flotante recibido del sensor a bytes individuales que se denomina FloatToByte.

3.3.4.-Codificación o compresión de caracteres

Es necesaria una rutina de codificación y decodificación de caracteres, en realidad dos rutinas


diferentes. En el capítulo 2 , se describió el modo en el que los bytes de tipo caracter son
comprimidos, o mejor dicho, los parámetros de tipo caracter, como el tag (número identificador del
dispositivo o etiqueta), el DESCRIPTOR y los mensajes de texto de 32 caracteres. Esta codificación
es del modo siguiente. Los caracteres son tipo ASCII, pero cada cuatro bytes (8 bits) se comprimen en
tres, se eliminan los dos bits superiores del byte, es decir, el byte ya no es ASCII sino de 6 bits.
Luego, solo se utiliza una parte del código ASCII que son los caracteres desde el 20 hex hasta el 5F ,
estos incluyen signos de uso frecuente y letras mayúsculas. Para codificar, simplemente se eliminan
los dos bits superiores de cada byte y con una serie o secuencia de SHIFTs, ANDs y Ors, se
comprimen a los 3 bytes. Para decodificar es un poco más complejo, de acuerdo a los dos bits más
significativos (de los 6 bits) se añaden los bits que faltan. Si estos dos bits son 00 entonces se cambia
la parte superior del byte a 0100, pero si son 01, se cambian a 0101, de modo que los bytes superiores
serán 2, 3, 4 ó 5 ( del 20 al 5F hex).

3.3.5.-Conversión analógico a digital

Esta es una pequeña rutina que lee el puerto número 8 del TIGER, al cual se ha conectado
previamente la salida de un ADC, circuito integrado que transforma un valor analógico introducido,
en un valor digital a su salida, en forma serial. Al invocar la rutina ADC12bit se obtiene el valor
medido por el sensor, que es el que se asigna a la variable primaria.

45
Conociendo la existencia de estas rutinas de transformación de enteros a flotante, de
compresión de caracteres y obtención de valores, podemos dar ejemplos de comandos y su
implementación en el programa.

Cuando el maestro envía el comando número 18, en el campo de datos se encuentran el tag el
descriptor (con compresión de caracteres) y la fecha (sin comprimir). Luego, se decodifica y se
asignan los valores enviados a los parámetros del dispositivo, la respuesta debe ser igual o incluir los
mismo datos que envió el maestro o los nuevos valores de los parámetros tag, descriptor y fecha.

De los comandos universales, los únicos que incluyen datos del maestro al dispositivo de
campo, son los tres últimos, el 17, 18 y 19. El 17 es el que transmite un mensaje al dispositivo (un
mensaje de 32 caracteres que debe presentarse en la pantalla LCD), el 18 es el antes mencionado y el
19 modifica el número de ensamble final (NFE), uno de los parámetros del dispositivo.

Al recibir los demás comando se debe emitir una respuesta con los datos que según el comando
le correspondan, por ejemplo, el comando número uno es el que transmite la variable primaria (la
medición del sensor) junto con las unidades de la medición. Las unidades se indican de acuerdo a una
tabla con números enteros. Luego el primer byte del campo de datos se utiliza para incluir la unidad, y
los siguientes cuatro bytes, es decir, del 1 al 4, para almacenar los bytes que resulten de transformar el
valor flotante de la variable primaria a bytes. El comando 3 es bastante similar, solo que este incluye
las cuatro variables posibles del protocolo, cada una con su unidad de medición, excepto los primeros
cuatro byte, que indican la corriente del lazo en mA.

El comando 13 envía al maestro el tag, descriptor y la fecha, luego se debe invocar a la rutina
de codificación de caracteres. Para el tag que es de 8 caracteres, se asignan 6 bytes del mensaje; para
el descriptor, de 16 caracteres, se asignan 12 bytes; pero la fecha no necesita compresión, ya que tres
bytes son suficientes, día, año y mes respectivamente. Este comando permite observar los valores sin
poder modificarlos ( cosa que se realiza con el comando 18 se mencionó anteriormente).

Un comando interesante es el comando 12, este es aquel en el que el maestro recibe un mensaje
(de 32 caracteres) del dispositivo remoto, pero dado que el dispositivo remoto en el momento del
diseño del proyecto no incluía un teclado para poder ingresar mensajes, se implementó un mensaje
fijo que se transmite siempre que se le envíe ese comando. En un futuro se pretende añadir pequeños
teclados a los dispositivos, para poder modificar su programación en el campo y enviar mensajes de
texto.
46
Algunos fragmentos del código se encuentran en el anexo 9 de este libro. Finalmente, el
software o programa del maestro (computador personal).

3.4.-Programa para el maestro o interfaz para el usuario

El programa realizado para el maestro de prueba, posee una estructura similar a la del programa
del Basic TIGER, sin embargo, la diferencia entre los lenguajes de programación Basic y Java, hacen
que las rutinas sean algo más complicadas. Para llevar acabo la programación en este lenguaje se
acudió a la interfaz de aplicación de programación de Java (API, clases y objetos ya existentes); y se
procedió a realizar lo mismo que en el programa del TIGER, pero incluyendo una interfaz gráfica
que permite interactuar con el usuario.

Java es un lenguaje de programación orientado a objetos (si desea saber más sobre esto se le
sugiere revise la bibliografía), luego, en vez de programas o rutinas, se les denomina clases, las
mismas se invocan las unas a las otras para lograr el mismo resultado que el programa del TIGER. En
nuestro caso, el maestro dispone de una clase principal que crea la interfaz gráfica y activa los
botones que el usuario utilizará para controlar la aplicación. Al presionar o seleccionar alguno de los
ítem de la ventana de interfaz, se llama a otra clase que determina cual de las acciones se debe
realizar.

47
La interfaz es la siguiente (figura 3.15):

Figura 3.15 Interfaz gráfica del programa maestro

Como puede observar, la interfaz no es para ser utilizada por cualquier usuario, se planea hacer
modificaciones a la misma una vez que todo el dispositivo este completo, para ofrecer el servicio de
instalación completo de dispositivos de campo y maestro, pero cabe notar que para la empresa es
prioridad el dispositivo (hardware y firmware) y no el software. La interfaz contiene campos que
pueden ser editados y otros que no, ya que son los que se calculan al momento de ensamblar el
mensaje.

• El primer campo es la cantidad fija de bytes de preámbulo que poseen los mensajes hacia el
dispositivo.

• El segundo indica el valor hexadecimal del byte de inicio, de acuerdo a lo que el usuario
seleccione con los checkbox el valor que aparece en dicho campo se modifica.

48
• El tercer campo es el de la dirección. Dicha dirección se escribe en valores decimales byte por
byte, de no introducir correctamente la dirección el programa genera errores (no se ha incluido
en el programa diálogos de error, de modo que de cometer algún error este será visible en el
command prompt o el terminal desde el cual se corrió el programa java Hart).

• El cuarto no es un campo sino una lista de selección con los comandos disponibles del
dispositivo, aunque, siendo este un maestro para utilizar con cualquier dispositivo Hart, debería
permitir escritura, de no poseer el dispositivo dicho comando, deberá enviar un mensaje en el
cual los bytes de estado o estatus indican que el mismo no dispone del comando.

• La cuenta de bytes se genera automáticamente al presionar el botón “Componer”.

• El campo de datos presenta lo que se añade al mensaje, de no poseer ningún dato se indica o
simplemente aparece el comando que se ha seleccionado. Recuerde que, como se mencionó en
la parte del programa del TIGER, solo los comandos 17, 18 y 19, son los que envían datos del
maestro al dispositivo.

• Finalmente, un campo de texto en el que se escribe lo que el programa esta realizando o recibe
del dispositivo de campo.

Los botones:

• RESET, inicializa todos los campos de la interfaz.

• EXIT, cierra el programa.

• SEND, envía el mensaje.

• COMPONER, ensambla el mensaje.

De modo que para poder enviar un mensaje al dispositivo ocurren los siguientes eventos:

Se selecciona el formato del mensaje, se escribe la dirección y se le da al botón de componer


(en caso de que el comando a enviar sea diferente del 17, en cuyo caso también se introduce el
mensaje de 32 caracteres en el campo de datos), al seleccionar cualquiera de los botones de la interfaz
se invoca la clase ManejaEventos, que decide cual de las demás clases debe ser llamada, y asigna
valores a los campos de texto de la interfaz.
49
Al presionar el botón de componer la ventana se actualiza. Para este momento, ya se ha
asignado valores a cada byte que compone el mensaje, al invocar una clase denominada
ComposicionMensaje, la cual además contiene métodos (subrutinas) que codifican los bytes de tag,
descriptor y del mensaje de 32 caracteres.

Luego se presiona el botón de SEND o enviar, al hacerlo, se invoca la misma rutina


composición de mensaje y la clase SerialConection, que transmite el mensaje al módem Hart de modo
serial. Mientras el mensaje es enviado al dispositivo y se espera una respuesta se le informa al usuario
mediante el campo de mensaje del TIGRE, en el cual se imprimen las palabras …enviando el
mensaje…, para que el usuario sepa que ha funcionado la comunicación del maestro hacia el
dispositivo (es decir, entró a la rutina que envía los datos por el puerto serial al módem).

Finalmente al obtener una respuesta del TIGER se invoca la clase MessageAnalisis que se encarga
de dividir el mensaje en las partes respectivas y según el comando que se envió se muestra en el
campo de Mensaje del TIGER los valores de los bytes o campos individuales del mensaje más
importantes y luego lo que el comando en si debe enviar. Por ejemplo el comando 3 incluye la
corriente del lazo, las unidades y variables (de la primaria a la cuarta) y se muestran de la siguiente
forma:

• Corriente en mA: valor recibido

• Unidades variable primaria: valor recibido

• Variable primaria: valor recibido

• Unidades de la segunda: valor recibido

• Segunda variable: valor recibido

• Unidades tercera variable: valor recibido

• Tercera variable: valor recibido

• Unidades cuarta variable: valor recibido

• Cuarta variable: valor recibido

Para cada comando se muestra la estructura de lo recibido de un modo similar, descripción y


después de los dos puntos el valor recibido o asignado.

50
El programa del maestro no es un programa secuencial, a diferencia del programa del TIGRE,
este llama a las diferentes clases o rutinas a medida que se necesita de ellas, por ejemplo, por cada
byte que se recibe se invoca la clase SerialConection y la clase MesageAnalisis.

De este modo se culmina la descripción del sistema diseñado y se procede al capítulo de


pruebas y resultados.

51
CAPITULO 4.- PRUEBAS Y RESULTADOS

4.1.-El circuito impreso digital y programa del microcontrolador:


El resultado final de este proyecto es un prototipo, como se mencionó anteriormente, la tarjeta
digital se muestra en la siguiente figura 4.1:

Figura 4.1 Tarjeta digital con todos sus elementos

Como se puede observar, la tarjeta digital incluye todo lo que se mencionó en su descripción.
Se puede observar el módem (la tarjeta que se encuentra conectada por encima de ambos
conectadores DB-9), el circuito conversor analógico digital, que se observa en el lado izquierdo del
microcontrolador y el circuito generador del lazo que se encuentra debajo de la tarjeta del módem.
Este circuito contiene el hardware y firmware del diseño.

52
4.2.- Interfaz para el usuario
La interfaz gráfica para el usuario en el PC, o en otras palabras el maestro funciona del
siguiente modo:

Figura 4.2 Interfaz gráfica del maestro

Al iniciar el programa aparece la ventana principal en blanco, como se muestra en la figura


anterior; los campos se encuentran vacíos y esperando que el usuario proceda a llenar y seleccionar
los valores deseados. Una vez introducidos los valores deseados se presiona el botón de componer y
la ventana muestra los valores calculados para el resto del mensaje, como se muestra a continuación
(figura 4.3):

53
Figura 4.3 Interfaz una vez presionado COMPONER

Como se puede observar para este momento, los campos contiene los valores introducidos por
el usuario y los establecidos por el sistema, en este caso el número de bytes de preámbulo es 20, el
formato de mensaje elegido es el formato largo, el cual contiene un campo de dirección de cinco
bytes, el valor de ésta dirección se encuentra en el siguiente campo de texto. El comando que había
sido elegido, la cuenta de bytes que en este caso es cero (recuerde que el comando 3 no contiene datos
del maestro hacia el dispositivo) y el campo de datos que muestra el comando elegido (se mencionó
anteriormente que en caso de que el comando no contuviese ningún dato se mostraría en este campo
el comando elegido. Una vez listo el mensaje se presiona el botón de SEND y la pantalla aparece esta
vez del siguiente modo (figura 4.4):

54
Figura 4.4 Interfaz después de presionar SEND

En la figura se nota que el botón SEND queda inhabilitado una vez que se presiona, esto es para
impedir que el usuario presione el mismo varias veces y cree un conflicto dentro del programa, este se
reactivará una vez que se presione componer de nuevo.

El botón de RESET reinicia la ventana, quedando esta como se muestra en la figura 4.2 en la
cual se borra el contenido del mensaje del TIGRE, para poder continuar enviando mensajes sin la
necesidad de utilizar las barras deslizantes del área de texto (scrollbars) , sin embargo deberá rescribir
los campos de dirección para cada vez que utilice el RESET.

Finalmente, aparecen los resultados de la comunicación, esto después de que el programa ha


procesado el mensaje recibido, y se muestran como se ilustra en la figura 4.5:

55
Figura 4.5 Interfaz con los resultados del proceso de comunicación

Como puede observarse, los resultados incluyen el valor de los bytes de inicio, la dirección, el
comando y el de estado; sin embargo a un usuario que no esté programando no le interesa el valor de
estos, sino la frase que indica que el mensaje fue recibido correctamente y los valores que pidió
mediante el comando elegido.

4.3.- El sistema completo


Una vez realizadas las conexiones entre el hardware, firmware y software o entre el
microcontrolador, el módem del dispositivo de campo al módem del maestro mediante el lazo de
corriente, y el módem del maestro al computador mediante un cable serial; se procedió a correr en el
PC el programa del maestro Hart, realizado en JAVA. Para correrlo es necesario abrir el command
prompt del computador y ejecutar el comando java Hart5. Luego se procedió a elegir todos los
comandos disponibles, los cuales para el momento son los comandos universales, y verificar que la
respuesta fuese la asignada por la Fundación Hart; observando los cambios en los valores de la
variables primaria, la recepción de mensajes de texto de 32 caracteres, y que no respondiese a
mensajes con direcciones diferentes a la asignada a este dispositivo en particular, entre otras.
56
Una de las principales cosas a probar era el correcto funcionamiento de las rutinas de recepción
y análisis, para lo cual se incluyó en el programa maestro de PC unas líneas que indican el estado en
el que se recibió el mensaje (esto se verifica comparando el byte de suma de verificación recibido, con
uno calculado por el programa) e imprimiendo líneas con los valores de cada byte individual, para
verificar que, por ejemplo, el byte de inicio tuviese valores 06 0 86, y no cualquier otro, en cuyo caso
habría algún error en el sistema o en la comunicación.

Al notar que todos los comandos implementados recibían la respuesta esperada, se dio por
culminado el diseño. Tomando en cuenta que aún faltaban detalles, como los datos enumerados y la
implementación de los muchos otros comandos, pero que para ese momento era imposible
implementar, ya que el diseño de la parte analógica del sensor no había sido realizada y las rutinas de
calibración y demás opciones que permite el protocolo no podían ser programadas sin éste.

El resultado concreto de este proyecto es un sistema que se basa en el protocolo de


comunicación Hart, una tarjeta digital que mediante el uso de un microcontrolador procesa una señal
analógica FSK de frecuencias 1200 Hz y 2200 Hz para emitir una respuesta al mensaje de comando
del maestro, cuya interfaz es el programa del computador. Con esto vemos que se cumplen los
objetivos del proyecto, aún faltando cosas para poder ser un diseño final de venta al público, pero que
realiza las funciones deseadas: comprender el protocolo Hart.

En la foto que se presenta al final de ésta sección (figura 4.6) puede observar todo el sistema
conectado, el circuito digital, con el microcontrolador, el módem y demás partes, y la conexión
mediante solo dos hilos hacia el módem del computador que se conecta al mismo vía serial. Se
observa en la pantalla del computador el programa o interfaz funcionando y en la pantalla LCD un
mensaje que da la bienvenida a Hart de Flotech S.A.

57
Figura 4.6 Sistema con capacidad de manejar el protocolo Hart

58
CAPITULO 5.-CONCLUSIONES Y RECOMENDACIONES

Sección 5.1.- CONCLUSIONES

• Se diseño una tarjeta digital con capacidad de comunicación mediante el protocolo Hart.

• El dispositivo diseñado contiene únicamente los comandos universales, a pesar de ello cumplen
el requisito básico de la fundación Hart.

• El diseño del firmware se realizó de modo modular, es decir, basta con incluir un case nuevo
en cada switch para poder implementar los comandos de práctica común tanto como los
comandos específicos de dispositivo.

• Al realizar la programación del protocolo en una rutina aislada de aquella que controla el sensor
como tal, se hace posible la implementación de la misma en múltiples sensores o equipos que
utilicen dicho protocolo.

• Se diseño una interfaz gráfica que corre en cualquier máquina o computador personal ya que
fue desarrollada en el lenguaje Java, de uso relativamente sencillo y fácil comprensión visual.

• El uso de dispositivo como el diseñado en este proyecto permite ahorros al momento de la


digitalización de campos industriales, ya que el protocolo hace uso de los cables instalados
para comunicación analógica de 4 – 20 mA , y no es necesario ir hasta el punto en el cual se
encuentra ubicado el sensor para cambiar la fecha, ajustes de datos o incluso calibrarlo (ésta
opción aun no se encuentra disponible).

59
Sección 5.2.- RECOMENDACIONES

• Se recomienda adquirir un software maestro para el computador, aprobado por la


Fundación Hart, para probar los equipos una vez que estén listos para ser vendidos.
Para ello se puede contactar a la compañía a la cual se le compraron los circuitos
integrados del módem hart, Smar Research Coorporation , la cual se puede contactar
mediante Internet a la siguiente dirección: http://www.smarresearch.com/.

• Adquirir de la fundación las hojas de datos y especificaciones del protocolo, las cuales si
se registra la compañía en la Fundación son enviadas como uno de los materiales de
ingreso, pero de no pretender ser miembro de la fundación se venden por separado por
un precio de $400. Para adquirir estas especificaciones de protocolo deberá contactar a
la Fundación Hart. Dirección electrónica : http://www.hartfundation.com

• Incluir en el programa del dispositivo remoto o TIGER las tablas que indican las
unidades de medida y demás símbolos que se interpreten mediante las mismas. Por
ejemplo, las unidades de metros corresponden a algún entero del 0 al 255 (se asigna 1
byte para unidades, es decir, 255 unidades de medición posibles).

• Si no se pretende adquirir el software del maestro se recomienda realizar diversas


modificaciones al programa actual en Java, dado que este no es un programa para ser
utilizado por personas ajenas a la programación en Java y al programa en sí.

• Realizar un circuito impreso final que incluya todos los componentes digitales, el
microcontrolador, el generador del lazo de corriente, el módem hart con la circuitería
correspondiente y el conversor análogo digital. Ésta deberá conectarse al circuito
impreso o a la tarjeta analógica mediante conectadores y fijarse de modo que ambas
queden estables dentro de la caja a prueba de explosión.

• Se recomienda rediseñar el filtro de salida del módem para convertirlo de un simple


circuito RC a un filtro activo. O la inclusión de un filtro integrado, disponibles en el
mercado de componentes.

60
REFERENCIAS BIBLIOGRÁFICAS

1. Bowden R., "HART Field Communications protocol. A Technical Oveview", Segunda Edición,
Agosto de 1997, 85 páginas.

2. Wilke Technology GmbH, “BASIC TIGER MANUAL” , Versión 2.8, Junio de 1998, todo el
manual.

3. Smar Research, “HT2012 HART Modem Datasheet”

4. Linear Technology, “LTC1286/LTC1298 Micropower Sampling 12-Bit A/D Converters in S0-8


Packages”

5. Analog devices, “4 – 20 mA Transmitter”

6. Smar Research, “HI 311 HART Serial Interface”

7. http:// www.hartfundation.com

8. http:// www.smarresearch.com

9. http:// www.javasun.com

61
ANEXO 1
HART field communication protocol

An introduction for users and manufacturers


ANEXO 2
Tablas resumen de los comandos

del protocolo Hart


ANEXO 3
Hojas de datos del integrado HT2012
ANEXO 4
Hojas de datos de la interfaz Hart HT311
ANEXO 5
Hojas de datos del integrado AD694
ANEXO 6
Hojas de datos del integrado LTC1298
ANEXO 7
Primer diseño del circuito impreso

Del módem Hart


ANEXO 8
Fragmentos del código de

el microcontrolador
'---------------------------------------------------------------------------
' Variables para la compresión de mensajes ASCII
'---------------------------------------------------------------------------
ARRAY PACKCHAR(25) OF BYTE 'arreglo que contiene el mensaje comprimido
ARRAY UNPACKCHAR(33) OF BYTE 'arreglo que contiene el mensaje sin comprimir
BYTE C
BYTE BIT2220 'diferentes bytes para la compresión de
BYTE BIT0002 'los caracteres o mensajes de texto ASCII
BYTE BIT2200
BYTE BIT0022
BYTE BIT2000
BYTE BIT0222
BYTE BIT0200
BYTE BIT0220
BYTE TEMP
BYTE TEMPA
BYTE M,O,P,R,S,T
BYTE Packet_size
BYTE Unpacket_size ' variable que me da el tamaño de lo que se
BYTE Unpacket_to ' comprime o descomprime.
BYTE Packet_to

'---------------------------------------------------------------------------
'Rutina Principal
'---------------------------------------------------------------------------
TASK MAIN ' inicio de la rutina MAIN
#INCLUDE DEFINE_I.INC ' definicion de simbolos
'---------------------------------------------------------------------------
' Drivers de los dispositivos y parámetros
'---------------------------------------------------------------------------
INSTALL DEVICE #LCD, "LCD1.TDD" ' instala el display (BASIC-Tiger)

' instala el driver serial y fija la tasa de baudios:


INSTALL DEVICE #SER, "SER1.TDD",BD_1_200, DP_8O, JA, BD_1_200, DP_8O, JA
' <-----Ser-Ch-0-----> <-----Ser-Ch-1----->
'---------------------------------------------------------------------------
CALL INIT_KEYB ( LCD ) ' inicializa el teclado con LCD
PRINT #LCD, "<01>"; ' limpia la pantalla
PRINT #LCD, "Flotech S.A. HART" ' salida al Display
'---------------------------------------------------------------------------
' Variables que componen el protocolo HART
'---------------------------------------------------------------------------
BYTE D
D=0

CIF=02h ' codigo de identificación del fabricante


CTDDF=03h ' codigo del tipo de dispositivo del fabricante
PREAMBLE=14h ' numero de bytes del preambulo requeridos
COMMANDREV=05h ' revision de los comandos universales
COMMANDSDREV=04h ' revision de los comandos especificos de dispositivo
SOFTREV=01h ' revision del software
HARDREV=01h ' revision del hardware
BFDD=00100000b ' banderas del funcionamiento del dispositivo
'BIT 0 = si es un dispositivo multisensor
'BIT 1 = si se requiere control por EEPROM
'BIT 2 = si es un dispositivo de puente
NID(0)=25h ' numero de identificacion del dispositivo
PVU=01h ' unidades de la variable primaria
SVU=02h ' unidades de la variable secundaria
TVU=03h ' unidades de la variable terciaria
FVU=04h ' unidades de la cuarta variable
FOR D=0 TO 3
PV(D)=01h ' variable primaria
SV(D)=02h ' variable secundaria
TV(D)=03h ' variable terciaria
FV(D)=04h ' cuarta variable
CURRENTLOOP(D)=05h ' corriente en mA en el lazo
PORRANGO(D)=06h ' porcentaje (mA) en el rango del lazo
NEXT
POLLADD=0Fh ' polling address direccion de "polling"
UIDTAG(0)=45h ' identificador unico asociado al tag
UIDTAG(1)=52h
UIDTAG(2)=49h
UIDTAG(3)=4Bh
UIDTAG(4)=41h
UIDTAG(5)=46h
UIDTAG(6)=45h
UIDTAG(7)=42h

FOR D=0 TO 32
MESAGE(D)=0 ' mensaje de hasta 32 caracteres
NEXT

FOR D=0 TO 16
DESCRIPTOR(D)=0
NEXT

FECHA(0)=01h ' fecha


FECHA(1)=0Bh ' fecha
FECHA(2)=00h ' fecha

' Información específica del sensor


SERIAL(0)=23h
SERIAL(1)=24h ' número serial del sensor
SERIAL(2)=25h

UNITS=0 ' unidades de los límites y el rango


FOR D=0 TO 3
LNS(D)=01h ' límite nivel superior
LNI(D)=02h ' límite nivel inferior
MS(D)=03h 'minimun span
NEXT
' Información de salida
ALARMA=01h ' codigo de seleccion de alarma
TF=01h ' codigo de funcion de transferencia
PVUNITS=04h ' unidades de la PV y del rango
FOR D=0 TO 3
MAXVR(D)=08h ' mayor valor del rango
MINVR(D)=04h ' minimo valor del rango
DAMPV(D)=06h ' damping value en segundos
NEXT
CPE=46h ' codigo de proteccion a escritura
EPD=98h ' etiqueta privada del distribuidor
NFE(0)=00h ' numero de ensamble final
NFE(1)=01h
NFE(2)=02h
'---------------------------------------------------------------------------
' Variables para la compresion de mensajes ASCII

iii
'---------------------------------------------------------------------------
' al hacer la operación And
BIT2220=11111100b ' solo se extraen los 6 bits superiores
BIT0002=00000011b ' solo se extraen los 2 bits inferiores
BIT2200=11110000b ' solo se extraen los 4 bits superiores
BIT0022=00001111b ' solo se extraen los 4 bits inferiores
BIT2000=11000000b ' solo se extraen los 2 bits superiores
BIT0222=00111111b ' solo se extraen los 6 bits inferiores
BIT0200=00110000b ' solo se extraen los 2 bits medio izq
BIT0220=00111100b ' solo se extraen los 4 bits medio

FOR C=0 TO 32 ' inicializacion de los arreglos


UNPACKCHAR(C)=0 ' que comprimen los datos para
NEXT ' ser enviados en ASCII
FOR C=0 TO 24
PACKCHAR(C)=0
NEXT
'----------------------------------------------------------------------------
PERMANENTADDRESS(0)=45h ' 69 en decimal
PERMANENTADDRESS(1)=46h ' 70 en decimal
PERMANENTADDRESS(2)=47h ' 71 en decimal
PERMANENTADDRESS(3)=48h ' 72 en decimal
PERMANENTADDRESS(4)=49h ' 73 en decimal

PERMANENTADDRESSB=45h ' 69 en decimal

RUN TASK MesageReceiver ' llamada a la rutina principal


END ' encargada de recibir los mensajes
' de entrada (comandos del maestro)

'---------------------------------------------------------------------------
' Rutina que recibe el mensaje completo desde el puerto serial
'---------------------------------------------------------------------------

TASK MesageReceiver

DIR_PIN 7,3,0

BYTE D,N,Z,M ' byte que se utilizan como contadores


M=20 ' el preambulo tiene 20 bytes
chek=54 ' inicialización del final del mensaje
N=0 ' inicializacion de los contadores
Z=0
D=0

WHILE Z=0 ' ciclo infinito


begin: ' inicio de la rutina
OUT 7,00000100b,4 ' RTS puesta en 1 para recibir

MesageIn(N)=00h ' inicializo MesageIn


WAIT_DURATION 50 ' espera por el proximo byte

WHILE MesageIn(N)=00h ' mientras no haya entrada


GET #SER,#1,0,MesageIn(N) ' recibe caracteres del puerto

IF N<20 AND MesageIn(N)=0FFh THEN ' si el caracter recibido se encuentra


N=N+1 ' si lo es se pasa al byte siguiente
GOTO begin ' y se recibe el proximo

iv
ELSE

IF N>19 THEN ' si no es FFh pero es mayor que 19


GOTO program ' adelante recibe y analiza el mensaje
ENDIF

MesageIn(N)=00h ' 20 entonces inicializo el mensaje y


N=0 ' el contador y me regreso al pricipio
GOTO begin
ENDIF
ENDWHILE

v
ANEXO 9
Fragmentos del código de

la interfaz gráfica o maestro Hart


// esta es la clase Hart5.java

import javax.swing.*;
import javax.swing.JComponent.*;
import java.awt.*;
import java.awt.Component.*;
import javax.swing.SwingConstants.*;
import javax.swing.plaf.*;
import java.awt.GridBagConstraints.*;
import javax.comm.*;

class Hart5
{
Byte size;
static TextField preambelbytes = new TextField("",20);
static TextField startbyte = new TextField("",20);
static TextField addressbytes = new TextField("",20);
static TextField commandbyte = new TextField("",20);
static TextField bytecountbyte = new TextField("",20);
static TextField databytes = new TextField("",32);
static TextArea mensajeout = new TextArea("",1,50,TextArea.SCROLLBARS_HORIZONTAL_ONLY);
static Choice commandchoice = new Choice();
static TextArea mensajein = new TextArea("",10,50);

public static void main(String a[])


{

//definicion de variables
JFrame f = new JFrame("MASTER TERMINAL");
JPanel p1,p2,p3;

Button borrar = new Button("RESET");


Button salir = new Button("EXIT");
Button enviar = new Button("SEND");
Button ensamble = new Button("COMPONER");

CheckboxGroup grupo = new CheckboxGroup();


Checkbox largo = new Checkbox("Formato Largo",grupo,true);
Checkbox corto = new Checkbox("Formato Corto",grupo,false);

JLabel label1= new JLabel("Partes del mensaje HART:");


JLabel label2= new JLabel("Mensaje Enviado:",JLabel.RIGHT);
JLabel label3= new JLabel("Preambulo:",JLabel.RIGHT);
JLabel label4= new JLabel("Byte de Start:",JLabel.RIGHT);
JLabel label5= new JLabel("Direccion:",JLabel.RIGHT);
JLabel label6= new JLabel("Comando:",JLabel.RIGHT);
JLabel label7= new JLabel("Cuenta de bytes:",JLabel.RIGHT);
JLabel label8= new JLabel("Datos:",JLabel.RIGHT);
JLabel label10= new JLabel("Mensaje del TIGER:");
JLabel label11= new JLabel("Tamaño de dirección:");
JLabel label12= new JLabel(" ");

SerialConnection4 conect = new SerialConnection4(mensajeout,mensajein);

ManejaEventos4 eVentos = new ManejaEventos4(mensajein,mensajeout,

preambelbytes,startbyte,

addressbytes,commandbyte,
bytecountbyte,databytes,

conect,enviar);

ManejadordeSelecion selecion = new ManejadordeSelecion(startbyte,

addressbytes );

ManejadordeComando comando = new ManejadordeComando(commandbyte);

Font letra1 = new Font("Helvetica",Font.BOLD,14);

GridBagLayout gridbag = new GridBagLayout();


GridBagConstraints c = new GridBagConstraints();

commandchoice.addItem("0");
commandchoice.addItem("1");
commandchoice.addItem("2");
commandchoice.addItem("3");
commandchoice.addItem("6");
commandchoice.addItem("11");
commandchoice.addItem("12");
commandchoice.addItem("14");
commandchoice.addItem("15");
commandchoice.addItem("16");
commandchoice.addItem("17");
commandchoice.addItem("18");
commandchoice.addItem("19");
commandchoice.addItemListener(comando);

//crear el panel donde van los botones


p1 = new JPanel();
p1.setBackground(Color.blue);
p1.setFont(letra1);
p1.add(borrar);
p1.add(salir);
p1.add(enviar);
p1.add(ensamble);

//crear el panel donde van los campos del mensaje


p2 = new JPanel();
p2.setLayout(gridbag);
preambelbytes.setEditable(false);
bytecountbyte.setEditable(false);
startbyte.setEditable(false);
mensajeout.setEditable(false);
commandbyte.setEditable(false);

c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label3,c);
p2.add(label3);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(preambelbytes, c);
p2.add(preambelbytes);

iii
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label4, c);
p2.add(label4);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(startbyte,c);
p2.add(startbyte);

c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE;
gridbag.setConstraints(label11,c);
p2.add(label11);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(largo,c);
p2.add(largo);

c.gridwidth = GridBagConstraints.RELATIVE;
gridbag.setConstraints(label12,c);
p2.add(label12);

c.gridwidth = GridBagConstraints.REMAINDER; //end row


gridbag.setConstraints(corto,c);
p2.add(corto);

c.fill=GridBagConstraints.NONE;
c.weightx = 0.0;
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label5, c);
p2.add(label5);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(addressbytes , c);
p2.add(addressbytes );

c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label6, c);
p2.add(label6);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(commandbyte , c);
//p2.add(commandbyte );

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(commandchoice , c);
p2.add(commandchoice );

c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label7, c);

iv
p2.add(label7);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(bytecountbyte , c);
p2.add(bytecountbyte );

c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label8, c);
p2.add(label8);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(databytes , c);
p2.add(databytes );
/**
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label2, c);
p2.add(label2);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(mensajeout, c);
p2.add(mensajeout);
*/
c.anchor=GridBagConstraints.EAST;
c.gridwidth = GridBagConstraints.RELATIVE; //next-to-last in row
gridbag.setConstraints(label10, c);
p2.add(label10);

c.anchor=GridBagConstraints.WEST;
c.gridwidth = GridBagConstraints.REMAINDER; //end row
gridbag.setConstraints(mensajein, c);
p2.add(mensajein);

ensamble.addActionListener(eVentos);
borrar.addActionListener(eVentos);
enviar.addActionListener(eVentos);
salir.addActionListener(eVentos);
largo.addItemListener(selecion);
corto.addItemListener(selecion);

//agregar el panel al frame


f.getContentPane().add("North",p2);
f.getContentPane().add("South",p1);

//reduce la pantallita al tamaño de los objetos


f.pack();

conect.openConnection();

//hace visible el panel llamado primero


f.setVisible(true);
}

Вам также может понравиться